Re: For want of a Unicode equivalency, the elegant chr/ord functionality was lost.

[Justin J. Meza]

Hey Iso,

> I'd like to start by thanking you for the effort you've put into lci. I've
> had something of a fascination with LOLCODE since first discovering it, and
> I assure you the time you've taken to create so thorough and efficient an
> interpreter has not gone unappreciated. Alas, as with most-if not
> all-software, there are a few rough spots worth addressing.

Glad you like it! Feedback is always welcome :) and I've provided my
detailed comments below. In general, feel free to contribute to the
project, as my spare time to improve lci is increasingly limited.

> I was pleased to see that you'd proved LOLCODE Turing-complete, but your
> brute-force approach to implementing the chr() and ord() of other, lesser
> languages struck me as unbecoming. My hunch was that LOLCODE's semantics
> would be powerful enough to permit a more algorithmic approach, and I'm
> happy to report that it proved to be the case. It's not perfect, but here's my
> attempt at chr() <http://www.dinkypage.com/166894>; the code inherently
> "speaks" for itself. : )

This is a much nicer way of implementing chr()! (It would be cool if
you could swap in your chr() and ord() implementations into the BF
interpreter and submit a patch for the test case at
test/1.3-Tests/0-Benchmarks/1-BFInterpreter/test.lol.)

> They're not the crux of my post, but I did notice a few areas for potential
> improvement in writing this function. While the spec does mandate the
> <operation> clause, having to write UPPIN YR nop to simulate a while loop
> leads me to believe that this was an error (in judgment, if nothing else).
> Whether or not to provide a more natural syntax to the detriment of
> compatibility is, of course, up to your discretion.

I agree that the mandatory <operation> clause is annoying and makes
while looping contrived. Maybe it's time to break compatibility? I've
already merged changes from the 1.3 proposal into the master branch, so
1.2 compatibility is already "broken" (for the better). I don't recall
at the moment if there were any alternatives that were proposed on the
old LOLCODE forum for fixing this, though that would be interesting to
look in to.

> I also ran into the fact that ":()" is a syntax error, thus the prepended
> zero in the final SMOOSH; it seemed cleaner than sanity-checking ord and

:() being a syntax error makes sense, I think, because the colon-bracket
expressions all take some sort of argument and do not make any
assumptions about default values if one is left out.

> returning early. This in turn led me to discover that "foo:(0)bar" will be
> truncated in all cases. I do realize that handling embedded nulls might be
> tricky, but this strikes me as an unsightly implementation detail poking
> through. Again, how to proceed is entirely your prerogative.

I think you're right here, as well, and this should probably be fixed,
though the correct semantics are not yet clear to me. For example,
under which conditions should the null character not appear as part of
the string? Taking a cue from other languages may be helpful.

> Implementing chr() was fairly trivial given the language's interpolation
> capabilities, but the story for ord() was not quite as bright. Without
> native support, the only feasible way to simulate its functionality seemed
> to me to be to loop and compare <http://www.dinkypage.com/166898>. Much to

As an aside, chr() and ord() may be perfect things to offload to some
library code like what I've started in the future branch. (Keep in mind
the library binding infrastructure still needs a lot of cleaning up.)

> my chagrin, I found that BOTH SAEM "B" AN ":(42)" is FAIL. This was the
> impetus behind my posting, as it's unexpected and, I imagine, unintended
> behavior. Passing a and b through castStringExplicit() in opEqStringString() does
> fix this inconsistency (and without breaking any tests), but I figured I'd
> get your input before submitting a pull request.

Ah, this is indeed a bug, and you are correct in your solution; thanks!
Please to submit a pull request -- just make sure that you are doing
castStringExplicit() in such a way that the spec's (confusing)
stipulation that "there is no automatic casting in the equality, so BOTH
SAEM "3" AN 3 is FAIL" still holds.

> lci is performant enough that it's not *too* slow, but looping potentially

Actually, I need to make an optimization pass over lci, which I haven't
done in awhile. The main problem that I see in terms of performance is
that it's full of indirect branches (jump tables) and random data
accesses (pointers, everywhere). Making a JIT engine and changing the
data layout would definitely help things out. Just some things I hadn't
documented elsewhere, so they seemed appropriate to note here :).

> thousands of times to find a character's ordinal value isn't particularly
> efficient. With that in mind, I considered an alternate approach<http://www.dinkypage.com/166901>.
> It's still defined in terms of chrin, and stashing the lookup table in a
> global BUKKIT doesn't exactly observe best practices, but it does overcome
> the performance hurdle. Then again, it's gimped by the current single-byte
> restriction on SRS identifiers. : /

I think this is reasonable. By the way, what is the single-byte
restriction on SRS identifiers?

> Well, I have a fair bit more to say about LOLCODE and the direction in
> which I believe you're poised to take it by being the author of the premier
> interpreter, but I'll stop building this wall of text here. There is a

You should definitely contribute if you are interested! Feel free to
post on the forum, and hop on IRC if you'd like to chat.

> chance I have an unhealthy obsession with this language, but I do believe
> it's one you share. : )

Haha, you got that right!

- Justin

On Mon, Feb 25, 2013 at 07:42:42PM -0800, Iso P. Sephile wrote:
> Hey, Justin.
>
> I'd like to start by thanking you for the effort you've put into lci. I've
> had something of a fascination with LOLCODE since first discovering it, and
> I assure you the time you've taken to create so thorough and efficient an
> interpreter has not gone unappreciated. Alas, as with most-if not
> all-software, there are a few rough spots worth addressing.
>
> I was pleased to see that you'd proved LOLCODE Turing-complete, but your
> brute-force approach to implementing the chr() and ord() of other, lesser
> languages struck me as unbecoming. My hunch was that LOLCODE's semantics
> would be powerful enough to permit a more algorithmic approach, and I'm
> happy to report that it proved to be the case. It's not perfect, but here's my
> attempt at chr() <http://www.dinkypage.com/166894>; the code inherently
> "speaks" for itself. : )
>
> They're not the crux of my post, but I did notice a few areas for potential
> improvement in writing this function. While the spec does mandate the
> <operation> clause, having to write UPPIN YR nop to simulate a while loop
> leads me to believe that this was an error (in judgment, if nothing else).
> Whether or not to provide a more natural syntax to the detriment of
> compatibility is, of course, up to your discretion.
>
> I also ran into the fact that ":()" is a syntax error, thus the prepended
> zero in the final SMOOSH; it seemed cleaner than sanity-checking ord and
> returning early. This in turn led me to discover that "foo:(0)bar" will be
> truncated in all cases. I do realize that handling embedded nulls might be
> tricky, but this strikes me as an unsightly implementation detail poking
> through. Again, how to proceed is entirely your prerogative.
>
> Implementing chr() was fairly trivial given the language's interpolation
> capabilities, but the story for ord() was not quite as bright. Without
> native support, the only feasible way to simulate its functionality seemed
> to me to be to loop and compare <http://www.dinkypage.com/166898>. Much to
> my chagrin, I found that BOTH SAEM "B" AN ":(42)" is FAIL. This was the
> impetus behind my posting, as it's unexpected and, I imagine, unintended
> behavior. Passing a and b through castStringExplicit() in opEqStringString() does
> fix this inconsistency (and without breaking any tests), but I figured I'd
> get your input before submitting a pull request.
>
> lci is performant enough that it's not *too* slow, but looping potentially
> thousands of times to find a character's ordinal value isn't particularly
> efficient. With that in mind, I considered an alternate approach<http://www.dinkypage.com/166901>.
> It's still defined in terms of chrin, and stashing the lookup table in a
> global BUKKIT doesn't exactly observe best practices, but it does overcome
> the performance hurdle. Then again, it's gimped by the current single-byte
> restriction on SRS identifiers. : /
>
> Well, I have a fair bit more to say about LOLCODE and the direction in
> which I believe you're poised to take it by being the author of the premier
> interpreter, but I'll stop building this wall of text here. There is a
> chance I have an unhealthy obsession with this language, but I do believe
> it's one you share. : )
>
> Eagerly awaiting your input,
> Iso P. Sephile
>
> --
> You received this message because you are subscribed to the Google Groups "lci-general" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lci-general...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Joseph Toppi]

You may want to include your own fork of the spec. The links back to
the original are nice, but since the lolcode.com has not had the
attention it requires in years it could be confusing for those not
able to spend the required time to sort it out.

--
- Joe Toppi
(402) 714-7539
Top...@gmail.com

[Justin J. Meza]

> You may want to include your own fork of the spec. The links back to
> the original are nice, but since the lolcode.com has not had the
> attention it requires in years it could be confusing for those not
> able to spend the required time to sort it out.

I think this is a really good idea, and something that I've been wanting
to do. I'll set up a wiki on lolcode.org some time soon and create a
page for that.

On a related note, the original intent of the "HAI <version>" syntax was
to prevent precisely this and allow users to decide which version of
LOLCODE syntax to interpret their program with (mainly for backward
compatibility, though I suppose learning could be another reason). I
ditched that semantic mainly in favor of more readable code as 1.3
frequently revises 1.2 and does not strictly expand upon it. Maybe one
day it would be useful to add in a "compatibility" mode, though I also
feel that there are aspects of 1.2 that are probably best forgotten :).

- Justin