smalltalk evolution
Locked
123
123
 
|
Randal wrote to Kamil:
> The more syntax you eliminate, the more you end up with LISP. Maybe you > want LISP... you know where to find it! There are alternatives if you think outside the box. My "underlining syntax" proposal for Neo Smalltalk, for example: http://www.merlintec.com:8080/software/4 -- Jecel |
|
|
In reply to this post by Kamil Tomsik
2011/5/31 [hidden email] <[hidden email]>:
> In short: > > 1.) binary messages make sense only for math. I've never implemented even > one binary message, have you? (for non-math things) > > Why not step further and make dsl for equations? let them live outside of > language. > (with everything common to math world) > Example : / for building file path > 2.) keyword messages with more than 2 arguments are just ugly - they smell > in the "missing another object" way. And 2 arguments are rare too. I would > allow one argument at top. > They are rare anyway... In my experience, the 16 arguments limit, though well founded from Object POV, is limiting interoperability with 3rd party library (LAPACK) and that's just boring. My opinion is that educating is better than just forbiding. We can tolerate exceptions. Anyway, the workarounds we'll build might well be much uglier... dic := Dictionary new. SystemNavigation default allBehaviorsDo: [:e | e selectorsDo: [:s | (dic at: s numArgs ifAbsentPut: [Set new]) add: s]]. dic collect: [:e | e size] -> a Dictionary(0->18320 1->10083 2->3560 3->1331 4->556 5->201 6->88 7->47 8->24 9->4 10->7 11->1 12->3 13->3 14->1 15->1 ) > 3.) unary messages - I would drop them too, and the reason is - I don't > write a lot of "return" code, I give orders, I want actions from my objects. > I don't want another objects on which I can operate (or get another ones, > and again and again). But another syntax sugar for passing "yourself" would > be needed :-/. > > 4.) all of this could result in consistent syntax like: > receiver doSomething: yourself. > receiver doSomething: param. > I'm not convinced it would ease readability. OK, imperative shall be the preferred mode, tell don't ask, but eliminating queries altogether is a bit totalitarian to my taste. I invite you to rewrite a utility library, say Graphics, with this style and come back with the result if you are pleased with it. > this simplification also allows like-english cascade: > receiver doSomething: param, doSomethingElse: anotherParam. > > or multiple receivers (like F-Script): > receiver, anotherReceiver, anotherReceiver doSomething: yourself, > doSomethingElse: param. > > This is not proposal, just my current "state-of-thinking". > Designing a language is a very interesting topic. But a very involved one too. I'd say try it, eat your own dog food and share a posteriori opinions, it will be much more fruitfull. Nicolas > On Tue, 31 May 2011 21:01:24 +0200, Igor Stasenko <[hidden email]> > wrote: > >> 2011/5/31 Kamil Tomsik <[hidden email]>: >>> >>> It's not anti-smalltalk post, >>> it's just a list of smells. (not big ones) >>> >> ehm.. you saying: >> 1. different message types with different precedence -> distraction, >> parentheses >> >> now, just for comparison, count the number of precedence rules in >> another procedural languages. >> in smalltalk there are only 4: unary, binary, keywords, cascade. >> >> I can imagine that we can easily get rid of binary messages.. and >> replace them with keywords, so >> instead of writing: >> a + b. >> one must write: >> a add: b. >> >> but that will lead to much larger number of parens everywhere. >> Keyword syntax should stay. It is most superior form of expression >> known by myself, because if message selector is picked carefully, >> then it tells, what arguments are expected for each keyword, unlike to >> C where function could have 5-10 arguments >> and you have to refer to its source code in order to write down the >> correct arguments to make a function call. >> >>> Smalltalk is great language. >>> >> >> What makes a smalltalk great is not just language, but also >> environment. If you look at it purely from syntax point of view, then >> i'm >> afraid, you don't see a whole image. >> Because without dev tools, it will be not much better than PHP, Ruby >> or Javascript, where you on your own with source code, and have to >> manually navigate through code. > > |
|
|
In reply to this post by Randal L. Schwartz
On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz
<[hidden email]> wrote: >>>>>> "info@tomsik" == info@tomsik cz <[hidden email]> writes: > > info> In short: 1.) binary messages make sense only for math. I've never > info> implemented even one binary message, have you? (for non-math > info> things) > > info> Why not step further and make dsl for equations? let them live > info> outside of language. (with everything common to math world) > > info> 2.) keyword messages with more than 2 arguments are just ugly - > info> they smell in the "missing another object" way. And 2 arguments > info> are rare too. I would allow one argument at top. > > So, you've now eliminated both possible ways of creating a new Point: > > 3 @ 4 > Point x: 3 y: 4 > I'll go few steps further to show big-picture in hypothetical syntax (one-argument closures with argument as implicit receiver, no returns -> CPS) Point new: [x: 3, y: 4, printOn: aStream]. <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, <msgForNew>: <arg>]. concepts: always left-to-right (receiver->message->argument), no parentheses -> uniformity returns: nothing, does something vs. (Point x: 3 y: 4) printOn: aStream. (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. concepts: sometimes left-to-right, depending on parentheses and message-type (syntax) returns: aPoint, which won't be used anyway, because it was printed already. > I wonder what language we would end up with if all of your (even > conflicting) goals were implemented. > > The more syntax you eliminate, the more you end up with LISP. Maybe you > want LISP... you know where to find it! > I'm not saying "let's drop objects", I'm saying "let's simplify language, let's drop unused/misused/bad-in-long-process things" |
|
|
In reply to this post by Nicolas Cellier
Example from my previous reply to Randal for illustration:
Point new: [x: 3, y: 4, printOn: aStream]. Always left-to-right syntax, always one argument, possible multiple receivers and messages, syntax sugar for closures, closure always have only one argument which is also implicit receiver - you can't deny it's at least interesting to think about such kind of uniformity. > Example : / for building file path okay, maybe, still not worth of losing left-to-right > >> 2.) keyword messages with more than 2 arguments are just ugly - they >> smell in the "missing another object" way. And 2 arguments are rare >> too. Iwould allow one argument at top. >> > > They are rare anyway... > In my experience, the 16 arguments limit, though well founded from > Object POV, is limiting interoperability with 3rd party library > (LAPACK) and that's just boring. > My opinion is that educating is better than just forbiding. > We can tolerate exceptions. Anyway, the workarounds we'll build might > well be much uglier... > > dic := Dictionary new. > SystemNavigation default allBehaviorsDo: [:e | > e selectorsDo: [:s | (dic at: s numArgs ifAbsentPut: [Set new]) add: > s]]. > dic collect: [:e | e size] > -> > a Dictionary(0->18320 1->10083 2->3560 3->1331 4->556 5->201 6->88 > 7->47 8->24 9->4 10->7 11->1 12->3 13->3 14->1 15->1 ) > yes, however I think external libraries shouldn't be just "bridged", new library should be designed, in the mood of rest of the language. > >> 3.) unary messages - I would drop them too, and the reason is - I don't >> write a lot of "return" code, I give orders, I want actions from my >> objects. >> I don't want another objects on which I can operate (or get another >> ones, >> and again and again). But another syntax sugar for passing "yourself" >> would >> be needed :-/. >> >> 4.) all of this could result in consistent syntax like: >> receiver doSomething: yourself. >> receiver doSomething: param. >> > > I'm not convinced it would ease readability. > OK, imperative shall be the preferred mode, tell don't ask, but > eliminating queries altogether is a bit totalitarian to my taste. > I invite you to rewrite a utility library, say Graphics, with this > style and come back with the result if you are pleased with it. > Have a look on that illustration on top - imperative while still readable: create new point, with x: 3, y: 4 and print it on given stream. >> this simplification also allows like-english cascade: >> receiver doSomething: param, doSomethingElse: anotherParam. >> >> or multiple receivers (like F-Script): >> receiver, anotherReceiver, anotherReceiver doSomething: yourself, >> doSomethingElse: param. >> >> This is not proposal, just my current "state-of-thinking". >> > > Designing a language is a very interesting topic. But a very involved > one too. > I'd say try it, eat your own dog food and share a posteriori opinions, > it will be much more fruitfull. > > Nicolas I think about it - I was just curious about: 1. if there is any effort to change squeak on language level 2. what do people who already implemented one successful language, think about what I've just written Kamil |
|
|
> I think about it - I was just curious about:
> 1. if there is any effort to change squeak on language level I joining to what Nicolas said: try eating own food. Implement new syntax, implement some library on it. Show results, proving that changing syntax make things less complex, easier to read and understand, and of course easier and faster to implement. Otherwise its just a voice in the desert. > 2. what do people who already implemented one successful language, think > about what I've just written i don't know. Maybe you should ask them instead? Ask perl author(s) or ruby author(s), what they thinking about what you just wrote. (especially Ruby one, which has no formally defined grammar). I would really like to know what they thinking. Seriously & Pun intended. -- Best regards, Igor Stasenko AKA sig. |
|
|
>>>>> "Igor" == Igor Stasenko <[hidden email]> writes:
Igor> I joining to what Nicolas said: try eating own food. Igor> Implement new syntax, implement some library on it. And don't forget to implement the entire toolchain, including debugger. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion |
|
|
Maybe it's time to throw out syntax and "text" based programming all together...
The punctuation is just there to trigger the parser to perform ... and trigger the memory of those "in the know" about: what "did", or "does", or "will" happen.
What if we use spreadsheet cells, or colors, or fonts, or little icons superimposed on the labels (text labels/names for code, data, or other memory artifacts or equipment) to more clearly express visually what is more often hidden in meaning.
Each cell/label can expand to explicitly visually express its connection to time, persistence, mutability, scope, nesting, linking, precedence, execution order, namespace, importance to the individual programmer or importance to society at large, implications of change, and other properties.
Why? For the same reason syntax coloring helps the memory. There's just too little information visually expressed in syntax, a holdover from the early dark days of computing, when every bit & byte was expensive. It's why we vocally speak to each other with much intonation to carry extra meaning and not just speak in monotones. We're in the GUI age now. And I don't mean graphical drag and drop programming or APL special symbols! I mean code entry by typing ... but translated, and stored, with its visual representation of meaning. For example, in such an IDE, one could change the English word with one in another language with the same meaning, but the references and context remain the same, independent of the text of the label, like a spreadsheet cell does.
Simplicity ... through multi-level, collapsable, visual explicitly. - Darius
|
|
|
Yes, I'm pretty sure next big language will continue where Self stopped.
(programming as an experience) Visual programming is much more "direct" than reading & writing. However I'm not sure if we can make useful visual programming language without need for any kind of scripting. On Wed, 01 Jun 2011 00:58:34 +0200, Darius Clarke <[hidden email]> wrote: > Maybe it's time to throw out syntax and "text" based programming all > together... > > The punctuation is just there to trigger the parser to perform ... and > trigger the memory of those "in the know" about: what "did", or "does", > or > "will" happen. > What if we use spreadsheet cells, or colors, or fonts, or little icons > superimposed on the labels (text labels/names for code, data, or other > memory artifacts or equipment) to more clearly express visually what is > more > often hidden in meaning. > > Each cell/label can expand to explicitly visually express its connection > to > time, persistence, mutability, scope, nesting, linking, precedence, > execution order, namespace, importance to the individual programmer or > importance to society at large, implications of change, and other > properties. > > Why? For the same reason syntax coloring helps the memory. There's just > too > little information visually expressed in syntax, a holdover from the > early > dark days of computing, when every bit & byte was expensive. It's why we > vocally speak to each other with much intonation to carry extra meaning > and > not just speak in monotones. We're in the GUI age now. And I don't mean > graphical drag and drop programming or APL special symbols! I mean code > entry by typing ... but translated, and stored, with its visual > representation of meaning. For example, in such an IDE, one could change > the > English word with one in another language with the same meaning, but the > references and context remain the same, independent of the text of the > label, like a spreadsheet cell does. > > Simplicity ... through multi-level, collapsable, visual explicitly. > > - Darius -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
|
|
In reply to this post by Igor Stasenko
On Wed, 01 Jun 2011 00:15:50 +0200, Igor Stasenko <[hidden email]>
wrote: introducing concept itself is not a problem, rewriting/generating libraries will be harder. >> I think about it - I was just curious about: >> 1. if there is any effort to change squeak on language level > > I joining to what Nicolas said: try eating own food. > Implement new syntax, implement some library on it. > Show results, proving that changing syntax make things less complex, > easier to read and understand, > and of course easier and faster to implement. > Otherwise its just a voice in the desert. > >> 2. what do people who already implemented one successful language, think >> about what I've just written > > i don't know. Maybe you should ask them instead? > Ask perl author(s) or ruby author(s), what they thinking about what > you just wrote. > (especially Ruby one, which has no formally defined grammar). > > I would really like to know what they thinking. > Seriously & Pun intended. > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
|
|
In reply to this post by Darius Clarke
>>>>> "Darius" == Darius Clarke <[hidden email]> writes:
Darius> What if we use spreadsheet cells, or colors, or fonts, or little icons Darius> superimposed on the labels (text labels/names for code, data, or other Darius> memory artifacts or equipment) to more clearly express visually what is more Darius> often hidden in meaning. But don't leave out those of us for whom all of that is merely a distraction. I don't grok icons. I hate fontification coloring. If the next big thing is visual programming, I'm outta here. Darius> Why? For the same reason syntax coloring helps the memory. Except for me. It does nothing, except annoy me. Please remember that not *everyone* has "visual" as their lead processing system, and for some of us, it's nearly absent. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion |
|
|
In reply to this post by Kamil Tomsik
[hidden email] wrote:
> In short: > > 1.) binary messages make sense only for math. I've never implemented > even one binary message, have you? (for non-math things) That's not true (the first part. I don't know what you have ever implemented). For instance look for implementors of #=, #==, #>, #>>, #->, #+, #,, #&, #|. This is a nice example of something I have implemented: Text buildWithStyles: ({ #H3 -> (ParagraphStyle named: 'Heading 3'). #b11 -> (CharacterStyle named: 'Blue 11'). #r10b -> (CharacterStyle named: 'Red 10 bold'). #g11i -> (CharacterStyle named: 'Green 11 Italic') } as: Dictionary) contents: [ :builder | builder , 'Starts with no character style. But later gets' < #b11 , ' small and blue' , ' and stays like that. Then' >< #r10b , ' emphasized and inside this,' < #g11i , ' green and italic' > ' for a while. Later' > ' back to Heading 3.' / #H3]. The objectives for this were: - the styles can be crated dynamically, and there's no need to add new selectors for new styles - it is very unobtrusive, the text is reasonably easy to read (much nicer than, for example, rtf or html), especially with Shout. Anyway, even if it were true that binary messages "make sense only for math", that wouldn't be a reason to ban them! Math stuff is useful too! Cheers, Juan Vuletich |
|
|
In reply to this post by Kamil Tomsik
[hidden email] wrote:
> On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz > <[hidden email]> wrote: > >>>>>>> "info@tomsik" == info@tomsik cz <[hidden email]> writes: >> >> info> In short: 1.) binary messages make sense only for math. I've never >> info> implemented even one binary message, have you? (for non-math >> info> things) >> >> info> Why not step further and make dsl for equations? let them live >> info> outside of language. (with everything common to math world) >> >> info> 2.) keyword messages with more than 2 arguments are just ugly - >> info> they smell in the "missing another object" way. And 2 arguments >> info> are rare too. I would allow one argument at top. >> >> So, you've now eliminated both possible ways of creating a new Point: >> >> 3 @ 4 >> Point x: 3 y: 4 >> > > I'll go few steps further to show big-picture in hypothetical syntax > (one-argument closures with argument as implicit receiver, no returns > -> CPS) > > Point new: [x: 3, y: 4, printOn: aStream]. > <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, > <msgForNew>: <arg>]. > concepts: always left-to-right (receiver->message->argument), no > parentheses -> uniformity > returns: nothing, does something So, #new: creates a point without values for x and y... What if I want to only build objects that make sense, meaning that their instance variables must conform to some invariant defined by the class? > vs. > (Point x: 3 y: 4) printOn: aStream. > (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. > concepts: sometimes left-to-right, depending on parentheses and > message-type (syntax) > returns: aPoint, which won't be used anyway, because it was printed > already. Easy choice. This is much nicer. Cheers, Juan Vuletich >> I wonder what language we would end up with if all of your (even >> conflicting) goals were implemented. >> >> The more syntax you eliminate, the more you end up with LISP. Maybe you >> want LISP... you know where to find it! >> > > I'm not saying "let's drop objects", I'm saying "let's simplify > language, let's drop unused/misused/bad-in-long-process things" > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1375 / Virus Database: 1509/3663 - Release Date: 05/27/11 > > |
|
|
In reply to this post by Randal L. Schwartz
Depends on what "visual programming" is.
Visual programming is not (mainly) wysiwyg designer. It's just evolution - from consoles, to browsers and editors, to visual representations of units and whole systems. I've written post about it: http://cztomsik.posterous.com/visual-programming On Wed, 01 Jun 2011 02:50:10 +0200, Randal L. Schwartz <[hidden email]> wrote: >>>>>> "Darius" == Darius Clarke <[hidden email]> writes: > > Darius> What if we use spreadsheet cells, or colors, or fonts, or little > icons > Darius> superimposed on the labels (text labels/names for code, data, or > other > Darius> memory artifacts or equipment) to more clearly express visually > what is more > Darius> often hidden in meaning. > > But don't leave out those of us for whom all of that is merely a > distraction. > > I don't grok icons. I hate fontification coloring. > > If the next big thing is visual programming, I'm outta here. > > Darius> Why? For the same reason syntax coloring helps the memory. > > Except for me. It does nothing, except annoy me. > > Please remember that not *everyone* has "visual" as their lead > processing system, and for some of us, it's nearly absent. > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
|
|
In reply to this post by Juan Vuletich-4
> So, #new: creates a point without values for x and y... What if I want > to only build objects that make sense, meaning that their instance > variables must conform to some invariant defined by the class? > you can't do this even in smalltalk. ...and checking arguments presence is not enough, you would need to check its internal state too - and you shouldn't do that. Best, Kamil |
|
|
In reply to this post by Juan Vuletich-4
Hi all,
If you don't like the Squeak language as it is, all you need to do is to write a new compiler and use it for compiling the methods of your own classes. Many different languages can co-exist in the same image without problems. VW has done it; the methods of some classes were written in SQL when I looked at it several years ago. I've done it when I got rid of the annoying class companion, the metaclass. (Several of my classes shared the same metaclass). The experiment didn't lead where I wanted to go, so I abandoned it. My BabyIDE environment for DCI programming does it by extending Traits with knowledge about the (DCI) Context of the methods. None of it exactly straight forward, but doable. Here are some details if you're interested Most programming languages such as Java are used to specify complete programs. The 'original' of a program is its text form. A compiler translates to a binary form. There is no Smalltalk language in this sense. The 'original' of a program is its binary form as an object structure in the image. The creation of a new class object is done by a process in this image. Usually, this is done by a command in the Browser. The common textual form for defining a new class is a 'doIt'; a statement to be interpreted by the image. The so called Smalltalk language is used to specify methods; one method at the time. The compilation and installation of a method is done by the class; the methods of different classes can be specified in different languages. So, if you really want a different syntax, you can write your own compiler and share it with other people who share your interests. There's no need for an up-front decision and translation of all legacy code. Many interesting experiments could be made this way. --Trygve On 2011.06.01 03:24, Juan Vuletich wrote: [hidden email] wrote: --
Trygve
Reenskaug mailto: [hidden email] Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378
Oslo Tel: (+47) 22 49 57 27 Norway |
|
|
In reply to this post by Kamil Tomsik
On 31 May 2011 22:43, [hidden email] <[hidden email]> wrote:
> Example from my previous reply to Randal for illustration: > > Point new: [x: 3, y: 4, printOn: aStream]. > > Always left-to-right syntax, always one argument, possible multiple > receivers and messages, syntax sugar for closures, closure always have only > one argument which is also implicit receiver - you can't deny it's at least > interesting to think about such kind of uniformity. Absolutely. It's called the lambda calculus. And it's very interesting to work things out using lambda calculus, and figure out the semantics of statements... but would you really want to program in the lambda calculus? Even the textbooks allow multiple parameter functions, with the understanding that \xyz <whatever> is really \x \y \z <curried whatever. frank |
|
|
In reply to this post by Trygve
On 1 June 2011 08:30, Trygve Reenskaug <[hidden email]> wrote:
> Hi all, > If you don't like the Squeak language as it is, all you need to do is to > write a new compiler and use it for compiling the methods of your own > classes. Many different languages can co-exist in the same image without > problems. VW has done it; the methods of some classes were written in SQL > when I looked at it several years ago. I've done it when I got rid of the > annoying class companion, the metaclass. (Several of my classes shared the > same metaclass). The experiment didn't lead where I wanted to go, so I > abandoned it. My BabyIDE environment for DCI programming does it by > extending Traits with knowledge about the (DCI) Context of the methods. None > of it exactly straight forward, but doable. > > Here are some details if you're interested > > Most programming languages such as Java are used to specify complete > programs. The 'original' of a program is its text form. A compiler > translates to a binary form. > > There is no Smalltalk language in this sense. The 'original' of a program is > its binary form as an object structure in the image. The creation of a new > class object is done by a process in this image. Usually, this is done by a > command in the Browser. The common textual form for defining a new class is > a 'doIt'; a statement to be interpreted by the image. The so called > Smalltalk language is used to specify methods; one method at the time. The > compilation and installation of a method is done by the class; the methods > of different classes can be specified in different languages. > > So, if you really want a different syntax, you can write your own compiler > and share it with other people who share your interests. There's no need for > an up-front decision and translation of all legacy code. > > Many interesting experiments could be made this way. Amen. And what I'd like to see Trunk do is enable this kind of experimentation, by providing hooks into the base system, and making things pluggable/modular so that (a) you can actually run the experiment - by swapping out a Compiler, for instance - and (b) you don't have to hack on the Squeak platform itself. That lets your experiment fail without taking down the entire image. frank > --Trygve > > > > > On 2011.06.01 03:24, Juan Vuletich wrote: > > [hidden email] wrote: > > On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz > <[hidden email]> wrote: > > "info@tomsik" == info@tomsik cz <[hidden email]> writes: > > info> In short: 1.) binary messages make sense only for math. I've never > info> implemented even one binary message, have you? (for non-math > info> things) > > info> Why not step further and make dsl for equations? let them live > info> outside of language. (with everything common to math world) > > info> 2.) keyword messages with more than 2 arguments are just ugly - > info> they smell in the "missing another object" way. And 2 arguments > info> are rare too. I would allow one argument at top. > > So, you've now eliminated both possible ways of creating a new Point: > > 3 @ 4 > Point x: 3 y: 4 > > > I'll go few steps further to show big-picture in hypothetical syntax > (one-argument closures with argument as implicit receiver, no returns -> > CPS) > > Point new: [x: 3, y: 4, printOn: aStream]. > <rcvr> <msg>: <arg>[<msgForNew>: <arg>, <msgForNew>: <arg>, <msgForNew>: > <arg>]. > concepts: always left-to-right (receiver->message->argument), no parentheses > -> uniformity > returns: nothing, does something > > So, #new: creates a point without values for x and y... What if I want to > only build objects that make sense, meaning that their instance variables > must conform to some invariant defined by the class? > > vs. > (Point x: 3 y: 4) printOn: aStream. > (<rcvr> <msg>: <arg> <key2>: <arg2>) <msg>: <arg>. > concepts: sometimes left-to-right, depending on parentheses and message-type > (syntax) > returns: aPoint, which won't be used anyway, because it was printed already. > > Easy choice. This is much nicer. > > Cheers, > Juan Vuletich > > I wonder what language we would end up with if all of your (even > conflicting) goals were implemented. > > The more syntax you eliminate, the more you end up with LISP. Maybe you > want LISP... you know where to find it! > > > I'm not saying "let's drop objects", I'm saying "let's simplify language, > let's drop unused/misused/bad-in-long-process things" > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1375 / Virus Database: 1509/3663 - Release Date: 05/27/11 > > > > > > > -- > > Trygve Reenskaug mailto: [hidden email] > > Morgedalsvn. 5A http://folk.uio.no/trygver/ > > N-0378 Oslo Tel: (+47) 22 49 57 27 > > Norway > > > |
|
|
In reply to this post by Nicolas Cellier
Am 2011-05-31 um 23:25 schrieb Nicolas Cellier: > 2011/5/31 [hidden email] <[hidden email]>: >> In short: >> >> 1.) binary messages make sense only for math. I've never implemented even >> one binary message, have you? (for non-math things) >> >> Why not step further and make dsl for equations? let them live outside of >> language. >> (with everything common to math world) >> > > Example : / for building file path Example: >> for accessing Methods in a class like this: Class >> #name Best -Tobias |
|
|
In reply to this post by Kamil Tomsik
> 1.) binary messages make sense only for math. I've never implemented even
> one binary message, have you? (for non-math things) 49 of them for this package only: http://www.zogotounga.net/comp/squeak/functionaltalk.htm (see at the bottom of the page) Stef |
|
|
In reply to this post by Frank Shearar-3
> On 31 May 2011 22:43, [hidden email] <[hidden email]> wrote: >> Example from my previous reply to Randal for illustration: >> >> Point new: [x: 3, y: 4, printOn: aStream]. >> >> Always left-to-right syntax, always one argument, possible multiple >> receivers and messages, syntax sugar for closures, closure always have >> only >> one argument which is also implicit receiver - you can't deny it's at >> least >> interesting to think about such kind of uniformity. > > Absolutely. It's called the lambda calculus. And it's very interesting > to work things out using lambda calculus, and figure out the semantics > of statements... but would you really want to program in the lambda > calculus? > > Even the textbooks allow multiple parameter functions, with the > understanding that \xyz <whatever> is really \x \y \z <curried > whatever. > > frank > Lambda calculus has different purpose (evaluation), this is sequence of orders (no return value) in logic left-to-right order. Actually I'd like to see something very different (in hypertalk style) and with "smart" syntax like: Account>>deposit amount = increase balance by amount. SomeScript>>doSomethingWith account = deposit amount(100) to account. This is just sketch, prototype in my head, which wasn't crystalized yet, but it's IMHO interesting approach and could improve readability too. However left-to-right tell-dont-ask style improves design and is also much easier to read and "scan". (I do write a lot of code this way so I can compare) It is also very natural for people and their thinking. (we usually don't want to GET/EVALUATE something, we want things to be DONE) I do not need low-level support in language, I can already code this way, but every interaction with existing library is just pain... Hm, as I think about it, maybe I don't need to rewrite libraries, maybe some kind of dynamic wrapper could be enough... I'm curious for your opinions. It's very enlightening discussion, thx for that. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |