On 4/27/06, stéphane ducasse ducasse@iam.unibe.ch wrote:

...

Anyway I think that would be nice to make something to run St scripts from the command line... just to attract users from Python/Perl/(put your classic text file scripting language here) to Squeak.

exactly and also me when I have to write some script shells, and I would prefer to write some sqrit-shell :)

ColoredPoint>>foo: zork <category: 'foobar'> <author: 'sd' date: '24/06/2006'>

I'd like to unify method bodies and blocks:

ColoredPoint >> [ foo:aFoo bar:aBar | self doStuff. ]

This way, >> is really a message with a block argument, and one could do:

aBlock := [ foo:aFoo bar:aBar | self blah ]. aBlock foo:42 bar:51. Maybe #foo:bar: should just be an alias for #value:value in this precise instance of Block, instead of defining a new method in Block.

The current syntax ("anonymous" blocks) could still be allowed as syntactic shortcut: aBlock := [ :x :y | self blah ]. being synonymous for: aBlock := [ value:x value:y | self blah ].

Also, what should self be in the context of a script ? In a (VW) workspace it's an undefined object...

Le Mardi 16 Mai 2006 21:35, stéphane ducasse a écrit :

...

The current syntax ("anonymous" blocks) could still be allowed as syntactic shortcut: aBlock := [ :x :y | self blah ]. being synonymous for: aBlock := [ value:x value:y | self blah ].

Quite neat! even if I dislike the |

Nice to make things explicit. But a clever mind might think of writing

aBlock := [x: xInteger y: yInteger xInteger blah: yInteger ].

and believe he/she can evaluate with:

aBlock x: 1 y: 0.

Nicolas

KernelPackage import: Point.

Package declare: 'ColoredPointPackage'.

Why not instead: Package ColoredPointPackage; import: Point from: #System

It is plain Smalltalk, and is less verbose.

Point < ColoredPpoint variables: 'x y' ; classvar: 'Foo'

I would prefer: Point subclass: #ColoredPoint var: 'x y'; classvar: 'Foo'.

var/classvar is more homogeneous than variables/classvar

ColoredPoint>>foo: zork <category: 'foobar'> <author: 'sd' date: '24/06/2006'> [ ljkljl ^ ]

Cheers, Alexandre

...

Why not instead: Package ColoredPointPackage; import: Point from: #System

because I tried to be as close as possible to the message passing syntax

Yes, I know, but Package ColoredPointPackage; import: Point from: #System

is fully Smalltalk compliant. ColoredPointPackage is in that case a message sent to the object Package.

There was a similar trick used in Squeak 3.3.

Cheers, Alexandre

On May 16, 2006, at 4:38 PM, stéphane ducasse wrote:

Yes I know I thought about it too but I never liked the idea that sending a message would create a method or a class. May be I'm too old fashioned :)

Is there another way to do it?

Colin

Hans-Martin Mosner wrote:

When we define methods, we don't write SomeClass compile: 'method source' classified: 'protocol' because that would be pretty clumsy.

Now for class definitions, I don't see how all the alternative approaches of defining classes give a real advantage over the traditional message send expression.

Isn't there a certain contradiction between "pretty clumsy" on the one hand and "no real advantage" on the other? If you need to understand some code, being non-clumsy is a real advantage to me and having less clumsy class definitions would certainly help in understanding code faster and better. And yes, VW holds the all-time low in the signal to noise ratio of class definitions ;-)

Cheers, - Andreas

On 5/17/06, Lord ZealoN lordzealon@gmail.com wrote:

I haven't read all the mails but, why we would need something like a makefile?. I think squeak don't need it. Squeak don't have a edit-compile cycle, True?

Ruby doesn't either, and it has rake... I use it to build LaTeX documents for instance. I'd like to use smalltalk to automate out-of-smalltalk stuff, and to call smalltalk code from the command line as simply as I can call whatever script.

...

...

Yes I know I thought about it too but I never liked the idea that sending a message would create a method or a class. May be I'm too old fashioned :)

Is there another way to do it?

To "define" a class nothing is required (you must write "source" code in a piece of paper/aTextFile). If you want to create an object (like a class) you need to DO something, ... e.g. send a message.

Working with OOLanguages, only definition is possible (an required), because execution is not allowed when you are "there"; a computer/machive will do the work later in time (evading object creation if possible :-( ). It is like writing a letter to God, talking about ideal objects...

Working IN smalltalk, computation/production is a side effect of a working environment. When you are in the environment, you must do(evaluate) actions and create classes/species (if it is possible at the moment of evaluation). It is like working in real world.

The "doIt" instead of "defineIt" has important implications in systems development/creation. Is is not a good/bad idea; it is a requirement to send messages. It is possible becasue the receiver is near your fingers and at the same time. Building open systems (instead of closed/ideal systems) let you lower the risks of working declarativelly.

hope this help, Ale.

On 17 mai 06, at 00:34, Colin Putney wrote:

On May 16, 2006, at 4:38 PM, stéphane ducasse wrote:

...

Yes I know I thought about it too but I never liked the idea that sending a message would create a method or a class. May be I'm too old fashioned :)

Is there another way to do it?

I meant a message that is not defined yet to create a pacakage

Package ColoredPointPackage would not be known when you are defining it. Sorry for the confusion.

Stef

Colin

Le Mardi 16 Mai 2006 17:06, stéphane ducasse a écrit :

...

It is plain Smalltalk, and is less verbose.

...

Point < ColoredPpoint      variables: 'x y' ;      classvar: 'Foo'

I would prefer: Point subclass: #ColoredPoint   var: 'x y'; classvar: 'Foo'.

Var and classvar are cool. I like the <  :)

Note that it's funny that a super-class is not super-ior

Nicolas

Few months ago, I worked on a scripting languages, here is a snippet:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= package Kernel

rootclass Obj;

Obj { yourself ^ self } Obj { == other <primitive: 110> } Obj { ~~ other ^ (self == other) ifTrue: [false] ifTrue:[true] } Obj { = other ^ self == other } Obj { ~= other ^ (self = other) == false}

Obj {isNil ^ false} Obj {isNotNil ^ true} Obj {isBoolean ^false} Obj {isCollection ^false} Obj {isClass ^false} Obj {isSymbol ^false} Obj {isInteger ^false} Obj {perform: aSymbol <primitive: 83>}

Obj class {new ^ self basicNew} Obj class {basicNew <primitive: 70>} Obj class {isClass ^true}

class Boolean extends Obj; Boolean {isBoolean ^ true}

class False extends Boolean; False { ifTrue: block ^ self } False { ifFalse: block ^ block value } False { ifTrue: trueBlock ifFalse: falseBlock ^ falseBlock value } False { ifFalse: falseBlock ifTrue: trueBlock ^ falseBlock value } False { enot ^ True new } False { eor: other ^ other value} False { eand: other ^ False new}

class True extends Boolean; True { eifTrue: block ^ block value } True { eifFalse: block ^ self } True { enot ^ False new } True { eor: other ^ True new } True { eand: other ^ other value }

end -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Any comments are welcomed

Cheers, Alexandre

Am Apr 27, 2006 um 8:37 AM schrieb stéphane ducasse:

KernelPackage import: Point.

Package declare: 'ColoredPointPackage'.

Point < ColoredPpoint variables: 'x y' ; classvar: 'Foo'

ColoredPoint>>foo: zork <category: 'foobar'> <author: 'sd' date: '24/06/2006'> [ ljkljl ^ ]

On 27 avr. 06, at 05:47, Wilkes Joiner wrote:

Rake is using blocks, just with an alternative syntax.

task :target => [:dep1, :dep2] do # do stuff end

I know this is why I ask if someone was working on a squeak version :)

On 4/26/06, stéphane ducasse ducasse@iam.unibe.ch wrote:

...

hi all

I wanted to know if one of you was working on something similar than rake in ruby: a makefile/ant like framework. Using blocks :) so it seems better.

Stef