Slices time complexity

[Rustom Mody]

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>