Re: [proposal] infix function syntax sugar

[Philipp Janda <siffiejoe@...>]

On 20.12.2011 11:34, Xavier Wang wrote:
> 在 2011-12-18 傍晚6:32，"Philipp Janda"<siffiejoe@gmx.net>写道：
>>
>> [...]
>>
>> (although I still can't see how infix
>> functions would help him solve his userdata allocation problem):
>>
> Sorry for late reply, I'm just fired by boss :-( so I can't online serveral
> days.

Sorry to hear that.

> 
> 
> think this:
> local f = obj:getflags()
> if f:contains "FOO, BAR" then
>    -- do something
> end
> 
> if you want to write f:something, then f must a userdata or table, so you
> must allocate a memory for that value.

As far as I know, f can be anything including numbers, lightuserdata and
strings. With some C hacking you could probably even use boolean (which
is an int in the C implementation).

> but if you do conditions like this:
> if contains(f, "FOO, BAR") then
>    -- do something
> end
> 
> then no memory will allocate. but it's not clearly, think this:
> 
> if f `contains` "Foo, Bar" then
> end
> 
> it just a syntax sugar of normal form. it's very like f:contains, but don't
> need allocate any memory.

That depends on what f is. If you want type-safety, f is a table or a
full userdata and you need to allocate memory. If you don't need
type-safety (i.e. if you are the only one using lightuserdata), and you
are ok with implementation-defined behavior, you would probably use
lightuserdata. Else you have only numbers.

To implement type-safe enums, I would add something like

struct {
  uint32_t value;
  uint32_t enum_id;
} e;

to the Value union in lobject.h and a global counter (in the registry,
maybe) to create unique enum_ids. This wouldn't bloat Lua objects for
the common case that lua_Number is a double, and you would have lots of
different type-safe enum types of 32 Bits each. You could even
reimplement booleans as a special case of one of those enum types.

There was an enum patch[1] some time ago, but I think it allocated extra
memory for the enums.

  [1]: http://lua-users.org/lists/lua-l/2006-09/msg01085.html

> 
> regards.
> 

Philipp