[Ohrrpgce] thoughts about slice handles

[Ralph Versteegen]

2009/1/15 James Paige <Bob at hamsterrepublic.com>:
> On Wed, Jan 14, 2009 at 10:11:40PM -0800, S'orlok Reaves wrote:
>>
>> > Another option is to just make a couple commands like:
>> >  create string slice(stringID)
>> >  update string slice(stringID)
>> I know this is way beyond the context of this email chain, but is it possible, given an ID, to detect if this is an old-style string ID or a new-style slice ID, and then pass it to the appropriate function automatically?
>>
>> I know that your original idea could do this, but I dis-liked the large indices (although I understand your use of them, now). What about creating a new "type" in the HSpeak bytecode:
>>
>> Kind "1" is (already) for numbers.
>> Make kind "8" be "slice IDs", or "handles".
>
> Hmmm... Interesting. So you are suggesting extending the existing "kind"
> system to add other data types to the language, right?

It might make sense to add extra command kinds for array manipulation
and maybe string commands, but I don't think separating commands
handles is very beneficial: if HamsterSpeak becomes typed, I propose
that it should be weakly typed and commands could therefore return
values of any type.

>> It seems like slices are going to be a huge, completely separate part of your infrastructure, so why try to multiplex them onto the "number" type, where they just add confusion? Moreover, this allows you to have a middle layer between handles and their internal representation, so that you can change from a big array to a linked list, to an array of linked lists (or whatever) without worrying about breaking existing code.
>
> Well, I am hoping that slices will not really be completely separate. I
> intend to migrate a lot of code to use them, and although the migration
> process introduces a risk of breakage, it also introduces and even
> larger risk of bugfixage, since most of the old code is so crufty and so
> badly in need of a cleaning.
>
>> You'll need a little bit of syntax for this in Hamsterspeak, of course, and in CUSTOM. What do you think?
>
> But what syntax, I wonder?
>
> I'd love to hear TMC weigh in on this one.
>
> ---
> James

S'orlok has quite a nice point which I've also been thinking about. If
HamsterSpeak becomes a typed language, then we could add a special
type for opaque objects which could be used for handles. :=, == and !=
would be the only supported operators (checked at runtime), and you
could assign it to variables and pass it around to scripts and
commands as you like. If passed to a builtin command not expecting it
(don't worry, we wouldn't need to add type checking to every existing
command) you could get a beautifully informative error.

What I like about this is that if viewed in a script debugger I might
someday write, or written out by 'trace', you'd see "Menu handle 129
(instance of 'Main menu')" instead of "129"

We won't get away with turning any existing handles (such as NPC
references) from integers into opaque types not supporting arithmetic
operations because they are occasionally used as integers, for example
comparing NPC references to determine layering. However, sprite,
slice, menu, and menu item handles should all be ok?

So, we could also add a special weak type which is an integer which
knows what it's meant to be enumerating. Then in a debugger you would
see "String 5" instead of '5', but you could still pass it to any
command without error (maybe an optional warning) or multiple by 8 to
calculate a y position on screen, for example.

I can't think of any need for new syntax. Maybe just a new command for
two "is opaque type"