On Wed, Jan 16, 2013 at 9:53 AM, john skaller <skal...@users.sourceforge.net
> wrote:
>
> On 17/01/2013, at 4:43 AM, Dobes Vandermeer wrote:
>
> > In Felix you can do this:
> > fun f(i:int) =>
> > let ?g = fun (x:int) => i + x in
> > g (i+2)
> > ;
> > but this is not the same: it makes g a closure. Closure can only
> > be inlined away with data flow analysis, it may happen in this case
> > but I wouldn't bet on it :)
> >
> > There's no need to make bets, just try it out and look at the
> disassembly to see what happens with your preferred compilers.
>
> Ah, I'm talking about the Felix compiler flxg.
>
Well, in the end all that matters is what reaches the CPU, so you can see
whether gcc and msvc with optimizations turns on will eliminate those
closure objects for you. You never know ...
> >
> > In CoffeeScript they only have the lambda syntax for definition
> functions; i.e. they have f = fun (x) => x*x and NOT fun f(x) => x*x. This
> works surprisingly well and keeps the language nice and simple - now
> there's just one function construct to support, and at little cost
> (basically just the extra " = " in terms of character count; it's no harder
> to read, and its trivial for the compiler to assign a name to the function
> when appropriate).
> >
> > You could do the same transform - just treat val g = fun(x) => x*x as if
> they had typed fun g(x) => x*x .
>
> Actually no, I can't. The reason is, functions bound by name like
>
> fun f(x:int)=> x;
>
> can be overloaded on the name. Variables like:
>
> val f = fun (x:int) => x;
>
Well, if people are shadowing existing function definitions with new
variables containing a closure, that is confusing. How does felix
currently handle something like:
fun f(x:int) => x*x
fun g(a) {
fun f(b:string) = a+b;
return f(5);
}
Do the "inner" and "outer" f somehow merge together so that it selects
between both inner AND outer versions of f?
> cannot be overloaded. The semantics in both cases are probably the same
> (modulo the weirdness we have previously discussed) after binding though.
>
> There's a second reason this cannot be done in general: polymorphism.
> In a fun binder like:
>
> fun f[T] (x:T) => x;
>
> f is polymorphic. You cannot do this:
>
> val f[T] = fun(x:T) => x;
>
> or whatever the syntax would be, because that would denote
> a polymorphic closure. Felix does not allow polymorphic objects.
> [Boxed ones might be supported, but they're not at this time]
>
I guess there's two suggestions here.
One, the more viable one, is to consider treating val f = fun(x) => x as
equivalent to fun f(x) => x. It's a good point about overloading, though,
that's probably going to make things too confusing.
The other might be to eliminate the function declaration syntax - that
wouldn't look so good in Felix because you still have to put "val" or "let"
in front so now you'd have "val f = fun(x) => x" which isn't as slick as
CoffeeScript's "f = (x) -> x". And there's the issue with polymorphic
functions and overloading, although inventing a syntax for polymorphism
which basically require a "declarative" syntax to avoid confusing people
who have the usual interpretation of assignment (the last value assigned is
the only value).
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
