On Mon, 2007-10-22 at 10:05 -0700, Erick Tryzelaar wrote:
> 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.
How about just some basic I/O?
We have stream abstraction, but we need functions to
open files as
1) Native handle
2) C FILE*
3) C++ iostream
and then model these 3 different file types with instances
of the I/O typeclasses (so we can do I/O the same way
on all 3 once they're opened).
I/O is always a source of fun errors .. :)
> > > 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.
That happens in Felix with exceptions (but not abort()), and is
actually a bug/problem! Since threads are detached, there is no
way to get the thread return code, nor any way for the thread
to report an error (unless you organise it with pchannels
or a shared variable or whatever).
However thread failures are even worse than ordinary ones.
> >
> > > 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.
Felix doesn't sit well with signals or callbacks, because these
things use the machine stack which gets in the way. It also has
no way (other than C/C++ binding code) to access global data
(deliberately) whereas signals can ONLY access global data.
RF was going to work on signals..
> > > 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.
Yes, but agreeing isn't enough: it's actually an R&D problem to
*find* the right primitives.
Fthreads/channels feel right, they're very powerful and the
implementation in the driver is so simple -- they just have
to be right.
however the non-local goto method of exception handling
mixed up with throwing continuations smells. For example
you'd think unwinding the stack would be a matter of
forgetting it and letting the gc collect unreachable frames,
but this *isn't* the case because the caller addresses would
persist and make upstack frames accessible if there were
a single pointer into the top of stack frame.. so actually
the unwinding code has to NULL out these pointers.
> > 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.
Neither have I: spending too much time on the libraries (C++)
and the compiler (Ocaml).
> 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.
Channel (p or f) can be message passing .. but neither excludes
ALSO sharing memory.
Another level (processes) could do that.
> 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.
The kinding only works up to a point: Felix does calculate
meta-types, but higher order types (kinds) don't really work.
What I mean is you have kinds, but you can't make values
of them, you can only calculate the kinds of existing types.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
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
