Discussions in support of the LOLCODE.com wiki
You are not logged in.
I searched through the forum for suggestions like this, but I came up empty, so if it has been brought up before please forgive. I notice that the assignment by addtion ( += ) operator is implemented as
UPZ a!![b]
in which the value stored in a has the value of b added to it.
Why not do one of these
a NOMZ b
a NOM b
a NOM NOM NOM b
instead? After all, when the kitteh NOMZ the cheezburger, the cheezeburger is INSIDE the kitteh. Seems obvious to me and one other enthusiast (who is a pro developer, whereas I am merely a somewhat bright amateur). I have read suggestions for using NOM for trimming yarn variables or returning sub-yarns, and for file deletion or object deallocation. None of these seem consistent with the essence of NOMming, which is, strictly speaking, an act of eating. I think DO NOT WANT would work better for deletion and deallocation.
Back to operators, the assignment by subtraction ( -= ) could be
a BARF b
a BARFZ b
a ACKZ b
or somesuch. I like ACKZ for the Bill the Cat reference a la Bloom County, but it doesn't seem to be anywhere in the LOLCat canon. There are examples of "barf" and "barf'd" that show up on ICHC, so if you want to be consistent with that, there you go.
I like this project. I am a technical trainer, and some of the classes I teach involve a bit of coding. If the dotnet implementation becomes useable, I can't wait to see the looks on peoples' faces when they get some sample code from me ![]()
Offline
Cool idea. The trouble is, we're trying to stay away from infix operators in the current revs of the language. Which means for now we're stuck with A R SUM OF A AN B. We could, however, eventually add an increment function, which would look something like A IZ NOMMIN.
The meta-trouble is, there's been a lot of changes since 1.2 and the 1.3 draft on the main site, but they aren't organized or collected anywhere. In addition, the site's seen very little activity in the last few weeks...months...
The most involved members, JoshSuereth and Coda, were last seen developing a simple language called Protocopter that's going to have a roughly 1-to-1 correspondence with LOLCODE, so that the front-end can parse LOLCODE and spit out Protocopter, then anyone's backend can take Protocopter and give .NET bytecode, Parrot bytecode, C, or straight-up assembly. Or just interpret it on the fly. (The idea being both to separate interface from syntax, since it was getting confusing in the discussions, and to make it a little easier to write a back-end.)
The project may revive soon...and I love the idea of tech trainees using LOLCODE to learn programming. Remember that the Bukkit-model is prototype-based (like JavaScript, at least before the strange changes in 2.0), so it won't match up exactly to the more OO-based languages that rule today.
Offline
Actually those changes to ECMAScript have been cancelled.
The proposal was stricken down in exchange for a more modest revision to the standard.
And as far as the project reviving is concerned, I wrote a fairly hefty piece of self-referential Protocopter code the other night -- an implementation of Protocopter's "function" class, itself written in Protocopter. I realized a few hours afterward that I'd actually introduced a couple of bugs into the implementation, too.
(That's a good sign -- when you realize that code in a language that lacks a compiler/interpreter actually has a bug in it.)
Offline