Teaching new tricks to an old dog (C++ -->Ada)

[jayessay]

And that is why $YOUR_LANGUAGE should allow arbitrary array indices. Or
should have all types be anonymous. Or should use structural type
equivalence. Or should combine data and method declarations for object
types. <Looks around guiltily.> Or should have a preprocessor. Or
infer all types. Or whatever. Just like $MY_LANGUAGE.

I don't buy this total "relativism". It smacks of the "Turing
equivalent" arguments.

This is quite correct, but also largely irrelevant. The general context

I suppose you are correct here. I'm here because I still do follow
(at least in passing) how Ada is doing and what it's followers are up
to. I try not to get into these things, but the comment from J.Coffin
comparing Lisp macros to a "preprocessor" was too much to ignore.
It's sad really how very little people here have even the ghost of an
idea of what something like Common Lisp is, can provide, and can do.

of a language flamewar is that every feature $YOUR_LANGUAGE has that
$MY_LANGUAGE doesn't have is unnecessary, and a clear sign of its
inferiority. Any feature $MY_LANGUAGE has that $YOUR_LANGUAGE lacks
is absolutely essential, and a clear sign of its superiority.

Well, now _that_ is certainly on target.

A functional language like Lisp lacks many of the features being argued

Lisp is not really a functional language, though it can be used as
one. It is very much multiparadigm.

Yes, a person can do all kinds of neat things in Lisp. A good programmer
can do all kinds of neat things elegantly in any language, and a bad
programmer cannot.

This again sounds like a TE argument and so not particularly good.
The key thing aboug Lisp is that it is a programmable programming
language and thus can incorporate at any point any construct from any
language seamlessly and transparently into it. Does that make it
_necessarily_ superior to anything else? No - that typically is
heavily context dependent. But after having analyzed and used all
these "lesser" languages it is clear to me that in _most_ cases it is
definitely superior. Nobody here is going to believe any of this.
Then again, next to nobody here even has the ghost of a clue about the
facts that would undermine their belief.

I'm sure you meant expressive convenience. Turing completeness ensures

No, I meant expressive capability also called expressivness, or
expressivity. Turing equivalence is totally irrelevant. If it had
any meaning in such discussions we would all be toggling in programs
as 1' and 0's at consoles.

"The sooner we can forget that FORTRAN has ever existed, the better, for
as a vehicle of thought it is no longer adequate: it wastes our
brainpower, is too risky and therefore too expensive to use."
- E.W. Dijkstra, EWD 340

The arguments being carried on here echo this complaint. Implicit in the
arguments for both sides is that the one wastes brainpower while the
other conserves it. That's fairly important, given that brainpower is
the only tool a programmer really has.

Yes, indeed. This is very on target and is at the heart of the issue.
Which brings us full circle to the point here that the differences
being argued, from the perspective of Lisp (or Smalltalk) are so small
as to be meaningless.


/Jon

 

[jayessay]

jayessay wrote:

[ ... ]

Lisp macros are _not_ a preprocessor and they are _vastly_ more
capable than what people typically think of when they see/hear
"macros". Lisp macros are full code analyzing and generating
constructs.

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++.

And this is just _completely_ untrue. Not even close.

but it's more or less beside the point -- which was that Ada
provides substantially less still.

While I agree with you on this, I don't really care.

Lisp only came into the conversation at all because it was implied that
the C preprocessor was _so_ unusual that nothing else provided even
vaguely similar capabilities.

Lisp coming into the conversation here is just a _bad_ thing to do.
Not because you are wrong about "preprocessors" being unusual (you're
right - they aren't.), but because you "equate" (in any sense) Lisp
macros as being a "preprocessor". They aren't. Indeed due to they
way they are defined they _can't_ be. And it is this _way_ in which
they are defined that makes them so totally different and _vastly_
more capable. If you were stupid enough to waste your time doing so,
you could write a C++ compiler _as_ Lisp macros.

something utterly unique. I certainly did not mean to imply any
particularly strong similarity between C macros and those in Lisp. As
far as that goes, most assemblers have far more macro capability as
well

OK, thanks. And I agree with the macro assembler comment as well.

As usualy, I disagree -- and I also use Lisp part of the time, and have
not only used Smalltalk, but written a fairly substantial part of a
Smalltalk implementation.

Then you don't really understand the fundamental aspect of Lisp. Just
hacking a line or two of Scheme or even CL is not "using" Lisp.

Nonetheless, I didn't and don't see the arguments as silly from either
direction. I see people who have chosen particular areas in which to
pursue their vision of perfection. While I consider it perfectly
reasonable to disagree with them, I hope I never become so
self-satisfied or condescending as to pronounce their concerns or
vision as "silly" or anything like it.

Too late.


/Jon

 

[Ioannis Vranos]

template<class T, const int MIN, const int MAX >

A solution will have this parameterization and checks:

class Array: public vector
{
// Only provide definitions for operator at() and operator[] that
// really *only* explicitly call the base ones with the proper index.
// And the few constructors doing the same, *only* explicitly passing
// the *same* arguments to the base constructors.

// Check indexing precondition Index::contains(v) in at(v) and
// operator[](v).

};

I think it is *that* simple.

O.K., I'll wait.

Unfortunately, I just tried to do it, however I have to use allocators,
and I do not know allocators yet. It looks like each of my compilers
uses its own one, different from the others, and when I used
allocator_type instead I still got errors.


Anyway, this has been my short progress. I could add run-time checks but
did not proceed since I stuck with allocators.


// Implementation-defined:
// typedef implementation defined iterator; // See 23.1
// typedef implementation defined const_iterator; // See 23.1
// typedef implementation defined size_type; // See 23.1
// typedef implementation defined difference_type;// See 23.1

#include <iostream>

#include <vector>


using namespace std;


template<class T, class A>
class Varray: public std::vector<T>
{
const A MIN, MAX;

public:
explicit Varray(const Allocator &al = Allocator(),
const A min, const A max): vector<T>(al), MIN(min),
MAX(max) {}

explicit Varray(size_type n, const T& value = T(),
const Allocator &al = Allocator(), const A min, const A max):
vector(n, value, al), MIN(min), MAX(max) {}

template <class InputIterator>
Varray(InputIterator first, InputIterator last,
const Allocator &al = Allocator(), const A min, const A max):
vector(first, last, al), MIN(min), MAX(max) {}

// ==> To be implemented
Varray(const Varray<T,Allocator>& x){}

Varray() {}

// ==> All the following to be implemented
// Varray<T,Allocator>& operator=(const Varray<T,Allocator>& x) {}
// template <class InputIterator>
// void assign(InputIterator first, InputIterator last);
// void assign(size_type n, const T& u);
// Allocator get_allocator() const;

// Only provide definitions for operator at() and operator[] that
// really *only* explicitly call the base ones with the proper index.

// Check indexing precondition Index::contains(v) in at(v) and
// operator[](v).
};


int main()
{
using namespace std;
}

 

[Ioannis Vranos]

Unfortunately, I just tried to do it, however I have to use allocators,
and I do not know allocators yet.

Of course, this does not mean that it can not be done.

 

[Dmitry A. Kazakov]

Cool. Sad that it is not open source.

There is Ada for that!

 

[Dmitry A. Kazakov]

To claim improved project success, you have to do some pretty difficult
basic research. Most of us here are programmers, not software engineering
researchers, so most of us at best have only anecdotal evidence. Therefore
when we compare languages we do so from the basis of things that affect us
as programmers.

Yes, this is of course true.

Yet it is very difficult to find competent C++ programmers. Even people
with years of practical experience are unable to do very basic things
already at the level of *using* a class/template library in a proper way.
To ask them to write reusable code... Then that evil C heritage, I see it
again and again, people doing some quite silly C-ish micro optimizations in
a loop where they create and destroy 10 string objects. It is not a science
it is just psychology...

 

[Martin Krischik]

I'm the last to attribute these facts directly to C vs. Ada, but it
doesn't seem to indicate that using Ada is particularly crucial to
either economic or technical success in this market, which places about
as high an emphasis on reliability as any. I'd also note that SCADE is
routinely used in other high-reliability markets as well, including
other transportation and nuclear plant control.

You are aware that SCADE supports more then one target programming language?

http://www.esterel-technologies.com/products/scade-suite/code-generation.html

On the one hand this supports you claim - If you use SCADE then programming
language is indeed irrelevant.

On the other hand, looking at the code sample I guess no one ever need to do
any editing inside the generated code. I suspect that programming is done
in "SCADE" not C or Ada.

Martin

PS: I find the order they give in there drop-down box quite telling with
SPARK-Ada at the top and Standart C at the bottom while at the same time
all marketing texts say first C then Ada. I supports my suspicion that
languages are more often chosen marketing effort then by actual facts.

 

[Jerry Coffin]

jayessay wrote:

[ ... ]

And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C preprocessor
can do that a Lisp macro can't do?

Lisp coming into the conversation here is just a _bad_ thing to do.
Not because you are wrong about "preprocessors" being unusual (you're
right - they aren't.), but because you "equate" (in any sense) Lisp
macros as being a "preprocessor".

I never made such an "equation" -- if you saw such a thing in what I
said, it's entirely your own delusion.

[ ... ]

Then you don't really understand the fundamental aspect of Lisp.

I wish I was still sufficiently young and inexperienced to draw such
solid conclusions based on such a complete lack of evidence or
knowledge.

 

[Martin Krischik]

I have not seen one so far, only some handcoded range checking
which is not the point.

I have got one:

http://cvs.sourceforge.net/viewcvs.py/adacl/CppCL/Include/AdaArray.H?view=markup

The compiler will use the information present in Index
to establish properties of the Adalike::vector type such that
Adalike::vector indexing (an operation) is based on properties
of Index (Index is a type! It is not an algorithm base on min
and max int parameters).

This has something to do with making the base types int, long, etc.
class types. When they are class types, you can invoke their
methods, derive other number types, and then you can use
their interface to build an array that is using the information
provided by int or provided by a type derived from int.

That's on my TODO list. Using the following class:

http://cvs.sourceforge.net/viewcvs.py/adacl/CppCL/Include/Ada-Range.hpp?view=markup

Martin

Disclaimer: Both sources might not be in working order - everytime I switch
compiler (IBM C++ -> MS-C++ -> G++) the code need reworking and the switch
to GNU is not finished yet.

 

[Ludovic Brenta]

Well, actually, during the Ada 9X design I tried to push for a
class-hierarchy of exceptions. I don't like every detail of the way
C++ does it, but at least in *this* regard, it's better than Ada.

Jerry Coffin is wrong that Ada does not allow attaching information
to exception, by the way. Ada allows attaching Strings, which is
admittedly a kludge. Using the class-hierarchy, as Jerry advocates,
would be cleaner, and type safe.

I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations. I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code. In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called. I see this as a maintenance
problem.

Another concern of mine with exception classes is that they'd have to
be allocated on the heap. There are situations where there is no heap
to allocate from, or where dynamic allocation is forbidden. I think
it necessary to provide a simple exception mechanism that does not
require any dynamic allocation, much less dynamic dispatching.

Perhaps a good middle-ground would be an addition to Ada along the
lines of:

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra;

Programs that want to carry rich information with exceptions would be
allowed to do so, while "pragma Restrictions (No_Dispatch)" or
"No_Dynamic_Allocation" would guarantee, to those interested, that no
such thing happens.

I am aware that all this would require the compiler to provide two
exception mechanisms and two kinds of Exception_Occurrences, so I may
have opened a can of worms here. Just thinking out loud

 

[Dmitry A. Kazakov]

I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations. I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code. In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called. I see this as a maintenance
problem.

Another concern of mine with exception classes is that they'd have to
be allocated on the heap. There are situations where there is no heap
to allocate from, or where dynamic allocation is forbidden. I think
it necessary to provide a simple exception mechanism that does not
require any dynamic allocation, much less dynamic dispatching.

Perhaps a good middle-ground would be an addition to Ada along the
lines of:

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra;

Programs that want to carry rich information with exceptions would be
allowed to do so, while "pragma Restrictions (No_Dispatch)" or
"No_Dynamic_Allocation" would guarantee, to those interested, that no
such thing happens.

I am aware that all this would require the compiler to provide two
exception mechanisms and two kinds of Exception_Occurrences, so I may
have opened a can of worms here.

You had. -))

Just thinking out loud

A pair of simple questions:

1. Dispatching to non-existing methods of Extra_Information?

2. Accessibility rules for members of Extra_Information. Technically
Extra_Information is a sort of result value. As such it requires special
handling of all access values (pointers) it may do to local objects.

3. Extra_Information should probably be controlled, what about finalization
rules?

4. Two copies of Extra_Information if the exception was raised in a
rendezvous? Protected type Extra_Information? (protected types are still
untagged)

5. When and where Extra_Information gets deallocated?

I think that before making any detailed proposals we should consider a
contract model of exceptions. Points 1..5 might look very different if
there were exception contracts.

 

[Georg Bauhaus]

How about

declare
...
procedure bounce is
begin
set_up_information_to_pass;
end;
begin
raise with bounce'access;
end;

 

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

You are aware that SCADE supports more then one target programming
language?

Yes, I'm aware that Ada is mentioned in their marketing information,
but looking through several 3rd-party web sites, I haven't been able to
find any mention of anybody ever having actually used this ability. I
was talking specifically about Airbus' use, and looking at:

http://www.esil.univ-mrs.fr/~spc/rcs02/slides/Baufreton.pdf
and:
http://www.systemes-critiques.org/jslc2001_slides/FrancoisXavier_Dormoy.ppt

indicates that they're consistently using C, not Ada. I also mentioned
use in other transport, and if you look at slide 12 of the second link
above, you'll notice where it specifically says this was done with C
code as well.

So far, I've found several references that mention generating C code,
some that don't specify the language, zero that mention having
generated Ada.

On the one hand this supports you claim - If you use SCADE then
programming language is indeed irrelevant.

First of all, I don't recall having made any such claim. What I have
said is that choice of programming language is but one factor among
many, and that I believe it's only rarely the single most important
factor.

Second, this seems to assume that all the code is generated by SCADE,
and none written directly. This does NOT seem to be the case -- if you
look at page 6 of:

http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf

you'll see that they only claim 70% of the code was generated by SCADE.
Given the size of project we're talking about, the remaining 30% is a
_significant_ amount of code. It seems likely to me that if they were
using Ada for the hand-written code, they'd generate Ada as well.

[ ... ]

PS: I find the order they give in there drop-down box quite telling
with SPARK-Ada at the top and Standart C at the bottom while at the
same time all marketing texts say first C then Ada. I supports my
suspicion that languages are more often chosen marketing effort
then by actual facts.

Even if we assume that all the references I've found that didn't
specify a programming language were using Ada, it still appears that C
is being used considerably more than Ada.

What I find telling is that somebody is so desparate to find _anything_
to favor their position that they'll read the order of strings in a
listbox as really meaning something -- especially when they're
apparently just in alphabetical order!

I think it's also worth noting that SCADE itself appears to be written
in C++. While they don't specify this directly, the API they supply to
make it programmable is specifically stated as being for C++ (e.g.
http://www.liveware.com.br/pdf/telelogic_scade.pdf
page 23). While they could undoubtedly provide a C++ API from Ada, it
seems most likely to me that if it was written in Ada, use from Ada
would be supported (and mentioned). I'm sure writing in Ada and ONLY
supporting C++ is a theoretical possibility, but it strikes me as quite
unlikely.

 

[jayessay]

jayessay wrote:

[ ... ]

And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C preprocessor
can do that a Lisp macro can't do?

Nothing, but then I never indicated otherwise. The point was (not as
clear as it should have been indicated) that the phrase "they provide
capabilities _similar_ to those available in the preprocessor"
(emphasis added) is wrong. They don't. For many reasons. They are
in no way anything like a preprocessor.

I never made such an "equation" -- if you saw such a thing in what I
said, it's entirely your own delusion.

Yeah right. You specifically state otherwise in the quote at the
start (please note the "in any sense").

I wish I was still sufficiently young and inexperienced to draw such
solid conclusions based on such a complete lack of evidence or
knowledge.

You have provided a mass of evidence to support the conclusion. The
fact that you don't understand this is actually even more evidence.


/Jon

 

[Ioannis Vranos]

I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations. I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code. In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

Being able to do whatever you want can certainly cause confusion for
anyone who is used to be helped how to program.

However, if you know the language, you know what to do and what to not
do. Also this way is more powerful.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called. I see this as a maintenance
problem.

Being able to walk alone can also lead to confusion. Isn't it better
if you walk with assistance?

Another concern of mine with exception classes is that they'd have to
be allocated on the heap.

No, they do not have to. One can (and in most times does) throw an
exception object on the stack.

 

[Owen Jacobson]

I am suggesting that the code will be less-than obvious to many C++
programmers. Certainly, after careful study, the experienced C++
programmer might be able to read your example, but there is room for
misinterpretation unless one is supplied a fair amount of documentation.

I haven't read this entire thread, but I just paged back up to your Ada
example and read both it and Ioannis' C++ example. I'm a C++ developer by
trade, and don't know Ada, but, yes, the Ada example was extremely
readable. So was the C++ example: the intent of both programs was
immediately clear.

This doesn't mean either example is inherently clear, just that a random
passer-by found both of them to be clear.

 

[Jerry Coffin]

jayessay wrote:

[ ... ]

I very specifcally said they were not in a preprocessor, and
merely that they provide capabilities similar to those
available in the preprocessor in C++.

And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C
preprocessor can do that a Lisp macro can't do?

Nothing, but then I never indicated otherwise.

You clearly don't understand even the simplest logic. Being able to do
all the same things directly implies having similar capabilities.

[ ... ]

Yeah right. You specifically state otherwise in the quote at the
start (please note the "in any sense").

[ ... ]

You have provided a mass of evidence to support the conclusion. The
fact that you don't understand this is actually even more evidence.

100% pure, triple distilled nonsense.

I might be a bit worried by your condemnation, but looking through your
posts elsewhere makes it clear that even on cll you're known primarily
for flaming. e.g.:

http://groups-beta.google.com/group/comp.lang.lisp/msg/a302a7e69b52ca77

My reaction is about the same as theirs: run along now, child.

 

[jayessay]

jayessay wrote:

[ ... ]

I very specifcally said they were not in a preprocessor, and
merely that they provide capabilities similar to those
available in the preprocessor in C++.

And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C
preprocessor can do that a Lisp macro can't do?

Nothing, but then I never indicated otherwise.

You clearly don't understand even the simplest logic. Being able to do
all the same things directly implies having similar capabilities.

You don't understand plain English. What you are saying is just
irrelevant.

100% pure, triple distilled nonsense.

Hardly. Your problem is simple. You made an incorrect statement but
for reasons that are beyond me you can't come to grips with that fact.
Your technique here is just to keep reiterating your mistake and
posturing as if you had a clue. You don't. And it is becoming
painfully clear.

posts elsewhere makes it clear that even on cll you're known primarily
for flaming. e.g.:

Hardly. But if it soothes your ego to think so, I'm fine with that.
I don't really understand why you are so obsessed with trying to not
come to grips with your mistake here. It's not as if it's that big a
deal.


/Jon

 

[Martin Krischik]

Martin Krischik wrote:

So far, I've found several references that mention generating C code,
some that don't specify the language, zero that mention having
generated Ada.

IMHO: One of the greatest mistakes Ada using companies do is keep quite
about it. It hurts the language a lot. Of course that means we never know.

But I am not a dreamer: There will be more C then Ada out there. It's just
the way it is.

Even if we assume that all the references I've found that didn't
specify a programming language were using Ada, it still appears that C
is being used considerably more than Ada.

I know :-( .

What I find telling is that somebody is so desparate to find _anything_
to favor their position that they'll read the order of strings in a
listbox as really meaning something -- especially when they're
apparently just in alphabetical order!

No, I was making a different point here. You are right: they are
alphabetical and I have overlooked that. But the important part of my
question was: but why didn't marketing use an alphabetical order when
writing the web side?

So my point stands: marketing effort or perhaps "coolness" has more to
influence then actual technical facts. Which I find sad, but is true for as
long I can think back for all sorts of technologies.

With Regards

Martin

 

[Ioannis Vranos]

IMHO: One of the greatest mistakes Ada using companies do is keep quite
about it. It hurts the language a lot. Of course that means we never know.

The same complaint exists in C++ community, that the companies do not advertise the
language that they use.

But I am not a dreamer: There will be more C then Ada out there. It's just
the way it is.

Well, if it becomes more freely available, no permission from any ministry for making a
compiler or something is required, I think it can become mainstream. I think it would make
more sense if Delphi was based on Ada than Object Pascal for example.

No, I was making a different point here. You are right: they are
alphabetical and I have overlooked that. But the important part of my
question was: but why didn't marketing use an alphabetical order when
writing the web side?

It is about the audience numbers I guess. But trust me this doesn't do any harm in
reality. As it wouldn't make any difference for C++ if some site mentions a library
"suitable for Java, Cobol and C++".



--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90. If someone finds it
inconvenient, please let me know].