++ -- again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

++ -- again

TedVanGaalen
Thanks Tobias and Igor for your thoughts about this increment/decrement theme.
@Tobias: what kind of side effect(s) are you talking about? I don't
understand, sorry.

@Igor, Yes, I completely agree with you that Smalltalk should not
transform to a C++ like dialect.  At first, I simply would like wanted
++ -- (monadic) and for that matter also += -=  *= and /=  (dyadic) as
messages for the Integer classes, possibly as primitive methods.

But then again, If this would be implemented, I can imagine people
using ugly and hard to read statement trains like
anotherInt += anInt ++ * 1234 ,
I don't find these constructs very nice either.. So, after realizing
this.. perhaps you're right: just let it be.  (probably would have
needed here () as wel)
Greetings from Ravensburg area
TedvG

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Igor Stasenko
On 20 April 2011 23:18, Ted F.A. van Gaalen <[hidden email]> wrote:

> Thanks Tobias and Igor for your thoughts about this increment/decrement theme.
> @Tobias: what kind of side effect(s) are you talking about? I don't
> understand, sorry.
>
> @Igor, Yes, I completely agree with you that Smalltalk should not
> transform to a C++ like dialect.  At first, I simply would like wanted
> ++ -- (monadic) and for that matter also += -=  *= and /=  (dyadic) as
> messages for the Integer classes, possibly as primitive methods.
>
> But then again, If this would be implemented, I can imagine people
> using ugly and hard to read statement trains like
> anotherInt += anInt ++ * 1234 ,
> I don't find these constructs very nice either.. So, after realizing
> this.. perhaps you're right: just let it be.  (probably would have
> needed here () as wel)

Yes.
As to me it is simply not worth to dedicate a special operator for
increment or decrement.
It makes no sense, considering how many other operators you could
imagine, and considering how often
you using value increment in smalltalk.
If you do things right, you don't need to write it by yourself ,
because it is done once in #to:do: and/or #do: loops.
So, it is really very small number of use cases where you may need to
use increment or decrement.
Unlike from C, where you will use ++ or -- on almost every loop , in
smalltalk for loops you using collections and closures,
incread of manually writing them again and again.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Tobias Pape
In reply to this post by TedVanGaalen

Am 2011-04-20 um 22:18 schrieb Ted F.A. van Gaalen:

> Thanks Tobias and Igor for your thoughts about this increment/decrement theme.
> @Tobias: what kind of side effect(s) are you talking about? I don't
> understand, sorry.

No problem, I wrote a bit complicated.
What I mean is that
        i++
instructs the object ‘i’ to change its state, ie, increment
itself.
However, the Object in ‘i’ is meant to be an
integer. So, how to interpret that? say, ‘i’ is 5.
Essentially,
        i++
says
        ‘five, change your state to be six’
But that would imply, because all integers are the respecive same
over the image, that all fives are suddenly sixes.

The point is,
in C, variables denote memory cells, and it is a common
operation to say ‘memory cell, increment your content by one’,
whereas in Smalltalk, a variable denotes an object and
such an increment is rather senseless on integer objects.

In other words, each integer in a Smalltalk image is
a kind of Singleton.
( as
        1 = 1 " => true"
        1 == 1 " => true"
)
Hence,
| a b |
a := 1.
b := 1.
a = b " => true (a and b have the same content)".
a == b "=> true (ie, they are the indentical object)".

"but"

a ++. "hypothetical"
a = b "=> ??, probably false".
a == b " => ??, can't think of that".


So Long,
        -Tobias










Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Igor Stasenko
On 21 April 2011 07:58, Tobias Pape <[hidden email]> wrote:

>
> Am 2011-04-20 um 22:18 schrieb Ted F.A. van Gaalen:
>
>> Thanks Tobias and Igor for your thoughts about this increment/decrement theme.
>> @Tobias: what kind of side effect(s) are you talking about? I don't
>> understand, sorry.
>
> No problem, I wrote a bit complicated.
> What I mean is that
>        i++
> instructs the object ‘i’ to change its state, ie, increment
> itself.
> However, the Object in ‘i’ is meant to be an
> integer. So, how to interpret that? say, ‘i’ is 5.
> Essentially,
>        i++
> says
>        ‘five, change your state to be six’
> But that would imply, because all integers are the respecive same
> over the image, that all fives are suddenly sixes.
>
> The point is,
> in C, variables denote memory cells, and it is a common
> operation to say ‘memory cell, increment your content by one’,
> whereas in Smalltalk, a variable denotes an object and
> such an increment is rather senseless on integer objects.
>
> In other words, each integer in a Smalltalk image is
> a kind of Singleton.
> (       as
>        1 = 1 " => true"
>        1 == 1 " => true"
> )
> Hence,
> | a b |
> a := 1.
> b := 1.
> a = b " => true (a and b have the same content)".
> a == b "=> true (ie, they are the indentical object)".
>
> "but"
>
> a ++. "hypothetical"
> a = b "=> ??, probably false".
> a == b " => ??, can't think of that".
>

yes, because variables in smalltalk are references to objects. and
variables in C are memory pointers.

A ++ operator is evil, because you cannot override or redefine it
(like any other message). And it works only for numbers (no pointers
in smalltalk)
and so, completely falls out of object model.


>
> So Long,
>        -Tobias
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Lukas Renggli
> A ++ operator is evil, because you cannot override or redefine it
> (like any other message).

In C++ you can.

> And it works only for numbers (no pointers
> in smalltalk)
> and so, completely falls out of object model.

It can be done and has been done in Helvetia without falling out of
the object model.

I don't remember the details, but I was essentially rewriting

    i++

to something along

    i increment: [ :v | i := v ]

where you the semantics of #increment: are implemented in the objects
as you wish. For numbers this would be something like:

    Number>>#increment: aBlock
        ^ aBlock value: self + 1

For other objects other 'meaningful' implementations can be added, for example:

    SequenceableCollection>>#increment: aBlock
        ^ aBlock value: self allButFirst , (Array with: self first)

    Stream>>#increment: aBlock
        ^ aStream skip: 1

    etc.

Cheers,
Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Igor Stasenko
On 21 April 2011 17:37, Lukas Renggli <[hidden email]> wrote:
>> A ++ operator is evil, because you cannot override or redefine it
>> (like any other message).
>
> In C++ you can.
>

yep.. been there

>> And it works only for numbers (no pointers
>> in smalltalk)
>> and so, completely falls out of object model.
>
> It can be done and has been done in Helvetia without falling out of
> the object model.
>
> I don't remember the details, but I was essentially rewriting
>
>    i++
>
> to something along
>
>    i increment: [ :v | i := v ]
>
> where you the semantics of #increment: are implemented in the objects
> as you wish. For numbers this would be something like:
>
>    Number>>#increment: aBlock
>        ^ aBlock value: self + 1
>
> For other objects other 'meaningful' implementations can be added, for example:
>
>    SequenceableCollection>>#increment: aBlock
>        ^ aBlock value: self allButFirst , (Array with: self first)
>
>    Stream>>#increment: aBlock
>        ^ aStream skip: 1
>
>    etc.
>

So, what is your point? Yes, we can extend a syntax. And with Helvetia
this is piece of cake.
The question -  do we need it so much that want to sacrifice a syntax
simplicity, consistency and clarity for that? (outside of serving as
an example of extending syntax ;)

Well, yeah, we can introduce weird stuff at any moment. Things like
macros or quasi-quotes will eventually turn once self-explanatory
smalltalk code into DSL, where only author can understand what it
does...
I am fine with having DSLs around with any possible extensions that
people may want them to be. But making it to be default syntax? Hell
no!

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Lukas Renggli
> So, what is your point?

To prove your (quoted) sentence wrong: "And it works only for numbers
(no pointers
in smalltalk) and so, completely falls out of object model."

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

Igor Stasenko
On 21 April 2011 18:06, Lukas Renggli <[hidden email]> wrote:
>> So, what is your point?
>
> To prove your (quoted) sentence wrong: "And it works only for numbers
> (no pointers
> in smalltalk) and so, completely falls out of object model."
>

Sure it is. Unless you turn it into message send with trick which you
described above.
But then it become even worse from performance point of view, because
of use of block closure for doing simple increment.

so, people will be punished from using

i++

instead of

i := i + 1

which i finding amusing :)


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: ++ -- again

TedVanGaalen
'dnanietiM izeürG' asSchweizerString reversed, '!'

O dear, I've really stirred up++ things :o)

Coincidently I, was in Helvetiae today, 110 km from where
I currently live (Ravensburg) near Appenzell,
had an unprepared ascend++  from Wasserau to the
higher Seealpsee. So beautiful. Lungs bursting, heart pumping.
but now i feel good! Get away from those screens from time to time!

New for me: Looked up Helvetia in a bird's eye view. thanks.
Will read more there too.
How far does one go?  I do like the SQL extension though.

Not that I am important or so, far from it, but you can read more
about me on linkedIn.
I am trying to switch from many other languages/systems
to Smalltalk, with the goal of finding a job where I can use it
sooner better than later.

I did often mainframe (PL/1, Cobol, DB2) projects with the same kind of fun
as someone working on old locomotives on a historic railway.

I have made my CV as a Seaside Smalltalk app,
could put it in a Monticello package and would like to ask
you to take a look at it and tell me how I am doing?
If so: but where to place the .mcz?
it contains a html tree as well.
The idea is to put it on a Seaside server
for everyone to see.(especially those
who could employ me, as i am currently without work)
There will be more than just the CV,
e.g. UML diagrams and a technical description.


Thanks.
Won't write so much off topic next time, sorry :o)



















On Thu, Apr 21, 2011 at 7:19 PM, Igor Stasenko <[hidden email]> wrote:

> On 21 April 2011 18:06, Lukas Renggli <[hidden email]> wrote:
>>> So, what is your point?
>>
>> To prove your (quoted) sentence wrong: "And it works only for numbers
>> (no pointers
>> in smalltalk) and so, completely falls out of object model."
>>
>
> Sure it is. Unless you turn it into message send with trick which you
> described above.
> But then it become even worse from performance point of view, because
> of use of block closure for doing simple increment.
>
> so, people will be punished from using
>
> i++
>
> instead of
>
> i := i + 1
>
> which i finding amusing :)
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>