[mercury-users] A thought on state variables and the library

[doug.auclair at logicaltypes.com]

Dear Julien,

Thanks for your reply.  We dialogued:

>>[...]consolidate all sv<foo> and <foo> 
>> module pairs into just one module per type with the predicates 
>> in the sv style. 
>We will eventually do that just that. 

Great.  Any timeframe on the eventuality?  On my point on the note
of multiple modules being confusing for the new user -- of course the
module is clear from its declarations, as you pointed out, but seeing
the options, I, as a new user, immediately opted for module <foo> 
instead of sv<foo> ... experience has shown me that predisposition
was often misplaced.

... on to DCGs:

>> Here I would also like to note that the refman has, as the Melbourne 
>> team views it, inappropriate DCG usage (e.g.: sect 8.1, 10.2, 10.7), 
>section 8.1 is an example of the syntax for lambda expressions that use 
>DCGs, section 10.2 is an example of the syntax for method instance 
>definitions with DCGs. I don't think either should be omitted from 
>the reference manual. (Actually, presumably your objection is just that 
>the example used in both cases is threading the I/O state?) 

Exactly so, sir, especially since code examples using DCGs to thread
io state submitted to these lists by various parties have been universally
condemned.  Perhaps instead use a parser or scanner example for the lambda
expressions and method instance definition examples in the refman, 
because I feel threading io state with DCGs in the refman provide the
reader with the misleading assumption that one uses DCGs to thread
state (even though it is stated elsewhere otherwise, because when
new JRandom user is looking up lambda expressions with io state, they
do not read caveats about sv notation verses DCG notation elsewhere
in the refman).

>>[...] the (Prolog) transition guide (e.g.: sect 3), 
>One could argue that since it is a Prolog transition guide that DCGs at 
>least have an air of familiarity to them; that said it should probably 
>at least mention state variables. 

I think the mood of the maillists have come out strongly against DCGs
for threaded state, so I believe this mood should be communicated to
the new user with something more assertive in the transition guide,
such as:

"Use state variables; do not use DCGs (except for scanners/parsers)"
[and then provide the example using the sv notation]

After all, the chapter heading is "3. Input and output", so I believe it's
setting the new user down the Wrong Path (as defined by the Melbourne
team) if the DCG notation is used over the sv notation.  In my experience,
Prolog users are smart, and can handle such a change without much
fuss, if the ground rules are spelt out clearly at the get-go.


... again, these are points from an outsider, looking in, so I hope you
find them useful.

Sincerely,
Doug Auclair



--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------