Modular syntax, and the Refactoring Browser (was Re: [squeak-dev] smalltalk evolution)
Locked
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 > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |