regular, non-syntax parameters

[gelisam]

It would be weird for the language to have syntax parameters (#105) but not regular parameters.

The API could look like this:

makeParameter : a -> IO (Param a) 
readParameter : Param a -> IO a 
parameterize : Param a -> a -> IO b -> IO b 

We also discussed writeParameter, but I'd rather not support that. I would prefer to provide IORefs separately, and then users can define a Param (IORef a) if they want a mutable parameter.

We also discussed whether IO was the right effect type. We don't have a lot of effect types right now, so IO is the obvious choice right now, but in the future it might be nice to separate our effects into smaller bins.

We even discussed using Identity, that is, to allow parameters as an ambient effect, but we'd first have to convince ourselves that parameters can't break our guarantee that the order in which tasks are scheduled doesn't affect which code is generated nor which types are inferred.

[gelisam]

I'm not a big fan of the name, because it's too easily confused with parameters-vs-arguments, but I guess the name is too standard to change...

Although, if the audience is Haskellers, maybe ReaderRef, hinting to the fact that they behave as if we had one Reader for each parameter?

[gelisam]

We discussed the following implementation strategy.

While the macro expander and the tasks system runs in the Expand monad, once a piece of syntax is fully-expanded into a piece of Core, we execute this Core expression in the Eval monad, outside of the tasks system. That monad simply has a mapping of variables to values, as by that point all the scoping issues have been resolved.

It would thus suffice to add another Reader effect to Eval holding the values of the reader-refs.

[gelisam]

Darn, "reader ref" will be super confusing for users who come from Racket rather than Haskell, because it will remind them of reader macros! Is there a name which will be clear to both communities?

[gelisam]

Would "ReaderParam" be clear to both or confusing to both?

[gelisam]

Maybe PVar for parameters and SVar for syntax parameters? Users from both communities will have to read the documentation in order to learn what they're about, but after that, the P or S will help Racketeers remember which is which.