Thanks for your reply...
Paul Hudak
case expr of C f -> ... V (Variable (VVariable s)) -> ... ...
I think you mean:
case expr of C f -> ... V (VVariable s) -> ...
which is not quite as verbose.
Yes, I think I should have checked my examples more carefully.
I don't think that the problem is as bad as you make it out to be. If you adopt my use of short constructor names, then something like:
(snip)
Well, my example wasn't very good, and is quite a bit simpler than the actual application I'm developing. I think I will take your advice on shorter names, however. To give you an idea of the kind of code I'm ending up with, here's a construction from my program: Variable (VVariable(varName, (Value (Number (NNumber (varValue, varDimension)))))) Here VVariable and NNumber are newtype constructors of tuples, and the entire expression is an "Expression" which, among other things has: data Expression = Value Value | Variable Variable | ... and Value has "data Value = Number Number | ..." Now the newtype constructors seem a bit unnecessary, perhaps, but I guess they increase the type-checking. So I still feel that the above construtor is overly verbose.
On the other hand, there are much deeper issues at play here regarding the representation of a language with variables as a data type.
The reference you gave on "higher-order abstract syntax" may be quite useful. I have also been looking over your paper on using Haskell as an Embedded DSL, which is extremely appealing for my application. I'm attempting to synthesize all of this into a coherent game plan...
What I did in my book was very simple, and the use of variables was only given as an exercise (by the way, you left out the "Let" constructor, which presuambly has the form "Let String Expr").
Yes indeed. I guess I should have tried compiling my example. I have the urge to post my solution to that exercise just so you know I did it right :-) I'm about to post an SOE question separately. peace, Isaac