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

Hi Francisco,

on Sat, 08 Apr 2006 12:49:02 +0200, you <[hidden email]> 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.

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

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:

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:

--
Romain Robbes          http://www.inf.unisi.ch/~robbes/

Try either "30 april, 2006" or "2006 april: 30"

--Alan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] 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: [hidden email]
[mailto:[hidden email]] 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:
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 <[hidden email]> wrote:

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" <[hidden email]>
Newsgroups: gmane.comp.lang.smalltalk.squeak.general
Sent: Saturday, April 08, 2006 11:13 AM
Subject: Re: Squeak forth and Logo

"SmallSqueak" <[hidden email]>  wrote...

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" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Saturday, April 15, 2006 12:24 PM
Subject: Re: Squeak forth and Logo

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.

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:

        http://www.rx-core.org/

    This engine is used in RetroForth:

        http://retroforth.org

    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:

        http://flatassembler.net/

    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" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Saturday, April 15, 2006 12:24 PM
Subject: Re: Squeak forth and Logo


> "SmallSqueak" <[hidden email]>  wrote...
>
> >...
> >   That "small" talk was printed in "Higher-Order and Symbolic
Computation" 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" <[hidden email]> 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

> - 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?

Hi!

=?ISO-8859-1?Q?st=E9phane_ducasse?= <[hidden email]> 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

Hi,

[hidden email] 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