Maude-help mailing list

[Francisco Duran <duran AT lcc.uma.es>]

Hi,

I agree with Steven, in your case the best solution should be putting 
Fun and Token in different CCs.

From my experience, however, I'd add to Steven's comments that in 
general things get simpler if we distinguish between the syntax (the 
grammar with which parsing) and the internal representation (used for 
manipulating the inputs and doing reductions). In the current release 
and if we someday have more powerful parsing capabilities.

You use reduce in your examples, but if your goal is providing an 
environment for Erlang, you will someday want to use LOOP-MODE, 
metaParse, and metaPrettyPrint. Assuming there is no ambiguity, from 
parsing with metaParse something like
  token / token = token
in SYNTAX you'd get a term
  '_=_['_/_['token.Token, 'token.Token], 'token.Token]
You can then use this term with metaReduce, or transform it as wished. 
Once you get it reduced, you use metaPrettyPrint to give the result back 
nicely.

It looks however like you have the semantics of Fun and Token when 
defining the module SYNTAX, and you are trying to use the same module in 
the three stages. However, SYNTAX should care about syntax, and not 
about the logical internal representation. Consider distinguishing the 
syntax, let's say in a module SYNTAX2, and the internal representation, 
in a module INTERNAL-REPRESENTATION.

mod SYNTAX2 is
        sorts Token Fun Att Def Exp .
        subsort Token Fun < Exp .

        op token : -> Token .
        op _/_ : Token Token -> Fun .
        
        op _/_=_ : Token Token Exp -> Def [format (b b b o)] .
        op _=_ : Token Exp -> Att [format (r r r o)] .

        sort NeDefList .
        subsort Def < NeDefList .
        op _,_ : Def Def -> NeDefList .
endm

Notice the change, the term above now parses without ambiguity, as
  '_/_=_['token.Token, 'token.Token, 'token.Token]

The internal representation may be completely different, consider

mod INTERNAL-REPRESENTATION is
        sorts Token Fun Att Def Exp .
        subsort Token Fun < Exp .

        op token : -> Token .
        op _/_ : Token Token -> Fun .
        
        op _=d_ : Fun Exp -> Def [format (b b b o)] .
        op _=a_ : Token Exp -> Att [format (r r r o)] .

        sort NeDefList .
        subsort Def < NeDefList .
        op _,_ : Def Def -> NeDefList .
endm

The term
  '_/_=_['token.Token, 'token.Token, 'token.Token]
can by converted to
  '_=d_['_/_['token.Token, 'token.Token], 'token.Token]
and used in metaReduce with INTERNAL-REPRESENTATION. You can then 
convert the term back to the syntax in SYNTAX2 and use metaPrettyPrint 
to show the result in the syntax known by the user.

I hope this helps.

Francisco Duran



Steven Eker wrote:

> Hi,
>
> The reason that ad hoc overloading is not allowed between operators
> with the same arity kinds but different coarity kinds is precisely in
> order to ensure unique, unambiguous meta-term representations -
> otherwise meta-programming becomes very painful because when
> constructing a new meta-term you would have to ensure there was
> enought context for disambiguation.
>
> The current release version of Maude quietly allows you to break this
> rule at the object level because there is a full context free parser,
> and any ambiguities are discovered and reported. This has caused much
> confusion with users wondering while code that was accepted at the
> object level fails at the metalevel so future releases will complain
> about illegal overloading - the next version of Core Maude is actually
> ready but is being held up until the use of illegal overloading is
> removed from Full Maude.
>
> You might think that subsort information should be used to
> disambiguate your first example, but in fact it is important that
> terms such as 1 / X:Rat which can only be sorted at the kind level are
> parsed by the context free parser, so context free parsing is done on
> kinds rather than sorts.
>
> The are a number of problems with getting Maude to parse the concrete
> syntax of another language. I don't have any good solutions; some
> people use preprocessing scripts. In your example, I would be inclined
> to put Fun and Token in different classes.
>
> Ultimately we plan to have something like ASF+SDF's parsing but
> integrating this nicely with Maude features, especially the metalevel,
> is challenging.
>
> Best regards,
>
> Steven Eker
>
> _______________________________________________
> Maude-help mailing list
> Maude-help AT maude.cs.uiuc.edu
> http://maude.cs.uiuc.edu/cgi-bin/mailman/listinfo/maude-help