When compiling the declaration:

f(0, 0) = f(0)

CodeWorld produces a bizarre error message:

Couldn't match type Number with (Number, Number)
Expected type: integer-gmp:GHC.Integer.Type.Integer
               -> (Number, Number)
  Actual type: integer-gmp:GHC.Integer.Type.Integer -> Number
In the first argument of f, namely (0)
In the expression: f (0)
In an equation for f: f (0, 0) = f (0)

Eww! GHC appears to be talking about the type of the implied fromInteger function, which is inserted by the RebindaleSyntax language extension.

A pattern match failure looks pretty awful:

P02419H-LTUMYgT3m0AtqgQ==.hs:3:1-31: Non-exhaustive patterns in function branch

Two issues here:

1. The hash-based file name wasn't replaced with a friendly version as we do for compile errors.
2. The column range in the srcloc isn't converted into a link as we do for compiler errors.

Both should be happening. This probably means moving all post-processing of compiler messages to the client, but that's fine.

The tutorial help should be much more elaborate. It should include:

1. A sequence of lessons, to introduce students gradually to the capabilities of the system.
2. Exercises to do along the way.

We could support programmatic generation of sound by using a function Number -> Number (time to amplitude sample). The sampling frequency would need to be FAR higher than the animation frequency, so we'd batch it and use a buffer.

Problems:

• The JavaScript audio API doesn't work with Internet Explorer (possibly other browsers).

• Performance would be a challenge, and we need to make sure this can be done efficiently to avoid stuttering, even on slow computers.

• It's not clear how to merge this into games. The obvious way would be

  audibleInteractionOf(initial, step, event, draw, sound)

But this ties the audio sample rate to the frame rate, which is bad. Another way would be to maintain a different World type for sound, but this is too complicated. Definitely could use some thought.

• We'd need a reasonable kind of abstraction that doesn't involve new ADTs with complicated behaviors. Working directly with wave forms might be an educational experience for a bit, but it shouldn't be unreasonably hard to just choose a timbre and play a melody.

Simple refactoring like "extract definition", "rename", etc. would be helpful.

Additional operations should be added to combine shapes:

intersection :: [Picture] -> Picture
difference :: Picture -> Picture -> Picture

(Names are debatable.) intersection should produce a picture bounded by the intersection of the list. The second should produce a picture containing all areas of the first image that are not also in the second. Note that together with the existing pictures, this gives the three basic operations for constructive geometry.

The implementation is a little tricky. Combining two images in this way can be done with globalCompositeOperation (https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html) But getting the resulting shapes to nest correctly will involve using off-screen canvases as temporaries. Since creating a new off-screen canvas is expensive, this should involve determining the minimum number of offscreen canvases needed, and reusing them between frames.

It's very useful to be able to superimpose a coordinate plane onto the image. To facilitate this, predefine a "coordinatePlane" symbol, which is the the axes and coordinate plane, and can be drawn onto the canvas.

If the identity token expires, the server fails to validate it, but the client thinks the token is still valid. At this point, strange things start failing. Even signing out and signing back in does not restore things to a usable state.

In Firefox, this message sometimes appears in the JavaScript console:

TypeError: gapi.auth is undefined

This is most likely a result of a timing problem, where some call that relies on sign-in state is being made before the authentication API is completely loaded.

Rather than requiring everyone have a Google account, there should be other options. Including:

• Creating a username and password for this specific site.
• Log in via something else, such as Facebook

This means we'll need to maintain our own user identifier, and a mapping from various kinds of credentials to the local identifier. Not too hard.

When the user hovers the mouse over a standard library function, we should pop up a tool tip with basic type and documentation for that symbol.

Hi, please try the following code, and experience the truth that in your code yellow indeed is equal to red. I'm quite certain that is real life, it isn't :)

main = animationOf scene
scene t = text $ showBool $ yellow == red
showBool True  = "true"
showBool False = "false"

I couldn't immediately find the Eq instance to fix this myself. I only looked here: https://github.com/google/codeworld/blob/master/codeworld-base/Internal/Color.hs

I've just hard-coded the list of built-in words into JavaScript for syntax highlighting. This duplicates the efforts for auto-complete, and is very likely to get out of date if the prelude is modified in the future. Instead, this should be generated from the output of codeworld-autocomplete just like the auto-complete word list is.

Most likely, both should just use a JavaScript source file that defines the list in a structured format (with type information, etc., for future features... but that can be added when the time comes)

Examples should be more easily browsable in the UI. That might just mean a collapsible section (or sections), a tree structure, a search box... something that's not just a wall of buttons.

Auto-complete on ctrl-space is not very discoverable if you don't know about it. Perhaps, instead of binding to ctrl-space, we should actually pop up auto-complete rather more often?

For an extreme case, we could attempt to pop up auto-complete on every keystroke. Then you'd just basically always work with a list of auto-complete options sitting by the cursor. We'd obviously need to turn off the option to auto-choose unique completions, and there are probably some other things we should do to blacklist certain keys at certain times, so that it's at least possible to dismiss the auto-complete box manually.

We should see try to theme haddock to make the API documentation less busy. Things like instances should be removed. The page structure should be re-organized to remove references to modules (like Prelude). Confusing notation should be removed for fixity declarations (or the entire fixity removed if it can't be phrased in a more friendly way.)

Instead of just listing names, auto-complete should say something more. Ideally, each autocomplete option would have a word in bold, and a little info-block next to it with its type and a one-line description of its meaning.

Right now, auto-complete works against a fixed list of symbols from the standard library. In addition to that, it should look in the current file for things that look like definitions, and add them to the auto-complete list.

For animation, simulation, and game modes: add a debug option, where students can look at how things look at different times, control the speed of motion (slow-motion and pause), and so on.

The debugger wouldn't operate within the rendering of a single frame; just between frames. So this isn't a GHC internals sort of thing; just a JavaScript/UI issue.

The editor should offer auto-complete. Possible sources of auto-complete words:

1. The standard library
2. Occasional parse of the user program for things that look like definitions.

Optionally, auto-complete should look for context, by knowing types, scanning backwards for something that looks like the beginning of an expression, and finding things with an appropriate type to fit in the current cursor location.

Text is spaced very oddly sometimes. This probably has to do with the fact that we're rendering in a 1px font. We should instead render in a larger font, and scale the result down to the desired size.

GHCJS currently runs using the system and user-wide package databases in ~/.ghcjs. This means that updating GHCJS to a new version requires about an hour of downtime while the new GHCJS version is bootstrapped and packages installed.

We should use a sandboxed environment, so that it's possible to rebuild and bootstrap GHCJS, and then copy the environment over in a single operation.

Students should be able to work together on a group project, and see what each other is doing, edit simultaneously, etc.

It's an open question whether this should follow a source control model, or a Google Docs style collaborative editing. The latter would probably be better, given the ease of use and lower required complexity of projects, but it's also harder to build.

There should be some way for students to share their projects with friends, parents, etc. This could involve:

1. Posting to Google+, Facebook, etc., assuming they have an account (for students under 13, this is problematic)
2. Sharing by email (but careful about abuse potential!)
3. Some kind of sharing within the site itself.

I lean away from doing anything too elaborate here, since I would rather integrate with something than reinvent it. The right way forward isn't clear.

The current set of examples is very scary. We should collect short, easy, and clean examples, each with a specific topic. One or two elaborate examples would be fine, but they should be the exception, and moved to the end.

It's currently possible to write a sort of DOS attack against the server by submitting code that's very expensive to compile (or even doesn't terminate, with UndecidableInstances). To fix this, we should set a time limit for the compiler, and kill it after it's run for too long.

All standard library functions should be reworked to use tuples as arguments, rather than currying.

The reason for this is that we want to keep the language as close as possible to mathematics, and in mathematics, it's ubiquitous to model multi-parameter functions as cartesian products and to write them as f(x,y). The idea is to adopt a convention (just like in mathematics) of always writing parentheses in function application.

As a nice side-effect of that notation, the number of situations where parentheses are only needed for negative numbers drops a lot, and the places where it happens are more obviously confusing.

Firefox shows a lot of errors in the JavaScript console, such as:

syntax error listExamples:1
syntax error listProjects:1
not well-formed compile:1

Since these responses are just plain text, it's not really clear what syntax or well-formed-ness condition Firefox is trying to check. Should probably track these down and figure out what they are about.

This does not stop the correct operation of the site.

The web site is poorly designed, from a visual standpoint. It needs some care and attention from someone with decent visual design skills and more experience with web page design.

thikRectangle leaves a corner out of the picture. This is because it's converted into a thickLine, and the underlying canvas doesn't realize it's a closed shape.

Two possibilities for a fix:

1. If the last point is the same as the first in a path, just close it instead of explicitly moving to the last point.
2. Introduce a new primitive for an open polygon, and use that instead of thickLine.

Students should be able to create "library" projects, that give common definitions and can be imported by other projects of theirs. This would be an alternative to copying and pasting definitions between their projects.

There is no haddock-format documentation for most of the API. This should change. Given the target audience, we need extremely high quality documentation, including examples with images of the results, and careful explanations that don't assume prior knowledge of language ideas.

We can do a better job of showing only the auto-complete options that might fit in a certain context. For example, we could look around the current cursor position to see if the user is typing a function call, and if so, look up the type of the function, and only show function names if they might eventually lead to the desired result type.

This would necessarily be a heuristic, since the user is typing the program, so it's guaranteed to not be syntactically correct most of the time; but there's a lot we can do.

Students and teachers should be able to comment on projects. The comments could be attached to the entire project, or a line of code.

For pedagogical reasons, we likely want to rescale the "logical" canvas to (-10, 10) x (-10, 10). This would:

(a) let students reason with smaller numbers that they are more familiar with.
(b) introduce more reasons to use fractions or decimals for precision, which aligns with middle school mathematics.

In picture, animation, and simulation modes, when the user hovers the mouse over the picture, we should render a tool tip with the coordinates of the current point. When the user clicks, we should "pin" the tool tip, leaving a visual pin there, labeled with the coordinates where the mouse click occurred. Clicking a pin should cause it to go away.

In the past, students found this to be an extremely helpful way to plan their drawings.

The standard pattern in CodeWorld is that a program defines a potentially large tree structure, and then traverses it exactly once. Laziness helps here, but the default memoization that Haskell uses for lazy values is unnecessary, and likely results in worse-than-needed memory usage for large scenes.

I should:

1. See if I can gather benchmarking or profiling data to show that this is a real problem.
2. If so, consider possible solutions. For example, pictures could be Church encoded as functions, if the result performed better in benchmarks. Or the recursive constructors could use () -> Picture instead of Picture to prevent memoization of their result.

Hi,

I'm using Chrome and currently getting many errors. My javascript console is telling me that it's simply internal server errors (when I press the run button). Things were working fine with Chrome last night. Was there possibly a redeploy that might have broken things?

Things are working well in Safari though.

-Josh

There's a blank line left when we strip the license from the beginning of sample programs. It's pointless. Kill it.

There should be some guided help flows that show new users around, with arrows pointing to which buttons to click, etc.

Right now, a runtime exception just stops the program, and you have to open the JavaScript console to see the error. This needs to change.

Because we limit the incoming size of requests, trying to save a file with a large undo history can overrun this and fail. The workaround is to copy the buffer, paste into a new buffer, and save that. What a pain!

Need to increase the max size limit, and/or limit the length of undo history to stop this from happening.

Students should be able to import library projects (see #12) from other students.

Currently, TemplateHaskell isn't possible within CodeWorld because we pass --no-native to GHCJS. With Luite's upcoming TH changes, though, this will not suffice. Most likely, the right answer is to build a filter that pre-parses the source file using haskell-src-exts, and then rejects programs which enable TemplateHaskell, and perhaps other dangerous extensions as well.

Add an interactive list comprehension builder that lets students build list comprehensions easily and see sample results as they go.

It's not entirely clear how this should work, but it's an interesting idea.

The auto-complete generator currently finds only variables/functions, and type names. It should also find the constructors for types. This is just a matter of writing the appropriate regular expression.

It would be really cool if students could generate links to install their projects as Android or iOS apps on a phone or tablet. The app would be a web view, wrapped as an application with a set of generated files.

Concerns:

• The set of available events would be much smaller. It may be that we should simplify the event model anyway to include just mouse moves, clicks, and drags.
• iOS might not be possible without the student either jailbreaking or getting a $100 developer license. Android would require enabling third-party apps.

For picture, animation, and simulation modes, add controls for the students to zoom and pan the canvas. Gloss has these, and they are often convenient.

Students should be able to submit projects for public release, which would go into a project browser that other students can see.

Some form of filtering might be needed to make this safe for kids projects. An easy implementation would be a global queue for trusted users to evaluate. A more elaborate answer would know who each child's teacher is, and let them approve it.

It's actually pretty easy to create enough projects that you start to lose track of them all in a flat list. I should add the ability for students to group projects into folders, so they can keep similar or related projects together.