2017-11-10 12:08 GMT+01:00 Sven Van Caekenberghe
<sven@stfx.eu>:
> On 10 Nov 2017, at 11:59, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
>
> My proposition was to force methodBody closing to be on first column,
> and disambiguate potential method conflicts by forcing a more transparent white space.
>
> Maybe we can force the white space only on conflicting lines that would begin with a ].
> Most methods are indented (and even formatted) so the conflict should be extremely rare.
> It could happen though with multiple line literal string
>
> ^'
> [
> something went wrong here
> ]
> '
>
> If first column trick is not acceptable, then we will indeed come up with more visible escape sequences.
But don't you think that it would be weird to insert extra whitespace and not remove it (under the assumption that it does not matter), because is string constants like in your example, you would actually change code !
And yes, we are discussing a very rare case.
But as you showed, simplifying #methodBody is really important.
Indeed, in some well known case, a literal would be modified bewteen Pharo and Tonel which would be rare but weird...
Currently, Tonel does not have to change the syntax at all.
The first goals are:
- we should prefer a syntax agnostic format for two reasons
* not insulting the future and supporting alternate syntax extensions (compilerClass)
* making the parsing both robust and efficient (not necessary to use a RB parser for a quick scan)
- we don't want too many decorations that would make the Tonel syntax look different from Pharo syntax
If we also want to support human edited Tonel files:
- we want something resilient (not be too much picky about a missing leading space for example)
- we want the most simple rules and least surprising rules
The first two goals look really antagonist...
There are other possibilities: if we don't want to change the methodBody at all, then let's change the opening/closing sequence
- at write, choose a closing sequence that has no exact match in source code, then use the inverse sequence as the opening sequence
- at read, just scan for the inverse of opening sequence
opening sequence could be any combination of [{<(
or maybe just a single [ repeated as many times as necessary