Prev: Exposing contained types.. Especially LISTS
Next: Layer integrity versus polymorphism
From: S Perryman on 18 Dec 2007 12:14
Paolo Bonzini wrote:

>>moveLeft(Distance distance, Speed speed)
>>{
>> this.target =
>> new Vector(this.position.x() - distance.value(), this.position.y())
>> this.speed = speed ;
>>
>>}

> Yes, but then you invoke this as

> s.moveLeft distance: 3.meters, speed: 5.mph

> which loses the "English-ness" claimed in the Groovy article. Using
> variables called "at" and "left" is mandatory in Groovy if you want to
> keep the English-like naming of methods.

>>The converse drawback in Smalltalk does not appear to be as easily overcome
>>(weak typing etc) .

> I don't see how weak typing helps or hinders the problem that you
> cannot write both of
>
> s moveLeft: 5 meters at: 3 mph
> s at: 3 mph moveLeft: 5 meters

The problem comes with the change to the conflict between the required
change to the Smalltalk dispatch mechanism, and op names. Here is the
problem :

monster moveLeft: distance at: speed
monster at: time24Hour moveLeft: distance

The signatures are moveLeft:at: and at:moveLeft.
The existing dispatch scheme is sequential, so the following are
differentiated :

m moveLeft: 5 at: 5
m at: midnight moveLeft: 5


Position-independent keyword parameters changes the dispatch to be
based on a map, not a sequence. Now when we have :

m moveLeft: 5 at midnight

there is a conflict as there are two ops that can be invoked.
This particular conflict is actually resolveable in strongly-typed prog
langs, as the 24 hr time type is not compatible with the first signature.
But weakly-typed prog langs do not have that information to hand.

This fact is also the reason why Lisp etc could allow multiple defs of the
same keyword in an op signature (except for case akin to the example
above) .


Regards,
Steven Perryman
From: S Perryman on 18 Dec 2007 15:48
Paolo Bonzini wrote:

[ example snipped ... ]

> Sure. Thanks for this example, it is very clear (calling methods like
> that in Smalltalk would be considered very poor style, but that's okay
> for the sake of exemplification).

But the issue is worse than poor style, because the example actually
affects which op gets invoked in a Smalltalk env.

In a strongly-typed prog lang, it is merely multiple operations with the
same name but different signatures (keyword parameters defined or not) .


> However, this is not a problem with Smalltalk vs. Lisp keywords; it's
> just the lack of multimethods.

Lisp etc doesn't need multiple dispatch to solve the issues we are
discussing here (that would be using a sledgehammer to crack a nut) .


Regards,
Steven Perryman
From: S Perryman on 20 Dec 2007 04:18
Paolo Bonzini wrote:

>>In a strongly-typed prog lang, it is merely multiple operations with the
>>same name but different signatures (keyword parameters defined or not) .

> Allowing different signatures but basing the dispatch on static types
> (i.e. not having multimethods) is broken by design. Anyway, this
> thread was on keywords, not on typing.

Indeed.
But the problem I described for Smalltalk and position-independent
keyword parameters is a problem precisely because of typing.

In order to remove the problem you have deemed such scenarios "poor
style" when it actually is quite reasonable. Or suggested the use of
multiple dispatch, which as I stated is a "sledge-hammer to crack a
nut" .

My point still remains.
There are better prog langs than Smalltalk to base keyword parameter
syntax/semantics on.


Regards,
Steven Perryman
From: Stefan Schmiedl on 20 Dec 2007 18:26
On Thu, 20 Dec 2007 13:50:33 -0800 (PST)
johnt <trinderjohn(a)dsl.pipex.com> wrote:

> I'm not an expert like you guys, but it seems to me you're mixing the
> debate up on 2 key issues -
>
> (1) code readability
> (2) writeability
>
> For me readability has a much higher priority. Also, when writing code
> in Smalltalk it's pretty easy to look up messages and if there's
> autocomplete, so much the better.

I have worked with Lisp environments where seeing the definition of
a function was just a keypress (Meta-. IIRC) away.

> But for readability, surely ST beats Lisp hands down. I'm thinking of
> all the brackets that have to be used as well as the poverty of pretty-
> print formatting of code in Lisp due it's syntactic simplicity.

I have worked with Lisp environments supporting syntax coloring, too.

And "readable" is what you have learned to read.

s.
From: Panu on 21 Dec 2007 23:40
S Perryman wrote:

> My point still remains.
> There are better prog langs than Smalltalk to base keyword parameter
> syntax/semantics on.

I think it is misguided to phrase the issue in terms of
which programming language "is better". Rather it should
be about the benefits of particular syntactic conventions
chosen. In the end perhaps this discussion will enhance
the next version of each language involved.

My original post was inspired by my perception that many
main-stream languages seem to adapt features from Smalltalk
at a slow pace, yet always going in its direction. To start
with, C++ made C more like Smalltalk by adopting 'methods'.
Groovy introduced closures to java, and now now they are
adopting keyword arguments as well.

I grant that the beauty here may be in the eye of the beholder.
Since Lisp inspired many features of Smalltalk, you can argue
that the trend is towards Lisp-like features as well.

I'm curious: did the keyword arguments appear first in
Lisp, or in Smalltalk?

The interesting question to me is, is it better to require
a fixed order of keyword arguments or not? I'm inclined
to think the former, but I'm open to all arguments in favor
of the latter.


-Panu Viljamaa

 |  Next  |  Last
Pages: 1 2 3
Prev: Exposing contained types.. Especially LISTS
Next: Layer integrity versus polymorphism