Concatenating lists

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

Concatenating lists

Jan Erik Moström
Hi,

I've just started to learn Haskell and played around a bit and tried this

1: let x = [1,2,3]
2: let x = x ++ [4,5,6]
3: x

The last line doesn't give a result. I assume that this is because 'x' is a name of a value, in the second line I redefine 'x' to a new value but Haskell doesn't evaluate the value until the last line but then 'x' becomes recursively defined in itself (the second x on line 2 is interpreted to refer to the value of the first x on line 2 and  not the value defined in line 1). This behavior is caused by the lazy evaluation in Haskell.

Have I understood this correctly?

- jem




Reply | Threaded
Open this post in threaded view
|

Concatenating lists

Antoine Latter-2
On Thu, Mar 22, 2012 at 9:44 AM, Jan Erik Mostr?m <lists at mostrom.pp.se> wrote:

> Hi,
>
> I've just started to learn Haskell and played around a bit and tried this
>
> 1: let x = [1,2,3]
> 2: let x = x ++ [4,5,6]
> 3: x
>
> The last line doesn't give a result. I assume that this is because 'x' is a name of a value, in the second line I redefine 'x' to a new value but Haskell doesn't evaluate the value until the last line but then 'x' becomes recursively defined in itself (the second x on line 2 is interpreted to refer to the value of the first x on line 2 and ?not the value defined in line 1). This behavior is caused by the lazy evaluation in Haskell.
>
> Have I understood this correctly?
>

Yeah, that sounds right.

Antoine


Reply | Threaded
Open this post in threaded view
|

Concatenating lists

Lorenzo Bolla
In reply to this post by Jan Erik Moström
On Thu, Mar 22, 2012 at 2:44 PM, Jan Erik Mostr?m <lists at mostrom.pp.se>wrote:

> Hi,
>
> I've just started to learn Haskell and played around a bit and tried this
>
> 1: let x = [1,2,3]
> 2: let x = x ++ [4,5,6]
> 3: x
>
> The last line doesn't give a result. I assume that this is because 'x' is
> a name of a value, in the second line I redefine 'x' to a new value but
> Haskell doesn't evaluate the value until the last line but then 'x' becomes
> recursively defined in itself (the second x on line 2 is interpreted to
> refer to the value of the first x on line 2 and  not the value defined in
> line 1). This behavior is caused by the lazy evaluation in Haskell.
>
> Have I understood this correctly?
>

Yes.




>
> - jem
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20120322/63bb1e37/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Concatenating lists

Felipe Lessa
In reply to this post by Jan Erik Moström
On Thu, Mar 22, 2012 at 11:44 AM, Jan Erik Mostr?m <lists at mostrom.pp.se> wrote:

> Hi,
>
> I've just started to learn Haskell and played around a bit and tried this
>
> 1: let x = [1,2,3]
> 2: let x = x ++ [4,5,6]
> 3: x
>
> The last line doesn't give a result. I assume that this is because 'x' is a name of a value, in the second line I redefine 'x' to a new value but Haskell doesn't evaluate the value until the last line but then 'x' becomes recursively defined in itself (the second x on line 2 is interpreted to refer to the value of the first x on line 2 and ?not the value defined in line 1). This behavior is caused by the lazy evaluation in Haskell.
>
> Have I understood this correctly?

Your conclusion is correct, but your reasoning is not.  It's not due
to lazyness that x is recursively defined, it's because of the scope.
When you type your second x on the second line, that x will refer to
the closest (in scope) definition of something called x -- which is
the the definition of x on the second line itself.

Cheers,

--
Felipe.


Reply | Threaded
Open this post in threaded view
|

Concatenating lists

Jan Erik Moström
On 2012-03-22 at 16:12 , Felipe Almeida Lessa wrote:
> Your conclusion is correct, but your reasoning is not. It's not due
> to lazyness that x is recursively defined, it's because of the scope.
> When you type your second x on the second line, that x will refer to
> the closest (in scope) definition of something called x -- which is
> the the definition of x on the second line itself.

Aha, thanks for explaining. I didn't consider scope - I did some searching of scoping and need to think about that for a while, a bit different than 'normal'. However, I would like to ask one more thing:

Assume

let a = 5 + 3

Would 5+3 be calculated directly or would it be deferred to later?
Assume it's calculated and the value 8 is given the name 'a'. Then

let a = a + 4

What happens is that Haskell tries to evaluate the second 'a' on that line and then finds the first 'a' and enters into infinite recursion.

And this is what confuses me a little bit. I can type in 'let a = a + 4' and Haskell accepts it, the infinite recursion does not happen until I type 'a' to show the value, this makes me think that the evaluation is deferred to later (and also why I asked about 5+3). Is this correct?

- jem


Reply | Threaded
Open this post in threaded view
|

Concatenating lists

Thomas Davie
The logical issue you're hitting is mostly because the REPL (ghci most likely) is simulating something that you should ignore for the moment (the IO monad).

In Haskell, typically, you don't define one thing, then define another thing "later".  A definition in a Haskell program doesn't assign a value, it binds a value.  While assignment says "a now has the value 5 + 3", binding says "a always has, now has, and always will have the value 5+3".

A Haskell program like this that binds the same value twice is simply incorrect:
a = 5+3
a = 5+4

There are two competing facts here.

When typing into the REPL, you can rebind values, because each subsequent line appears (at least in the logical model) in an inner definition to the past.  This is how scoping comes into it ? the later (and hence inner) let takes precedence because it is in a closer scope.

My advice to you would be to stop thinking of trying to re-assign values right now, it's not the correct way to think about a Haskell program at all.

Bob
if (*ra4 != 0xffc78948) { return false; }

On 22 Mar 2012, at 15:54, Jan Erik Mostr?m wrote:

> On 2012-03-22 at 16:12 , Felipe Almeida Lessa wrote:
>> Your conclusion is correct, but your reasoning is not. It's not due
>> to lazyness that x is recursively defined, it's because of the scope.
>> When you type your second x on the second line, that x will refer to
>> the closest (in scope) definition of something called x -- which is
>> the the definition of x on the second line itself.
>
> Aha, thanks for explaining. I didn't consider scope - I did some searching of scoping and need to think about that for a while, a bit different than 'normal'. However, I would like to ask one more thing:
>
> Assume
>
> let a = 5 + 3
>
> Would 5+3 be calculated directly or would it be deferred to later?
> Assume it's calculated and the value 8 is given the name 'a'. Then
>
> let a = a + 4
>
> What happens is that Haskell tries to evaluate the second 'a' on that line and then finds the first 'a' and enters into infinite recursion.
>
> And this is what confuses me a little bit. I can type in 'let a = a + 4' and Haskell accepts it, the infinite recursion does not happen until I type 'a' to show the value, this makes me think that the evaluation is deferred to later (and also why I asked about 5+3). Is this correct?
>
> - jem
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20120322/f523ae24/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

Concatenating lists

Jan Erik Moström


On 2012-03-22 at 17:11 , Thomas Davie wrote:

> When typing into the REPL, you can rebind values, because each subsequent line appears (at least in the logical model) in an inner definition to the past


Ahhh, I didn't know that. I'm probably a bit biased from previous ML/Python experiences.
> My advice to you would be to stop thinking of trying to re-assign values right now, it's not the correct way to think about a Haskell program at all.

No, I understand that ...  

Thanks for explaining.

- jem