At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>I think we definitely have to be able to resize vtables at compile time,
>>which is a form of run time. It's vaguely possible we could restrict
>>multithreading during compile phase.
>
>We need to be single-threaded when we make any sort of wholesale
>structural change to the universe. It's a lot easier (and cheaper) to do
>it during a period where we're guaranteed to be single-threaded than it is
>to have all the running threads go stop and check periodically. (I don't
>really want to be coordinating on mutexes every statement or block or whatever)
Are we really willing to pay the price and handle the complexities of
*resizing* vtables?
If the idea is supporting arbitrary add-on operators, which I believe will
be done seldom, for only some specific classes, wouldn't it be better to
have a ``catch all'' entry for operators different than the built-in ones?
Of course, add-on operators would not have the same ``performance'' of
built-in ones, but:
1) We don't have to add an entry to *all* vtables for each operator we want
to add to a *specific* class.
2) Anyway, even resizing vtables we would need some more indirection to
determine in which position of the vtable is which operator.
3) We wouldn't have to deal with the complexities of resizing vtables.
4) Having one only vtable entry as a ``catch all'' would allow defining new
operators ``on the fly''. For example, I try to use the theta operator
between two bignumbers. Even if theta wasn't defined, it would call the
``catch all'' of the bignumber vtable, that could do a search à la
AutoLoader, or even define the operator based on the Unicode number of the
symbol theta, or anything like that.
In any of the two ways (resizing or catch all), the operator can be
transparently used in the language, so the choice of which one to use
actually doesn't impact the language, AFAICT.
- Branden
