I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards. It would be nicer if I could write:
2006 year april 30
It would never had occurred to me that numbers *could* be selectors if I hadn't taken a look at Forth. In that amazing little language *anything* can be a selector (eg. #?! or ^%* are valid selectors or word names, as they call them).
As a comprise, I decided to use the following expression:
2006 year april day30
But that leaves me with another problem. Basically defining 31 methods like this:
TmActualMonth>>day30 ^ self dayNumber: 30
Very boring. In the very Logo way, I created a method that creates those boring methods:
TmActualMonth class>>installBoringMethods (1 to: 31) collect: [:number | self fakeCompile: (String streamContents: [:stream | stream nextPutAll: 'day'; print: number; cr; tab; nextPutAll: '^ self dayNumber: '; print: number ] ) ]
Now I have to rush to our first UK Smalltalk meeting. Stephen Taylor from APL fame will be giving a presentation. It seems that there are lots of similarities between the APL and the Smalltalk community. But we are bigger!!
-Francisco
Hi Francisco,
on Sat, 08 Apr 2006 12:49:02 +0200, you francisco.garau@gmail.com wrote:
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards.
How about a binary selector instead of a keyword selector, would be in sync with elegance of syntax:
2006 year april , 30 2006 year april @ 30
/Klaus
it's a pity #/ is already used, otherwise you could just say:
2006 / 4 / 30
maybe another binary selector is still available though.
Romain
On Apr 8, 2006, at 1:17 PM, Klaus D. Witzel wrote:
Hi Francisco,
on Sat, 08 Apr 2006 12:49:02 +0200, you francisco.garau@gmail.com wrote:
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards.
How about a binary selector instead of a keyword selector, would be in sync with elegance of syntax:
2006 year april , 30 2006 year april @ 30/Klaus
-- Romain Robbes http://www.inf.unisi.ch/~robbes/
Check out the original Smalltalk-72. It was a very extensible language at all levels and nothing special had to be done if you wanted to use a number as a selector.
Cheers,
Alan
-----------
At 03:49 AM 4/8/2006, Francisco Garau wrote:
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards. It would be nicer if I could write:
2006 year april 30
It would never had occurred to me that numbers *could* be selectors if I hadn't taken a look at Forth. In that amazing little language *anything* can be a selector (eg. #?! or ^%* are valid selectors or word names, as they call them).
As a comprise, I decided to use the following expression:
2006 year april day30
But that leaves me with another problem. Basically defining 31 methods like this:
TmActualMonth>>day30 ^ self dayNumber: 30
Very boring. In the very Logo way, I created a method that creates those boring methods:
TmActualMonth class>>installBoringMethods (1 to: 31) collect: [:number | self fakeCompile: (String streamContents: [:stream | stream nextPutAll: 'day'; print: number; cr; tab; nextPutAll: '^ self dayNumber: '; print: number ] ) ]
Now I have to rush to our first UK Smalltalk meeting. Stephen Taylor from APL fame will be giving a presentation. It seems that there are lots of similarities between the APL and the Smalltalk community. But we are bigger!!
-Francisco
Dear Squeakers,
Alan wrote:
Check out the original Smalltalk-72. It was a very extensible language at all levels and nothing special had to be done if you wanted to use a number as a selector.
It is interesting to note Guy Steele "stealing" the biological metaphor when referring to Fortress:
http://research.sun.com/projects/plrg/fortress0618.pdf
as a "growable language" !
Actually he gave an interesting talk, "Growing a Language" (OOPSLA98?) starting with words of just one syllable then he had to define bigger words before he could use them in the talk (is that a "small" talk ? ;-)
That "small" talk was printed in "Higher-Order and Symbolic Computation" (12/1999, pp 221-236):
http://www.brics.dk/~hosc/local/HOSC-12-3-pp221-236.pdf
So much for Guy's "small" talk and his "growable language".
Now back to the real Smalltalk's, perhaps Smalltalk 72 is the most growable of them all ?
Dan had an image of Smalltalk 72 running inside Squeak.
Is there a real VM for Smalltalk 72 with source available some where?
Any pointer is very much appreciated. It would be interesting to see the trio plugins for Smalltalk 72 VM running atop a couple of other VM (Forth is one of them ;-)
Cheers,
SmallSqueak
P.S: If Smalltalk 72 was the most growable then perhaps Squeak is the most shrinkable ? ;-)
----- Original Message ----- From: "Alan Kay" alan.kay@squeakland.org Newsgroups: gmane.comp.lang.smalltalk.squeak.general Sent: Saturday, April 08, 2006 11:13 AM Subject: Re: Squeak forth and Logo
Check out the original Smalltalk-72. It was a very extensible language at all levels and nothing special had to be done if you wanted to use a number as a selector.
Cheers,
Alan
At 03:49 AM 4/8/2006, Francisco Garau wrote:
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards. It would be nicer if I could write:
2006 year april 30
It would never had occurred to me that numbers *could* be selectors if I hadn't taken a look at Forth. In that amazing little language *anything* can be a selector (eg. #?! or ^%* are valid selectors or word names, as they call them).
As a comprise, I decided to use the following expression:
2006 year april day30
But that leaves me with another problem. Basically defining 31 methods like this:
TmActualMonth>>day30 ^ self dayNumber: 30
Very boring. In the very Logo way, I created a method that creates those boring methods:
TmActualMonth class>>installBoringMethods (1 to: 31) collect: [:number | self fakeCompile: (String streamContents: [:stream | stream nextPutAll: 'day'; print: number; cr; tab; nextPutAll: '^ self dayNumber: '; print: number ] ) ]
Now I have to rush to our first UK Smalltalk meeting. Stephen Taylor from APL fame will be giving a presentation. It seems that there are lots of similarities between the APL and the Smalltalk community. But we are bigger!!
-Francisco
"SmallSqueak" smallsqueak@rogers.com wrote...
... That "small" talk was printed in "Higher-Order and Symbolic Computation" (12/1999, pp 221-236):
http://www.brics.dk/~hosc/local/HOSC-12-3-pp221-236.pdfSo much for Guy's "small" talk and his "growable language".
Now back to the real Smalltalk's, perhaps Smalltalk 72 is the most growable of them all ?
Dan had an image of Smalltalk 72 running inside Squeak.
Is there a real VM for Smalltalk 72 with source available some where?
Any pointer is very much appreciated. It would be interesting to see the trio plugins for Smalltalk 72 VM running atop a couple of other VM (Forth is one of them ;-)
Hi, PhiHo -
It's on my list to revive the St-72 that I did in squeak. I believe it will "just run" if you load it into Squeak 3.4 (it's on SqueakMap). Even if it doesn't, all the code is there if you are interested plus, as I say, I'll put out a revised version for 3.9 "pretty soon".
I always feel the need to mention that the greatest strength of St-72 was also its greatest weakness: By including syntax in the purview of programming, it (a) ran slowly because of parsing as it went, and (b) it was possible to write all sorts of ambiguous programs. Oh, and did I mention (c) there were modularity problems with free variables.
That said, Smalltalk-72 got us off the launch pad -- it gave us a completely malleable and interactive system that was truly object-oriented. That's why I bother to keep it available. Plus, when we moved to St-76, I made the statement to Alan that we could always do St-72 in St-76, so it's a completion thing ;-).
- Dan
PS: About Forth... I love Forth -- it's in many ways like St-72, and yet totally different. St-72 has automatic storage management and is really safe. Forth does not have automatic and is pretty fragile. St-72 is slow, and Forth rips. I tried a couple of Forth variants with Smalltalk's nice structure, but lack of garbage collection made it really hard to live the same way. Helge Horch made a pretty nice run at an OO Forth, if you are interested.
Hi Dan,
I believe it will "just run" if you load it into Squeak 3.4 (it's on SqueakMap).
Can I just drag and drop it into Squeak VM 3.4 ?
I always feel the need to mention that the greatest strength of St-72 was also its greatest weakness:
By including syntax in the purview of programming, it
(a) ran slowly because of parsing as it went,
How so, was Smalltalk 72 code interpreted instead of compiled or was it compiled every time it's run ?
and (b) it was possible to write all sorts of ambiguous programs.
and also all sort of clever programs. ;-)
Oh, and did I mention (c) there were modularity problems with free variables.
Did Squeak inherit this trait (modularity problems ? ;-)
Actually I am still a total Smalltalk newbie. I would love to hear other opinions on the growth-ability and modularity of Smalltalk 72 and Squeak.
It looks like my hope on a modularly growable Smalltalk 72 is vanishing.
About the Forth VM, it was just another dream to refactor all platform dependent codes.
Basically, each plugin (including the infamous trio ;-) comprises portable ANSI C codes and a portable Forth script.
The Forth VM is, of course. just another plugin in assembly.
It can easily be visualized the VMMaker spitting out a bunch of portable C source and Forth scripts for all platforms.
The VM maintainers have to worry about the tiny Forth VM and plugin loader each worh about 10KB of runtime code.
Do you have any plan for Squeak?
Cheers,
PhiHo
P.S: I am still playing FreeCell with Squeak 3.6
----- Original Message ----- From: "Dan Ingalls" Dan@SqueakLand.org To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, April 15, 2006 12:24 PM Subject: Re: Squeak forth and Logo
"SmallSqueak" smallsqueak@rogers.com wrote...
... That "small" talk was printed in "Higher-Order and Symbolic Computation" (12/1999, pp 221-236):
http://www.brics.dk/~hosc/local/HOSC-12-3-pp221-236.pdfSo much for Guy's "small" talk and his "growable language".
Now back to the real Smalltalk's, perhaps Smalltalk 72 is the most growable of them all ?
Dan had an image of Smalltalk 72 running inside Squeak.
Is there a real VM for Smalltalk 72 with source available some where?
Any pointer is very much appreciated. It would be interesting to see the trio plugins for Smalltalk 72 VM running atop a couple of other VM (Forth is one of them ;-)
Hi, PhiHo -
It's on my list to revive the St-72 that I did in squeak. I believe it will "just run" if you load it into Squeak 3.4 (it's on SqueakMap). Even if it doesn't, all the code is there if you are interested plus, as I say, I'll put out a revised version for 3.9 "pretty soon".
I always feel the need to mention that the greatest strength of St-72 was also its greatest weakness: By including syntax in the purview of programming, it (a) ran slowly because of parsing as it went, and (b) it was possible to write all sorts of ambiguous programs. Oh, and did I mention (c) there were modularity problems with free variables.
That said, Smalltalk-72 got us off the launch pad -- it gave us a completely malleable and interactive system that was truly object-oriented. That's why I bother to keep it available. Plus, when we moved to St-76, I made the statement to Alan that we could always do St-72 in St-76, so it's a completion thing ;-).
- Dan
PS: About Forth... I love Forth -- it's in many ways like St-72, and yet totally different. St-72 has automatic storage management and is really safe. Forth does not have automatic and is pretty fragile. St-72 is slow, and Forth rips. I tried a couple of Forth variants with Smalltalk's nice structure, but lack of garbage collection made it really hard to live the same way. Helge Horch made a pretty nice run at an OO Forth, if you are interested.
PhiHo -
[Just found this message unsent for two weeks...]
I believe it will "just run" if you load it into Squeak 3.4 (it's on SqueakMap).
Can I just drag and drop it into Squeak VM 3.4 ?
When in doubt, try it out (Ie I can't say).
I always feel the need to mention that the greatest strength of St-72 was also its greatest weakness:
By including syntax in the purview of programming, it
(a) ran slowly because of parsing as it went,
How so, was Smalltalk 72 code interpreted instead of compiled or was it compiled every time it's run ?
Yes. It was tokenized when read in (very much like Forth), and then the token streams were interpreted.
and (b) it was possible to write all sorts of ambiguous programs.
and also all sort of clever programs. ;-)
Absolutely. It's how we got experience with various patterns that worked well and that didn't.
Oh, and did I mention (c) there were modularity problems with free variables.
Did Squeak inherit this trait (modularity problems ? ;-)
To a lesser degree, yes ;-).
Actually I am still a total Smalltalk newbie. I would love to hear other opinions on the growth-ability and modularity of Smalltalk 72 and Squeak.
It looks like my hope on a modularly growable Smalltalk 72 is vanishing.
Don't let me discourage you about this. I wouldn't be surprised if a nice wrinkle could make it a bit better behaved, and yet leave it open in that wonderful way.
The notion of growable languages is interesting; there's always the risk of making things more complicated. I can't say that Smalltalk is the best language, but the St-76/80 syntax was my best shot at preserving most of the growability of St-72 while keeping the syntax simple and uniform(*). To me that is essential to making things understandable. And, among uniform syntaxes, I think keywords give a much greater experience of "growing" to suit different domains, whether they be numbers, music, graphics or AI.
(*) The same features that made St-72 not compilable made it actually unreadable! The parse could not be determined except by reading the code for the receiver (whose type, of course, could not be known until run time ;-). Unless everyone practiced good style (ie did not use those features), it was unusable. Interestingly this was a violation at the level of syntax, of the most valuable principle of OO design that Smalltalk introduced: No object should depend on the internal details of other objects in the system.
About the Forth VM, it was just another dream to refactor all platform dependent codes.
Basically, each plugin (including the infamous trio ;-) comprises portable ANSI C codes and a portable Forth script.
The Forth VM is, of course. just another plugin in assembly.
It can easily be visualized the VMMaker spitting out a bunch of portable C source and Forth scripts for all platforms.
The VM maintainers have to worry about the tiny Forth VM and plugin loader each worh about 10KB of runtime code.
Do you have any plan for Squeak?
Er... ?
Cheers,
PhiHo
P.S: I am still playing FreeCell with Squeak 3.6
Hehe. Me too, but not the way I used to. Think of what could have been done with all those cycles -- I kept track of all my games. I was indirectly helped out of this particular addiction by the following words of wisdom:
No one ever says on their death bed, "I wish I had watched more TV."
- Dan
Dan,
PS: About Forth...
I forgot to tell you about the ForthVM plugin.
I love Forth -- it's in many ways like St-72, and yet totally different. St-72 has automatic storage management and is really safe. Forth does not have automatic and is pretty fragile. I tried a couple of Forth variants with Smalltalk's nice structure, but lack of garbage collection made it really hard to live the same way.
Joy, Forth's Functional Cousin:
http://www.latrobe.edu.au/philosophy/phimvt/joy.html
has GC, using this:
http://www.hpl.hp.com/personal/Hans_Boehm/gc
Helge Horch made a pretty nice run at an OO Forth, if you are interested.
Actually, I found it here:
This engine is used in RetroForth:
Doesn't Retro-Forth sounds like "Back To The Future" or "Forward To The Past" ;-)
In fact, the rx-core was developed from earlier versions of RetroForth in a refactoring process.
Out of the box, librx.dll is a whoppy 8704 bytes librx.dll for Windows (there are versions for x86 BSD and Linux)
This librx source (in x86 assembly) was further modularised, (using assembly code refactoring browser aka notepad.exe ;-) and assembled with Flat Assembler:
resulted in a ForthVM plugin 5120 byte. (the file rx.forth used to bootstrap the engine is now external, read by the plugin loader and feed to the Forth kernel in the initializing step, instead of being embedded in the kernel)
St-72 is slow, and Forth rips.
This ForthVM can handle inline words defined in _m_a_c_h_i_n_e_c_o_d_e_ , something like this:
inline : dup [ $fc4689 3, $fc768d 3, ] ; : 1+ [ $40 1, ] ; : 1- [ $48 1, ] ; : swap [ $0687 2, ] ; : drop [ $ad 1, ] ; : nip [ $04c683 3, ] ; : 2drop [ $adad 2, ] ; : and [ $0623 2, ] nip ; : or [ $060b 2, ] nip ; : xor [ $0633 2, ] nip ;
Cheers,
SmallSqueak
P.S: Please note that I am only a Forth newbie, reading "Starting Forth":
http://home.vianetworks.nl/users/mhx/sf.html
and "Thinking Forth"
http://thinking-forth.sourceforge.net/
----- Original Message ----- From: "Dan Ingalls" Dan@SqueakLand.org To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, April 15, 2006 12:24 PM Subject: Re: Squeak forth and Logo
"SmallSqueak" smallsqueak@rogers.com wrote...
... That "small" talk was printed in "Higher-Order and Symbolic
Computation"
(12/1999, pp 221-236):
http://www.brics.dk/~hosc/local/HOSC-12-3-pp221-236.pdfSo much for Guy's "small" talk and his "growable language".
Now back to the real Smalltalk's, perhaps Smalltalk 72 is the most growable of them all ?
Dan had an image of Smalltalk 72 running inside Squeak.
Is there a real VM for Smalltalk 72 with source available some where?
Any pointer is very much appreciated. It would be interesting to see the trio plugins for Smalltalk 72 VM running atop a couple of other VM (Forth is one of them ;-)
Hi, PhiHo -
It's on my list to revive the St-72 that I did in squeak. I believe it
will "just run" if you load it into Squeak 3.4 (it's on SqueakMap). Even if it doesn't, all the code is there if you are interested plus, as I say, I'll put out a revised version for 3.9 "pretty soon".
I always feel the need to mention that the greatest strength of St-72 was
also its greatest weakness: By including syntax in the purview of programming, it (a) ran slowly because of parsing as it went, and (b) it was possible to write all sorts of ambiguous programs. Oh, and did I mention (c) there were modularity problems with free variables.
That said, Smalltalk-72 got us off the launch pad -- it gave us a
completely malleable and interactive system that was truly object-oriented. That's why I bother to keep it available. Plus, when we moved to St-76, I made the statement to Alan that we could always do St-72 in St-76, so it's a completion thing ;-).
- Dan
PS: About Forth... I love Forth -- it's in many ways like St-72, and yet totally different.
St-72 has automatic storage management and is really safe. Forth does not have automatic and is pretty fragile. St-72 is slow, and Forth rips. I tried a couple of Forth variants with Smalltalk's nice structure, but lack of garbage collection made it really hard to live the same way. Helge Horch made a pretty nice run at an OO Forth, if you are interested.
Hi!
"SmallSqueak" smallsqueak@rogers.com wrote:
Dan,
PS: About Forth...
I forgot to tell you about the ForthVM plugin.
It is funny, I have been toying with Forths too in my spare time, and with ideas around mixing with Squeak in various ways.
I also like retroforth, and I have been studying the code a little bit. I started looking for minimal forths and read a lot about eForth and its derivatives - since eForth is built from 31 IIRC (some claim you only need 13) primitive words written in small machine code snippets - and the rest is just written in itself. So essentially, emulating eForth comes down to just implementing those primitives.
First I was thinking of implementing it straight up in Squeak, just as an interesting gimmick. Then I realized that Exupery offers some interesting intermediate levels that can be used to gain the full force of Exupery. :)
But eForth is AFAIK not one of the current forths that have a prospering community (like Retro), and having a forth inside Squeak can be done with several purposes, of which eForth only fits one (the fun of it). The other purposes would be:
1. To offer a low level for speed. eForth is not fast. 2. To offer the stack based programming paradigm, hopefully mixed with Smalltalk in a neat way. No point in emulating any specific forth in this case, just borrowing the concepts and execution model. 3. To make Squeak a really slick IDE for forth programming. And then deploying "natively" in whatever forth we are "emulating". In this case a popular Forth, or a fast one (or both) is preferable. Retro covers many platforms and seems popular, but perhaps not blazingly fast (yet).
A few other interesting things in this area:
- FuelVM. This is actually a VM written in C (IIRC) that takes forth code as its "bytecodes". Interesting stuff, but I don't think it is developed right now. - Retroforth's friends: Reva, HelForth (they cross pollinate a lot) - Factor by Slava Pestov (factorcode.org). This is actually a very good general source of inspiration for new cool ideas to possibly bring to Squeak. It is forthish, but has GC and OO in full and lots of other neat stuff.
P.S: Please note that I am only a Forth newbie,
Me too, but I have been fascinated by forth since I was around 12 years old. Almost got myself a Jupiter Ace. ;) It was the first language I learned in which I could make first class constructions - evolve the language - much like we can in Smalltalk (or Lisp/Scheme of course).
regards, Göran
Hi!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
- Factor by Slava Pestov (factorcode.org). This is actually a very
good general source of inspiration for new cool ideas to possibly bring to Squeak.
Like what?
Well, one thing I found neat was the "builtin" hyperlinking of all code. All words were clickable. I would guess there are more things though, just my feeling - can't explain it. :)
regards, Göran
Am 27.04.2006 um 22:04 schrieb goran@krampe.se:
Hi!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
- Factor by Slava Pestov (factorcode.org). This is actually a very
good general source of inspiration for new cool ideas to possibly bring to Squeak.
Like what?
Well, one thing I found neat was the "builtin" hyperlinking of all code. All words were clickable.
Well we have that, though not by clicking.
It's like the second thing I teach people starting with Smalltalk, who usually wonder (or complain) about the lack of documentation. I tell them, that the documentation is right there, hyperlinked in the source code, and searchable, too. Cmd-n takes you to usage examples, whereas Cmd-m takes you to the definition. Cmd-Shift-W lets you search, and the Method Finder even finds stuff by example.
The first thing of course I mention is that Smalltalk is different ;-)
- Bert -
Hi!
Bert Freudenberg bert@impara.de wrote:
Am 27.04.2006 um 22:04 schrieb goran@krampe.se:
Hi! =?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
- Factor by Slava Pestov (factorcode.org). This is actually a very
good general source of inspiration for new cool ideas to possibly bring to Squeak.
Like what?
Well, one thing I found neat was the "builtin" hyperlinking of all code. All words were clickable.
Well we have that, though not by clicking.
And of course I know that. :) It was just an example, and it is a bit different when you can just click-click-click. I still find the Forth community (viewing Factor as a kind of Forth) worth gleaning at (and other communities too - like Haskell people seem to be doing weird things ;)).
regards, Göran
Hi,
goran@krampe.se wrote:
It is funny, I have been toying with Forths too in my spare time,
Is it spare time or spare spare time ;-)
[SNIPPED]
Retro covers many platforms,
Intel/AMD based Linux/BSD, MacIntel and Wintel are good start.
and seems popular
Not as popular as Win32Forth.
Win32Forth is much more mature, ISO/ANSI compliant but it's too much of a kitchen sink, IMHO ;-)
but perhaps not blazingly fast (yet).
I don't have any benchmarks but I am not much concerned with speed right now.
The goal of this experiment is to refactor platform dependent codes and these are mainly startup/initialization.
It's not ANSI/ISO compliant but has a clean slate ;-)
Thanks for sharing.
Cheers,
SmallSqueak
On 4/8/06, Francisco Garau francisco.garau@gmail.com wrote:
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
Take a look at "Chalten" the date package recently uploaded by Hernan. With this package you can write:
January first, 2006
There is more information about the design in: http://prog2.vub.ac.be/%7Ecderoove/esugtalks/Wilkinson.pdf
Cheers, Diego.-
Try either "30 april, 2006" or "2006 april: 30"
--Alan
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Francisco Garau Sent: Saturday, April 08, 2006 3:49 AM To: Squeak List Subject: Squeak forth and Logo
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards. It would be nicer if I could write:
2006 year april 30
It would never had occurred to me that numbers *could* be selectors if I hadn't taken a look at Forth. In that amazing little language *anything* can be a selector (eg. #?! or ^%* are valid selectors or word names, as they call them).
As a comprise, I decided to use the following expression:
2006 year april day30
But that leaves me with another problem. Basically defining 31 methods like this:
TmActualMonth>>day30 ^ self dayNumber: 30
Very boring. In the very Logo way, I created a method that creates those boring methods:
TmActualMonth class>>installBoringMethods (1 to: 31) collect: [:number | self fakeCompile: (String streamContents: [:stream | stream nextPutAll: 'day'; print: number; cr; tab; nextPutAll: '^ self dayNumber: '; print: number ] ) ]
Now I have to rush to our first UK Smalltalk meeting. Stephen Taylor from APL fame will be giving a presentation. It seems that there are lots of similarities between the APL and the Smalltalk community. But we are bigger!!
-Francisco
Try either "30 april, 2006" or "2006 april: 30"
--Alan
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Francisco Garau Sent: Saturday, April 08, 2006 3:49 AM To: Squeak List Subject: Squeak forth and Logo
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards. It would be nicer if I could write:
2006 year april 30
It would never had occurred to me that numbers *could* be selectors if I hadn't taken a look at Forth. In that amazing little language *anything* can be a selector (eg. #?! or ^%* are valid selectors or word names, as they call them).
As a comprise, I decided to use the following expression:
2006 year april day30
But that leaves me with another problem. Basically defining 31 methods like this:
TmActualMonth>>day30 ^ self dayNumber: 30
Very boring. In the very Logo way, I created a method that creates those boring methods:
TmActualMonth class>>installBoringMethods (1 to: 31) collect: [:number | self fakeCompile: (String streamContents: [:stream | stream nextPutAll: 'day'; print: number; cr; tab; nextPutAll: '^ self dayNumber: '; print: number ] ) ]
Now I have to rush to our first UK Smalltalk meeting. Stephen Taylor from APL fame will be giving a presentation. It seems that there are lots of similarities between the APL and the Smalltalk community. But we are bigger!!
-Francisco
Hello, Francisco Garau wrote:
I am having fun with dates, and I can build them with the following expression:
2006 year april dayNumber: 30
I don't like the keyword selector there, because it breaks the beauty of the expression and forces parenthesis afterwards. It would be nicer if I could write:
2006 year april 30
While it seems nice to be able to express dates in code like that, I am not sure how useful and valuable this is in practice. How often do you need hardcoded dates, anyway? In many cases where I've seen this, it is a hint that we should have added a configuration parameter... The single exception in the project in which I'm currently involved are the unit tests, because we need to set up sample objects with calendar dates in a repeatable way there. In my experience, using a unary selector to convert from Strings to Dates is at least as readable and more useful in general: '08.04.2006' asDate (we're using the DD.MM.YYYY notation here) If you really need to create Date objects from arbitrary expressions, the unary selector #april isn't going to help you a lot...
Cheers, Hans-Martin
While it seems nice to be able to express dates in code like that, I am not sure how useful and valuable this is in practice.
In Maui (naked objects), every keyword message has a "parameter-holder" widget, into which you drop either another object or enter a Smalltalk expression.
Since Date fields are common, these terse date-creation expressions will be very, very nice for entering dates.
- Chris
While it seems nice to be able to express dates in code like that, I am not sure how useful and valuable this is in practice.
In Maui (naked objects), every keyword message has a "parameter-holder" widget, into which you drop either another object or enter a Smalltalk expression.
Cool! I was thinking in resurrecting the Morphic Wrappers projects. Naked Objects seemed a better name to me. But you have already done so!
Do you have something we can play with?
Thanks -Francisco
Yes, on SqueakSource. Load "Maui" into a 3.8 image.
The documentation is sparse but this should be enough to get started:
http://minnow.cc.gatech.edu/squeak/3836
but if you have any questions I will be happy to answer them here.
- Chris
--- Francisco Garau francisco.garau@gmail.com wrote:
While it seems nice to be able to express dates in code like that,
I
am not sure how useful and valuable this is in practice.
In Maui (naked objects), every keyword message has a
"parameter-holder"
widget, into which you drop either another object or enter a
Smalltalk
expression.
Cool! I was thinking in resurrecting the Morphic Wrappers projects. Naked Objects seemed a better name to me. But you have already done so!
Do you have something we can play with?
Thanks -Francisco
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Alan L. Lovejoy -
Alan Lovejoy -
Bert Freudenberg -
Chris Muller -
Dan Ingalls -
Diego Fernandez -
Francisco Garau -
goran＠krampe.se -
Hans-Martin Mosner -
Klaus D. Witzel -
Romain Robbes -
SmallSqueak -
stéphane ducasse