Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible BUKKIT Implementation #11

Open
kierajreed opened this issue Oct 6, 2018 · 4 comments
Open

Possible BUKKIT Implementation #11

kierajreed opened this issue Oct 6, 2018 · 4 comments

Comments

@kierajreed
Copy link

I HAS A TEST ITZ []

PUT "hello" IN TEST

todo: accessing contents

@AlexisGoodfellow
Copy link

AlexisGoodfellow commented Oct 10, 2018

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
Copy link

ghost commented May 22, 2019

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
Copy link

AlexisGoodfellow commented Feb 5, 2020

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.

@alecgargett
Copy link

alecgargett commented Nov 27, 2024

I think the indexing system when GRABBIN should be "FURST WUN", "SEKENT WUN", "FURD WUN", "FORF WUN" and so on up to "TENF WUN" and then from then on "11F WUN" and so on.

So:

GRAB FURST WUN FRUM <bukkit>

I think this negates the need for "FRUNT" and instead of "BAK" I suggest negative indexing starting with "LAAS WUN" so that we can continue with "SEKENT LAAS WUN" and so on.

When inserting I suggest "BEFOR" and "AFTUR" and "IN" as in:

SHUV <var> BEFOR FURST WUN IN <bukkitt>

SHUV <var> AFTUR FURST WUN IN <bukkitt>

SHUV <var> AFTUR LAAS WUN IN <bukkitt>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants