On Wed, 2007-09-19 at 23:11 -0700, Erick Tryzelaar wrote:
> > You can't mix positional and named arguments.
> > I doubt this would make a lot of sense with overloading.
>
> You mean something like:
>
> fun f(a:int, b:int) = {...}
> f (1, b=2);
>
> ? Yeah, while I think it could be a useful extension, it's not that
> important as long as we can still pass in a curried arguments.
Yes, that's what I mean. This *could* actually be typed as:
struct { mem_0:int; b:int; }
indeed, with some fiddling:
(1,2)
could be typed as
struct { mem_0000: int; mem_0001: int; }
so that tuples were just records with components named 'mem_0000' etc.
You could even make the name '1' and write
x. 1
but
x.1
might be
x (.1)
unless floats had to have a leading digit. Then the name mangler would
fix it at C++ code generation time, Felix would actually use the
name '0001', '0002' etc instead of 'mem_0001'. So we might unify
tuples and records that way.
> > There are no default arguments. This DOES mix with
> > overloading (see C++). It is more or less mandatory
> > for functions with many arguments, since spelling
> > out all the overloads for N defaults yields 2^N functions.
>
> Someday. I'm doing a bit of work on those os wrappers, and it'd really
> simplify the interface :)
The main issue is that a given function would have a SET of type
signatures.
I think overload resolution could handle that easily: instead of
T1 -> f1
T2 -> f2
and match the LHS sig to find the RHS fun to use, just allow
more entries:
T11 -> f1
T12 -> f2
...
Now, actually I lied about 2^N: if we follow the C++/tuple technology,
then N defaults only makes N+1 functions (all args, the last one
cut off, the last 2 cut off, etc ..).
Only interesting case then is an array of 20,000 zeros with
the initial elements specified .. :)
> > To consider:
> >
> > It would be interesting to consider automatic coercions:
> >
> > fun f(a:int, b:int)=> a + 2* b;
> > f (a=1,b=2,c=3);
> >
> > This currently fails: there must be an exact match.
> > However, allowing subtyping is trivial to implement, and in fact
> > is simpler than the current algorithm which checks the record
> > and function have the same number of arguments.
>
>
> I'm undecided on this. In one respect it can be really handy in python
> to pass around an option file and just use the **kwds dictionary to
> query it. On the other hand, I feel like it's less safe doing this
> downsizing transparently. Your example *is* interesting though, I
> could see that being useful.
To be explicit, the problem is hijacking:
fun f(a:int, b:int, c:int) ..
woops, f(a=1,b=2,c=3) binds to a different function. Hijacking
is bad right? Except that you can already do exactly this with
specialisations of polymorphic functions, which is a kind
of subtyping, eg:
fun f[t](x:t)=> ..
fun f[t](x:t*t)=>..
fun f(x:int)=>..
> How would this all interact with typeclasses?
Unrelated. To explain more: the parameter names have nothing
to do with the actual function type, they're just used to choose
a function, and to guide construction of a conversion. The domain
of the function type is still (typically) a tuple, not a record.
> Would it work
> transparently, or could we extend typeclasses to make it more
> typesafe? Perhaps in the record polymorphism typeclass, instead of
> throwing away the extra fields as in ad hoc polymorphism, the extra
> fields would be hidden unless exposed through the record typeclass?
> I'm not sure if that really makes sense,
:_)
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
