FW: Modular syntax, and the Refactoring Browser (was Re: [squeak-dev] smalltalk evolution)

> From: Frank Shearar <[hidden email]>
> Reply-To: The general-purpose Squeak developers list
> <[hidden email]>
> Date: Thu, 2 Jun 2011 08:42:12 +0100
> To: The general-purpose Squeak developers list
> <[hidden email]>
> Subject: Modular syntax, and the Refactoring Browser (was Re: [squeak-dev]
> smalltalk evolution)
>
> On 2 June 2011 01:46, Casey Ransberger <[hidden email]> wrote:
>> So the #(static array literals) have been very useful to me due mostly to
>> their compactness.
>> I recently had a big dictionary of dictionaries of of dictionaries of... and
>> it was convenient to recursively grab the storeString. But if I just
>> #storeString'd it, the string was big enough to make the compiler choke. I
>> ended up recursively sending asArray, and then grabbing static array
>> literals (this was in a Cuis image.) This was a *much* more compact
>> representation of the object in question, and the compiler took to it
>> handily.
>> At first, I felt the same way that you feel about the static array literals
>> about the dynamic array literals; I didn't have any reference point for the
>> syntax, it looked odd, and reminded me only of dotted pairs in Lisp... which
>> isn't exactly the most recognizable idiom in the world.
>> Over time, though, the sheer utility of the dynamic arrays changed my mind.
>> I still like having the static arrays for symbolic processing, though.
>> If you really have a great desire to remove the static array literal syntax,
>> I will offer one piece of advice: find a way to let people have their cake
>> and eat it too. Wouldn't it be cool if our literals could be loaded and
>> unloaded as easily as changing a hat? I think you might even start seeing
>> more experimentation with new literal syntaxen.
>> It's that old mathematician's trick: if you can find a way to solve the more
>> general problem, you can eliminate a bunch of subproblems in one stroke.
>> Why not investigate making Squeak's syntax more modular? :)
>
> Yes, indeed! And, in fact, someone has put a lot of work into that
> very task recently, namely Lukas Renggli's thesis. LanguageBoxes [1]
> promises to allow the extension and composition of grammars with
> configurable scope - you may scope an extension per-method, per-class,
> per-package or per-image. Lukas gives an example of embedding SQLite's
> syntax into Smalltalk's... and then embedding Smalltalk literals
> within SQLite's grammar. (Yes, I also think the example's crazy - and
> that's why it's a _good_ example, showing what one can do.)
>
> TANSTAAFL kicks in here though: Pharo's moved on from when Lukas wrote
> his work, so LanguageBoxes (and Helvetia, on which it's based) no
> longer load, even into Pharo 1.1 images, for which Helvetia was
> written. So in my task list I've put a plan of action for making
> LanguageBoxes useful once again, namely splitting its packages into a
> core, with Pharo and Squeak extension packages. It's a big job, so if
> anyone else is interested, I'd be happy to share the workload :)
>
> I don't propose we include LanguageBoxes into Trunk - it's too big a
> chunk of code - but I would like to make it easy for language
> experimenters to use Squeak to experiment, and so having LanguageBoxes
> be able to plug into Trunk.
>
> One of the things on which LanguageBoxes depends is the RB AST tree.
> We've seen talk every now and then of bringing RB back into the image.
> Eliot proposed that someone fix up Browser's dependence on indices
> and, in return, would integrate RB back into the Browser.
>
> It seems to me (and I haven't looked at the differences between
> Squeak's AST and RB's) that we could win big by switching the ASTs we
> use?
>
> frank
>
> [1] http://scg.unibe.ch/research/helvetia
>
>> 2011/5/31 [hidden email] <[hidden email]>
>>>
>>> What's current state of squeak evolution?
>>>
>>> I do get the idea of squeak as independent-smalltalk,
>>> which CAN evolve without being fully compatible with the rest of st world
>>> (which is IMHO the only way to deliver better language)
>>>
>>> I've read few dozens of interesting proposals in here
>>> (like prototypes and dropping array literals)
>>>
>>> And while both being pretty interesting I would really like
>>> to see smalltalk with [1 . 2 . 3] asArray syntax instead of ugly
>>> and IMHO useless #(1 2 3)
>>>
>>> Syntax should be further discussed, yes, at least because [1, 2, 3]
>>> looks much better, but what's the chance of adopting something like this?
>>>
>>> What's the chance of saying: "guys, we made mistake, #(1 2 3) have really
>>> no advantage over blocks (except of performance), so let's drop it, let's
>>> simplify the language, let's make it even easier to learn for newcomers."
>>>
>>> Is something like this "part of plan"? Or is really the "make a new fork
>>> if
>>> you consider it useful" the only way to go?
>>>
>>> Because writing meta-program for transforming existing code shouldn't be
>>> so hard. Also "dropping" something could be just part of "changelog", even
>>> with
>>> appropriate convertor for legacy code. And I doubt that new fork could
>>> make it
>>> through without massive marketing. Even squeak is poorly known.
>>>
>>> Please do not take it as offense, ST is one of best languages I've ever
>>> encountered,
>>> but every language can be even better, and we should try.
>>>
>>
>>
>>
>> --
>> Casey Ransberger
>>
>>
>>
>>
>