Slices time complexity
Rustom Mody
rustompmody at gmail.com
Wed May 20 02:23:26 EDT 2015
On Wednesday, May 20, 2015 at 11:27:56 AM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 20 May 2015 14:30, Rustom Mody wrote:
>
> > And what about Java?
> > http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
> semantics
>
> Congratulations, you have found yet another example of the Java community's
> collective delusion and insistence on misusing terms for the maximum
> confusion possible.
>
> The mental gymnastics they go through to force the round peg of pass-by-
> sharing object semantics into the false dichotomy "pass-by-value versus
> pass-by-reference" is just crazy.
>
> One consequence of this is that the meaning of "call by value" depends on
> whether the value you are talking about is a boxed or unboxed value. Unboxed
> values are copied. Boxed values are not. Except that they are, if you
> understand that "the value" doesn't refer to the actual value, but to some
> hidden and implementation-dependent reference to the value.
>
> To quote Fredrik Lundh:
>
> well, I guess you can, in theory, value an artificial number
> assigned to an object as much as the object itself.
>
> "Joe, I think our son might be lost in the woods"
> "Don't worry, I have his social security number"
>
>
> http://effbot.org/zone/call-by-object.htm
>
>
> Rustom, if you are serious about this approach, then the implication is that
> if I execute "x = 23" in Python, and I ask you what the value of x is, you
> should answer something like "146588120" (that's the implementation
> dependent "value", i.e. the address of the int 23).
>
> It's just *nuts*, and all because the Java folks are unwilling or unable to
> distinguish between the language semantics and the implementation of the
> language. And you're falling into the same hole.
I am not arguing for the java-folks terminology or outlook.
I am arguing that for languages that execute on von Neumann machines memory
is not an optional negotiable concept.
And pointer is just first-classed memory as lambda is first-classed function.
Some languages firstclass it -- most notably C, also C# which increasingly fascinates me in its choices.
Others try to to unfirstclass , ie hide it in various half-assed ways -- Python, Java, Lisp.
Others try to hide it in the most heavy-handed way possible -- haskell
But you can never really hide it [law of leaky abstractions]
eg in haskell one makes an infinite list of ones thus
ones = 1 : ones
Now if you generalize this to
repeat x = x : repeat x
and then do
ones = repeat 1
you get poorer performance because the ones makes a box-n-arrow loop which the
repeat does not achieve.
To get round that we do
repeat x = repeatx
where repeatx = x : repeatx
In short any language that is implemented on von Neumann hw will need to address
memory. The language-designer may believe that there is a choice to 'unfirstclass' it. However people discussing language have no such choice:
If you dont have it in the formal implemented language, you must have it in the
informal discussion-language
[With a large amount of wild waving of hands]
<Admission>
I dont like teaching this. viz that in python
x = [[1,2],[1,2]]
is equal to y defined as
z = [1,2]
y = [z,z]
And although they are equal as in '==' they are not equal as in behavior, memory usage etc, a fact that can only be elucidated by box-n-arrow diagrams.
So as far as I can I teach by tabooing extend,append and all such mutablers
In the end though this is cheating
</Admission>
More information about the Python-list
mailing list