[squeak-dev] smalltalk evolution

Trygve Reenskaug trygver at ifi.uio.no
Wed Jun 1 07:30:39 UTC 2011


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:
> info at tomsik.cz wrote:
>> On Tue, 31 May 2011 22:01:14 +0200, Randal L. Schwartz 
>> <merlyn at stonehenge.com> wrote:
>>
>>>>>>>> "info at tomsik" == info at tomsik cz <info at tomsik.cz> 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: trygver at ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110601/4a6855c8/attachment.htm


More information about the Squeak-dev mailing list