The LOLCODE forum

How is this:

A Default Iterator would come pre packaged for most bukkits. In the bukkit specification one should have a mechanic to manipulate the keys stack (which is what gets iterated through).

ANY Variable can be used in foreach... it essentially checks if the variable is not valid or null.  We could make this cleaner by putting in a iterator notation. This would be in bukkit's spec obviously.

I would of course want a perl like solution: X R <BUKKIT>, BTW Iterates bukkit and places the value in X.

I'll peruse through the current specs and what's out there, and put one up for ya tomorrow.

A default iterator cycles through the keys stack to figure out which values to return.
What are the benefits of having no primitive variable types btw? Wouldn't that cause a lot more overhead?
Even java has primitve types.

I'm currently looking through the perldocs on Tie which shows how perl handles iteration underneath.

Last edited by bloodycelt (2008-02-14 21:24:48)

Python allows (and in fact encourages) "+".join([1, 2, 3]) -- this little snippet outputs the string "1+2+3". Also conceptually (Python doesn't do this but imagine it) (0.0023).exponent and (0.0023).mantissa would be useful methods on a float object. Python also defines operators like + in terms of magic methods on the numeric class types, so 1 + 2 is equivalent to 1.__add__(2), and I want to use this in LOLCODE for user-defined number types. (With this feature, you could implement complex numbers or matrices in LOLCODE with no need for underlying implementation support.)

By the way:

O HAI IM BaseIterator
    I HAS A walrus ITZ NOOB

    HOW DUZ I maek YR walrus?
        BTW, ideally you'll pass in a weakref
        MAH walrus R walrus
    IF U SAY SO

    HOW DUZ I getNext?
        DO NOT WANT UnimplementedFunction
    IF U SAY SO
KTHX

O HAI IM ArrayIterator IM LIEK BaseIterator
    I HAS A position ITZ 0
    HOW DUZ I getNext?
        I HAS A value ITZ MAH SRS MAH position MKAY
        MAH position R SUM OF MAH position AN 1
        FOUND YR value
    IF U SAY SO
KTHX

HOW DUZ BUKKIT IterateNumeric?
    I HAS A iterator ITZ A ArrayIterator WIT YR ME, BTW iterator = new ArrayIterator(this)
    FOUND YR iterator
KTHX

I HAS A train ITZ A BUKKIT
train'Z 0 R "A"
train'Z 1 R "B"
train'Z 2 R "C"
IM IN YR train IterateNumeric YR boxcar
    VISIBLE boxcar
IM OUTTA YR train

Naturally, this outputs:
A
B
C

Note, by the way, that I'm using "IM IN YR <bukkit> <function> YR <indexvariable> [TIL <condition>]"; we can use EATIN as the default iterator. If the <bukkit> parameter is a variable that doesn't exist, it falls back to the 1.2 interpretation of the statement. (Note that TIL <condition> still makes sense with an iterator object; you may want to stop the loop at a condition other than the end of the data.)

Just my idea. (That's a simplistic example, too; I'd actually want to maintain a little bit of metadata in the object itself so I can handle negative and discontinuous numeric indexes.)

I considered that, but storing the state in the bukkit itself means you can't use it more than once at a time. I couldn't implement something like:

foreach($array as $a) {
    foreach($array as $b) {
        if($a != $b) doSomething();
    }
}

That's just a simple example where you want to do something with every combination of elements in the array. To make that work, each foreach() has to have its own iteration state instead of depending on the array to store the iteration state internally.

I'm not opposed to "IM IN YR <expression> [EATIN YR <variable>]" instead of "IM IN YR <expression> <iterator> [YR <variable>]" but my syntax is SLIGHTLY shorter I'd put it up to a vote.

No, we're not using KTHX to end loops (although it does beg the question, is KTHX a better "code-block-ender" for ALL code blocks?


Anyway, Here's my $0.02:


You can have the syntax:

IM IN YR train
    VISIBLE IT
IM OUTT YR train

And still be using an iterator.  All bukkits should have some default method that returns an iterator over all the slots.   This loop is just syntactic sugar for calling that.   To explicitly call any other iterator, you use the following syntax.

IM IN YR train'Z CustomIterator 
    VISIBLE IT
IM OUTTA YR train'Z CustomIterator

+10 Genius points.

I like it.   Not sure if I like EATIN or NOMNOMNOM as the default iterator "slot".  Either way, I vote for that style.  (And KTHX for closing the loop).   

(P.S. How we gonna support backwards capabilities completely?  Some might be really really tough).

I too like the verb part being a slot, but I'd suggest one thing for while-style loops: make the (TIL|WILE) <condition> part allowed even without <slot> YR <bukkit>. It's not as good lolcat, (IM IN YR ceiling WILE BOTH SAEM cheezburger AN NOOB), but it's at least consistent.

Actually:

I think we should use CAN or HAI or something to force backwards compatibility.

IM IN YR <bukkit|label> [<VERB> [YR <return value>]]...

VERB is a function that is called every time the loop iterates. The namespace would be any bukkit function, WILE or TILL.

You can string them together and it will check each in order and exit on a null or false value.

If the object is not a bukkit (ie not a variable) the loop creates a loop type bukkit which for 1.3 will just act as a label, but possibly later on we can put in some functionality for some advanced loop control.

Return values of a function in the loop statement default to IT, (so IT can be overwritten multiple times) unless specified by YR.

If no VERB is specified, then the function calls the bukkit's default loop context function (which can be overridden).
This would usually be an iterator (EATIN), but in some cases (Integers/Yarns), it just checks if null and returns the boolean.

Last edited by bloodycelt (2008-03-12 20:50:11)

I think the main difference is the label and the bukkit are conflated; this might be a good thing because you don't always have to think of a loop label and you could be in a variable. But it's a bad thing for named breaks, if we have them, and the syntax doesn't work in LOL.

BTW bloodycelt's syntax
IM IN YR X'Z CHEEZBURGERS EATIN YR NEXTBURGER

Hmm...I see another problem with both syntaxes: the "YR" before the bukkit-expr is grammatically unnecessary.

Last edited by jediknil (2008-03-13 19:57:07)

feel free to set up another topic.  I don't mind voting for more than one thing at a time.

Okay, the vote has finally come to a close.

IM IN YR <label> [<slot> YR <bukkit-expr>] [(TIL|WILE) <condition>]

BUKKIT will implement "EATIN" that iterates over all slots.
The label is used for named breaks (GTFO <label>) and named loop ends (IM OUTTA YR <label>).
Iteration happens using the following scheme:
* If the <slot> YR <bukkit-expr> clause is not provided, no iteration takes place; the block loops until the condition fails.
* If <bukkit-expr>'Z <slot> exists, each iteration invokes the slot and stores the return value in IT until the iterator raises an expression or the condition fails. (The iterator object will most likely have a function to return its current value as well.)
* If I'Z <slot> exists, each iteration applies <slot> to <bukkit-expr> in-place until the condition fails.
* If neither function exists, it's an error.

KTHX is an acceptable end-of-loop statement now, yes; I thought we discussed that earlier in this thread.

Good point about making an explicit mention of infinite loops.

JoshSuereth and I were doing further discussion of this, and we've come up with an interesting idea: If the label IS a bukkit, it's used as the scope of the block, like a WITH statement.