in reply to On Wormholes, Time-Travel and Closures

liverpole,
Continuations, coroutines, callbacks, and closures - Oh my. Yes, it is very interesting how the state of the universe can be wrapped up in a neat little package. What is more interesting to me, is faster than light communication via quantum entanglement. I see articles every now and then about entanglement experiments but I am not holding my breath.

What would be nice is quantum entanglement for programming. I have often wanted "spooky action at a distance" when modifying a variable. Yes, I know tie can likely give me all that and a bag of chips but it doesn't feel quite as magical. It is more like lazy evaluation.

my $blind_mice; my $answer = $blind_mice * 14; $blind_mice = 3; print $answer; # 42 of course

Cheers - L~R

Replies are listed 'Best First'.
OT: Re^2: On Wormholes, Time-Travel and Closures
by hardburn (Abbot) on Dec 11, 2006 at 16:06 UTC

    What is more interesting to me, is faster than light communication via quantum entanglement. I see articles every now and then about entanglement experiments but I am not holding my breath.

    Unfortunately, the No-communication theorem shows that you can't use entagled quantum particles to communicate information.


    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      hardburn,
      Well, technically it shows a set of conditions in which failed local realism doesn't lead to faster than speed of light communication. Taking it further, it shows that it would statistically be impossible to differentiate changes to state as intentional communication or side-effects of observation itself. This seems to imply that you might be able to communicate this way but it would definately be unreliable.

      To be honest, I don't think we have scratched the surface on understanding this stuff and hence - not holding my breath.

      Cheers - L~R

Re^2: On Wormholes, Time-Travel and Closures
by qbxk (Friar) on Dec 11, 2006 at 15:31 UTC
    yikes, hope i never have to maintain code like that. it's hard enough tracing what happens, with that i'll have to enumerate and trace all possible futures as well

    spooky action indeed!


    It's not what you look like, when you're doin' what you’re doin'.
    It's what you’re doin' when you’re doin' what you look like you’re doin'!
         - Charles Wright & the Watts 103rd Street Rhythm Band, Express yourself
      qbxk,
      No offense, but this likely has to do with your lack of exposure to pure functional languages. In some languages, variables can't change value so it is moot. It does kind of make you wonder why they still call them variables. In other languages, you need to desginate this behavior (default being eager) which is a visual indicator like tie.

      We are of course talking about Perl, not other languages, so your point is well taken. Re: Evaluating variables when called is an example of such a desire. I am kind of interested in where Perl 6 will go with this.

      Cheers - L~R

        Well, if you say, in math, that function f() is defined by equation f(x) = 2*x + 1 + sin(x) what would you call the "x"? A variable. And does it change within evaluation of the 2*x + 1 + sin(x)? The sentence that variables can't change value is not really correct actually. Next time you evaluate a function the x defined as its parameter or as an internal variable may have a totally different value. It's just that instead of "hey, I want to have a blackboard on which I'll write numbers and I'll call it X. Write 5 there now! OK and now clean it and write 10 there!" you just say "the value of something I wish to call X depends on the parameters of the function like this". And it's just the habits from imperative language that force you to look for ways to overwrite the X later instead of using a different name for the result of a different computation.