First, looking at the syntax for passing a closure to a method, it seems peculiar. I guess I'm just not clear on the grammar for method invocations. Fan requires parens around its arguments, but this rule does not apply to closures. It looks prettier this way, but is it possible to pass more than one closure to a method? I probably just need to play around with them a bit more to figure this all out.
One point I noticed playing around was that I was able to assign closures new values of the wrong type in certain cases (but not in all). Here is an example (sorry for the older version, but the problem is probably still around, since it wasn't documented in the build fix log for 1.0.25 or 1.0.26).
C:\Documents and Settings\malonm\Desktop\fan\bin>fansh
Fan Shell v1.0.24 ('?' for help)
fansh> f := |Str x| { echo(x) }
|sys::Str->sys::Void|
fansh> f("Hi")
Hi
fansh> f = |->Int| { return 42 }
|->sys::Int|
fansh> (|->Int| { return 42 }).type
|->sys::Int|
fansh> f.type
|->sys::Int|
fansh> f()
ERROR(1): Invalid args |sys::Str|, not ()
fansh> f("Hi")
fansh>
So f is now broken. It changed its type. It doesn't accept being called with a void parameter. It accepts a string parameter, but then doesn't do anything.
brianThu 1 May 2008
I'll take a look at the typing issue. That could be a bug. Although in general the fansh is a bit weak right now since Fan doesn't have a real REPL - fansh kind of fakes it out be recompiling a bunch of little scripts. So it could just be a flaw in fansh.
Closures in Fan are just expressions - so you can use them as arguments to methods (as many as you like). The ability to pass a closure as the last argument outside of the parenthesis is straight from Ruby. If you haven't seen this section it covers closures parameters.
tacticsThu 1 May 2008
Ah, it is all clear now.
I was originally thrown off a bit due to the fact that only closures could leave the parens off. Ruby, of course, makes parens entirely optional. But Ruby treats its blocks in a kinda screwy weird way.
And I shall keep your point about fansh in mind in case I come across any other strangeness with it.
tactics Thu 1 May 2008
I had a few questions about closures in Fan.
First, looking at the syntax for passing a closure to a method, it seems peculiar. I guess I'm just not clear on the grammar for method invocations. Fan requires parens around its arguments, but this rule does not apply to closures. It looks prettier this way, but is it possible to pass more than one closure to a method? I probably just need to play around with them a bit more to figure this all out.
One point I noticed playing around was that I was able to assign closures new values of the wrong type in certain cases (but not in all). Here is an example (sorry for the older version, but the problem is probably still around, since it wasn't documented in the build fix log for 1.0.25 or 1.0.26).
So f is now broken. It changed its type. It doesn't accept being called with a void parameter. It accepts a string parameter, but then doesn't do anything.
brian Thu 1 May 2008
I'll take a look at the typing issue. That could be a bug. Although in general the fansh is a bit weak right now since Fan doesn't have a real REPL - fansh kind of fakes it out be recompiling a bunch of little scripts. So it could just be a flaw in fansh.
Closures in Fan are just expressions - so you can use them as arguments to methods (as many as you like). The ability to pass a closure as the last argument outside of the parenthesis is straight from Ruby. If you haven't seen this section it covers closures parameters.
tactics Thu 1 May 2008
Ah, it is all clear now.
I was originally thrown off a bit due to the fact that only closures could leave the parens off. Ruby, of course, makes parens entirely optional. But Ruby treats its blocks in a kinda screwy weird way.
And I shall keep your point about fansh in mind in case I come across any other strangeness with it.