On Mon, 2007-09-10 at 20:33 -0700, Erick Tryzelaar wrote:
> On 9/10/07, skaller <[EMAIL PROTECTED]> wrote:
> > I'm thinking to make begin/end keywords. Begin/end mark a block,
> > and are equivalent to { } sometimes, like Ocaml.
> > do/done marks a loop or control structure *without* a scope,
> > i.e. it's labels and gotos.
> >
> > So vaguely:
> >
> > whilst c begin sts end;
> > ==> whilst c do { sts }; done;
> >
>
> Sure, makes sense. However, I think it'd be reasonable to consider if
> we actually need do/done structures without scope. Lots of languages
> don't have this construct.
do/done stuff is just goto sugar. You're asking the wrong
question I think. The question is why we need begin/end/scope
block scoped for/while etc statements, when we have Higher
Order Functions???
The goto sugar is useful for low level implementations,
particularly when the HOF version may not be optimised.
Don't forget .. we have no exception handling.
Standard EH is only proper for reporting faults before
program termination. Non-local goto is ugly, but it is
a proper low level primitive (standard EH is NOT).
Some kind of continuation management, e.g. delimited
continuations, may be the best.
> > So .. if you say 'open f' and f doesn't exist, Felix
> > aborts, as it should.
>
> I disagree. I think the runtime library should only bomb if it's
> actually a fatal error. Something like a missing file or other
> spurious errors *should* be handle-able.
Yes and No. Read again: if you say 'open f' and f can't
be open .. this is a Fatal Error by definition. The name
suggests it opens a file .. and open a file it MUST.
If you actually mean 'try to open a file', don't use the
'necessarily open a file' function with post-condition
'the file is open'.
> > Otherwise use
> >
> > let h = try_open f in match h with
> > | Failed => ...
> > | Handle h => ..
> > endmatch
>
> Sure, except if you have to do a lot of kernel interactions, this gets
> really ugly.
I don't see how this is any different to what C does, except
we have a disciplined static typing regime. If you use 'try_open'
you HAVE to check the result. If you don't want to check the
result, you have to use 'open'.
> To, say, change a directory tree's group and permissions,
> would be very ugly and unwieldy.
I agree there is a problem with escaping context -- Felix only
provides non-local goto, and it does NOT work across functions.
But we can't implement a solution for a non-existant proposal.
I have no idea how to solve this properly.
Undelimited type based exceptions (as in C++) are definitely
wrong, polymorphic variant constructor based exceptions like
Ocaml has are better, but also wrong.
Throwing and catching objects and applying a type/constructor
switch is a totally crap idea.
A sane idea is something like: to throw, you write on a channel.
The catch is a procedure reading on the channel.
So .. if you complete normally the channel is forgotten by
the writer and the reader becomes unreachable and suicides.
If you have an exceptional completion, the writer gains
control and continues on, and when it forgets the channel,
the error-ing context suicides.
So using coroutines/continuations here like that is a MUCH better
idea IMHO, though only an idea at present. Want resumable
exceptions? Sure, well the exception handler can do what
it wants and write back on the exception channel, and the
raiser expecting support can try to read the channel.
Etc ..
The point is..
Felix threads ALREADY subsume exception handling.
Remember .. Felix threads suicide when unreachable so
'unwinding' a context like 'throwing' unwinds the stack
is automatic and already works.
The main problem is that you can't do fthreading inside
functions.
Which is why I implemented the 'get rid of all the
functions' optimisation.. :)
I've checked.. generators convert properly to procedures,
and even 'yield' seems to work. The problem now is simply
that application of closures (expressions for the function)
still use the machine stack.
> This would be doable if we put enough sugar into it. On the other
> hand, monadic exceptions might be simpler. I need to read up on them.
Yep, we will provide sugar when we know WHAT to sugar .. :)
It's a real problem: compiler programming needs to be driven in part
by library implementations, which needs to be driven by user
applications .. and I simply cannot do all three of those things,
in fact I could use a second compiler writer .. and then
there is documentation and advocacy.. ;(
If we could get equivalent of 2-3 full time voluntary work units,
I might double or triple that by throwing money at it.. but we're under
the 1 unit level. For tax reasons I actually have to throw some
cash at something and whatever it is will probably divert attention
from other things.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
