Thanks for the feedback!
Andreas Rossberg wrote:
* The definition of environment would be simpler and closer to SICP if
you just said "type env = frame list", with "type frame = value
Frame.map". That would also allow you to reuse some list combinators
for lookup and update.
Changed it over. Stumbled across "withtype" which I needed for the
dependencies.
* The structural comparison with "ValBool true" in eval (case TmIf) is
not valid SML. It only works here because Alice does not yet implement
equality types, but that will change (better use a case). Likewise the
real comparison in apply_primitive_procedure (use Real.==).
I think I got rid of all the comparisons.
* You could take advantage of currying in the cases TmApplication and
TmBegin if you defined eval in curried form.
I'm not sure I follow what the advantages are? Would it require that I
make "env" the first paramater, since it's the same for the map and
foldl functions?
* It does not seem to make sense to define ValClosure to carry a
*list* of terms - you never use it.
I had put that in the last minute as that seems to be what the Scheme
code does. I think Scheme uses it for the function definitions within
other functions. I took it out as it's not in use, but I suppose that
the parser is probably the key to whether it's needed or not.
* If you want to be ML-ish then you could also simplify lambdas and
application to single argument constructions. Instead of variable
arity there, I would probably combine and generalise TmUnit/ValUnit
and TmPair/ValPair to a single TmTuple/ValTuple (or just rely on
currying).
After futzing with the primitives some more, I decided to make the
interpreter more Scheme like.
* In the valueToString function, note that Char.toString does perform
escaping. For symmetry, you might want to do the same for strings (via
String.toString). Also, I'd probably add quotes.
I was having problems along these lines, but I'm not sure I actually got
them worked out. In the meantime, I put it back to the way it was.
* A rather more sophisticated change would be to simplify
apply_primitive_procedure by introducing an auxiliary datatype with
higher-order constructors:
I messed about with the suggestions, but in the end decided that it
would probably be better to just package up all the primitives in a
module, thinking that you could write a different module for whatever
source language you like. In the process, I tried to get the few
primitives I have to act like they do in Scheme (autoconversion,
variable arity for +, weird results for and/or, etc...).
Let should be simple, computationally it is just a combination of
lambda and apply:
let x = e1 in e2 == (fn x => e2)(e1)
So you can copy&paste&specialise the evaluation rules.
I haven't had time to do much along these lines. Strictly speaking, the
evaluator support for let is not in the SICP text - though it is one of
the exercises.
Thanks,
Chris Rathman
_______________________________________________
alice-users mailing list
[email protected]
http://www.ps.uni-sb.de/mailman/listinfo/alice-users
