[m-dev.] Re: Visual vs total arity clash example [fwd]

[Peter Schachte]

This is part of a reply I sent directly to Peter, but I thought it was
worth stirring up the whole group a little.

-- 
Peter Schachte                     Any sufficiently advanced technology is
mailto:schachte at cs.mu.OZ.AU        indistinguishable from a rigged demo.
http://www.cs.mu.oz.au/~schachte/      -- Andy Finkel, computer guy 
PGP: finger schachte at 128.250.37.3  


----- Forwarded message from Peter Schachte <schachte at cs.mu.oz.au> -----

I would argue that (unlike DCGs) there's no reason to allow users to
write EDCG clauses fully expanded.  Firstly, everything that can be
done by writing clauses directly can also be done with EDCG syntax, so
there's no need.  Secondly, doing this requires that users understand
how many arguments are added and in which order for each hidden
variable, and also what order the variables are added.  (I sure hope
you put the variables in some canonical order, eg alphabetically
sorted, rather than using the order provided.  There's no reason to
force users list these things in the right order when they list the
hiddens that a predicate handles.  Hiddens should be a set, not a
list.)  Yes, this can all be explained, and it's not terribly
difficult, but I see no reasons for users to have to understand these
complications.  More importantly, by explaining them, you lock
yourself into one implementation strategy when there may be better
approaches.

Finally, there's very little benefit to allowing users to write
expanded clauses, at least compared to the cost.  Can you give a
realistic example of a clause that's somehow better written already
expanded?  Remember, the cost is that you have to understand how EDGs
will be expanded in order to know whether two predicates in the same
module with the same name and different arities conflict.


Here's another idea for avoiding this problem:  put each EDCG
predicate/function in an 'EDCG' submodule of its proper module, and
export it from this module to the parent module.  That way:

1)  Misguided souls who understand the EDCG translation could write
    EDCG clauses directly by just putting them in the 'EDCG'
    submodule.

2)  Other misguided souls who want to write calls to EDCG predicates
    specifying all hidden arguments explicitly can do so.  If there's
    an arity conflict with a non-EDCG predicate, it may be handled by
    the standard overloading mechanism, but if that's not sufficient
    they can overcome it by explicitly module-qualifying the call.

3)  For everybody else, it just works.  "Visual arity" is *the* arity.

Actually, this isn't quite right because, eg, a predicate p/2 with 2
hidden arguments still conflicts with p/3 with 1 hidden argument.  So
the full solution is to have a separate submodule for each visual
arity.  In this example, 'EDCG2' and 'EDCG3'.

I'd still argue against documenting how the translation works, but if
you want to document that, at least with this scheme you can avoid
mysterious arity conflicts and still let misguided users do their own
hand translations.


-- 
Peter Schachte                     Any sufficiently advanced technology is
mailto:schachte at cs.mu.OZ.AU        indistinguishable from a rigged demo.
http://www.cs.mu.oz.au/~schachte/      -- Andy Finkel, computer guy 
PGP: finger schachte at 128.250.37.3  

----- End forwarded message -----
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------