On Fri, 2007-09-21 at 12:04 -0700, Erick Tryzelaar wrote:
> On 9/21/07, skaller <[EMAIL PROTECTED]> wrote:
> So no doing "fun f (a:int=1, b=a+1)"? :) Thats understandable.
It's not impossible to do, even
fun f(a:int=b, b:int=a)
makes sense provided you supply one of the arguments: typeclasses
allow that with default virtuals. However at the moment the assignments
are parallel, not serialised left to right or in an order determined
by dependency analysis.
> So, if we want to have non-named arguments, we have to define
> functions like ocaml's labeled functions, where the record is the
> first argument:
>
> fun f (a=5, b=6) (f:int->int) => ...;
fun f(a:int=5, b:int) (f:int->int) =>
The type is still mandatory .. probably doesn't need to be
if a default is given (as for var and val, the type could
be deduced from the default).
But yes, it's a problem you can't prevent use of named
arguments except by wrapping the function in a closure.
A curried form above hides the second argument names.
But you can do:
f := { fun (a:int)=a; }();
too .. however this f will be tricky to optimise.
> Generally I'm fine with this restriction. However, I don't think it'd
> play well with the dot notation:
>
> fun foo (s:string) (a=2, b=3) => ...;
>
> "abc".foo (a=1);
Good point, but I don't see an easy fix. The original
AST_curry .. pss
takes pss as a list of lists of parameters, so at this
point we have the information.
However what Ocaml changes that with labelled arguments to
a dictionary of lists, or more precisely, a dictionary
of patterns.
>
> Aside: I noticed that there's a problem using the dot notation with
> integers and floats, because the lexer interprets the dot for
> precision.
Yeah, you have to put a space or use parens:
1 . f
(1).f
rather than
1. f
but this is true for
r "hi" // r"hi" is a raw string
1.0 f // 1.0f is a float
(1.0).f // means f 1.0
1 + +1 // 1 ++ 1 is syntax error, ++ is a procedure
etc etc.
> Is it worthwhile trying to get the lexer to handle "1.foo"
> or "1.f.foo" correctly? I guess we could enforce that if you want to
> write one in float you have to have a number between the dot and the
> 'f' as in "1.0f.foo". That should be enough to distinguish a function
> call and a float.
The one that annoys me most is
z = z.(1),z.(0)
instead of
z= z.1,z.0
i.e. I can't name tuple components with plain integers without
putting parens. I also mess up
z[i] // woops, meant z.[i]
quite a lot .. in C++
z<i> // woops meant z[i]
is unlikely .. but then we'd need
a .< b
for less than. Well, I think we would... I haven't actually
tried it out with the parser. At present you can't write
a < b > c // means a < b and b > c
which would be ambiguous. Then there is the << >> confusion.
Actually I'd like to steal << and >> back, use shl, shr,
rotl, rotr, etc instead to steal these back.
There is a risk now we can GLR parse some C code, that
we're damaging chance of an actual syntax upgrade
from C/C++ by not using the same symbols. Having
to write
int f(int x){ return x; }; // trailing ;
already means we can't translate C/C++ as written,
unless we require something like:
extern "C++" { ... }
to switch the syntax.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
