Strange behavior when combing implicit conversion with () => Unit input parameter
Yoav Abrahami
I've started using Scala quite recently, and came upon what seems like
a strange and inconsistent behavior of the scala compiler.
As I work quite a bit with Threads, I create Runnable implementations
(the reason I am using ThreadPoolExecutor and not Actors is out of
scope for this issue).
I hope someone here can shade some light and explain what's going on
here and why it seems (to me) like an inconsistent handling of the
scala compiler.
In order to write the most elegant code I can with Runnable, I've
played with implicit and explicit conversions from a code block to a
Runnable. What I've found can be summarized as (see the code below)
()=>Unit implicitly converted to Runnable - does not work as expected
- prints hello 1 once
()=>Unit explicitly converted to Runnable - does work as expected -
prints hello 1 twice
(String)=>Unit implicitly converted to RunnableString - does work as
expected - prints hello 1 twice
(String)=>Unit explicitly converted to RunnableString - does work as
expected - prints hello 1 twice
Cheers,
Yoav
The code -
I've tried to introduce the following implicit conversion.
implicit def funcToRunnable(x: => Unit): Runnable = new Runnable {
println("converting...")
def run = {
x
}
}
Then to use it the following way
def playRunnableImplicit() {
println("playRunnableImplicit")
playRunnable({
println("hello 1")
println("hello 2")
})
}
where the method playRunnable (a method written to make the issue here
explicit) is
def playRunnable(r: Runnable): Unit = {
println("playRunnable.playing runnable")
r.run()
println("playRunnable.playing the runnable a second time")
r.run()
println("playRunnable.played runnable")
}
when running the playRunnableImplicit, the printed output is not what
I'd expect
playRunnableImplicit
hello 1
converting...
playRunnable.playing runnable
hello 2
playRunnable.playing the runnable a second time
hello 2
playRunnable.played runnable
The problem is that the first statement of the code block given to the
conversion is executed before the implicit conversion is done.
When using explicit conversion, we get the following
def playRunnableExplicit() {
println("playRunnableExplicit")
playRunnable(funcToRunnable({
println("hello 1")
println("hello 2")
}))
}
playRunnableExplicit
converting...
playRunnable.playing runnable
hello 1
hello 2
playRunnable.playing the runnable a second time
hello 1
hello 2
playRunnable.played runnable
interesting that by just adding the explicit conversion instead of the
implicit conversion, we get a different result.
Also, If we use the same pattern for an implicit conversion from
anything other then ()=>Unit block, it all works as expected. For
instance, if we define a trait RunnableString and a conversion from
(String)=>Unit, such as below, everything works as expected
trait RunnableString {
def run(s: String)
}
implicit def funcToRunnableString(x: String => Unit): RunnableString
= new RunnableString {
println("converting...")
def run(s: String) = {
x(s)
}
}
def playRunnableString(r: RunnableString): Unit = {
println("playRunnable.playing runnable")
r.run("a")
println("playRunnable.playing the runnable a second time")
r.run("b")
println("playRunnable.played runnable")
}
def playRunnableStringImplicit() {
println("playRunnableStringImplicit")
playRunnableString({s: String =>
println("hello 1 " + s)
println("hello 2 " + s)
})
}
def playRunnableStringExplicit() {
println("playRunnableStringExplicit")
playRunnableString(funcToRunnableString({s: String =>
println("hello 1 " + s)
println("hello 2 " + s)
}))
}
and the output is then
playRunnableStringImplicit
converting...
playRunnable.playing runnable
hello 1 a
hello 2 a
playRunnable.playing the runnable a second time
hello 1 b
hello 2 b
playRunnable.played runnable
playRunnableStringExplicit
converting...
playRunnable.playing runnable
hello 1 a
hello 2 a
playRunnable.playing the runnable a second time
hello 1 b
hello 2 b
playRunnable.played runnable
Iain McGinniss
println("playRunnableImplicit")
println("hello 1")
println("hello 2")
})
}
Daniel Sobral
> played with implicit and explicit conversions from a code block to a
> Runnable. What I've found can be summarized as (see the code below)
Code block is not an object. There's no "thunk" in Scala -- you either
have a function, or you don't. A code of block is simply a syntactical
scope whose value is that of the last statement. So you can't
"convert" a code block into something.
>
> ()=>Unit implicitly converted to Runnable - does not work as expected
> - prints hello 1 once
"() => Unit" is a function with one parameter list of arity 0. A
Function0, in other words.
> implicit def funcToRunnable(x: => Unit): Runnable = new Runnable {
A "=> Unit" is not a function at all. "=> Unit" is the same thing as
"Unit", but the parameter is passed by name instead of by value. In
practice, it means whatever is passed in place of the parameter is not
first evaluated and then have its value passed but, instead, is passed
"as is", and evaluated it time it is used.
Anyway, "=> Unit" is different than "() => Unit".
> println("converting...")
> def run = {
> x
> }
> }
>
> def playRunnableImplicit() {
> println("playRunnableImplicit")
> playRunnable({
> println("hello 1")
> println("hello 2")
> })
So, the parameter is { println("hello 1"); println("hello 2") }, which
does not conform to Runnable. However, there's a conversion from Unit
to Runnable, and the type of that parameter is Unit. The value of a
block is the value of it's last statement, but since Unit is being
passed by name, println("hello 2") is passed instead of just ()
(return value of println, not to be confused with empty parameter
list).
> }
At any rate, even if what you want were doable, it wouldn't be a good
idea. That's a gratuitous implicit conversion, saving a single token.
If, instead, you named funcToRunnable just "runnable", you could then
write
playRunnable(runnable { print("hello 1"); print("hello 2") })
No implicits required, and very little syntactic overhead.
--
Daniel C. Sobral
I travel to the future all the time.
Yoav Abrahami
thanks for your answer.
I have tried writing things like
playRunnable(() => {
playRunnable( => {
playRunnable({ () =>
playRunnable({ =>
but non of them compile.
I still did not find how to make scala consider a "code block" as a
()=>Unit func.
On Jul 22, 9:05 pm, Iain McGinniss <iainmc...@gmail.com> wrote:
> I think what you might be bumping up against here is that blocks are not
> actually functions:
>
Yoav Abrahami
What I fail to understand is why I cannot create a function / method
that does not get any parameters.
The case with RunnableString clearly works as scala considers the
block
{ s: String =>
println("hello 2 " + s)
}
{
println("hello 2")
}
is there a syntactic way to express in scala something that does not
get input parameters but such that can be evaluated later?
Thanks,
Yoav
√iktor Ҡlang
def block2fun0[T](block: => T): () => T = () => block
Yoav Abrahami
Thanks for your answer.
Viktor, the block2fun0 creates a () => T func. I am wondering about
creating a () => Unit, which is a bit different.
Let me try to clarify my question -
Consider the following code block
I fail to understand why Scala considers g(funcToRunnable(block)) as
one thing and g(block) (with implicit conversion) as something
else...
aren't the rules for implicit conversion are that it should do the
same thing as if we were using explicit conversion?
It seems that the Scala compiler does the following
in the case of explicit conversion - considers all the code block as a
() => Unit and passes all the block to the funcToRunnable method.
in the case of implicit conversion - executes the code block, taking
only the last statement and passes it to the funcToRunnable method.
strange, it's it?
Daniel Sobral
> Daniel,
> What I fail to understand is why I cannot create a function / method
> that does not get any parameters.
Functions and methods are different things. Do not confuse them.
Functions must ALWAYS get at list a 0-arity parameter list, because
that's how they "apply" syntactic sugar gets invoked.
> The case with RunnableString clearly works as scala considers the
> block
> { s: String =>
> println("hello 1 " + s)
> println("hello 2 " + s)
> }
> as a function, while it does not consider the block
> {
> println("hello 1")
> println("hello 2")
> }
> as a function
Because it has no parameter list. This would be a function:
{
() =>
println("hello 1")
println("hello 2")
}
>
Daniel Sobral
> On Sat, Jul 23, 2011 at 07:46, Yoav Abrahami <yoa...@gmail.com> wrote:
>> Daniel,
>> What I fail to understand is why I cannot create a function / method
>> that does not get any parameters.
>
> Functions and methods are different things. Do not confuse them.
> Functions must ALWAYS get at list a 0-arity parameter list, because
I meant "at _least_ a 0-arity parameter least" here.
Daniel Sobral
> def block2fun0[T](block: => T): () => T = () => block
This is pretty much what he had, but he is trying to make it apply
implicitly, which causes problem as I described. Specifically:
scala> implicit def block2fun0[T](block: => T): () => T = () => block
block2fun0: [T](block: => T)() => T
scala> val f: () => Unit = {
| println("hello 1")
| println("hello 2")
| }
hello 1
f: () => Unit = <function0>
scala> f()
hello 2
Daniel Sobral
> hi Viktor and Daniel,
> Thanks for your answer.
> Viktor, the block2fun0 creates a () => T func. I am wondering about
> creating a () => Unit, which is a bit different.
>
> Let me try to clarify my question -
> Consider the following code block
> {println("hello 1"); println("hello 2") }
>
> now consider using the following to convert it to a runnable
> implicit def funcToRunnable(x: => Unit): Runnable = new Runnable
> { def run = { x } }
>
> I fail to understand why Scala considers g(funcToRunnable(block)) as
> one thing and g(block) (with implicit conversion) as something
> else...
> aren't the rules for implicit conversion are that it should do the
> same thing as if we were using explicit conversion?
>
> It seems that the Scala compiler does the following
> in the case of explicit conversion - considers all the code block as a
> () => Unit and passes all the block to the funcToRunnable method.
> in the case of implicit conversion - executes the code block, taking
> only the last statement and passes it to the funcToRunnable method.
> strange, it's it?
You will *not* understand as long as you persist in thinking of "code
block". While there's something in Scala code block, it is not what
you think it is. So, first, make it clear to yourself: THERE IS NO
SUCH THING AS A CODE BLOCK. Convince yourself of that. If you start
reading the code and think "code block", stop and say that again:
there is no such thing as a code block. Once you take that completely
out of your mind, you can go back to the code:
{ s: String =>
println("hello 1 " + s)
println("hello 2 " + s)
}
This is a function literal. Function literals are either simple
expressions or delimited by () or {}, and they either have "_" in them
as placeholder parameters, or they start with "parameters =>", where
"parameters" may be a single identifier, with or without type, or a
list of identifiers inside parenthesis. Again, this is a function --
learn to recognize what marks a function.
{
println("hello 1")
println("hello 2")
}
This is nothing. It is just a couple of statements inside a scope delimiter.
After you have that fully understood, then you can start thinking of
"code block" as a delimited list of declarations and statements with a
value.
√iktor Ҡlang
you can have an implicit conversion between () => T and Runnable, but you'll need to use it like this:
val r: Runnable = () => println("pigdog")
which makes it a bit easier to just have a method called "runnable" that takes a by-name parameter of type T and returns a Runnable that invokes that by-name parameter:
val r = runnable { println("pigdog" }
Now, if there really is not a convincing reason to work with runnables in user code at all, I'd recommend working with () => T instead, it's way more useful.
val r = () => println("pigdog")
Viktor Klang
Akka Tech Lead
Stephen Haberman
{
println("hello 1")
println("hello 2")
}This is nothing. It is just a couple of statements inside a scope delimiter.
Roland Kuhn
Daniel Sobral
<stephen....@gmail.com> wrote:
>> {
>> println("hello 1")
>> println("hello 2")
>> }
>>
>> This is nothing. It is just a couple of statements inside a scope
>> delimiter.
>
> Okay, then how to do you explain:
> https://gist.github.com/1101709
I have explained it in two different ways already, but I'll try again.
Remember, first, that "=> Unit" is *not* a function. It is a parameter
passed by-name -- go look on wikipedia about that.
So, the first thing to notice is that there is no function anywhere,
and "doFunction" is incorrectly named. So, since this code has no
function in it, we can move ahead and understand how it works. If you
can't let go of the fact it has no function, then go back, re-read the
spec, re-read stuff I wrote... hell, read stack overflow about it.
There's no function signature anywhere, therefore there is no
function.
NEXT, let's see how it works:
def doFunction(f: => Unit) = { println("got " + (f _)) ; f ; f }
doFunction { println("1"); println("2") }
The grossly misnamed "doFunction" method takes a by-name Unit
parameter "f". That means that everywhere "f" appears, it is replaced
with what was passed. That means it will do this:
{ println("got " + ({ println("1"); println("2") } _)) ; {
println("1"); println("2") } ; { println("1"); println("2") } }
You might now try to take this opportunity to point out that it
printed "got <function0>", so it must be a function. Well, I've got
two words for you: eta expansion. When you wrote "f _", Scala created
a function for you. That's what it does when you write "f _". You'd
have a stronger argument if you decompiled doFunction and showed that
it expected a function, but that's implementation, and, in fact, it is
just an interface name.
So, let's proceed:
doSam(body2sam({ println("1"); println("2") }))
becomes, because of body2sam's by-name parameter,
doSam(new SAM {
override def onSam = { println("1"); println("2") }
})
Finally, this:
doSam { println("1"); println("2") }
So, doSam does not receive a parameter by name, which means "{
println("1"); println("2") }" gets evaluated before being passed. It's
value is defined to be the value of the last statement, println("2").
Since it is not a SAM, Scala checks if it conforms to SAM through an
implicit conversion (or other means), which, in fact, it does. So it
becomes:
doSam { println("1"); body2sam(println("2")) }
All of which makes perfect sense and, while might be surprising the
first time you see it, can be easily deduced from the specification.
But only if you do pay attention to the specification, and stop
thinking of "block of code" as some sort of equivalent of a function,
never mind confusing by-name parameters with functions.
>
> AFAICT, the "couple of statements inside a scope delimiter" can indeed be a
> function, as the call to doFunction shows.
> It's quite odd that the same syntax (doFunction { ... } vs. doSam { ... })
> results in very different behavior depending on whether an implicit
> conversion is involved.
There's no oddity here -- it only looks odd because of your
presumption that there's a function here.
Yoav Abrahami
I think the example in https://gist.github.com/1101709 says it all.
doSam(body2sam({ println("1"); println("2") }))
// 1 2 1 2
doSam { println("1"); println("2") }
// got foo.Foo$$anon$1@416b13c7
// 2 2
the two functions above should (for any reasonable reader) produce the
same result. Why should the use of implicit conversion produce
something different?
If, as Roland says, this case is too complicated for the compiler, it
should be excluded - should not compile.
Something like saying "implicit conversion are not supported for
delayed evaluation of Unit parameters because of potential ambiguity"
However, having the same code (from the point of view of a developer)
do two different things is really bad for a programming language - it
is one of those things that was really bad in C++ (namely multiple
inheritance which was so bad it too 25 years for developers to
overcome). A programming language should not be ambiguous, ever.
When I say ambiguous, I mean from the point of view of the developer,
not the compiler
:-)
On Jul 25, 2:09 am, Daniel Sobral <dcsob...@gmail.com> wrote:
> On Sat, Jul 23, 2011 at 17:44, Stephen Haberman
>
Johannes Rudolph
> the two functions above should (for any reasonable reader) produce the
> same result. Why should the use of implicit conversion produce
> something different?
Actually for those cases the reader can't expect to much as long as
implicits and by-name parameters are concerned because at the
call-site those are completely transparent. To understand a program
completely the reader has to know at least the signatures of the
callees and which implicits are in scope. With his knowledge of how
implicit conversions work he can then infer what is happening.
But those are just artifacts of a powerful, generic language where
libraries can (re-)define semantics to a certain degree.
I agree that implicits taking a by-name parameter are a potential
pitfall and seldom useful and if something can be done against this it
would probably be putting a warning at the definition site of an
implicit conversion with a by-name parameter.
--
Johannes
-----------------------------------------------
Johannes Rudolph
http://virtual-void.net
Daniel Sobral
> Hi Daniel, Roland,
> I think the example in https://gist.github.com/1101709 says it all.
>
> doSam(body2sam({ println("1"); println("2") }))
> // got foo.Foo$$anon$1@2b86c6b2
> // 1 2 1 2
>
> doSam { println("1"); println("2") }
> // 1
> // got foo.Foo$$anon$1@416b13c7
> // 2 2
>
> the two functions above should (for any reasonable reader) produce the
> same result. Why should the use of implicit conversion produce
> something different?
Because { println("1"); println("2") } is not a function!
Let me try this in a different way...
scala> { println("1"); println("2") } == println("2")
1
2
2
res0: Boolean = true
Do you consider this result (true) to be correct or incorrect?
Yoav Abrahami
My point is not that this code fragment is a function, block, or not.
My point is that in a programming language, a code fragment (by
whatever name) should be understood by the compiler and developers as
the same thing, always.
In this case, it is not.
by your logic,
// got foo.Foo$$anon$1@2b86c6b2
// 1 2 1 2
// 1
// got foo.Foo$$anon$1@416b13c7
// 2 2
function.
On Jul 25, 2:55 pm, Daniel Sobral <dcsob...@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 05:58, Yoav Abrahami <yoa...@gmail.com> wrote:
> > Hi Daniel, Roland,
Roland Kuhn
> Hi Daniel,
>
> My point is not that this code fragment is a function, block, or not.
> My point is that in a programming language, a code fragment (by
> whatever name) should be understood by the compiler and developers as
> the same thing, always.
> In this case, it is not.
>
> by your logic,
> doSam(body2sam({ println("1"); println("2") }))
> // got foo.Foo$$anon$1@2b86c6b2
> // 1 2 1 2
> is wrong. it should print
>
> // 1
> // got foo.Foo$$anon$1@416b13c7
> // 2 2
>
> because, as you say, the code {println("1"); println("2")} is not a
> function.
>
So, finally we arrive at the crucial point: as I tried to explain
earlier, this special exception is in place so that libraries can
provide methods which "feel like" control constructs. It is a conscious
design decision which is immensely important if you want to write nice
DSLs, one of Scala's central strengths.
Scala is a hammer which fits many a nail. But if your special nail
absolutely requires that { ... } never is a function, then by all means
choose a different tool.
Regards,
Roland
Tony Morris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 25/07/11 23:28, Yoav Abrahami wrote:
> My point is that in a programming language, a code fragment (by
> whatever name) should be understood by the compiler and developers
> as the same thing, always.
Scala is not a lazy, pure functional programming language. Just sayin'
- --
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4tfOEACgkQmnpgrYe6r6052wCfe8aJOzvN56pBltyQTid3UZsU
Yp4An24ZfWsNNBvOFHiqXa86B/aVbBpd
=fnZG
-----END PGP SIGNATURE-----
Josh Suereth
Yoav Abrahami
I do not object for scala to handle a code fragment as a special case
as it does.
I do object for it to allow writing implicit conversions on it that
does something completely different.
I'd like Scala to be consistent in this regard, or disallow the
implicit conversion. If we have a special case, as you say here,
disallowing the implicit conversion is the right thing to do - as a
complementary special case.
Cheers,
Yoav
Stephen Haberman
> I have explained it in two different ways already, but I'll try again.
Thanks for taking the time to do so.
> Remember, first, that "=> Unit" is *not* a function.
Hm...okay, I guess that makes sense.
I still find myself tempted to think of them that way, especially for
DSLs and custom control structures where they're used (abused?) to get
syntactically-cheap functions, e.g.:
def main(args: Array[String]): Unit = {
bar { println("1"); println("2") }
bar { _ => println("1"); println("2") }
bar { s => println(s); println(s) }
}
def bar(f: String => Unit): Unit = f("hi")
def bar(f: => Unit): Unit = bar(_ => f)
Where I want the first bar call to be considered, effectively, as a
function that ignores its parameter. Here it works as expected, and is
what I was attempting to emulate against an API that takes a SAM.
Pimping the API seems to be the better way to go.
- Stephen
Daniel Sobral
> My point is that in a programming language, a code fragment (by
> whatever name) should be understood by the compiler and developers as
> the same thing, always.
> In this case, it is not.
>
> by your logic,
> doSam(body2sam({ println("1"); println("2") }))
> // got foo.Foo$$anon$1@2b86c6b2
> // 1 2 1 2
> is wrong. it should print
>
> // 1
> // got foo.Foo$$anon$1@416b13c7
> // 2 2
>
> because, as you say, the code {println("1"); println("2")} is not a
> function.
But body2sam receives a parameter by name -- you can't use by name
parameters and ignore how they work. You are being explicit in that
println("1") is part of it. Implicitly, it becomes:
{ println("1"); body2sam(println("2")) }
This is all according to the rules. The problem is not with the rules,
the problem is with your expectation that body2sam would apply over
the whole block, instead of its value. And that expectation only
exists because you insist of thinking of the block as a kind of "block
of code" object.
Daniel Sobral
<stephen....@gmail.com> wrote:
>
> Where I want the first bar call to be considered, effectively, as a
> function that ignores its parameter. Here it works as expected, and is
> what I was attempting to emulate against an API that takes a SAM.
> Pimping the API seems to be the better way to go.
Don't go overboard with implicit conversions. It costs very little to
put a "bar" in front of the block, so do that.
Roland Kuhn
of the SLS]
Yes, there must have been some misunderstanding on my part along the
way: allowing by-name parameters on implicit conversions is
questionable. So, as long as by-name parameters in general remain
supported, we are in agreement ;-)
BTW: can someone think of a non-confusing use-case for conversions
taking by-name arguments?
Regards,
Roland
Mark Harrah
Johannes Rudolph <johannes...@googlemail.com> wrote:
> I agree that implicits taking a by-name parameter are a potential
> pitfall and seldom useful and if something can be done against this it
> would probably be putting a warning at the definition site of an
> implicit conversion with a by-name parameter.
https://issues.scala-lang.org/browse/SI-3237
-Mark
Ðavîd Låndïs
> Also, the => A vs. () => A debate is a bit confusing at first to all of us
> in the language. Daniel has a great explanation, but I'm not surprised it
> threw you for a loop at first. It does for all of us.
>
Watch out, you almost said it was "complex". I new here, but even I
know better than that ;)
Yoav Abrahami
I think your still not getting my point.
I agree - there is no code block.
I agree - there is no function.
However, I do not agree that
please run the code
// got foo.Foo$$anon$1@2b86c6b2
// 1 2 1 2
doSam({ println("1"); body2sam(println("2")) }))
// got foo.Foo$$anon$1@2b86c6b2
// 1 2 2
those are two different things.
My observation is that if we apply body2sam as an implicit conversion
on {println("1"); println("2")}, the compiler sees code written as the
second example, not the first.
I understand that the compiler has a hard life in this case, because
when it looks were the body2sam conversion fits the code, it finds two
places.
adding body2sam to the code {println("1"); println("2")} can be done
as
body2sam({println("1"); println("2")})
or
{println("1"); body2sam(println("2"))}
And those two ways are different!
In such a case, we have ambiguity and the compiler must issue a
compilation error. The fact that it does not means there is something
broken with the Scala compiler.
Thanks for helping me clarify the issue.
Cheers,
Yoav
by your logic,
doSam(body2sam({ println("1"); println("2") }))
// got foo.Foo$$anon$1@2b86c6b2
// 1 2 1 2
is wrong. it should print
// 1
// got foo.Foo$$anon$1@416b13c7
// 2 2
Daniel Sobral
> Daniel,
>
> I think your still not getting my point.
>
> I agree - there is no code block.
> I agree - there is no function.
>
> However, I do not agree that
> body2sam({ println("1"); println("2") } )
>
> is equivalent to
> { println("1"); body2sam(println("2")) }
>
> because they print something completely different!
I'm not saying they are the same, I'm saying they are different. When
you use implicits, it is the latter version that is used. When you do
it explicitly, you can do it any way you want, and the example
happened to use the former.
> My observation is that if we apply body2sam as an implicit conversion
> on {println("1"); println("2")}, the compiler sees code written as the
> second example, not the first.
> I understand that the compiler has a hard life in this case, because
> when it looks were the body2sam conversion fits the code, it finds two
> places.
> adding body2sam to the code {println("1"); println("2")} can be done
> as
> body2sam({println("1"); println("2")})
> or
> {println("1"); body2sam(println("2"))}
> And those two ways are different!
> In such a case, we have ambiguity and the compiler must issue a
> compilation error. The fact that it does not means there is something
> broken with the Scala compiler.
There are many ways things can be written in different manners with
different meanings and still be valid, why would this cause a warning?
There's no ambiguity here -- there's need of a Unit, and the last
statement of the block provides one. Since the parameter is by name,
it passes that statement by name.
The only "ambiguity" here is "I'd like it to do something else." Well,
it doesn't, but it is not ambiguous.
Tony Morris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
IO is associative but does not commute.
Yoav, I suggest trying your examples in a language where the
type-checker makes some of your observations more apparent. You are
right of course, but it can be made more obvious with a type checker
that delineates between these differents type of value.
- --
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4t32AACgkQmnpgrYe6r60amwCglMj/LSpkS249MilmVv1wlvs3
Y+IAn1bvKPgMASJLz/YvXbGeoDTVQkpz
=RVW0
-----END PGP SIGNATURE-----