[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