I've started hacking up a compiler (as in, assembly) for LOLCODE, and to even get started I had to laundry list some limitations that I was going to operate on while I was playing around with it, so that on the off-chance someone convinces me to show them the code, I can point to that and throw up my hands in absolution. Anyway, I started thinking very seriously about the direction that LOLCODE is going to go, and I think it all boils down to one question:

Should LOLCODE be strongly typed?

Yes

So far, LOLCODE has appeared to me to be entirely loosely typed. I see this as causing lots of problems when it comes to implementation… even if we limit ourselves to LOLCODE being interpreted. — Kyle, 2007/05/29 09:11

Pros for Strong Typing

It'll make our lives a lot easier when it comes to implementation, especially if we make the types fairly low-level (INT CHAR STR FLOAT). — Kyle, 2007/05/29 09:11

No

Cons against Strong Typing

We would have to change our declaration/assignment “operators” to be more along the lines of “I HAS A INT CALLED COUNT/LOL COUNT R 4” instead of “I HAS A COUNT IZ 4”… which I don't necessarily see as a bad thing — Kyle, 2007/05/29 09:11

I figure this dialog needs to be started… add comments in whatever sections you deem appropriate. — Kyle, 2007/05/29 09:11

I vote for dynamic typing (for now anyway). If an operation can be supported with implicit type casting, then fine; otherwise…hmm:

HAI
CAN HAS STDIO?
I HAS A var ITZ 5
I HAS A var2 ITZ "foo"

VISIBLE var N var2
BTW prints 5foo

UP YR var2!!5
BTW this could generate an error, or it could simply
BTW add 5 to the last character of the string, making
BTW its value "fot"

KTHXBYE

It might be good to figure this out before going too crazy with operators. I also think we shouldn't necessarily shy away from a challenge. :) — ILikePi, 2007/05/29 15:49

I agree with dynamic typing. Otherwise, it sounds too much like a programming language. — Risser, 2007/05/29 16:31

Why not use a combination? Both Objective-C and the new Actionscript have opt-in type checking. In Objective-C, everything is declared as a pointer. If you declare an instance as a pointer of type id (not void), then type-checking will not be performed on that instance unless it is cast to another type of pointer. However, if you declare the pointer as a pointer to a specific class, type checking is done at compile-time.

We could do something similar by having all variables default to being typeless, with the types we already have, then really the only problem we have is if we try to use a string as a number, assuming it's not a string of numbers. If someone wants to be careful that they don't fall into this trap, they can use the optional typing syntax. Things might get a little more complicated in introducing arrays, functions and classes, but I think it's doable. — Michael Buckley, 2007/05/30 17:11

I definitely think a default typeless style with optional typing would be good. BOOL, NUMBR, WRDZ are the ones I would suggest.

I HAS A BOOL CHECK IZ (YA RLY/NO WAI)
I HAS A CHECK IZ (YA RLY/NO WAI)

I HAS A NUMBR VAL IZ #
I HAS A VAL IZ #

I HAS A WRDZ SPEECH IZ I HAS A DREEM
BTW everything following IZ is part of the value)
I HAS A SPEECH IZ I HAS A DREEM

But it prevents someone from saying

I HAS A VAL IZ I HAS A DREEM
UP VAL!!1

— Greg, 2007/05/31 15:07

Except BOOL should be BUUL

— timlin45, 2007/06/04 18:52