Smalltalk › Pharo › Pharo Smalltalk Developers

interactive method definition (was Re: Calypso wishlist)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Ben Coman

interactive method definition (was Re: Calypso wishlist)

On 9 February 2018 at 03:43, Nicolas Cellier <[hidden email]> wrote:

Then you might have used kind of named block params like
MyClass >> [foo:aFoo bar:aBar | self foo: aFoo; bar: aBar]

Le 8 févr. 2018 20:11, "Stephane Ducasse" <[hidden email]> a écrit :
Hi ben

This is not what I asked for :). In nautilus you do not have to switch
mode to define a method.

Ahh, cool. I change the subject.

Now about your proposal. I would like to be able the type tonel method
definition

SomeClass >> echo: anObject [
^ 42
]

Tonel represents what I want for methods.

Is this your ideal, or mainly to align with Tonel? Because it seems Tonel was developed

without much consideration of interactive method definition -- which is fine in as much as

Tonel was designed to quickly overcome a specific problem with Windows+Git, but it

Tonel shouldn't be set in stone since its introduction changes the environment

and stimulates further thinking on requirements.

Amongst your many priorities, could you ask someone familiar with changing compiler syntax

have a serious look at implementing both ways:

1. Tonel syntax for interactive method definition

2. Named block parameters for interactive method definition

to determine practically which one is preferred and easier to support.

And feed that into determining whether syntax should adapt to Tonel

or whether Tonel should adapt to the latter. It would be better to do this

earlier while Tonel is young before it becomes more widely used by other dialects.

Also btw, would having named block parameters possibly unify more methods and blocks?

(only a random thought, I'm not familiar with the low level distinction)

cheers -ben

P.S. should Tonel include a format-version field on the first line?

Its seems a good practice even if the format never does change for a long time.

This way students could just type nearly as in the books and I would
change the book to reflect this.
And people can decide either to type all the time the class or not.

Stef

On Thu, Feb 8, 2018 at 6:28 PM, Ben Coman <[hidden email]> wrote:
>
>
> On 9 February 2018 at 00:45, Ben Coman <[hidden email]> wrote:
>> On 8 February 2018 at 16:22, Stephane Ducasse <[hidden email]>
>> wrote:
>>> Hi denis
>>>
>>> - I would like to be able to define a method even in the class pane
>>> and that the system detects it automatically.
>>
>> It would be nice to do it from anywhere including Playground with
>> something like...
>> Classname >> #methodname >> [ method source here ]
>>
>> So I just tired a quick experiment...
>>
>> Object subclass: #SomeClass
>> instanceVariableNames: ''
>> classVariableNames: ''
>> package: 'MethodBuilderExperiment'
>>
>> On SomeClass defined method...
>> existingMethod
>> ^1
>>
>> On CompiledMethod defined method...
>> >> blockClosure
>> | newSource |
>> newSource := self methodNode selector, String crlf,
>> blockClosure sourceNode newSource allButFirst allButLast.
>> self methodClass compile: newSource
>>
>>
>> Now each of the following lines can be evaluated...
>>
>> SomeClass existingMethod "==> 1"
>> SomeClass >> #existingMethod >> [ ^42].
>> SomeClass existingMethod "==> 42"
>
> That should have been.
>
> SomeClass new existingMethod "==> 1"
> SomeClass >> #existingMethod >> [ ^42].
> SomeClass new existingMethod "==> 42"
>
>>
>>
>>
>> And another experiment...
>>
>> Object subclass: #MethodBuilder
>> instanceVariableNames: 'methodClass methodSelector'
>> classVariableNames: ''
>> package: 'MethodBuilderExperiment'
>>
>> On MethodBuilder defined method...
>> class: aClass selector: aSelector
>> methodClass := aClass.
>> methodSelector := aSelector.
>>
>> On MethodBuilder defined method...
>> >> blockClosure
>> |newSource|
>> newSource := methodSelector, String crlf,
>> blockClosure sourceNode newSource allButFirst allButLast.
>> methodClass compile: newSource
>>
>> On Behaviour re-defined method...
>> compiledMethodAt: selector
>> ^ self methodDict at: selector ifAbsent:
>> [ MethodBuilder new class: self selector: selector ]
>>
>>
>> Now each of the following lines can be evaluated...
>>
>> Someclass noMethod "==> error... Instance of SomeClass class did not
>> understand #noMethod"
>> SomeClass >> #noMethod >> [ ^42 ].
>> Someclass noMethod "==> 42"
>
> And should have been...
> Someclass new noMethod "==> error... Instance of SomeClass class did not
> understand #noMethod"
> SomeClass >> #noMethod >> [ ^42 ].
> Someclass new noMethod "==> 42"
>
>
> I see that is a bit problematic for keyword messages, but with a tweak...
>
> On MethodBuilder defined...
> >> blockClosure
> |newSource|
> methodSelector isArray
> ifFalse: [ newSource := methodSelector ]
> ifTrue: [
> newSource := ''.
> methodSelector do: [ :token | newSource := newSource , token asString, ' ' ]
> ].
> newSource := newSource, String crlf,
> blockClosure sourceNode newSource allButFirst allButLast.
> methodClass compile: newSource
>
>
> now the following can be evaluated...
>
> SomeClass >>#(echo: anObject) >> [ ^anObject ].
> SomeClass new echo: 'doyoulike'. "==> doyoulike"
>
>
> Another form to define a method might be...
> SomeClass >> [ echo: anObject
> ^anObject ]
>
> I think that looks better, but would require a loosening of block syntax.
>
> cheers -ben
>
>>> - Then we are starting to reverse engineering the ecompletion system
>>> and I'm learning it.
>>> I would like to know if Calypso can communicate with ecompletion the
>>> fact that we are defining a method. Then I have to check how the
>>> system can know that we are typing method argument when defining the
>>> signature but I think that this is not related to calypso.
>>>
>>> Stef
>>>
>

Stephane Ducasse-3

Re: interactive method definition (was Re: Calypso wishlist)

> Is this your ideal, or mainly to align with Tonel? Because it seems Tonel
> was developed
> without much consideration of interactive method definition -- which is fine
> in as much as
> Tonel was designed to quickly overcome a specific problem with Windows+Git,
> but it
> Tonel shouldn't be set in stone since its introduction changes the
> environment
> and stimulates further thinking on requirements.

Not only. We decided that the methods syntax in tonel could be used in browser
and in email. I have this proposal since before ESUG in lugano (2005)
so I really thought about it
a lot. This is not by accident that the code in all my book follow
nearly this shape.
The tonel structure is nice because it mimics also other languages.

fooSignature {

}

> Amongst your many priorities, could you ask someone familiar with changing
> compiler syntax
> have a serious look at implementing both ways:
> 1. Tonel syntax for interactive method definition

Yes but we are really busy
And yes we want this. So we should do it.

> 2. Named block parameters for interactive method definition

2 mega sucks.
And we will not do it. Sorry.

> to determine practically which one is preferred and easier to support.

I will veto 2. And I will be really strong on it.
I'm teaching Pharo and this is enough.

> And feed that into determining whether syntax should adapt to Tonel
> or whether Tonel should adapt to the latter. It would be better to do this
> earlier while Tonel is young before it becomes more widely used by other
> dialects.

Tonel method definition will not change.

> Also btw, would having named block parameters possibly unify more methods
> and blocks?
> (only a random thought, I'm not familiar with the low level distinction)

This is not because they look the same that in the conceptual model
they should.
Now I would like to have optional parameter value (but it can be a bit
touchy since there
are many design decision to take and it impacts senders and the rest.

>
> cheers -ben
>
>
> P.S. should Tonel include a format-version field on the first line?
> Its seems a good practice even if the format never does change for a long
> time.

Tonel has a property file that encodes metadata.

Stephane Ducasse-3

Re: interactive method definition (was Re: Calypso wishlist)

In fact I'm stupid because I already coded it by extending the parser
and I lost the code.
I should look around or redo it.

On Sat, Feb 10, 2018 at 7:10 PM, Stephane Ducasse
<[hidden email]> wrote:

>> Is this your ideal, or mainly to align with Tonel? Because it seems Tonel
>> was developed
>> without much consideration of interactive method definition -- which is fine
>> in as much as
>> Tonel was designed to quickly overcome a specific problem with Windows+Git,
>> but it
>> Tonel shouldn't be set in stone since its introduction changes the
>> environment
>> and stimulates further thinking on requirements.
>
> Not only. We decided that the methods syntax in tonel could be used in browser
> and in email. I have this proposal since before ESUG in lugano (2005)
> so I really thought about it
> a lot. This is not by accident that the code in all my book follow
> nearly this shape.
> The tonel structure is nice because it mimics also other languages.
>
> fooSignature {
>
> }
>
>
>> Amongst your many priorities, could you ask someone familiar with changing
>> compiler syntax
>> have a serious look at implementing both ways:
>> 1. Tonel syntax for interactive method definition
>
> Yes but we are really busy
> And yes we want this. So we should do it.
>
>> 2. Named block parameters for interactive method definition
>
> 2 mega sucks.
> And we will not do it. Sorry.
>
>
>> to determine practically which one is preferred and easier to support.
>
> I will veto 2. And I will be really strong on it.
> I'm teaching Pharo and this is enough.
>
>> And feed that into determining whether syntax should adapt to Tonel
>> or whether Tonel should adapt to the latter. It would be better to do this
>> earlier while Tonel is young before it becomes more widely used by other
>> dialects.
>
> Tonel method definition will not change.
>
>
>> Also btw, would having named block parameters possibly unify more methods
>> and blocks?
>> (only a random thought, I'm not familiar with the low level distinction)
>
> This is not because they look the same that in the conceptual model
> they should.
> Now I would like to have optional parameter value (but it can be a bit
> touchy since there
> are many design decision to take and it impacts senders and the rest.
>
>
>
>>
>> cheers -ben
>>
>>
>> P.S. should Tonel include a format-version field on the first line?
>> Its seems a good practice even if the format never does change for a long
>> time.
>
> Tonel has a property file that encodes metadata.