representation getting verbose...
22 Oct 2002 12:19:09 -0400
Thanks for your reply...
Paul Hudak <email@example.com> writes:
> > 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:
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 =
| 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
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.