[m-dev.] EDCGs
Ralph Becket
rbeck at microsoft.com
Mon Dec 20 21:06:00 AEDT 1999
My tuppeny'orth: I like the revised presentation on EDCGs (modulo the
restrictions). But I have to say I found the example code quite hard
to follow. As I see it, one of the key reasons why one would use
Mercury is that it is declarative, which can be read as meaning that
each `statement' can be interpreted without reference to its context.
This is why we frown on destructive assignment and, in particular, global
variables in imperative languages. The down-side is that, in Prolog-
style syntax, one ends up supplying many intermediate value names
(Foo0, Foo1, ..., Foo) which can make code hard to read, particularly
in predicates with many in-out argument pairs. DCGs bend the rules a
little, but are simple enough that it's fairly easy to see what's
going on and, thanks to { } escaping, where the DCG args aren't passed.
In EDCGs, however, the only clue one has as to which arguments get
passed to which predicates is to go and look at the `htype' and `hmode'
declarations for each the predicates concerned. For my money, this is
almost as bad as having explicit global variables.
I just want to throw an old idea of mine back into the melting pot again
(Richard O'Keefe really didn't like this one, but...) The suggestion was
not to hide the extra variables at all, but to solve the problem of having
to come up with lots of intermediary names. Basically, if one sees a
`primed' variable X` then it may be referred to subsequently
(i.e. "lexically later") as just X. There would be the obvious tie-up
rules for variables in the head. So one would write
main(IO, IO`) :-
io__write_string("Hello, World!", IO, IO`),
io__nl(IO, IO`).
The idea of "lexically later" is nothing particularly strange, being part
of DCG expansion as it is. If people are interested and don't think this
is *too* horrible then I can write up the expansion rules for consideration.
Cheers,
Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list