Adding state example for Koka #2
Conversation
| @@ -0,0 +1,5 @@ | |||
| # Assuming the Koka folder is a peer of effects-rosetta-stone | |||
| KOKA ?= ../../../../koka/out/debug/koka-0.9.0-dev | |||
There was a problem hiding this comment.
This is a bad assumption. A better assumption is that koka is in the path, so I would just say koka here. If it's not in the path, it will be passed to the Makefile from the outer environment.
There was a problem hiding this comment.
I see. However, if one just installs koka and runs jake, it currently only builds koka-0.9.0-dev, so the user then needs to make koka an alias or something? Should I change koka's build to create a plain koka executable too?
|
|
||
| // We define first a state handler using functions. | ||
| // But you would never do this in practice in Koka! -- | ||
| // use a parameterised handler instead: see `fun state` for that. |
There was a problem hiding this comment.
Yes yes, we know that, and we will have a separate example to point this out. It's still worth having a comment explaining there's another way in Koka.
| get() | ||
| } | ||
|
|
||
| // Here we use a paremeterised handler with a local state `st` |
There was a problem hiding this comment.
From here onwards the code should be moved to a separate example which is exactly like this example but it uses parameterized handlers. See #3 for discussion on creating such an example.
There was a problem hiding this comment.
I disagree. We should be comparing idiomatic code from each language. The idiomatic version of simple state in Koka and Links uses parameterised handlers. The idiomatic version of simple state in Frank uses shallow handlers. The description of the example should be flexible enough (and perhaps updated) in order to accommodate different idioms. I think it is more valuable to highlight the differences in features between languages rather than stressing the lowest common denominator.
There was a problem hiding this comment.
There should be multiple examples: idiomatic usage, as well as trying to impose the same structure in multiple languages, with a careful readme that helps the reader navigate through them.
You well know that one learns much by trying to faithfully express one collection of abstractions using another ;).
There was a problem hiding this comment.
That certainly makes sense sometimes, but the idiomatic version should be the primary one. Daan did include the crippled version in Koka too. For Frank it is simply not possible to express the Eff version because Frank does not have deep handlers (and I'm sure the same issue will crop up with other languages and features).
There was a problem hiding this comment.
Great! Then there should be a description of Frank's inability to do so with deep handlers. This kind of comparison is exactly the kind of examples and non examples this repo is for.
Similarly, there should be a corresponding shallow handler example in effect demonstrating how awkward it is in Eff.
There was a problem hiding this comment.
You misunderstand. There is absolutely a place for the kind of commentary you describe. But, placing each minor variant of state in a different directory (rather than in the same file, as @daanx did), is too fine a level of granularity for my taste. More generally, if we are too fussy then people won't bother submitting any examples. I think it would be better to err on the side of accepting mildly ill-formed examples rather than rejecting them and then losing the goodwill of the submitters. We can always curate them and add further commentary after the fact.
There was a problem hiding this comment.
Not different directory, but different example files all grouped under the same 'state' directory.
There was a problem hiding this comment.
@slindley has a point: too fina a granularity is cumbersome. However, we should ensure that code gets compared, rather than just demonstrated. It's the Rosetta stone after all. How about this: if there are several natural ways of implementing an effect, they should all be collected under the same example and compared.
There was a problem hiding this comment.
Maybe following the example of Rosettacode might be useful here? They seem to allow for having a few different implementations per language, if the different versions help demonstrate the interesting qualities of the language.
There was a problem hiding this comment.
I agree with @slindley here: for each example problem, first provide the idiomatic version, and then, if applicable, also provide another approach. When I am looking to compare, I would like to see the idiomatic versions first, not crippled ones just for the sake of emulating other approaches.
(This also helps language designers: otherwise we need at least 2 versions for each example, shallow for Frank and deep for Koka.)
I think it is better to provide higher level challenge problems instead of requiring the exact same language features. For example, do an example with producer/consumer where Frank can shine with shallow handlers + multi handlers, where Koka would need to get by in some other way; that is really interesting to compare from my perspective.
Anyway, just my 2c, I am already very grateful that this repository is set up.
| } | ||
|
|
||
| fun main() { | ||
| example1a().println |
There was a problem hiding this comment.
Is it necessary to print things? If we can get Koka toplevel to just show us the values of computed examples, it might be better not to print. Printing is an effect, and so in a sense it pollutes the example.
5 participants
Thanks Andrej