On Sun, Mar 08, 2009 at 10:35:35PM +0100, Florian Weimer wrote:
> * Eric Rannaud:
> > 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)?
>
> Lua has a neat trick for this: if the argument is a table expression
> (roughly corresponding to a record), you can omit the parentheses in a
> function application. So you can write:
>
> proc {arg1 = foo, arg2 = bar}
>
> So if you have decent record constructors, you don't need labeled
> arguments IMHO (except for currying, maybe, but that's rather obscure
> anyway).
The issue is that only procedures designed to take one record as
argument can use this trick. And wouldn't you end up defining pretty
much one record type per procedure? (not the case in Lua, as tables are
weakly dynamically "typed").
On the other hand, I really hope for decent record constructors in BitC
(and static initializers in general), although they can come later in
the language. They are very useful for static lookup tables and structs.
In C99, I can do:
enum TYPES {
FOO = 0,
BAR,
TYPES__NUM,
};
static const uint32_t lut[TYPES__NUM] = {
[FOO] = 0x123;
[BAR] = 0x124;
};
But in ISO C++, I can't and that's very very error prone, or impossible
-- e.g. sparse lookup tables for a character class in a lexer:
static const int cclass[256] = {
[' '] = C_SPACE,
['\t'] = C_SPACE,
['\n'] = C_SPACE | C_EOL,
['a' ... 'z'] = C_ALPHA | C_LOWER, /* OK, this one is a GCC
extension... */
['A' ... 'Z'] = C_ALPHA | C_UPPER,
};
Same thing for structs. As is often the case, a solution is finally
coming in C++0x, but they chose a more complex approach. They introduce
constexpr:
struct record {
int foo;
int bar;
};
constexpr struct record record_init()
{
struct record r;
r.foo = 0x123;
r.bar = 0x124;
return r;
}
static const struct record some_default = record_init();
G++ used to support labeled initializers as an extension in C++, but
they pulled it because of worries wrt. initialization order, IIRC.
Initialization order is a real question: do you evaluate expressions in
the order they're given, in the order the fields appear in the record
type definition, or is it unspecified?
This is not a problem for keyword arguments as procedure arguments are
generally evaluated in a non-specified order, and this is usually
well-understood.
Thanks.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
