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

[Julien Fischer]

On Wed, 14 Feb 2007 doug.auclair at logicaltypes.com wrote:

> A few of the previous posts have stated the preference of using
> state variables over DCGs.  This brings to my mind an unrelated
> issue:  many of the modules in the standard library have redundant
> sv<foo> module equivalents.

The sv* module are not redundant; they are intended to smooth the
transition to the state variable friendly argument orderings.  Once
that has been done we can then change the orderings of original 
versions and then delete the sv* versions.  (This has been the
intention since Mercury 0.12 or whenever we originally added them.)

> In my day-to-day usage, I prefer using the sv<foo> module over
> its (Prolog-y?) <foo> version; so I'm thinking, with the current
> emphasis on sv usage, that now is a good time to "cut the chord"
> of Prolog "compatibility" and 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.

> I think this will help the new user, as it reduces the bewildering
> number of module options for a data type (bewildering == "more
> than one", and sometimes the standard library has more than three
> such options) as well as reinforce the sv style and usage.

It's not *that* bewildering - particularly if you read the comments
at the head of any of the sv* modules.

> -----
>
> On that note, I'd like to submit svgraph -- graph has the Prolog-y
> foo(XIn, arg, arg, Xout) style, and also has a very naive (read: inefficient)
> pathing algorithm.  svgraph is in the sv style and adds some alternate
> pathing options.  Under my proprosal above svgraph, svmap, sv<foo>
> would replace graph, map, <foo>, slimming down and unifying the
> standard library under the sv style.

When we do merge the svmap and map modules, to take one example, it will
be under the name map, not svmap; likewise for the other sv* modules.

> -----
>
> 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?)

10.7 should probably be changed.

> 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.

> and the compiler sources use
> DCGs in 28 modules in compiler/ (some is of course appropriate for
> parsing tasks ... but not all), and these uses in manuals and sources
> may mislead some to use DCGs in ways that the Melbourne Mercury
> team dislikes

The use of DCGs for threading the I/O state in the compiler in 28
modules as opposed to the use of state variables in over 300 modules is likely
to mislead?!?  The compiler modules that use DCG syntax for that purpose
are all fairly unused or are parts of components that will probably 
removed in the future (e.g, the robdd interface for the contstraint
based mode analyser).  IMO, there is very little point in anyway spending the
time to change this code to state variables.

> ... which makes it rather confusing receiving criticism for
> DCG usage from a group that publishes manuals using the same DCG
> style in the same situations ... HTH.

I think that the manual is fairly clear on DCGs vs. state variables for
various purposes:

 	(DCG notation is intended for writing parsers and sequence generators
 	in a particular style; in the past it has also been used to thread an
 	implicit state variable, typically the IO state, through code.
 	As a matter of style, we recommend that in future DCG notation be
 	reserved for writing parsers and sequence generators and that state
 	variable syntax be used for passing state threads.)

Julien.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------