Possible BUKKIT Implementation

[kierajreed]

I HAS A TEST ITZ []

PUT "hello" IN TEST

todo: accessing contents

[AlexisGoodfellow]

For information storage, I'd go with SHUV <var> INTO <numbr_index> OF <bukkit>.

Provided with the language should be the special values FRUNT and BAK for each end of the bukkit. This syntax should be SHUV <var> INTO FRUNT OF <bukkit> and SHUV <var> INTO BAK OF <bukkit>.

As for accessors, I think GRAB <numbr_index> FRUM <bukkit> should do nicely (again, with FRUNT and BAK builtins).

For removing elements from the bukkit, I suggest REMOOV <numbr_index> FRUM <bukkit> (again, with FRUNT and BAK builtins).

[ghost]

Same syntax can work for associative arrays: lose the FRUNT and BAK (only for associative arrays), and use a <yarn_key> instead of <numbr_index>.

Possibly can integrate both into the same storage system (i.e. same BUKKIT can hold both indexed and associative array entries)

[AlexisGoodfellow]

After becoming a little older and wiser, these are now my thoughts:

1. I'm in favor of associative arrays being BUKKITs
2. I also think we should have numerically indexed LIZTs

FRUNT and BAK should only apply to LIZT, but the SHUV/GRAB/REMOOV syntax seems like it could be used by both LIZTs and BUKKITs. If so, they'll need to have different initialization syntax so that the interpreter/compiler can have a deterministic parse tree.

To that end, I'm in favor of the syntax I HAS A VAR ITZ EMTEE_BUKKIT and I HAS A VAR ITZ EMTEE_LIZT, respectively. This ensures that the grammar of LOLCODE doesn't change significantly and makes the initialization constants easily tokenizable.