Smalltalk › Squeak › Squeak - Dev

Any reason for assigning block parameter in inject:into:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

43 messages Options

123

Bert Freudenberg

Re: Any reason for assigning block parameter in inject:into:

Well in 3.8 that method reads like this:

String>>asPacked
"Convert to a longinteger that describes the string"

^ self inject: 0 into: [ :pack :next | pack := pack * 256 + next
asInteger ].

And the assignment is meaningless, perhaps the author did not fully
understand #inject:into:. It should certainly be removed.

- Bert -

On Apr 29, 2007, at 14:38 , nicolas cellier wrote:

> Hi Lukas,
>
> I perfectly understand your argument. duplicating args in
> temporaries is bad.
>
> But you reformulate Tim so well: It might also confuse beginners,
> that i cannot believe you did not understand him.
> He did not mean anything else.
>
> And I feel like the example given by stephane is exactly a case of
> such confusion.
>
> asPacked
> ^ self
> inject: 0
> into: [:t1 :t2 | t1 := t1 * 256 + t2 asInteger]
>
> unless it is just an effect of Decompiler?
> Who would name block variables t1 and t2 but the Decompiler?
>
> However, stupid me, one thing I cannot understand is the reason to
> do so for ImageSegment. Any light on this?
>
>
> Nicolas
>
> Lukas Renggli a écrit :
>>> Perhaps if you think of it along the lines of:-
>>> a) names in a method are just local tags for programmer convenience
>>> so that you don't have to keep it all in your head as you read/write
>>> code,
>>> b) objects passed into the method as parameters are bound to the
>>> parameter tags;
>>> it might help.
>> I don't understand what you mean.
>> Temps and method and block arguments are all slots in some context
>> object. It is only the compiler that tries to stop you in an
>> inconsistent way from assigning to some of these slots. I initially
>> asked because I find that an unnecessary restriction. Usually the
>> philosophy of Smalltalk is to open the possibilities that the
>> programmer has, not to arbitrarily restrict them.
>> I don't say it is good style to assign to arguments. It might also
>> confuse beginners, I agree. I don't even suggest to change the
>> language. I only asked why this restriction was made in the first
>> place. Luckily you can always use the debugger/inspector or
>> thisContext tempAt:put: (there are a few methods that actually do
>> that
>> in the standard image) to change these values.
>> Lukas
>
>

Bert Freudenberg

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Colin Putney

On Apr 29, 2007, at 16:09 , Colin Putney wrote:

> On Apr 29, 2007, at 10:03 AM, tim Rowledge wrote:
>
>> Assigning some new object to the tag used for a parameter is
>> confusing and pointless because it can have no effect outside the
>> local context despite *looking like* it might replace the object
>> to someone not familiar. To prevent that confusion, the compiler
>> prevents the assignment.
>
> Interesting. As far as I can tell, you're the only poster in this
> thread that thinks assigning to a parameter name implies that the
> parameter was passed by reference. Lukas was just complaining that
> parameter slots are read-only, and giving examples of cases where
> it would be nice to be able to write to them. I occasionally feel
> this way too - making parameters different from other temps feels
> arbitrarily inconsistent.
>
> I wonder if this is a sign of changing times. After all,
> "confusion" is a mismatch between expectations and reality. Perhaps
> were seeing a change in expectations? Back in the days of yore,
> people were coming to Smalltalk from low-level languages where it
> was possible to pass pointers around, and returning a value through
> a pass-by-reference parameter was a common idiom. These days,
> people who are interested in Smalltalk are probably coming from
> other dynamic languages where that's not possible, and treating
> parameters as just another temp feels natural.
>
> Personally, I think it would be nice to be able to write to
> parameter slots, but it's not worth breaking compatibility with
> other Smalltalks.

+1

I wouldn't expect assigning to a variable to affect the sending
method. I think of method arguments as temps. Which they are, in
Squeak at least. I actually don't see a compelling reason to disallow
assigning to method args, except for stylistic ones.

I'd argue similarly for block parameters, but the current compiler
does not do the Right Thing when assigning to them in some
situations. It's unacceptable to get different results for these two
expressions:

Array streamContents: [:s | (1 to: 5) do: [:i | s nextPut: (i := i +
1)]]

Array streamContents: [:s | 1 to: 5 do: [:i | s nextPut: (i := i + 1)]]

The optimization of #to:do: expects the block parameter to not be
assigned to.

- Bert -

timrowledge

Re: Any reason for assigning block parameter in inject:into:

The difference is that both you, Bert, and Colin are quite versed in
Smalltalk. Anyone looking at Smalltalk as if it were C or some other
dismal bit-mangling nonsense might very well be seeing the method
parameter(s) as pointers.

Whatever we think about reasons, the definition is that method
parameters and and block args are not supposed to be assigned to; we
should make sure the compiler enforces that properly.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I asked Mom if I was a gifted child ... she said they certainly
wouldn't have paid for me.

Bryce Kampjes

Re: Any reason for assigning block parameter in inject:into:

tim Rowledge writes:
> The difference is that both you, Bert, and Colin are quite versed in
> Smalltalk. Anyone looking at Smalltalk as if it were C or some other
> dismal bit-mangling nonsense might very well be seeing the method
> parameter(s) as pointers.

C copies the arguments and allows you to change them. Just
like Smalltalk would if we allowed arguments to be changed.
I think Pascal didn't allow arguments to be changed. Personally
I'm happy with the status quo, but could live with mutable
arguments too.

Bryce

keith1y

Re: Any reason for assigning block parameter in inject:into:

[hidden email] wrote:

> tim Rowledge writes:
> > The difference is that both you, Bert, and Colin are quite versed in
> > Smalltalk. Anyone looking at Smalltalk as if it were C or some other
> > dismal bit-mangling nonsense might very well be seeing the method
> > parameter(s) as pointers.
>
> C copies the arguments and allows you to change them. Just
> like Smalltalk would if we allowed arguments to be changed.
> I think Pascal didn't allow arguments to be changed. Personally
> I'm happy with the status quo, but could live with mutable
> arguments too.
>
> Bryce
>

Dont forget this is squeak, where at this language level no one agrees
and nothing changes, and we are probably destined never to have
namespaces either.

Actually on this issue the status quo has been something I have looked
at and got annoyed with many times. Thinking - why do I have to create a
method temporary with the same 'role suggesting instance variable name',
when all I want to do is coerce the item into a known type, before using it.

regards

Keith

timrowledge

Re: Any reason for assigning block parameter in inject:into:

On 29-Apr-07, at 4:18 PM, Keith Hodges wrote:

> all I want to do is coerce the item into a known type, before
> using it.

Aaaaaaaaaaaaarrrrrrrghh! <runs screaming down the hall waving arms>

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- MAZEL TON - Lots of luck

keith1y

Re: Any reason for assigning block parameter in inject:into:

>
> Aaaaaaaaaaaaarrrrrrrghh! <runs screaming down the hall waving arms>
Could you waive them in the direction to point me to the code where I
can change the compiler to enable assignment to method params please.

Keith

Vassili Bykov-2

Re: Any reason for assigning block parameter in inject:into:

I find if completely natural to expect to be able to assign to
arguments, and for reasons entirely unrelated to Javascript. An
argument is a binding in the environment created for evaluating the
body of a lambda expression when it is applied, and as such there is
no fundamental difference between it an a temporary variable. I see

| a |
a := 3.
a := a + 4

and

[:a | a := a + 4] value: 3

as the same thing. In this light, I see the "classic" policy of
disallowing the latter as an arbitrary restriction, even when
supported by emphatic hand-waving.

Oh, and the VisualWorks compiler has a configuration option to allow
assignments to arguments.

--Vassili

Alan L. Lovejoy

RE: Any reason for assigning block parameter in inject:into:

<Vassili>I see the "classic" policy of disallowing the latter as an
arbitrary restriction, even when supported by emphatic
hand-waving.</Vassili>

I concur. The restriction on assignment to arguments simply creates an
unnecessary semantic distinction between arguments and other variables, and
so adds complexity to the denotational semantics of Smalltalk syntax. It's
not as bad as Java's distinction between objects and primitive values, but
it's a language design flaw of the same sort.

Bindings/assignments are not axioms, and Smalltalk is not a logic/functional
programming language. Immutable bindings belong in a language where all
bindings are immutable.

--Alan

timrowledge

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Stéphane Ducasse-3

Clearly I'm going to have to just content myself with disagreeing. I
think you're all quite, quite mad.....

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Moves his lips to pretend he's reading.

Blake-5

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Bryce Kampjes

On Sun, 29 Apr 2007 14:52:45 -0700, <[hidden email]> wrote:

Traditional Pascal had only by-value arguments, I believe.

I think Turbo Pascal 1.0 introduced by-ref arguments--well, actually UCSD
Pascal probably introduced them earlier, and that was 25 years ago. (The
current iteration has by-value, by-ref changeable and by-ref NOT
changeable (as an optimization).

I don't really have a dog in this race but does it make sense to care what
someone coming from another language might think? Shouldn't internal
consistency be the primary consideration?

===Blake===

brad fowlow

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Colin Putney

I don't think it's quite that.

Assigning simply to parameters is rarely if ever 'magical'
in reaching up the call chain. (Among widespread languages,
one exception is the goulash of C++ reference parameters;
I can't think of others offhand.)

For the workaday C programmer,
there's a very big difference between arg = 3; and (*arg) = 3.
The distinction between 'what's in the local parameter' and
'what I have to do to change longer-lived state'
is always front and center in low-level languages.

I don't think the real confusion that's avoided
by barring assignment-to-arguments
isn't that of someone writing
param := foo
and expecting non-local effects up the call chain.

Rather it's the confusion of sorting out what's going on in a piece
of code
when someone's decided variable names are too much work to invent,
and reused parameter names for other quantities along the way.

When you're reading a piece of unfamiliar code, every bit of solid
ground helps;
knowing that the value of a parameter doesn't change in the course
of the method makes it that much easier to read and debug.

- brad

> I wonder if this is a sign of changing times. After all,
> "confusion" is a mismatch between expectations and reality. Perhaps
> were seeing a change in expectations? Back in the days of yore,
> people were coming to Smalltalk from low-level languages where it
> was possible to pass pointers around, and returning a value through
> a pass-by-reference parameter was a common idiom. These days,
> people who are interested in Smalltalk are probably coming from
> other dynamic languages where that's not possible, and treating
> parameters as just another temp feels natural.
>
> Personally, I think it would be nice to be able to write to
> parameter slots, but it's not worth breaking compatibility with
> other Smalltalks.
>
> Colin
>

J J-6

Re: default args (was Re: Any reason for assigning block parameterin inject:into

In reply to this post by Philippe Marschall

>From: "Philippe Marschall" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: default args (was Re: Any reason for assigning block
>parameterin inject:into:)
>Date: Sun, 29 Apr 2007 15:14:24 +0000
>
>Nicolas is right, this gets real messy, real fast. See Seaside:
>Canvas <-> HtmlBuilder
>
>Cheers
>Philippe

Well it is certainly true that the default argument pattern doesn't fit
everything. Doesn't canvas use a pattern of having an object with default
ivars that one can modify with mutator functions (i.e. a totally different
pattern then what was mentioned before)?

_________________________________________________________________
Mortgage rates near historic lows. Refinance $200,000 loan for as low as
$771/month*
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f8&disc=y&vers=689&s=4056&p=5117

J J-6

Re: default args (was Re: Any reason for assigning block parameterin inject:into

In reply to this post by Lukas Renggli

>From: "Lukas Renggli" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: default args (was Re: Any reason for assigning block
>parameterin inject:into:)
>Date: Sun, 29 Apr 2007 17:39:54 +0200
>
>My example was a bit JavaScript biased, but wh about something like that?
>
>aString := aString asUppercase.
>aNumber := aNumber asInteger.
>...

Yea, ok, that does make more sense. I guess I just get nervous when someone
appears to me to suggest that we need something that other languages have to
have due to design issues.

Not that I have anything against JavaScript, I hear it is quite flexible in
many areas. It just sounds like default argument situations is not one of
those areas.

>In Smalltalk this literally translates to
>
> var := var ifNil: [ default ]
>
>This is rarely used in Smalltalk, however it is very similar to:
>
> var || (var = default);
> var ifNil: [ var := default ]

I usually see (and use) this for doing lazy initialization of ivars, I
haven't seen it for defaulting method arguments.

>>Nicolas is right, this gets real messy, real fast. See Seaside:
>>Canvas <-> HtmlBuilder
>
>Not just there, there are many other examples where framework
>designers had to rethink that approach because it stopped to scale.
>That's probably also a reason why there is the 'move method'
>refactoring. Selector prefixes for default arguments simply do not
>scale.

Selector prefixes? You mean the technique of providing shorter methods
which call the main method with default arguments? It is just a pattern, no
pattern makes sense in every possible situation. A few default-able
arguments is very manageable. More then that and one would probably want
some other pattern, not default arguments at all.

_________________________________________________________________
MSN is giving away a trip to Vegas to see Elton John. Enter to win today.
http://msnconcertcontest.com?icid-nceltontagline

J J-6

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Bert Freudenberg

>From: Bert Freudenberg <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Any reason for assigning block parameter in inject:into:
>Date: Sun, 29 Apr 2007 16:30:25 -0400
>
>+1
>
>I wouldn't expect assigning to a variable to affect the sending method. I
>think of method arguments as temps. Which they are, in Squeak at least. I
>actually don't see a compelling reason to disallow assigning to method
>args, except for stylistic ones.

I should probably mention that I am not stating an opinion against the
ability to assign to the variables. If it makes sense and doesn't hurt
anything then ok.

I'm simply against adding a feature to support some broken technique that we
shouldn't be using anyway. If there are other motivations, then I have no
issue with it.

_________________________________________________________________
Interest Rates NEAR 39yr LOWS! $430,000 Mortgage for $1,299/mo - Calculate
new payment
http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-19132&moid=14888

J J-6

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by keith1y

>From: Keith Hodges <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Any reason for assigning block parameter in inject:into:
>Date: Mon, 30 Apr 2007 00:36:01 +0100
>
>>Aaaaaaaaaaaaarrrrrrrghh! <runs screaming down the hall waving arms>
>Could you waive them in the direction to point me to the code where I can
>change the compiler to enable assignment to method params please.
>
>Keith

But once you do that, any code you write can only be used by people who have
your hack.

In Squeak the parameters are copies that just happen to be read-only, but is
it this way in the other dialects? I would expect the parameter to be
read-only, but I would expect that because I would expect at the low level
the "pointer" to the original location is being passed for efficiency (since
an object copy could be expensive) and therefor must be read-only.

_________________________________________________________________
Dont quit your job Take Classes Online and Earn your Degree in 1 year.
Start Today!
http://www.classesusa.com/clickcount.cfm?id=866146&goto=http%3A%2F%2Fwww.classesusa.com%2Ffeaturedschools%2Fonlinedegreesmp%2Fform-dyn1.html%3Fsplovr%3D866144

J J-6

RE: Any reason for assigning block parameter in inject:into:

In reply to this post by Stéphane Ducasse-3

>From: "Alan Lovejoy" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "'The general-purpose Squeak developers
>list'"<[hidden email]>
>Subject: RE: Any reason for assigning block parameter in inject:into:
>Date: Sun, 29 Apr 2007 17:47:04 -0700
>
>I concur. The restriction on assignment to arguments simply creates an
>unnecessary semantic distinction between arguments and other variables, and
>so adds complexity to the denotational semantics of Smalltalk syntax. It's
>not as bad as Java's distinction between objects and primitive values, but
>it's a language design flaw of the same sort.

But I thought lots of people here *wanted* optional read-only values, no?
If those are added as I have seen requested several times then how will we
distinguish *those*?

With the view given by most here, it does seem quite arbitrary. But with
the view that "the system wants that for efficiency" (even though it seems
that isn't the case in at least Squeak), it is actually the expected
behavior.

_________________________________________________________________
Download Messenger. Join the im Initiative. Help make a difference today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07

J J-6

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Bryce Kampjes

>From: <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Any reason for assigning block parameter in inject:into:
>Date: Sun, 29 Apr 2007 22:52:45 +0100
>
>C copies the arguments and allows you to change them. Just
>like Smalltalk would if we allowed arguments to be changed.
>I think Pascal didn't allow arguments to be changed. Personally
>I'm happy with the status quo, but could live with mutable
>arguments too.
>
>Bryce

That's true. C has only call-by-value semantics. Call-by-reference in C is
purely by convention.

However, I think what he is saying is: smalltalk is using references (i.e.
pointers to locations, but that I don't have to manage myself with
ref/dereffing), so if I pass a reference that is automatically dereffed, and
then change it, wont that change the original place? Think C++: if you see
a function take a &param and it isn't const then you know something funny is
going on (or you're looking at a bug).

_________________________________________________________________
Download Messenger. Join the im Initiative. Help make a difference today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07

Herbert König

Re: Any reason for assigning block parameter in inject:into:

In reply to this post by Colin Putney

Hello Colin,

CP> Interesting. As far as I can tell, you're the only poster in this
CP> thread that thinks assigning to a parameter name implies that the
CP> parameter was passed by reference. Lukas was just complaining that
CP> parameter slots are read-only, and giving examples of cases where it
CP> would be nice to be able to write to them. I occasionally feel this
CP> way too - making parameters different from other temps feels
CP> arbitrarily inconsistent.

in LISP I do this regularly. A parameter usually being a list which in
my function needs some preprocessing (e.g. removing collinear adjacent line
segments) but still has the same meaning after the preprocessing.

Funny thing is I never came across this in my Squeak programming.

This makes me wonder what will happen, when I start complementing my
LISP work (= bread and butter) with Squeak.

Cheers

Herbert mailto:[hidden email]

Philippe Marschall

Re: default args (was Re: Any reason for assigning block parameterin inject:into

In reply to this post by J J-6

2007/4/30, J J <[hidden email]>:

> >From: "Philippe Marschall" <[hidden email]>
> >Reply-To: The general-purpose Squeak developers
> >list<[hidden email]>
> >To: "The general-purpose Squeak developers
> >list"<[hidden email]>
> >Subject: Re: default args (was Re: Any reason for assigning block
> >parameterin inject:into:)
> >Date: Sun, 29 Apr 2007 15:14:24 +0000
> >
> >Nicolas is right, this gets real messy, real fast. See Seaside:
> >Canvas <-> HtmlBuilder
> >
> >Cheers
> >Philippe
>
> Well it is certainly true that the default argument pattern doesn't fit
> everything. Doesn't canvas use a pattern of having an object with default
> ivars that one can modify with mutator functions (i.e. a totally different
> pattern then what was mentioned before)?

Yeah, more or less. It does the traditional Smalltalk thingie: makes
an object of if.

Cheers
Philippe

> _________________________________________________________________
> Mortgage rates near historic lows. Refinance $200,000 loan for as low as
> $771/month*
> https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f8&disc=y&vers=689&s=4056&p=5117
>
>
>

123