Bijan Parsia bparsia@email.unc.edu wrote:
At 10:55 PM -0400 8/11/99, Lex Spoon wrote:
Well, it's certainly open to discussion :) I'd think it best to count the first indent as just part of method definition. So to get a block inside a method, you'd have to add *another* indentation, like this:
myMethod | x y z | x := 1 y := 2 z := 3
Blargh! That's gross! Imagine the errors! You can't *tell*, without a comment, whether this is a misindentation or a block. *Silent*, *SEMANTIC* errors due to copy and paste are evil. Python doesn't have *that* problem.
Well, I'm sure people would get real careful with how far they indent. And we'd get real good at reading it, too, so long as we don't read source code from *other* smalltalks. When indentation has a lot of significance, it should be as easy to mis-indent as it would to accidentally place a BEGIN keyword in the middle of somewhere: possible but not common.
In fact, it's surely easier for an author to notice an extra tab floating around, than it is for them to notice an extra [ tossed in somewhere.
This syntax also works out fine for storing a block into a variable:
myMethod | b x y | b := x := 1 y := 2 ^b
It doesn't *look* real nice, but the fact that it's different is surely a big contributor.
However big a contributer it may be, it's contribution is *totally* swamped by the contribution of the intrinsic butt-ugliness of it :) Ugh. Espeically with the caret making the "b"s visually misalign!
Heheh, well, okay. Can't really argue with you there. :)
Lex
In fact, it's surely easier for an author to notice an extra tab floating around, than it is for them to notice an extra [ tossed in somewhere.
This syntax also works out fine for storing a block into a variable:
myMethod | b x y | b := x := 1 y := 2 ^bIt doesn't *look* real nice, but the fact that it's different is surely a big contributor.
However big a contributer it may be, it's contribution is *totally* swamped by the contribution of the intrinsic butt-ugliness of it :) Ugh. Espeically with the caret making the "b"s visually misalign!
Heheh, well, okay. Can't really argue with you there. :)
Lex
Why use indentation to MEAN something? Indentation based languages are horrid, and hard to read. Besides, whats wrong with [] for blocks? I'll keep delimiters over tabs anyday. Modula-3 code is hard to read in large programs, because you have to keep visually lining up the indents. At least in C, I can count {'s and }'s and test nesting.
About the whole assignment speil, I think whats needed is way of specifying 'self' without typing it, like a special character, or way of denoting a function. That would be short, and sweet.
Is the apostrophe used? so, instead of "self foo" we can say "`foo", or some other perhaps more noticeable symbol...
And simple accessors? Always include them, even if they don't do anything but return or access inst vars. A good SmallTalk compiler will always inline anyways, and thuse no need to worry about the extra message sends. You may need to change them in the future anyways. By including them from the start, you won't have to go through an object, and change every occurence of 'a :=' to 'self a:'. It's bitten me on the rear a few times.
And if its too hard to type 4 extra chars for 'self', well, there is a point were efficency becomes laziness. I mean, CS people are lazy, but THAT lazy?
:)
Daniel Joyce
And simple accessors? Always include them, even if they don't do anything but return or access inst vars. A good SmallTalk compiler will always inline anyways, and thuse no need to worry about the extra message sends. You may need to change them in the future anyways. By including them from the start, you won't have to go through an object, and change every occurence of 'a :=' to 'self a:'. It's bitten me on the rear a few times.
I just did that in a fairly extensive piece of code recently. The exercise took less than fifteen minutes, and wasn't error-prone at all, thanks to the browser's facility for creating a browser for "defs of inst var." I simply went down the list, made the changes and had solid working code for the revisions in virtually no time at all. In comparison, it takes about that same amount of time to actually create all those accessors at the outset of the code, and is disruptive if I have to write new accessors on an "as you go" basis.
While I haven't been hacking Smalltalk seriously for more than a year or so now, this is only the first time I have had to do it. On a cost/benefit scale, I don't think this "bitten me on the rear" issue weighs terribly heavily.
On the other hand, I don't think any amount of evangelizing on the virtues of "always using accessors" will make a hog's breath of difference until the "optimization" and "automation" is actually accomplished by the compiler and the creation of accessors is automated. People simply won't choose a textually longer, more difficult approach that runs almost twice as slowly over a more textually straightforward process that requires no human overhead for creating all those accessors.
If using accessors is truly desired as a matter of course, I think someone need to take the assignment away from us expressly, perhaps dropping it into a primitive as has been suggested by some.
From: "Andrew C. Greenberg" werdna@gate.net
On the other hand, I don't think any amount of evangelizing on the virtues of "always using accessors" will make a hog's breath of difference until the "optimization" and "automation" is actually accomplished by the compiler and the creation of accessors is automated. People simply won't choose a textually longer, more difficult approach that runs almost twice as slowly over a more textually straightforward process that requires no human overhead for creating all those accessors.
That was the essence of my proposal: (a) let the most straightforward syntax mean message passing, (b) let that be optimized away by the compiler and (c) allow it to work without the (c.I) hassle or (c.II) non-privacy of *having* to define accessor-methods (that doesn't mean that you can't define accessors).
Marcel
At 1:05 AM -0400 8/14/99, Lex Spoon wrote:
Bijan Parsia bparsia@email.unc.edu wrote:
At 10:55 PM -0400 8/11/99, Lex Spoon wrote:
Well, it's certainly open to discussion :) I'd think it best to count the first indent as just part of method definition. So to get a block inside a method, you'd have to add *another* indentation, like this:
myMethod | x y z | x := 1 y := 2 z := 3
Blargh! That's gross! Imagine the errors! You can't *tell*, without a comment, whether this is a misindentation or a block. *Silent*, *SEMANTIC* errors due to copy and paste are evil. Python doesn't have *that* problem.
Well, I'm sure people would get real careful with how far they indent.
No, the problem is if this is *someone else's* code, or old code of mine and I can't *remember* what I wanted to do. I can't look at the code and *be sure* that it's intended to be a block. And the compiler couldn't help me.
And we'd get real good at reading it, too, so long as we don't read source code from *other* smalltalks. When indentation has a lot of significance, it should be as easy to mis-indent as it would to accidentally place a BEGIN keyword in the middle of somewhere: possible but not common.
But a misplaced BEGIN is syntactically incorrect, and can be caught by the compiler. The error I'm pointed out is *semantic* and *can't* be caught by the compiler. One thing that makes Python work is that a misindentation *standardly* causes a syntax error.
And geez! You want people to be real careful? To *have* to be real careful? Eek.
In fact, it's surely easier for an author to notice an extra tab floating around, than it is for them to notice an extra [ tossed in somewhere.
Not when My Friend the Compiler puts a little arrow and some text saying, "You bonehead! don't you think ye old right bracket here would be a good idea?"
Give that we aren't working in a text editor, but have the power of parse based pretty print, I don't see why we need to mess with the syntax to get what you want.
Oh, for a *neat* way of "eliminating" the brackets etc. you do need to check out Golgi the outliner, which is still floating around, I think. (Though I haven't heard from Michael in a while. Michael! You still out there?) It allowed you to use and outliner in a code pane, and the little line handles were semantically significant (i.e., the handle for the temp declaration was a |, for a block it was a [, but you didn't have to type the characters, and you didn't have to close them).
Cheers, Bijan.
Wow, lots of "sound and fury ...".
Here's one of the original notations I proposed for Smalltalk-71-2, but which never got implemented. The idea was that you could use open and close parens if you wanted, but if you alternatively wished to "indent and line up" you <cr>ed before you closed the paren and the left one would be converted into a "gray line" (on a one bit map screen it would alternate black and white dots vertically to appear gray). This vertical line was the height of the leading so it would connect up with the indent at the same level on subsequent lines. Each new <cr> would continue the vertical line. Typing a right paren would terminate this indenting level. The basic observation here was that we would be working on a computer after all, and hence really didn't have to imitate the typewriter slavishly. The computer should be able to create formats that really work for reading that might not have anything to do with long strings of text ...
Another observation and suggestion. Observation: Squeak/Smalltalk is not likely to spread to "the millions" unless it has a readable and inviting look to it. And "the millions" here includes other programmers. The two syntaxes most likely to succeed are "C-like" (which I just couldn't abide), or "scriptlike" (which could actually work). I don't think Python is a very good syntax for OOP, but good scripting syntaxes for real OOP languages have been done (c.f. CodeWorks). Suggestion: turn all the energy worrying about formatting Smalltalk-80 conventions into good ideas for making real OOP inviting to look at and we can make these happen right from the parse tree ....
Cheers to all,
Alan
Alan Kay said:
Suggestion: turn all the energy worrying about formatting
Smalltalk-80
conventions into good ideas for making real OOP inviting to look at and we can make these happen right from the parse tree ....
OK, let me throw in a couple of artifacts that I come across everyday for perusal.
1. Dave Winer's Frontier, which uses an outliner for scripting in UserTalk, and has a certain 'look'.
http://www.scripting.com/frontier/snippets/nerdsguide.html (scroll down to see editor)
http://frontier.userland.com/ (general)
(actually Frontier may be of interest to the Squeak community wrt. the way it deals with being a hot system. Guest Databases, Suites, etc. )
2. Haskell, which has an offside rule (or something ;-)
http://www.haskell.org/tutorial/patterns.html#sect4.6 (more layout up the page)
http://www.haskell.org/ (general, inc language definition)
I know that the Haskell community has recently been debating the implementation of the indent-rule, saying that it was much too complicated.
Cheers, Toby
At 12:55 PM -0400 8/14/99, Toby Watson wrote:
Alan Kay said:
Suggestion: turn all the energy worrying about formattingSmalltalk-80
conventions into good ideas for making real OOP inviting to look at and we can make these happen right from the parse tree ....
OK, let me throw in a couple of artifacts that I come across everyday for perusal.
- Dave Winer's Frontier, which uses an outliner for scripting in UserTalk,
and has a certain 'look'.
http://www.scripting.com/frontier/snippets/nerdsguide.html (scroll down to see editor)
http://frontier.userland.com/ (general)
(actually Frontier may be of interest to the Squeak community wrt. the way it deals with being a hot system. Guest Databases, Suites, etc. )
Michael Starke's Golgi in fact was inspired by Frontier and implements (in an alpha way) outlining code panes in Squeak, with the added advantage that the outline widgets are semantically significant.
Cheers, Bijan Parsia.
Bijan --
I thought Michal Starke's Golgi was a very nice start. Michal, where are you? We haven't heard from you about Golgi for a while. Have you tried the next step in Golgi?
Cheers,
Alan
------
At 6:54 AM -0800 8/15/99, Bijan Parsia wrote:
At 12:55 PM -0400 8/14/99, Toby Watson wrote:
Alan Kay said:
Suggestion: turn all the energy worrying about formattingSmalltalk-80
conventions into good ideas for making real OOP inviting to look at and we can make these happen right from the parse tree ....
OK, let me throw in a couple of artifacts that I come across everyday for perusal.
- Dave Winer's Frontier, which uses an outliner for scripting in UserTalk,
and has a certain 'look'.
http://www.scripting.com/frontier/snippets/nerdsguide.html (scroll down to see editor)
http://frontier.userland.com/ (general)
(actually Frontier may be of interest to the Squeak community wrt. the way it deals with being a hot system. Guest Databases, Suites, etc. )
Michael Starke's Golgi in fact was inspired by Frontier and implements (in an alpha way) outlining code panes in Squeak, with the added advantage that the outline widgets are semantically significant.
Cheers, Bijan Parsia.
On Aug 15, 1999, Alan Kay wrote:
I thought Michal Starke's Golgi was a very nice start. Michal, where are you? We haven't heard from you about
On the road somewhere between Bulgaria and Turkey at the time you wrote this ;-). Been far away from computers for a long time. Nice to see those msgs while catching up on a summer's worth of emails!
I've been using and steadily improving Golgi as an outline editor during the last year, and it works beautifully for my current 6000+ headers/notes. It's getting pretty solid, and I'll put another version up next week when i find time to package it.
On the code-editor aspect, less progress. Partly because I came to have the feeling of working against the system rather than with it, so I decided to pause.
[The trouble was in part that it was not a good idea to adapt the standard browser (it relies to much on having a string as a model). I'll thus restart a browser from scratch. But I haven't yet found a UI for the method/class/category part that I would really like to implement.]
good scripting syntaxes for real OOP languages have been done (c.f. CodeWorks)
care to elaborate on that (for those of us who know nothing about CodeWork)?
michal
Hi All,
Being a big proponent of outliners, excited by the idea of a Frontier like editor for Squeak and inspired by SyntaxMorph(thanks Bob!), I put together the beginnings of an outline-based code editor. I've been working with extending ObjectExplorer(thanks again Bob!). My first, quick and dirty approach was to subclass ListItemWrapper, overriding the contents method in the same way ObjectExplorerWrapper does. Not surprisingly that's not a very flexible approach. It expects that all nodes displayed will be homogeneous. So I changed ObjectExplorerWrapper contents to:
^ item getChildNodes
Then I implemented the behavior of the original ObjectExplorerWrapper>>contents as a method of Object named getChildNodes. ObjectExplorer works as it did before except that now any class can determine its appearance in an Explorer by overriding getChildNodes. I've never spent much time in the Compiler related classes, but looking at SyntaxMorph their behavior, relationship and structure came into focus so I started implementing getChildNodes for some of the ParseNode subclasses. If you evaluate the following:
| tree source | source _ (MessageNode compiledMethodAt: #asMorphicSyntax:) getSourceFromFile. tree _ Compiler new parse: source in: SyntaxMorph notifying: nil. tree explore.
you'll get an Explorer that *shows* a method as an outline the way Frontier works. Aside from making the nodes editable, there are many things that should/could be done from here. For starters:
1. Get rid of the curly braces! 2. Have AssignmentNodes display the reciever with the statement as a child 3. Implement SytaxMorph like popups 4. Add comments to ballon help
Comments, suggestions? Any Compiler savvy folks want to pitch in here?
Regards, -Laurence Bijan Parsia wrote:
At 12:55 PM -0400 8/14/99, Toby Watson wrote:
Alan Kay said:
Suggestion: turn all the energy worrying about formattingSmalltalk-80
conventions into good ideas for making real OOP inviting to look at and we can make these happen right from the parse tree ....
OK, let me throw in a couple of artifacts that I come across everyday for perusal.
- Dave Winer's Frontier, which uses an outliner for scripting in UserTalk,
and has a certain 'look'.
http://www.scripting.com/frontier/snippets/nerdsguide.html (scroll down to see editor)
http://frontier.userland.com/ (general)
(actually Frontier may be of interest to the Squeak community wrt. the way it deals with being a hot system. Guest Databases, Suites, etc. )
Michael Starke's Golgi in fact was inspired by Frontier and implements (in an alpha way) outlining code panes in Squeak, with the added advantage that the outline widgets are semantically significant.
Cheers, Bijan Parsia.
'From Squeak 2.5 of August 6, 1999 on 19 August 1999 at 9:43:08 am'!
!Object methodsFor: 'Outlining' stamp: 'LPR 8/19/1999 00:50'! canBeDragged ^ false! !
!Object methodsFor: 'Outlining' stamp: 'LPR 8/19/1999 00:53'! contents ^ self getChildNodes! !
!Object methodsFor: 'Outlining' stamp: 'LPR 8/18/1999 04:37'! getChildNodes | answer | answer _ OrderedCollection new. self class allInstVarNames asArray doWithIndex: [:each :index | answer add: (ObjectExplorerWrapper with: (self instVarAt: index) name: each model: self)]. 1 to: self basicSize do: [:index | answer add: (ObjectExplorerWrapper with: (self basicAt: index) name: index printString model: self)]. ^ answer! !
!Object methodsFor: 'Outlining' stamp: 'LPR 8/19/1999 00:55'! handlesMouseOver: evt ^ false! !
!Object methodsFor: 'Outlining' stamp: 'LPR 8/18/1999 18:06'! hasContents ^ self hasContentsInExplorer! !
!Object methodsFor: 'Outlining' stamp: 'LPR 8/18/1999 18:09'! preferredColor ^ nil! !
!BlockNode methodsFor: 'Outlining' stamp: 'LPR 8/19/1999 09:42'! getChildNodes ^statements! !
!MessageNode methodsFor: 'Outlining' stamp: 'LPR 8/19/1999 08:48'! getChildNodes "was taken from asMorphicSyntax: originally" | theChildNodes keywords prev arg thisKey | theChildNodes _ OrderedCollection new. special > 0 ifTrue: [arguments size = 0 ifTrue: [^ theChildNodes]. keywords _ selector key keywords. prev _ receiver. 1 to: keywords size do: [:part | arg _ arguments at: part. thisKey _ keywords at: part. (prev isMemberOf: BlockNode) | ((prev isMemberOf: MessageNode) and: [prev precedence >= 3]) | ((arg isMemberOf: BlockNode) and: [arg isComplex and: [thisKey ~= #do:]]) | (arguments size > 2) | (selector key = #ifTrue:ifFalse:) ifTrue: [theChildNodes add: arg]]]. ^theChildNodes! !
!MethodNode methodsFor: 'outlining' stamp: 'LPR 8/18/1999 18:02'! getChildNodes
^block statements! !
!ObjectExplorerWrapper methodsFor: 'as yet unclassified' stamp: 'LPR 8/18/1999 04:39'! contents " | answer | answer _ OrderedCollection new. item class allInstVarNames asArray doWithIndex: [:each :index | answer add: (ObjectExplorerWrapper with: (item instVarAt: index) name: each model: item)]. 1 to: item basicSize do: [:index | answer add: (ObjectExplorerWrapper with: (item basicAt: index) name: index printString model: item)]. ^ answer" ^ item getChildNodes! !
From: Alan Kay Alan.Kay@disney.com
Suggestion: turn all the energy worrying about formatting
Smalltalk-80
conventions into good ideas for making real OOP inviting to look
at and we
can make these happen right from the parse tree ....
My idea was to do something like this in small steps. Starting with where we are right now, look at places that are causing problems and change them, always keeping the overall goal in mind. Observe how the change works and repeat as necessary.
However, suggestions of small, incremental changes always seem to elicit *exactly* two reactions. The 'conservatives' complain about any change whatsoever whereas 'progressives' aren't satisfied with so small a change and want to redesign everything, preferably mitching and matching cncepts from as many languages 'du jour' as possible. Even more interesting, the hue and cry from the 'conservatives' seems to be the same for big changes as for small changes, suggesting that few radical changes are actually an effective measure for negative-feedback-minimization.
:-)))
Marcel
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andrew C. Greenberg -
Bijan Parsia -
Daniel Allan Joyce -
Laurence Rozier -
Lex Spoon -
Marcel Weiher -
michalstarke -
Toby Watson