Stuff related to the LOLCODE language.
3 posts Page 1 of 1
Postby dkackman » Fri Sep 12, 2014 6:48 pm
IMHO LOLCODE needs to support exception handling in order to be a robust and modern competitor in the language landscape.

I would propose this syntax

Code: Select all
AFAIK                                                                     BTW open the try block
    QUOSHUNT OF 10 AN 0                     
OMFG                                                                     BTW end exception block, open handler block
    FFS SMOOSH "You divided by zero" FML MKAY       BTW FML is the implicit exception YARN, FFS throws a new YARN which concatenates FML and an additional string
OIC                                                                         BTW close exception handler block


AFAIK - equivalent to try, implies I'm pretty sure this may work but who know, might not
All statements between AFAIK and OMFG tokens are within the exception handler
OMFG declares a catch block
FFS throws an exception - exceptions would always be typed as string/YARN
All thrown exceptions are captured implicitly in the FML variable. Every OMFG block has access to the implicit FML object which is the thrown string/YARN
OIC closes the catch block

Please consider this addition to the LOLCODE language specification
Postby Multiball » Sun Sep 28, 2014 10:59 pm
OMG and OMGWTF are the keywords for switch; I think it would be best to have something more different for exceptions.

At some point, PLZ TRY was considered for marking a "try" block, OH NOES was considered for marking an "exception" block, and ANYWAYZ was considered for marking a "finally" block. I think that syntax is very expressive and stylistically consistent as well as distinct and memorable.

Code: Select all
HAI 1.3
BTW It would look like this:

VISIBLE "IM DIVIDIN"
PLZ TRY
     QUOSHUNT OF 10 AN 0
     VISIBLE IT
OH NOES
     VISIBLE "UR NOT CHUCK NORRIS U CANT DIVIDE BY 0"
ANYWAYZ
    VISIBLE "IM DONE DIVIDIN"

KTHXBAI


But in a larger sense, I don't think that LOLCODE has a very well-defined system for exceptions or try-throw-catch in general. At the very least, I haven't been able to observe any documentation to that effect. Before we start trying to try-throw-catch syntax in LOLCODE, it's important to figure out how we want try-throw-catch to work in the first place. Do we want the user to be able to throw arbitrary values, of any type? Should there be a canonical exception type? It's common in many languages that allow try-throw-catch to catch multiple types of exception; should we specify which exception we're catching in the catch statement, or should have one catch statement and then the user can do logic inside to figure out what action to take?

Here's what I like: I like to be able to throw whatever I want and be able to catch whatever I want by listing an exception type in the catch statement. I think that LOLCODE should use IT to handle exceptions; the behavior should be consistent with implicitly returning IT if a function doesn't return anything explicitly.

Here's what I would propose:

PLZ TRY marks a try block.
OH NOES marks a catch block. To check IT for a particular value, you can use OH NOES, I C <expression>
ANYWAYZ marks a finally block.
O NO is syntax for "throw."

PLZ TRY must be followed by at least one OH NOES or ANYWAYZ block.
O NO can be followed by an expression: the value of this expression is stored in IT. If O NO is not followed by an expression, then IT well have whatever value it has anyway.

To catch multiple different exceptions, check the value in IT.

It would look something like this:

Code: Select all
HAI 1.3

GIMMEH num1
GIMMEH num2

PLZ TRY
        I HAS A result ITZ SUM OF num1 AN num2
        IF BOTH SAEM result AN 0
             OH NO  "WHY YR NUMBRS SUM 2 ZERO?!"
        IF BOTH SAEM result AN BIGGR OF num1 AN num2
             OH NO "WHY YOU INPUT ZERO?!"
        VISIBLE SMOOSH result AN " IS THE SUM OF YR NUMBRS" MKAY
OH NOES, I C "WHY YOU NUMBR SUM 2 ZERO?!"
        VISIBLE IT
OH NOES, I C "WHY YOU INPUT ZERO?!"
        VISIBLE IT
ANYWAYZ
       VISIBLE "I IS DONE WITH RITHMETIC"

KTHXBAI


This is a bit awkward if you can't explicitly do type comparison, which is its own discussion. If you could check the type of the value that was thrown, then it would probably make the most sense to check the type of exception, rather than an explicit value. It should be possible to do either, as long as I C performs an arbitrary comparison to IT.

Thoughts?
Postby jjm » Mon Oct 20, 2014 8:53 pm
I agree that specifying exception handling syntax and semantics is a good idea. As Multiball pointed out, there was some discussion of this previously (for example, an approach similar to what Multiball referenced was described at https://web.archive.org/web/20111027091 ... /exception).

Multiball wrote:

But in a larger sense, I don't think that LOLCODE has a very well-defined system for exceptions or try-throw-catch in general. At the very least, I haven't been able to observe any documentation to that effect. Before we start trying to try-throw-catch syntax in LOLCODE, it's important to figure out how we want try-throw-catch to work in the first place. Do we want the user to be able to throw arbitrary values, of any type? Should there be a canonical exception type? It's common in many languages that allow try-throw-catch to catch multiple types of exception; should we specify which exception we're catching in the catch statement, or should have one catch statement and then the user can do logic inside to figure out what action to take?

Here's what I like: I like to be able to throw whatever I want and be able to catch whatever I want by listing an exception type in the catch statement. I think that LOLCODE should use IT to handle exceptions; the behavior should be consistent with implicitly returning IT if a function doesn't return anything explicitly.

<snip>

This is a bit awkward if you can't explicitly do type comparison, which is its own discussion. If you could check the type of the value that was thrown, then it would probably make the most sense to check the type of exception, rather than an explicit value. It should be possible to do either, as long as I C performs an arbitrary comparison to IT.

Thoughts?
I think that this general approach (and the one proposed before) makes sense (though I prefer your syntax :). I agree that functionality to check the type of variables would make this approach easier (and potentially prevent runtime errors), though that can be implemented separately.

In terms of the implementation strategy, my first thought is to implement try-catch-finally statements similar to how if-then-else statements implemented (definition here: https://github.com/justinmeza/lci/blob/ ... ser.h#L467, implementation here: https://github.com/justinmeza/lci/blob/ ... er.c#L3283).

To determine when an exception was thrown versus a normal return with IT, we could add another return type to the ReturnType object (https://github.com/justinmeza/lci/blob/ ... ter.h#L106), for example, RT_EXCEPTION. Then, any interpreter code that expects a ReturnType (for example, see how the current return types are checked for in a switch statement here: https://github.com/justinmeza/lci/blob/ ... 1745-L1762) would then need to be aware of RT_EXCEPTION, and in the case of a try-catch-finally statement, invoke the catch cases handle it appropriately (before eventually invoking the finally case).
3 posts Page 1 of 1

Login

Who is online

Users browsing this forum: No registered users and 2 guests

cron