Why does Newspeak force argument order?

[Igor Polyakov]

I understand that the compiled versions need the correct argument order, but what's stopping the compiler from rearranging the arguments in the canonical order?

Is there any case where we don't want someone to write

'blah' startingAt: 1 indexOfAnyOf: 'ah' instead of  'blah' indexOfAnyOf: 'ah' startingAt: 1

It seems to me those should give an identical result. In fact, you have ifTrue:IfFalse along with ifFalse:ifTrue in the True/False classes. It seems to me you could extend this to every function fairly easily. If anything, I'd like there to be a restriction on writing something like startingAt:indexOfAnyOf: and implementing it differently (!)

[Brian Rice]

My interpretation is that looking up symbol names is easier this way, is inherited from Smalltalk-80, and normalizes reading order for humans. A longer explanation is inline below:

On Mon, Aug 27, 2012 at 8:52 PM, Igor Polyakov <iop...@gmail.com> wrote:

I understand that the compiled versions need the correct argument order, but what's stopping the compiler from rearranging the arguments in the canonical order?

You would require a canonical normalizing order which might complicate method naming and lookup.

 

Is there any case where we don't want someone to write

'blah' startingAt: 1 indexOfAnyOf: 'ah' instead of  'blah' indexOfAnyOf: 'ah' startingAt: 1

I notice immediately that you picked keyword selectors with prepositional forms. Not all selectors conform to this convention.

For example, one might write:

3 add: 4 andThenMultiplyBy: 5

and expect 35, but "3 andThenMultiplyBy: 5 add: 3" reads like nonsense and is more difficult to read. The selector in this case has encoded a sequential interpretation in the phrase you read mentally. This is cribbed from English, of course, so may not be natural to everyone, but that's the tradition so far.

 

It seems to me those should give an identical result. In fact, you have ifTrue:IfFalse along with ifFalse:ifTrue in the True/False classes. It seems to me you could extend this to every function fairly easily. If anything, I'd like there to be a restriction on writing something like startingAt:indexOfAnyOf: and implementing it differently (!)

I think you haven't considered enough keyword selector forms, but you could try your proposed dialect as an experiment over Smalltalk.

On the other hand, Slate (my dialect) went about this in a different way. Slate decided to have re-orderable optional keyword arguments, so that this selector becomes:

'blah' indexOfAnyOf: 'ah' &start: 1

where &start is bound optionally and can occur in any order (after the main selector, which is what's used for lookup). One might include an &end as well; I found that this handled the prepositional case and allowed for re-ordering while indicating "primary" vs. "secondary" arguments. Note that I read the "&" prefix as "with".

--
-Brian T. Rice

[Gilad Bracha]

H iIgor,

On Mon, Aug 27, 2012 at 8:52 PM, Igor Polyakov <iop...@gmail.com> wrote:

I understand that the compiled versions need the correct argument order, but what's stopping the compiler from rearranging the arguments in the canonical order? 

 Brian explained this better than I will.

We have changed the Smalltalk syntax in small ways out of necessity - class nesting dictated implicit receivers for example. We might change a few more things over time, but this isn't one of them. However, overall the keyword message syntax has worked very well in Smalltalk and Self (and, in disfigured form, in Objective-C).

I see no advantage to this specific change. Not only does the compiler have to rearrange method names (and calls) - so does the reflective system. This means it would have to parse the symbols representing method names and then rearrange them before submitting them to the run time. And of course, humans have to rearrange this in their heads too.

In short, such a change adds complexity and adds no real expressive power.  That is ungoodthinkful.

--
Cheers, Gilad

[Vassili Bykov]

As a use case of keyword permutations with useful information encoded
in their order, expanded:collapsed: and collapsed:expanded: in
Hopscotch both combine two presenters into a disclosure panel, but the
initial state of one is expanded and the other one is collapsed. And I
bet anyone can guess which is which.

[Igor Polyakov]

Ruby 2.0 doesn't enforce order:

http://globaldev.co.uk/2013/03/ruby-2-0-0-in-detail/

As a native Slavic language speaker this is more natural to me as Slavic languages don't encode any information in word order. I still can't remember whether it's at:put: or put:at: (from lack of practice, obviously)

in PHP it's an order of magnitude worse: the needle and the haystack are in random order, depending on which function you call

[Frank Shearar]

On 13 March 2013 17:17, Igor Polyakov <iop...@gmail.com> wrote:
> Ruby 2.0 doesn't enforce order:
> http://globaldev.co.uk/2013/03/ruby-2-0-0-in-detail/
>
> As a native Slavic language speaker this is more natural to me as Slavic
> languages don't encode any information in word order. I still can't remember
> whether it's at:put: or put:at: (from lack of practice, obviously)
> in PHP it's an order of magnitude worse: the needle and the haystack are in
> random order, depending on which function you call

Neither Newspeak nor Smalltalk use keyword arguments. In Ruby these
are not arguments, they are dictionary keys. To be precise: in

method at: 1 put: 2

we have a method called :method taking a single dictionary as
parameter, in which are two keys :at and :put. It's identical to

method(:at => 1, :put => 2)

I don't know how much experience you have in working with these kinds
of methods. I have, and I hate it. You look at the method definition
and you have NO IDEA what parameters the method should take. You have
to manually scan the method looking for dictionary access - which can
occur in multiple ways (opt[:foo] or opt.fetch(:foo)) - and hope that
you haven't missed something, or someone hasn't done something extra
clever with the dictionary like merge it with other dictionaries.

It's a terrible way to program.

frank

> --
> You received this message because you are subscribed to the Google Groups
> "Newspeak Programming Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to newspeaklangua...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>