[m-rev.] for review: better error messages for lambda exprs

[Julien Fischer]

Hi Mark,

On Tue, 17 May 2016, Mark Brown wrote:

> On Tue, May 17, 2016 at 10:10 AM, Julien Fischer <jfischer at opturion.com> wrote:
>>
>> On Tue, 17 May 2016, Mark Brown wrote:
>>
>>>> +    ; Name = "or"                   % goal
>>>> +    ; Name = "and"                  % goal
>>>> +    ; Name = "try"                  % goal
>>>> +    ; Name = "@"                    % goal
>>>> +    ; Name = "true"                 % goal
>>>> +    ; Name = "fail"                 % goal
>>>
>>>
>>> Okay.
>>
>>
>> "or" and "and" are both currently used as predicate / function
>> names by the bool module.
>
> Yes, but there can be module based exceptions for such things.

I would prefer to avoid that kind of thing if possible.

> For the builtin types, you're probably right: there's generally not
> much potential for a parser to get confused by names that are not
> operators.

Another alternative would be to not restrict the use of the primitive
type names at all, but treat them as being "defined" by the builtin
module (i.e. so the usual module qualification mechanisms could be used
to resolve any ambiguities.)

> For >> and =< you're also probably right: with the other
> keywords in place, we should always be able to tell whether we're
> trying to parse an inst or mode.
>
> I'm trying to come up with a good set of rules that will tell us what
> should be a keyword. Something more concrete than just saying it's
> hard to produce good errors.
>
>>
>>>> +    ; Name = "with_type"            % goal
>>
>>
>> I'd be happy to (eventually) remove "with_type" in favour
>> of ":".
>>
>>>> +    ; Name = "with_inst"            % goal
>>>
>>>
>>> I'd rather deprecate these as significant.
>>
>>
>> What do you mean by that?  (There isn't a replacment
>> for "with_inst" is there?)
>
> No, but weren't we going to come up with one? Can '::' be used?

With the current operator table, you'd either always have to
parenthesize it, for example:

     :- pred (foo(T) :: bar).

rather than:

     :- pred foo(T) :: bar.

or modify the parser to allow '::' as the top-level functor in a pred or
func decl.  (I'm not sure what unintended consequences the latter may
have.)

Julien.