1c) TGen There is a port of a independant Lexer/Parser-Generator framework to Squeak called TGen. Search for the reference on: http://minnow.cc.gatech.edu/squeak (currently down)
1d) Programming Lab of the University of Brussels A researcher of the programming lab of the University of Brussels seems also to be working this area. Search for "Vrije Universiteit Brussel" in the mailing list archive and check what he is doing. He also maintains a Swiki-Web (I dont' have the URL at hand)
hmm, I guess I am that researcher (together with some other people at our lab) :) We have declarative languages running over Smalltalk code, so we needed parsers for these languages. For (what used to be) my language, I used the ParserGenerator. The reason is that this is a tool from another Smalltalk Environment (VisualWorks) in which I originally developed my stuff. I ported it to Squeak, but I am still waiting for an answer of the legal department whether I can release the port to the Squeak community or not (the departure of Cincom's VisualWorks responsible for Europe did not speed up this process...). The second option (which we are investigating now) is to use TGen. It seems to have some benefits over the ParserGenerator, but we are still investigating it.
- Little Languages
The second part of my question is "What's the ST way of dealing with little languages. Do you just build editors/inspectors instead?"
I don't understand the question exactly. A utterance in a "little language" in this context is a sequence of characters. The lexer/parser builds a tree of objects. With the inspectors you can look at any node of the tree and ask the object to do something. Very convenient when developing.
I was wondering about the question too. First of all, I do not know what you mean by 'little language'. Do you mean that it is not very different of Smalltalk's synta ? Do you mean it is something *very* simple ? Second, 'Do you just build editors/inspectors instead', I was wondering: 'instead of what' ?
-- Roel Wuyts Programming Technology Lab rwuyts@vub.ac.be Vrije Universiteit Brussel http://prog.vub.ac.be/~rwuyts Webmaster of European Smalltalk User Group: www.esug.org
On Tue, Aug 01, 2000 at 03:08:06PM +0200, Roel Wuyts wrote:
- Little Languages
The second part of my question is "What's the ST way of dealing with little languages. Do you just build editors/inspectors instead?"
I don't understand the question exactly. A utterance in a "little language" in this context is a sequence of characters. The lexer/parser builds a tree of objects. With the inspectors you can look at any node of the tree and ask the object to do something. Very convenient when developing.
I was wondering about the question too. First of all, I do not know what you mean by 'little language'. Do you mean that it is not very different of Smalltalk's synta ? Do you mean it is something *very* simple ? Second, 'Do you just build editors/inspectors instead', I was wondering: 'instead of what' ?
I'll add one thing to this, just because it's so obvious that it might be overlooked: Smalltalk is itself a perfectly serviceable "little language" in many cases. If you have a few carefully named classes and methods, that might be all that is required.
If you need something fancier, and are familiar with lex/yacc, then T-gen is what you're looking for.
Roel Wuyts wrote: [Chris Wright wrote]
- Little Languages
The second part of my question is "What's the ST way of dealing with little languages. Do you just build editors/inspectors instead?"
I don't understand the question exactly. A utterance in a "little language" in this context is a sequence of characters. The lexer/parser builds a tree of objects. With the inspectors you can look at any node of the tree and ask the object to do something. Very convenient when developing.
I was wondering about the question too. First of all, I do not know what you mean by 'little language'. Do you mean that it is not very different of Smalltalk's synta ? Do you mean it is something *very* simple ? Second, 'Do you just build editors/inspectors instead', I was wondering: 'instead of what' ?
By a 'little language' I meant an end-user language that is pretty domain specific. Typically syntactically trivial, and typically imperative in style (There was a period of enlightment when they were often Forth like...but that's a different story!). They are now often written by embedding Tcl, Guile, or for the enlightened, Python into applications.
Well, I guess I was wondering how those who live in the Smalltalk environment and deliver products in ST deal with the issue of "little languages". The LISP community sometimes defines LISP as a language in which you write the language to solve your particular problem, and I was wondering if the ST culture was a little different in this area. Perhaps the notion of a "new" language isn't relevant...Perhaps the ST way is to deliver objects that have the intended functionality, and allow end users to configure those objects with editors, rather than have the end user write code.
Thanks to all those who have replied. It's a very helpful community.
cheers
Chris
Dr. Chris Wright Deputy Director, Intensive Care Unit Monash Medical Centre Clayton, VIC AUSTRALIA
Well, I guess I was wondering how those who live in the Smalltalk environment and deliver products in ST deal with the issue of "little languages". ... Perhaps the notion of a "new" language isn't relevant...Perhaps the ST way is to deliver objects that have the intended functionality, and allow end users to configure those objects with editors, rather than have the end user write code.
Chris,
I'd suggest skipping your own syntax for now, and instead use Smalltalk's own to come as close to the one you "really" want. Smalltalk's "keyword syntax" will get you a long way, because it is far more suitable for this than in languages where you only get to choose a name for the procedure.
In fact, "little languages" was a concern of the Smalltalk designers, and the keyword syntax was what they came to regard as the best general-purpose solution to this--the earlier, greater flexibility (of "Smalltalk-72") was considered more complex than necessary.
An imagined script language statement like
draw string "hello" in window w at position x, y using font myFont at 12 points
(or something) would in procedure-style languages be restrained to
drawstring("hello", x, y, myFont, 12, window)
whereas here you can define your own methods like
window drawString: 'hello' atPosition: x@y withFont: font size: 12
By using the keyword syntax you could start solving your 'core' problem without writing any parser. Then, when that is done, you may have a better answer for the question above; you could back and do the syntax if you still think you need it. A long time ago I realized in hindsight that I could have saved myself the whole work of parsing true SQL syntax in this way, since it became clear afterward that the syntax was not essential to solving the problem.
Henrik
squeak-dev@lists.squeakfoundation.org
-
Chris Wright -
David T. Lewis -
Henrik Gedenryd -
Roel Wuyts