• Mark Evans (13/13) Mar 04 2003 This is an application of the FC++ library, whose author had a hand in t...
• Bill Cox (14/29) Mar 04 2003 Hi, Mark.
• Mark Evans (13/15) Mar 04 2003 Funny you should mention that; I have given it serious thought. XR is n...
• Sean L. Palmer (17/25) Mar 04 2003 Like I said, if you can (easily!) write a compiler in the language, the
• Garen (8/13) Mar 05 2003 ...
• Mark Evans (18/23) Mar 05 2003 Bootstrapping might be a litmus test, but there are many conceivable lit...
• Garen (5/15) Mar 05 2003 What is disputable? It seems pretty intuitive that typically more work ...
• Walter (3/6) Mar 05 2003 The trouble with writing D in D is hooking it up to existing back ends.
• Sean L. Palmer (6/12) Mar 06 2003 I will take your word for it.
• Walter (4/18) Mar 07 2003 ??

Mark Evans <Mark_member pathlink.com> writes:

This is an application of the FC++ library, whose author had a hand in this
work.  The concept of exact real arithmetic also appeals to me as a native
capability for D.

http://more.btexact.com/people/briggsk2/XR.html

"This is an implementation of exact (or constructive) real arithmetic, including
python and C++ versions. It is an alternative to multiple-precision
floating-point codes. An important distinction is that in multiple-precision
floating-point one sets the precision before starting a computation, and then
one cannot be sure of the final result. Interval arithmetic is an improvement on
this, but still not an ideal solution because if the final interval is larger
than desired, there is no simple way to restart the computation at higher
precision. By constrast, in XR no precision level is set in advance, and no
computation takes place until a final request takes place for some output."

Bill Cox <bill viasic.com> writes:

Mark Evans wrote:
 This is an application of the FC++ library, whose author had a hand in this
 work.  The concept of exact real arithmetic also appeals to me as a native
 capability for D.
 
 http://more.btexact.com/people/briggsk2/XR.html
 
 "This is an implementation of exact (or constructive) real arithmetic,
including
 python and C++ versions. It is an alternative to multiple-precision
 floating-point codes. An important distinction is that in multiple-precision
 floating-point one sets the precision before starting a computation, and then
 one cannot be sure of the final result. Interval arithmetic is an improvement
on
 this, but still not an ideal solution because if the final interval is larger
 than desired, there is no simple way to restart the computation at higher
 precision. By constrast, in XR no precision level is set in advance, and no
 computation takes place until a final request takes place for some output."


Hi, Mark.

You might find writing a compiler that includes the features you want 
enlightning.  I wrote a very simple one over Christmas (I had to spend 2 
weeks with my in-laws).  Three of the four advanced features I've been 
lobbying for have been tested in that compiler (Sather "includes" or 
virtual clases, advanced iterators, dynamic inheritance).  I also added 
some simple features, like the extended while loop.  I'm just now 
playing with compiler extensions.

I'd be interested in hearing about language features that allow things 
like exact real arithmetic to be supported in a standard library without 
any loss in speed.  I'm currently trying to see if aplication specific 
compiler extensions get you there.

Bill

Mark Evans <Mark_member pathlink.com> writes:

You might find writing a compiler that includes the features you want 
enlightning.

Funny you should mention that; I have given it serious thought.  XR is not the
only factor involved.  The capabilities I seek exist in other languages already,
and D folks appear consistently opposed to, or ignorant of them.  For example in
the stack frame tweaking discussions, no one brought out that first-class
continuations eliminate such nonsense.

From that standpoint, it might be more sensible for me to tack on low-level
bit-pushing capabilities to another language -- inline assembly, pointers,
optimized compilation based on TAL and/or Cyclone, etc.  Something similar to
what the Boost Python Library accomplished for Python, but with the freedom to
modify and merge the two languages involved.  I also never considered
'bootstrapping' a virtue, and think one should author compilers in languages
that are specialized, or at least particularly strong, for that purpose.

Mark

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

Like I said, if you can (easily!) write a compiler in the language, the
language has got to have something good going for it.  If you can't
(easily!) write a compiler in the language, it's not a good general purpose
language yet since quite a bit of day-to-day work involves parsing,
manipulating trees and graphs, recursion, etc.

So bootstrapping does serve a purpose as a kind of litmus test to the
maturity of a (general purpose) language.

A professional-grade compiler should use whatever is the best tool for the
job;  not all D compilers have to be written in D, but at very least one
should be.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b43khc$vn6$1 digitaldaemon.com...
 From that standpoint, it might be more sensible for me to tack on

low-level
 bit-pushing capabilities to another language -- inline assembly, pointers,
 optimized compilation based on TAL and/or Cyclone, etc.  Something similar

to
 what the Boost Python Library accomplished for Python, but with the

freedom to
 modify and merge the two languages involved.  I also never considered
 'bootstrapping' a virtue, and think one should author compilers in

languages
 that are specialized, or at least particularly strong, for that purpose.

 Mark

Garen <garen_nospam_ wsu.edu> writes:

Sean L. Palmer wrote:

 Like I said, if you can (easily!) write a compiler in the language, the
 language has got to have something good going for it.  If you can't
 (easily!) write a compiler in the language, it's not a good general purpose
 language yet since quite a bit of day-to-day work involves parsing,
 manipulating trees and graphs, recursion, etc.

...

Seems to me that there's no shortage of cool features; many have been explored
but producing efficient code for 'em is hard.  There's where I thought it was 
cool that someone with a fair deal of implementation experience (Walter) was 
designing D.

(As opposed to dreaming up a standard with a bunch of untested, unimplemented
ideas that blow up once they're tried.  C++ exceptions and export anyone?)

Mark Evans <Mark_member pathlink.com> writes:

Sean L. Palmer says:
 Like I said, if you can (easily!) write a compiler in the language, the
 language has got to have something good going for it.

Bootstrapping might be a litmus test, but there are many conceivable litmus
tests.  Bootstrapping duplicates work already done.  It also creates extra work,
because the target language has bugs while under development.  You're not just
writing the compiler, you're fighting these bugs.  And to fix the bugs, you need
to write a new version using the version which *has* them!

Moreover the general-purpose target language will never be as good at writing
its own compiler as the specialized ones designed for such purposes.
Boostrapping has a lot of cache, but I see in it no intrinsic value.

Garen says...
Seems to me that there's no shortage of cool features; many have been explored
but producing efficient code for 'em is hard.

There have been vague assertions to that effect, but few concrete examples, and
even those are disputable.

I'd like to offer a counterexample.  You admit that C++ is a high-performance
language.  Fine; take a look at FC++.  FC++ almost achieves functional language
power in C++.  Not quite the whole enchilada, but close.  (Read the papers.)  D
could take that result and, with just a few language enhancements above C++,
actually get the whole enchilada.  This kind of low-hanging fruit you dismiss by
saying it's too high to reach.

Mark

Garen <garen_nospam_ wsu.edu> writes:

Mark Evans wrote:
 
 There have been vague assertions to that effect, but few concrete examples, and
 even those are disputable.

What is disputable?  It seems pretty intuitive that typically more work is
involved to translate one representation to another the further they're apart
in structure, form, abstraction or whatever.

 
 I'd like to offer a counterexample.  You admit that C++ is a high-performance
 language.  Fine; take a look at FC++.  FC++ almost achieves functional language
 power in C++.  Not quite the whole enchilada, but close.  (Read the papers.)  D
 could take that result and, with just a few language enhancements above C++,
 actually get the whole enchilada.  This kind of low-hanging fruit you dismiss
by
 saying it's too high to reach.

I wasn't aware I dismissed anything. 

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b447kf$1an6$1 digitaldaemon.com...
 A professional-grade compiler should use whatever is the best tool for the
 job;  not all D compilers have to be written in D, but at very least one
 should be.

The trouble with writing D in D is hooking it up to existing back ends.

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

I will take your word for it.

What about just a front-end?  ;)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b46mos$2q9f$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b447kf$1an6$1 digitaldaemon.com...
 A professional-grade compiler should use whatever is the best tool for


the
 job;  not all D compilers have to be written in D, but at very least one
 should be.

 The trouble with writing D in D is hooking it up to existing back ends.

"Walter" <walter digitalmars.com> writes:

??

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b49i6c$1dks$1 digitaldaemon.com...
 I will take your word for it.

 What about just a front-end?  ;)

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:b46mos$2q9f$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b447kf$1an6$1 digitaldaemon.com...
 A professional-grade compiler should use whatever is the best tool for


 the
 job;  not all D compilers have to be written in D, but at very least



one
 should be.

 The trouble with writing D in D is hooking it up to existing back ends.