Re: "unsettag"!

[RLake@...]

Reuben Thomas escribió:

> > but it would certainly make sense if settag silently did nothing if the
tag
> > was
> > already what you were trying to set it to.

> But even if it silently does nothing, it should still reject tag({}) as
an
> illegal value...

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"))

exactly in the situation that myString was already a string. In fact,
rather than triggering a run time error, changetag could return nil, which
would be a definitive signal except in the case of changetag(nil,
tag(nil)), but I could live with that.

Actually, if I were putting that in the API, I would think about using a
sample object rather than a tag number; this would be more general,
particularly with the changes planned for tag methods. But given those
changes, this is all probably irrelevant. :-)


> > The same way I illustrated for making tables for which rawget doesn't
work,
> > I suppose. Why would you want to do that? My interest is in making
table
> > types for which foreach *does* work -- in accordance with the table
type.

> Sorry, I was getting confused, I thought you meant you could make tables
> for which for loops didn't work.

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. I suspect (actually, I know) that
you stuff magic keys into tables for your objects, too, so this isn't
actually about "n".

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.

> I mostly define functions in the order in which they're useful to curry,
> so I'd've defined settag the other way around.

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.
Sometimes that is more intuitive, even:

  lessThan6 = curryFrom2(lessThan, 6)
  decrement = curryFrom2(minus, 1)

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.

However, there are other occassions when you want to curry from the
beginning. A classic case is where you want to bind a prototype method to
the actual prototype from which it was extracted; i.e., you would like to
say:

  putOnWorkQueue = curry1(workQueue.push, workQueue)

In this case, though, you do want the self argument to come first.

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.

R.