"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:amomoe$nft$1@digitaldaemon.com...
> Egad.  Masochist?  ;)
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:amnk6l$2j71$1@digitaldaemon.com...
> > Why would you prefer setjmp/longjmp to exceptions?

setjmp/longjmp are two of those things best left in the dustbin of history <g>. I remember the long (and acrimonious) debates 12+ years ago about whether C++ should follow the termination or resumption method of handling exceptions. The consensus eventually settled on the termination model, and I think experience has shown it works well enough. It's not an area where I'm well informed, and I'll stick to what I know will work.

In article <amnk6l$2j71$1@digitaldaemon.com>, Walter says...
>
>Why would you prefer setjmp/longjmp to exceptions?

Sorry for the brevity, but I already typed this once and my machine hosed itself during the send...

1. setjmp/longjmp allow me to make exception capabilities on platforms whose compilers do not support exceptions.

2. exceptions only jump "up".  setjmp/longjmp can jump any direction. setjmp/longjmp allow you to create cooperative multithreading systems, which can be useful even when "real" threads are available, because a cooperative multithreading system has lower overhead (no CPU mode switch) and simpler synchronization semantics (all code between "yield()" calls is essentially inside a critical section).  Not for everybody, but if you know what you're doing it can be very useful.  Such a multithreading library is also cross platform (OS and compiler) portable -- and such libraries have been developed and sold.

3. I can make most of exceptions with setjmp/longjmp (I already have, once).  I can even make resumable exceptions with setjmp/longjmp.  I cannot make setjmp/longjmp out of exceptions.

Of course, setjmp/longjmp would be even more useful if the requirements were more stringent.  The actual ANSI requirements leave too much "undefined", as usual...  But I think I can get around that by making my own wrapper functions that I put in an external module -- no correct optimizer is going to trust the contents of its general purpose registers after coming back from a function call that resides in a module that isn't known until link time...

Mac

In article <amp30n$15b4$1@digitaldaemon.com>, Walter says...
>"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:amomoe$nft$1@digitaldaemon.com...
>> Egad.  Masochist?  ;)
>>
>> Sean

No, just the opposite actually.  I am willing to expend considerable effort in a short, focused development effort that pays considerable dividends to my ease of programming later.  setjmp/longjmp feature in some of these focused reused components.  Without these components, some of my other programming efforts would have been much more painful, over a much longer time period.

>>
>> "Walter" <walter@digitalmars.com> wrote in message news:amnk6l$2j71$1@digitaldaemon.com...
>> > Why would you prefer setjmp/longjmp to exceptions?
>
>setjmp/longjmp are two of those things best left in the dustbin of history <g>. I remember the long (and acrimonious) debates 12+ years ago about whether C++ should follow the termination or resumption method of handling exceptions. The consensus eventually settled on the termination model, and I think experience has shown it works well enough. It's not an area where I'm well informed, and I'll stick to what I know will work.

I am a little disturbed that a language that is trying to rid itself of outdated ideas from C/C++ would stick with a decision made over seven years before C++ was standardized.  Especially if you consider that some of those decisions might have been performance based.  How valid is a performance consideration today that was made based on the behavior of CPUs that were common 12 years ago?  12 years ago, caches were much smaller, 16bit segmented code was the norm, branch prediction was either primitive or non-existent, anonymous registers weren't available to microcode (for that matter, microcode may not have been present), etc.

I am also somewhat discouraged that my suggestion keeps getting shot down because resumption in other languages isn't sufficient.  I know that resumption in other languages isn't sufficient.  That's why I tried to work out a resumption mechanism that actually was useful, and suggest it to a group of people who seem to be interested in making a language full of features that actually are useful.

I do realize that I tend to do rather odd things with programming languages, and understand not wanting to spend the considerable effort necessary to support a new paradigm if I am the only person interested (and it would appear that I am, at least amongst the readers of this newsgroup.  I know that I have at least two very interested coworkers, but they're unlikely to switch to D anytime soon, so their opinions aren't terribly relevant here...).  So how about this:

1. Ignore the resumable exception handling (at least for now ;-), and focus your
energies on features you and the other users want and on bug fixes.
2. Leave me access to a setjmp/longjmp that, in some fashion, I can guarantee
will return me to the location I stored and with the proper values in all my
variables (which basically means any register caches got flushed by the longjmp,
I think).  If I have access to C's setjmp/longjmp, and if my "externally linked
wrapper function" system will provide the no-optimization guarantees I need,
then you wouldn't even have to do anything for this step...
3. Finish up whatever you intend to do with raii/auto references and make sure
they get cleaned up properly when an exception is thrown.

Given those three things (which hopefully don't actually require any code changes that you weren't going to make anyway), I can experiment with my own resumable exception system.  I can use setjmp/longjmp for my movements up and down the stack, and then I can use the built-in exceptions when my system reaches a termination/continuation stage.  Using the built-in exceptions at that stage will guarantee proper cleanup of raii/auto references and execution of finally clauses (and 'out' contracts?  or do exceptions invalidate those?), all of which have to be held off until it is known that the "exception" is not going to be resumed.

If I successfully make such a system, and if it shows usefulness either with my home projects or with my (or my coworkers) work projects, then I can come back with examples of how the system simplified the architecture and implementation of some real systems.  Then the value can be judged qualitatively, rather than with a great deal of hand-waving, which is all I am currently able to do, since no equivalent resumable exception system exists.  Also, my library should be a pretty good starting point for the issues you would have to consider in any compiler implementation you might choose to add.

I will point out that the implementation will probably start out as a set of C++ macros and functions.  That will increase the likelihood that my coworkers will start playing with the system.

Mac

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:amq3fe$2mq4$1@digitaldaemon.com...
> I am a little disturbed that a language that is trying to rid itself of
outdated
> ideas from C/C++ would stick with a decision made over seven years before
C++
> was standardized.

I'll also beg that I'm not well informed about the resumptive model, so I can't argue intelligently on its merits.

> Especially if you consider that some of those decisions might
> have been performance based.  How valid is a performance consideration
today
> that was made based on the behavior of CPUs that were common 12 years ago?
12
> years ago, caches were much smaller, 16bit segmented code was the norm,
branch
> prediction was either primitive or non-existent, anonymous registers
weren't
> available to microcode (for that matter, microcode may not have been
present),
> etc.

I think performance matters a lot, and will continue to matter. CPU improvements in the last 12 years have changed the way code is generated (such as scheduling), but the fundamental issues to writing fast code haven't.

> I am also somewhat discouraged that my suggestion keeps getting shot down because resumption in other languages isn't sufficient.  I know that
resumption
> in other languages isn't sufficient.  That's why I tried to work out a resumption mechanism that actually was useful, and suggest it to a group
of
> people who seem to be interested in making a language full of features
that
> actually are useful.

Ok.

> I do realize that I tend to do rather odd things with programming
languages, and
> understand not wanting to spend the considerable effort necessary to
support a
> new paradigm if I am the only person interested (and it would appear that
I am,
> at least amongst the readers of this newsgroup.  I know that I have at
least two
> very interested coworkers, but they're unlikely to switch to D anytime
soon, so
> their opinions aren't terribly relevant here...).  So how about this:

One of the goals of D is to make it easy for a correct and efficient compiler to be built. If a feature is hard to implement, coupled with not being widely demanded, realistically puts it further down the list.

> 1. Ignore the resumable exception handling (at least for now ;-), and
focus your
> energies on features you and the other users want and on bug fixes.

You're right.

> 2. Leave me access to a setjmp/longjmp that, in some fashion, I can
guarantee
> will return me to the location I stored and with the proper values in all
my
> variables (which basically means any register caches got flushed by the
longjmp,
> I think).  If I have access to C's setjmp/longjmp, and if my "externally
linked
> wrapper function" system will provide the no-optimization guarantees I
need,
> then you wouldn't even have to do anything for this step...

I think you can use setjmp/longjmp in D just as you would in C. After all, they share the code generator <g>.

> 3. Finish up whatever you intend to do with raii/auto references and make
sure
> they get cleaned up properly when an exception is thrown.

Yes, absolutely.

> Given those three things (which hopefully don't actually require any code changes that you weren't going to make anyway), I can experiment with my
own
> resumable exception system.  I can use setjmp/longjmp for my movements up
and
> down the stack, and then I can use the built-in exceptions when my system reaches a termination/continuation stage.

Ok.

>  Using the built-in exceptions at that
> stage will guarantee proper cleanup of raii/auto references and execution
of
> finally clauses (and 'out' contracts?  or do exceptions invalidate
those?), all
> of which have to be held off until it is known that the "exception" is not
going
> to be resumed.

Out contracts are not executed if an exception is thrown. I should probably
document that (!).

> If I successfully make such a system, and if it shows usefulness either
with my
> home projects or with my (or my coworkers) work projects, then I can come
back
> with examples of how the system simplified the architecture and
implementation
> of some real systems.  Then the value can be judged qualitatively, rather
than
> with a great deal of hand-waving, which is all I am currently able to do,
since
> no equivalent resumable exception system exists.  Also, my library should
be a
> pretty good starting point for the issues you would have to consider in
any
> compiler implementation you might choose to add.

Good idea.

> I will point out that the implementation will probably start out as a set
of C++
> macros and functions.  That will increase the likelihood that my coworkers
will
> start playing with the system.

Ok, I understand your reasons now. -Walter

Have you looked at Icon's goal-directed evaluation?  It is very well designed. Walter and you should both take a look at it.  See "coroutines" and "generators" in the documentation.  (The term "goal directed evaluation" is less frequent.)

Mark


In article <amq3fe$2mq4$1@digitaldaemon.com>, Mac Reiter says...
> setjmp/longjmp feature in some of these focused reused
>components.  Without these components, some of my other programming efforts would have been much more painful, over a much longer time period.

Icon uses a success/failure paradigm wherein either runtime condition is considered normal.  This paradigm is different from an "exception" which by definition should not happen.  In Icon, one uses many small pass/fail expressions which, taken as a group, can formulate small algorithms or even entire programs.

In the abstract, I suppose a language could support both paradigms, though implementing some of Icon's more advanced features (like goal-directed evaluation with its use of success/failure) would be lots of extra work.

Mark


In article <amt5mr$jqr$1@digitaldaemon.com>, Mark Evans says...
>
>Have you looked at Icon's goal-directed evaluation?  It is very well designed. Walter and you should both take a look at it.  See "coroutines" and "generators" in the documentation.  (The term "goal directed evaluation" is less frequent.)
>
>Mark
>
>
>In article <amq3fe$2mq4$1@digitaldaemon.com>, Mac Reiter says...
>> setjmp/longjmp feature in some of these focused reused
>>components.  Without these components, some of my other programming efforts would have been much more painful, over a much longer time period.
>
>
>

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:amt5mr$jqr$1@digitaldaemon.com...
> Have you looked at Icon's goal-directed evaluation?  It is very well
designed.
> Walter and you should both take a look at it.  See "coroutines" and
"generators"
> in the documentation.  (The term "goal directed evaluation" is less
frequent.)

I just received a copy of the Icon manual, but I haven't read it yet.