On 7/31/07, skaller <[EMAIL PROTECTED]> wrote:
> > This can help a little with emulating keyword arguments to a function,
> > with something ugly like this:
>
> On todo list .. the syntax sucks with keyword 'struct' needed,
> but { .. } has two other meanings as a closure for both
> procedures and functions. In fact, the struct thing is actually
> a closure, if you write:
>
> { var a = 5; var b = 6; }
>
> then the 'stack frame' of this procedure more or less IS the
> record of variables a and b. So perhaps
>
> &{ .. }
>
> might be used instead of
>
> struct { .. }
>
> ?? .. although it suggests a pointer .. lol .. ??
I kind of like this idea. It feels lispy. Say { ... } actually created
a raw stack frame, where the thing it was passed to had access to all
the internal values and variables. This raw stack frame then could be
passed to the "class" function which breaks apart the stack frame to
create a class. Something similar could be done with "fun"s and
"proc"s. As a side benefit, you could just pass a raw stack frame to a
function, and it would look almost exactly like a record.
I've got no idea how this could be implemented and typed though.
> You're suggesting default arguments .. and that definitely
> does break the rule. The problem isn't the rule as such,
> the problem is that overload resolution depends on the argument.
I can try, can't I? :)
> Here, f takes an explicit X argument, and there is a 'generic'
> _ctor_X function accepting suitable 'records'.
>
> This doesn't impact overloading ordinary functions, although it
> does impact overloading _ctor_X function things. However the 'lookup'
> of _ctor_X things is special anyhow, so we can code a special check
> to see if a record is given as an argument.
>
> The trick here is that 'X' is a type and so can't be overloaded itself,
> only one type named X is allowed in scope.
>
> Perhaps something like this would be OK?
I like it, but I think I see some problems with that. Say you want to
convert from cartesian to polar coordinates. You've got "struct Cart {
x:float; y:float; }" and "struct Polar { angle:float; magnitude:float;
}" and the simplest thing to do would be to have a _ctor_Cart and a
_ctor_Polar to just cast between the two. If we restricted the ctors
to accept only a subset of the type, we would have to define ugly
helper functions to do this.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
