help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working around the limitations of SMIE


From: Stefan Monnier
Subject: Re: Working around the limitations of SMIE
Date: Sat, 12 Nov 2022 14:06:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

>>> I am writing a major mode for a little language I am using at
>>> university, and wanted to try using SMIE for indentation and all the
>>> other things.  The issue I find myself confronted with is that functions
>>> are defined as in the following example:
>>>
>>>     func funktion(x : int): float
>>>       x := x * x;
>>>       return x;
>>>     end
>>>
>>> where there is no delimiter between the return type (float), and the
>>> rest of the body (such as "begin" or something like that).
>>
>> How is the separation between the function's return type and the
>> function's body defined?  Is it based on the newline that follows the
>> type, or is the language constrained to have types that are
>> a single identifiers?
>
> The latter.  This is the grammar production:
>
> functionDeclaration: ' func ' identifier '( ' ( parameterDeclaration ( ', '
> parameterDeclaration ) * ) ? ') '
>     ( ': ' typeName ) ? block ' end ' ;

Hmm... so the only "reliable" separator token is the close parenthesis, huh?
I think I'd go with a hack in the lexer which checks if this is "the
close paren of a function definition" and make it include the subsequent
type annotation (if present).  I.e. that new token would cover the whole of

    ')' ( ':' typeName ) ?

Then again, that wouldn't work with the usual handling of parens in SMIE
(IOW, you couldn't rely on syntax tables for them any more) :-(

Maybe instead you can try and make the lexer recognize just ": typeName"
(treating it as a special token) and then tweak the indentation rules so
as to align the subsequent instruction with it.

>>> Another issue I ran into with the above definition is that instructions
>>> are not indented correctly, as the above grammar doesn't express that in
>>> this language doesn't expect a semicolon after an end (just like C
>>> doesn't expect one after a "}").  So the result is that
>>>
>>> instead of:
>>>
>>>   while y >= y1 do
>>>     dummy := zeile(x1, x2, xstep, y);
>>>     y := y - ystep;
>>>   end
>>>   return 0;
>>>
>>> I get:
>>>
>>>   while y >= y1 do
>>>     dummy := zeile(x1, x2, xstep, y);
>>>     y := y - ystep;
>>>   end
>>>     return 0;
>>
>> Based on my experience, I suspect that the simplest solution for this is
>> to make "end" return 2 tokens (the "end" and then a ghost ";").
>
> Funnily enough I had tried this out too, but I must have messed up
> somewhere because the result wasn't what I had intended.

IIRC it's easier to get it not to work than to get it to work, the
"messed up" doesn't carry the right connotation.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]