[clean-list] parsing ambiguity

[Arjen van Weelden]

Hi,

Jigang Sun wrote:
> Please have a look at the following grammar extracted from language report v2.1
> 
> Application = {BrackGraph}+
>     | GraphExpr Operator GraphExpr
> (the above rule could be left factorized as 
> Application = {BrackGraph}+ {Operator GraphExpr})
> 
> 
> Operator = FunctionName // see A.7
>     | ConstructorName // see A.7
> 
> FunctionName = LowerCaseId | UpperCaseId | FunnyId
> ConstructorName = UpperCaseId | FunnyId
> 
> BrackGraph = GraphVariable
>     | Constructor
> 
> GraphVariable = Variable
> Variable = LowerCaseId
> 
> My questions are:
> 
> 1. in the Operator rule, FunctionName and ConstructorName are overlapping, for example FunnyId could be parsed as both FunctionName and ConstructorName.

In contrast to Haskell, Clean allows infix operators that are not
funnyIds, it allows function/operator names that start with an
uppercase, and it allows constructor names are funnyIds. A funnyId can
indeed be parsed as a function and as a constructor, it all depends
whether the identifier was declared as a function of as a constructor.
For example:

:: MyList a = $ | ($:$) infixr 1 a (MyList a)

(MyFunction) $ $ = True
(MyFunction) (x $:$ xs) (y $:$ ys)
	= x == y && xs MyFunction ys

> 2. first of BrackGraph and Operator could be the same kind of token, for example LowerCaseId.

It is probably written like this to make clear that operators (whether
defined as a function or constructor) should have two arguments, unless
you put parenthesis around it to make it a prefix function. The grammar
is by no means minimal or even precise.

> Any idears?

Try to take the language report a little less seriously. The Clean
people put a lot more effort in the compiler than the language report.

> Thanks a lot.
> 
> Jigang
> _______________________________________________
> clean-list mailing list
> clean-list at science.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/clean-list

kind regards,
	Arjen