

Froskell: Haskell with unlockable features for teaching programming - bontoJR
https://secure.plaimi.net/papers/2015-01-16-froskell-programming-language.html

======
Someone
I am not sure the "unlockable" features idea is a good one.

Firstly, that seems to imply that students will first learn what "simple error
message" means, and later, when they make the same mistake, get shown
"gobbledygook gook gook". Why would they spend time learning that new message,
if, for all they know, a few lessons on, the same mistake may produce yet
another error message?

Secondly, the good student may generalize from the subject of a lesson (for
example because they may have experience with another language), guess at
advanced syntax and try it out, and hurt their nose because their language
doesn't _yet_ support the feature.

I would think that the only good way forward is to spend time improving the
error messages in the full language. Possibly, that requires redesigning the
language (for example, having if...fi, do...od, and while...wend may be
superior to using braces everywhere)

Yes, that is hard work. In many languages, writing a parser that accepts valid
programs is way easier than writing a parser that gives meaningful error
messages and recovers from errors in the to be parsed code well.

If you have that, maybe, labeling parts of error messages as 'irrelevant for
this lesson' by graying them out might help, but I think you should present
all possible causes of parse errors up front.

[aside: from the title alone, I guessed this was a game where achievements
allowed you to buy language features: "your next task is to draw a Pythagorean
tree. You have 367 coins. You can buy recursive function calls for 100 coins,
Unicode emoji output for 150, floating point arithmetic for 250, or
goniometric functions for 200?"]

~~~
TheLoneWolfling
Agreed on all parts, give or take. An addition: I don't see how one could
suppress error messages relating to features that haven't been unlocked
without causing program validity itself to be dependent on what features you
have unlocked. Either that or have programs that don't have any observable
error messages but still don't work. And that's a _nasty_ side effect.

Note that a recursive-descent parser is actually probably the best approach
for this. They have the combination of being simple and relatively easy to
generate relevant error messages and recover from errors that you often don't
get with other parsers.

The classic shortfall of a recursive-descent parser (exponential-time worst
case complexity) doesn't generally apply to this sort of thing, as generally
the programs are relatively short.

------
TheLoneWolfling
I would find this sort of thing infuriating. Every time you learn a syntax, it
gets replaced by another? Your error messages depend on how far along you are?
Worse: program correctness depends on how far along you are? Good luck going
to a TA with that one...

Also, it's shooting yourself in the foot w.r.t. those people who come into the
program already knowing something. Driving away the advanced people isn't the
best thing in the world.

As an aside, that first example pretty much sums up why I don't like Haskell.
Not the error message, but that it doesn't work in the first place.

It's too bad, because I know I'm kind of shooting myself in the foot. But
first impressions leave a mark.

------
brudgers
The idea of a progression of "Student Languages" with reduced features, better
error messages, and a supporting IDE is exactly what the PLT Group provides in
the form of Racket. The only "features" it lacks are a monetization strategy
in general and one that sounds like in-app-purchases in particular and the IDE
running online (Racket's DrRacket is a stand-alone desktop application, but
runs natively on Windows, OSX, and *nix including with native UI as
applicable).

It has good documentation to boot. And in my opinion that's one of the truly
critical factors for a pedagogical language. YMMV.

------
rwl
I don't know if the authors of this proposal are here, but I wonder if they
have heard of Elm: [http://elm-lang.org/](http://elm-lang.org/)

If they are not completely married to Haskell, they might consider using Elm
instead. Why? Like Haskell, it's a functional language in the ML family. It
already has a browser-based IDE, and has a lot of built-in features that make
it well-suited to writing the kinds of programs beginners might be interested
in, like games.

Starting with Elm, the authors would be a lot closer to their goals; they
could focus on just implementing the concept of "unlockable" features in the
existing Elm IDE.

~~~
vezzy-fnord
_Like Haskell, it 's a functional language in the ML family._

Haskell isn't in the ML family. It's a successor to the concepts used in David
Turner's languages (but more specifically Miranda), themselves born out of a
language named Hope that came out nearly the same time as ML.

