Eigenstate: myrddin-dev mailing list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error Handling [Was: Wishlis


Hm. So, are you interested in taking a crack at error handling?

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.

For reference, what I'm currently focused on:

    - Parser generation
    - Self hosting (And with that, a C ABI)
    - 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.

-- 
    Ori Bernstein

Follow-Ups:
Re: Error Handling [Was: WishlisRyan Gonzalez <rymg19@xxxxxxxxx>
References:
Wishlist.Ori Bernstein <ori@xxxxxxxxxxxxxx>
Re: Wishlist.Ryan Gonzalez <rymg19@xxxxxxxxx>
Re: Wishlist.Ori Bernstein <ori@xxxxxxxxxxxxxx>
Re: Wishlist.Ryan Gonzalez <rymg19@xxxxxxxxx>