On Fri, Mar 06, 2009 at 01:41:31PM -0500, Jonathan S. Shapiro wrote:
> We seem to have two broad options for procedure application: I'm not
> entirely convinced that the second one works if we retain n-ary functions
> and we decide to do mixfix:
> 
> Option 1:
> 
>    proc-name( arg ... arg)
> 
> Option 2:
> 
>   proc-name arg ... arg

I realize you're not polling on this particular question, but this may
have an impact on your decision for procedure application syntax.

Have you considered supporting keyword arguments (aka. labels, named
arguments)?

This makes code audit a lot easier and safer:

        set-size :: (box: Box, width: int, height: int) -> void
        set-size box: b width: w height: h
        set-size b h w // wrong, but hard to catch

where the argument types are not all different.

As usual here, there is the question of whether you allow using both
positional arguments and keyword arguments at the same time, and how.
There is the Common Lisp way (positional args appear first, then keyword
args), the OLabl / OCaml way (non labeled arguments are extracted first
as positional arguments, then labeled arguments are extracted; check for
conflicts), the Python way (similar to OCaml, but keyword arguments are
put in a hash at runtime), etc.

My preference goes toward allowing only two modes: all positional or all
named, no mix. And of course, all of this handled at compile time.

Another question: can any procedure be called using keywords (Ada, VHDL,
Verilog; my strong preference)? Or does it have to be explicit in the
procedure definition (Ocaml, Lisp, Python)?

You also have the questions of whether you can have default values, when
to evaluate them, from what kind of expressions, etc. You may want to
allow default values only when all arguments are specified with a
keyword in a call. Default values can be problematic if the default is
changed behind the back of the caller 6 months later. I personally don't
seem them as essential, and somewhat dangerous.

Thanks.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to