On 10/22/07, skaller <[EMAIL PROTECTED]> wrote:
> If the program can 'handle' the error .. it isn't an error.
Well, yes, but it does need a name :) Thats why I like the list
further down below. It's not complete, but it helps to focus us.
> My take on this kind of 'discussion' is that you need USE CASES
> to make progress.
I'm working on some. I've been trying to adapt some erlang code to
pseudo-felix to visualize how the various error handling works. I
should post some of that one of these days.
> > 2. Program error: The given function was not supposed to be invoked in
> > this way by other parts of the program (with these arguments, or with
> > this external state, in this order wrt. other functions etc.).
>
> Yep. In this case termination is acceptable, however sometimes
> you might want to continue, in case the error is harmless
> (this is generally called a 'warning' :)
There's some argument against this. Erlang has all sorts of "program
errors", but all they do is kill the current process. Other processes
can catch the exit and possibly recover from it.
> > 1. Abort: Not really a practical solution. Abort is really only
> > appropriate for unrecoverable errors. This may or may not be
> > recoverable, so we cannot make the decision for the end user.
>
> I don't agree. In the case of an actual error, abort is the
> only viable solution.
>
> If you write a simplistic piece of code, which is typical
> of many scripts, this is exactly what you want, and you want
> it guaranteed. By using an API that doesn't support error
> handling, you've simplified your code, and it is likely it
> will run. If it doesn't, you want to know, LOUDLY :)
I am more comfortable with this if it's killing the current "thread"
instead of the entire program. Then, another thread could recover if
the situation is recoverable.
>
> > 2. Signals: Really only used for the kernel to talk to us, and it's
> > generally a pain to deal with.
>
> However we have no choice for some events, eg Ctrl-C.
True, but we could hide the signals from the end user. We could do
what python does and just set a flag when a signal occurs then call
the signal callback sometime in the future.
> > Finally, I'd like to try to exploit some of the interesting features
> > of felix, such as our unions, fibers, and threads. These provide some
> > nice primitives that we could build from.
> >
> > One of the early suggestions was that we provide two interfaces for
> > fail-able functions: one that returns an opt value, and one that
> > aborts if the function fails. Another was to use a fiber and pass in
> > an "error channel" to a function, and if an error occurred, write the
> > error into the channel. What if we were able to combine all of these?
>
> Actually, you could invert that question, and make it a REQUIREMENT.
Sure :) The more we can leverage felix throughout the system, the more
appealing I think we can make it to others.
> Interesting. However note Erlang is highly dynamic AND it
> uses a purely functional model of many processes and message
> passing, whereas Felix is oriented towards threads and shared
> memory (at the moment).
Since I keep reading erlang and haskell documentation, I keep
imagining felix growing towards a merger of them with nice scripting
abilities :) I don't really use variables unless I have to. Of course,
I haven't actually done that much programming in felix so that could
change.
> It would be really cool if we could *merge* Felix and Erlang,
> as they seem to be complimentary.
I agree. I could see felix being more of a typesafe version of erlang.
Scala kind of does that right now, but I don't think they integrate
actors throughout the language.
> The primitives Felix has are mixed: channels/fthreads
> are cool, but they're restricted to a single CPU.
>
> pchannels/pthread are similar, and will work on a multi-processor,
> and even look like fthread, but the semantics are quite different:
> pthreads can deadlock, fthreads can't.
>
> Processes with message passing are simplest since they don't
> need direct locking, like fthreads, however with no shared
> memory, communication exchanges are required for synchronisation
> which amount to locks anyway.
Erlang (and I think scala) doesn't expose os threads to the user. It
uses threads as just a container for running erlang processes, so the
semantics in the language don't really change. If pthread channels
were really just message passing, I think we could do this too with a
high level wrapper around fthreads and pthreads.
> The real problem is that the machine stack is 'supposed'
> to be just an optimisation of procedural code, and functions
> are really procedures. However which ever C++ code we make
> to handle this stuff remains limited by C++ itself.
> I sometimes wish I could just write assembler, it would
> get rid of all the problems of using a target without
> the proper semantics.
*dangles llvm-shaped bauble* :)
> Yes, such sugar is quite possible, but it won't do what you
> might expect from Ocaml or C++ because your desugared
> form shows checking a variant .. which means we have to
> know what variant to check.
>
> Don't forget, Felix doesn't have type inference, so stuff
> like
>
> | Failure ?e => ..
>
> will not work 'in general', we need to know the actually type variables
> used to popular the union:
>
> union Return[t,e] = | Ok of t | Failure of e
I lied a little bit with this, but it's really just the exception
monad with some sugar. If we had kinding working, I believe we could
do this right now.
> Have a look at the example Monad in Felix, which propagates
> error condition. It seems nice in theory .. but look at the
> code. It isn't that simple to use! The Haskell 'do' notation
> may help, though I don't really understand it.
I don't think it's that complicated. I believe that the example from
before is essentially this:
(return do_something (\x -> do_something_else x))
`catch` (\e -> handle_error e)
Which converts to this using bind:
(return do_something >>= do_something_else)
`catch` (\e -> handle_error e)
Which just converts to this:
do x <- do_something
do_something_else
`catch` (\e -> handle_error e)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
