Re: "unsettag"!

[Reuben Thomas <rrt@...>]

> No, I meant silently do *nothing* (including not produce an error). That
> would change the definition of "illegal values": the new definition would
> be that you cannot *change* the tag of an object except to a tag created by
> newtag() rather than the existing rule which is that you cannot *set* the
> tag of an object except to a tag created by newtag(). With the revised
> definition, it would be legal to say:
> 
>    changetag(myString, tag("an example string"))

> It's easy to make tables for which for loops don't work. :-) The classic
> case is a vector:
> 
> for k, v in myVector do
>   write(format("%i: %s\n", k, v)
> end
> 
> This won't work when you hit the "n" key.

Only because "n" isn't a valid integer. That's what I call a bug, not
a for loop not working. I meant the for loop itself going off the
rails, not the code in the middle barfing on the data.

> A more interesting question is how to make tables which are non-iteratable.
> With the existing Lua, that's not possible, but with "extended for and
> next" it would be: you would simply define the next tagmethod to always
> return nil.

That's what I was after.

> That's certainly a legitimate approach, but there's nothing stopping you
> from currying from the end of the argument list instead of the beginning.

Indeed.

> With Lua, currying at the end is even more useful, because the Lua
> convention (and not an unreasonable one, either) is that variable numbers
> of arguments go at the end.

And why would you want to curry the variable arguments?

> As a side issue, it's always been niggling at the back of my mind whether
> the construct object:method(arguments) should really be a ternary operator
> instead of object:method being exactly the curry shown above.

How would that make a difference?

-- 
http://sc3d.org/rrt/ | free, a.  already paid for (Peyton Jones)