[Pharo-dev] Encoding method source code in Tonel

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Nov 10 10:11:08 EST 2017


2017-11-10 12:08 GMT+01:00 Sven Van Caekenberghe <sven at 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



> 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen <
> henrik.s.johansen at veloxit.no>:
> > Can a line with a single ] ever at the "right" indentation level?
> > Forcing autoformat at commit is a bit heavy hand, but maybe inserting a
> tab
> > (or 2,3,4 spaces?) would be an ok workaround that doesn't require special
> > decoding when loading the code?
> >
> > Cheers,
> > Henry
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171110/385654fe/attachment-0002.html>


More information about the Pharo-dev mailing list