Re: Error Handling [Was: Wishlis

[Ryan Gonzalez <rymg19@xxxxxxxxx>]

On July 4, 2015 8:15:16 PM CDT, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:
>Hm. So, are you interested in taking a crack at error handling?
>

Maybe. I tend to get lost in C once the program gets beyond 100 lines!

>I haven't actually put too much thought into this so far. The main
>reason I
>asked for references is because all I've seen mentioned in academia are
>variations on error checking and exceptions. I'm actually not sure what
>other
>ideas have been tried, no matter how harebrained.
>
>As far as actually making an improvement, there are a few steps I'd
>want to go
>through before actually implementing something (these aren't
>necessarily in
>order, and of course things will be interleaved):
>
>1) Figure out the scope of the problem that is being solved. What
>exactly
>   are the goals?
>
>2) Informally sepecify a few alternatives, spelling out what sort of
>changes
>it would look like syntax-wise, what code generated should loosely look
>like, think a bit more about what the implications are, what features
>are
>interacted with and how, and whether the features have general
>applications
>   elsewhere.
>
>3) Figure out what it would look like in some nontrivial real world
>   code -- "port" some code to the proposal.
>
>4) Implement it.

I think this is my issue. Whenever I work on a compiler, I have a tendency to either stay at 2 forever or jump straight to 4. :)

>
>For reference, what I'm currently focused on:
>
>    - Parser generation
>    - Self hosting (And with that, a C ABI)

IMO, I'd leave self hosting for a little later on. Not that it's bad, but I've heard that it can be trouble because every potentially breaking change requires going through the entire compiler and fixing everything. Not fun!

As for parser generation, when Myrddin self-hosts, are you going to tweak YACC (byacc's source is very readable) to output Myrddin code, or are you going to hand-write the parser?

>    - Library coverage
>
>On Sat, 04 Jul 2015 11:43:44 -0500, Ryan Gonzalez <rymg19@xxxxxxxxx>
>wrote:
>
>> ...except, that's invalid. The second function passed to >>= must
>return a
>> monadic value. I think you meant:
>> 
>> someFunction >>= (\a -> return $ a+n)
>> 
>> or:
>> 
>> (n+) <$> someFunction
>
>Oops. Right. My haskell is rusty.
>
>> Well, Myrddin already has traits. You could do something like
>Haskell's 'do'
>> syntax. The person would put something like this:
>> 
>> try: std.option
>>  a()
>>  b()
>> error e
>>  ...
>> ;;
>> 
>> The 'try' is just syntactic sugar. It takes a type T that implements
>some
>> trait ('error'?) and a sequence of statements and does this:
>> 
>> For every statement that returns an item X of type T:
>>  If calling std.is_error or something like that on X returns true:
>>   Jump to the 'error' block, giving it X.
>
>That might not be bad, although at the moment, traits are purely
>compile
>time, so you wouldn't be able to mix hetrogenous error types.

I don't let Haskell lets you do that, either.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.