On 11/10/2017 07:11 AM, Nicolas Cellier wrote:

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...

Tonel is intended to be, I believe:
* For Smalltalk primarily (although there are other languages)
* Be for any Smalltalk dialect (although the first implementation is for Pharo, it is being ported to GemStone, and we intend to port it to VW and VA)
* Be human-readable (some people want to be able to use tools like GitHub to look at diffs and such)
* Be human-editable using normal text editors (important for porting -- sometimes you just have to edit the source before it will load, for instance)

I think that Tonel using [] to enclose the source is a pretty good idea. A proper parser should be able to correctly parse Smalltalk code from any dialect, and it makes it human-readable and human-editable.

However, as has been noted in this thread, it would also be nice to handle non-Smalltalk code. One way to do this (one that was in an earlier proposal but is not currently in Tonel) is to use pure STON for any source code that does not have standard Smalltalk syntax.�� A method like this would look something like:

{ 'category' : 'public',
�� 'source' : 'whatever the source code is, with STON escapes as necessary' }

Regards,
-Martin