Most Lisps specify an order of evaluation for procedure arguments. Scheme does not. Order of evaluation—including the order in which the expression in the operator position is evaluated—may be chosen by an implementation
that is why.
Name:
Anonymous2012-06-26 18:32
oh wow i didn't even know that. holy shit. that sucks.
>>4
In practice, parallelising the evaluation of arguments is rarely useful. Multithreading is best done by a human and loop parallelisation isn't affected by this ``problem''.
Name:
Anonymous2012-06-26 19:15
This is the same reason why lazy evaluation is used in Haskell, it is able to make speed and memory optimisations, because it only evaluates when it has to, it does not do unnecessary evaluation, and it can make faster running speed by choosing the best order of evaluation.
Name:
Anonymous2012-06-26 19:29
>>7 Haskell
speed and memory optimisations
nice joke, fucktard.
Name:
Anonymous2012-06-26 19:36
That's why we use R6RS Racket instead of R5RS Scheme. Racket is objectively better than Scheme.
Name:
Anonymous2012-06-26 19:40
procp1 = (inta, b)real : (a > b | xx | yy) procp2 = (reala; realb)real : (a > b | stop)
Algol lets the programmer choose. If the parameters are separated by commas, they're elaborated collaterally ("at the discretion of the implementer" possibly in parallel). If the parameters are separated by semicolons, they're elaborated serially (left to right).
>>8
Did you know abstract high level languages are easier to optimize? Haskell code can specify what should be achieved without dictating how to achieve it leaving that work to the compiler.
Name:
Anonymous2012-06-26 19:49
>>10
the fact that Haskell forces lazy evaluation and does not allow the option of non-lazy evaluation like ML does allows for far greater potential to optimise as the compiler can reason about the entire program in a lazy fashion.
Name:
Anonymous2012-06-26 19:57
>>12
You can force strict evaluation for certain code.
Who the fuck cares? That only matters when you rely on the order of evaluation within a expression, i.e. when you are operating on the results of code which also has side-effects with side-effects. Which is a horrible thing to do.
>>1
The Scheme standards are the least common denominator of Schemes, half of the language is optional, even tail call optimization, nobody is around to care. Don't write Scheme code as if its C++ and you'll be fine.
Name:
Anonymous2012-07-15 3:37
Really? I thought Scheme was better because of lazy evaluation