How come Ada isn't more popular?

How come Ada isn't more popular?

[artifact.one]

Hello.

I am a long time C programmer (10 years plus), having a look
at Ada for the first time. From my (inadequate) testing, it seems
that performance of average Ada code is on par with average
C code, and there's a clear advantage in runtime safety. The
GNU ada compiler makes pretty sure that there are very few
platforms without easy access to Ada, so portability should be
on at least an equal footing too.

My question is: how come Ada isn't more popular?

This isn't intended to start a flame war, I'm genuinely interested.

thanks,
MC

Re: How come Ada isn't more popular?

[adaworks]

<artifact.one@googlemail.com> wrote in message 
news:1169531612.200010.153120@38g2000cwa.googlegroups.com...
>
> My question is: how come Ada isn't more popular?
>
Ada suffered, in its early days, from a convergence of several
things.  One is that the designers of the language did not anticipate
the impact of the personal computer and the democratization of
computing.   There were other factors, as well.

1)  The DoD mandated Ada before there were any good compilers
     or development environments in place.   That began a routine
     practice of rubber-stamping waivers to use other languages.

2) The compiler publishers, having a captive audience, inflated the
     price of compilers and tools, making Ada unattractive for anyone
     in the non-DoD world.  For example, Alsys sold a compiler for
     the personal computer at $4000 per copy thereby putting out
     of the range of most companies and every hobbyist.

     Turbo Pascal and other alternatives were already in place and
     much cheaper than Ada.   A few brave souls tried to compete
     with products such as RR Software's Janus Ada and Meridian's
     AdaVantage, but the full environment (e.g., integrated editors,
     debuggers, etc.) were not in place they were for Turbo Pascal.

3)  Inept DoD management of the Ada initiative.  Sometimes it seemed
     that the DoD was trying to make Ada a bad choice for businesses.
     The public line was that they wanted commercial users, but the
     practices often put barriers in the way.

4)  Other languages were cheaper to acquire, cheaper to use, and had
     no copyight associated with them.   The copyright was eventually
     removed, but late.

5) The earliest compilers were not uniformly good.  I recall the mainframe
    compiler from Telesoft was, when compared to other language choices,
    simply terrible.   It was slow, had an awkward development environment,
    and did not support the central features of the mainframe very well.

    Many of those early compilers were "checkbox" compilers.   On the form
    where one had to check-off "Validated Ada Compiler" the fact that a 
validated
    compiler was available was considered enough.   One compiler I recall quite
    vividly was for the Tandem.   Although the compiler was validated, that same
    compiler was not integrated into the rest of the system tools, and barely
    supported by the operating system.   The word in the Tandem management
    was that no one was expected to take Ada seriously, but the checkbox had
    to be supported.   This was quite widespread in the industry.

6) Really good compilers began to appear around 1989.   By then Ada's reputation
    for being slow, cumbersome, and hard to use had already been firmly set.

7) Instruction in the language was bad.   I recall a U.S. Navy Admiral 
complaining
    about how hard it was to teach anyone Ada.   He described the efforts he put
    in place to make this happen.    I told him he had hired people to do the 
teaching
    who were incompetent.   That was true, but they had PhD's and he thought 
that
    should have ensured success.   The fact was that those teachers had not yet 
come
    to a full understanding of the Ada and their own confusion was more a source 
of
    obfuscation than enlightenment for the students.

8) Grabbing defeat from the jaws of victory.   In the mid-90's, when Ada became
    a powerful alternative to other languages, when tools were in place, the 
language
    modernized, and the availability of low-cost (or free) compilers could have 
made
    it attractive, the DoD lost its nerve and gave the impression that Ada was 
no longer
    part of the DoD language requirement.  A lot of people misinterpreted this 
and thought
    the DoD had decided to abandon Ada entirely.

9) Traitors.   Some people who were previously charged with promoting Ada, in
     particular certain former AJPO officials, once having left government, 
exploited
     their former role and joined the forces against Ada.   They were able to 
use their
     title as former ... to gain credibility and lobby against the use of Ada in 
exactly
     the places where it was appropriate to lobby for it.

Ada is not now, nor has it ever been, the perfect language.  There is no perfect
language.  However, anyone who understands Ada and has a good understanding
of the competing technologies realizes that Ada continues to be the most 
appropriate
choice when the requirement is for a language that will improve the probability 
of
an error-free software product at a reasonable cost.  The alternatives, mostly C
and C++ are generally less dependable.  In fact, I often wonder why anyone would
pick a language that is inherently error-prone (e.g., C++) and expect a result 
that
is error-free.

If one does an objective comparison of Ada to its alternatives, in the design 
and
constuction of dependable software, Ada will come in with high marks -- higher
than most alternatives.   If one is looking for a language that is well-suited 
to
supporting a long-lived software system, Ada is certainly better than most of
the alternatives.

More could be said in favor of Ada.   I will leave that more to others.

Richard Riehle

Re: How come Ada isn't more popular?

[artifact.one]

Ah, politics and dramatics! It's had quite a history then - always
a killer.

Thanks for the impromptu documentary.
MC

Re: How come Ada isn't more popular?

[Arthur Evans Jr]

In article <L2ith.12633$ji1.1337@newssvr12.news.prodigy.net>,
 <adaworks@sbcglobal.net> wrote:

> Ada suffered, in its early days, from a convergence of several
> things.

Richard Riehle wrote eloquently on this subject. I'll add one more point.

Ada came out at a time when the government in general and the defense 
Department in particular were widely perceived as evil. Since Ada was 
intended to be used to write programs that would kill people, some 
perceived it as inherently evil. Many folks, myself included, made the 
argument that wrenches are used to build weapons; should we ban 
wrenches? Those who had already made up their minds couldn't or wouldn't 
hear that argument.

This argument alone wasn't a major desideratum in Ada's failure to 
become more popular, but then neither was any one of Richard's 
arguments. All of these arguments taken together, though, were too much 
at the critical time when Ada might have succeeded as intended.

Too bad.

Art Evans

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Arthur Evans Jr wrote:
> 
> Ada came out at a time when the government in general and the defense 
> Department in particular were widely perceived as evil. Since Ada was 
> intended to be used to write programs that would kill people, some 
> perceived it as inherently evil. Many folks, myself included, made the 
> argument that wrenches are used to build weapons; should we ban 
> wrenches? Those who had already made up their minds couldn't or wouldn't 
> hear that argument.

These people never seemed to be very concerned about the DOD's 
involvement in COBOL, either.

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Arthur Evans Jr wrote:
>> Ada came out at a time when the government in general and the
>> defense Department in particular were widely perceived as
>> evil. Since Ada was intended to be used to write programs that would
>> kill people, some perceived it as inherently evil. Many folks,
>> myself included, made the argument that wrenches are used to build
>> weapons; should we ban wrenches? Those who had already made up their
>> minds couldn't or wouldn't hear that argument.
>
> These people never seemed to be very concerned about the DOD's
> involvement in COBOL, either.

Different generation?

Regards -- Markus

Re: How come Ada isn't more popular?

[Ed Falis]

adaworks@sbcglobal.net wrote:
> Ada suffered, in its early days, from a convergence of several
> things.

It would make a fascinating book.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

adaworks@sbcglobal.net wrote:
>>
> Ada suffered, in its early days, from a convergence of several
> things.  One is that the designers of the language did not anticipate
> the impact of the personal computer and the democratization of
> computing.   There were other factors, as well.

An excellent reply. Ada was also ahead of its time. Computers in 1983 
really weren't up to the demands of Ada.

>      Turbo Pascal and other alternatives were already in place and
>      much cheaper than Ada.   A few brave souls tried to compete
>      with products such as RR Software's Janus Ada and Meridian's
>      AdaVantage, but the full environment (e.g., integrated editors,
>      debuggers, etc.) were not in place they were for Turbo Pascal.

There's always the question of why, given TP's widespread popularity, C 
became more popular.

> 6) Really good compilers began to appear around 1989.   By then Ada's reputation
>     for being slow, cumbersome, and hard to use had already been firmly set.

Actually, the DEC Ada compiler of 1984 was pretty good.

> 8) Grabbing defeat from the jaws of victory.   In the mid-90's, when Ada became
>     a powerful alternative to other languages, when tools were in place, the 
> language
>     modernized, and the availability of low-cost (or free) compilers could have 
> made
>     it attractive, the DoD lost its nerve and gave the impression that Ada was 
> no longer
>     part of the DoD language requirement.  A lot of people misinterpreted this 
> and thought
>     the DoD had decided to abandon Ada entirely.

Windows 95 was the 1st widely used OS with support for tasking. Ada (95) 
was the only widely available language with support for tasking at the 
time. We probably lost a good opportunity to gain more acceptance of Ada 
by not including a standard windowing library and promoting Ada as the 
best language for taking advantage of Win95's features.

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Tue, 23 Jan 2007 20:09:48 GMT, Jeffrey R. Carter wrote:

> adaworks@sbcglobal.net wrote:
> 
>>      Turbo Pascal and other alternatives were already in place and
>>      much cheaper than Ada.   A few brave souls tried to compete
>>      with products such as RR Software's Janus Ada and Meridian's
>>      AdaVantage, but the full environment (e.g., integrated editors,
>>      debuggers, etc.) were not in place they were for Turbo Pascal.
> 
> There's always the question of why, given TP's widespread popularity, C 
> became more popular.

Because C was sufficiently worse. At some point Visual Basic came and
superseded both... (:-))

>> 6) Really good compilers began to appear around 1989.   By then Ada's reputation
>>     for being slow, cumbersome, and hard to use had already been firmly set.
> 
> Actually, the DEC Ada compiler of 1984 was pretty good.

Yes!
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> Because C was sufficiently worse. At some point Visual Basic came and
> superseded both... (:-))

What a depressing idea ...

-- 
Jeff Carter
"Strange women lying in ponds distributing swords
is no basis for a system of government."
Monty Python & the Holy Grail
66

Re: How come Ada isn't more popular?

[gautier_niouzes]

Jeffrey R. Carter:

> >      Turbo Pascal and other alternatives were already in place and
> >      much cheaper than Ada.   A few brave souls tried to compete
> >      with products such as RR Software's Janus Ada and Meridian's
> >      AdaVantage, but the full environment (e.g., integrated editors,
> >      debuggers, etc.) were not in place they were for Turbo Pascal.
> There's always the question of why, given TP's widespread popularity, C
> became more popular.

It has to do with the deep unportability of Pascal and (consequence)
the fragmentation of Pascal into incompatible dialects. At the time you
had Amiga's, Atari's, Mac's; you had MS Windows coming to replace DOS,
so a DOS-oriented, Pascal dialect had little chance against C, except
for a short time.
TP was an extremely fast compiler producing unoptimized code (except
some trivial XOR AX,AX's), but with the CPU's frequencies quickly up
around 1990, the interest was more targeted to profit from this speed
in the compiled code and less to have a couple millions more of LoC
compiled per second.
...
> Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
> was the only widely available language with support for tasking at the
> time. We probably lost a good opportunity to gain more acceptance of Ada
> by not including a standard windowing library and promoting Ada as the
> best language for taking advantage of Win95's features.

Mmmh I think  it was a good idea *not* to include a standard windowing
library: then now Ada would be stuck with an outdated standard
windowing library. There was also another problem then: the lack of a
good but cheap or free compiler.
Don't be so pessimistic, Ada's quality only appear with time - and of
course with the effort of brave souls.
If you say "I'm a smart software engineer, Ada is for me and not for
you", you won't help Ada.
If you make good, visible, useful open-source software with Ada, you
will help.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: How come Ada isn't more popular?

[tmoran]

> > Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
> > was the only widely available language with support for tasking at the
> > time. We probably lost a good opportunity to gain more acceptance of Ada
> > by not including a standard windowing library and promoting Ada as the
> > best language for taking advantage of Win95's features.
>
> Mmmh I think  it was a good idea *not* to include a standard windowing
> library: then now Ada would be stuck with an outdated standard
> windowing library. There was also another problem then: the lack of a
> good but cheap or free compiler.

    Actually some of us did try to make a standard Windows library and
promote Ada as the best language for Windows programming (see "CLAW, a
High Level, Portable, Ada 95 Binding for Microsoft Windows" TriAda 1997).
As a matter of fact, it seems everybody who wanted access to the Windows
API designed a standard windowing library - eg GWindows et al.
    Also, there was the Janus Ada compiler which was pretty cheap at
something like $100, and the early versions of the free Gnat compiler were
coming out at that time.

Re: How come Ada isn't more popular?

[Gautier]

tmoran@acm.org wrote:
>>> Windows 95 was the 1st widely used OS with support for tasking. Ada (95)
>>> was the only widely available language with support for tasking at the
>>> time. We probably lost a good opportunity to gain more acceptance of Ada
>>> by not including a standard windowing library and promoting Ada as the
>>> best language for taking advantage of Win95's features.
>> Mmmh I think  it was a good idea *not* to include a standard windowing
>> library: then now Ada would be stuck with an outdated standard
>> windowing library. There was also another problem then: the lack of a
>> good but cheap or free compiler.
> 
>     Actually some of us did try to make a standard Windows library and
> promote Ada as the best language for Windows programming (see "CLAW, a
> High Level, Portable, Ada 95 Binding for Microsoft Windows" TriAda 1997).
> As a matter of fact, it seems everybody who wanted access to the Windows
> API designed a standard windowing library - eg GWindows et al.

The point is that neither CLAW nor GWindows were included in the Ada standard, 
and it is a good thing. And promoting Ada for Windows programming in an Ada 
conference is good, but that won't make that language a lot more popular: you 
have to make promotion outside the insider circle...

>     Also, there was the Janus Ada compiler which was pretty cheap at
> something like $100, and the early versions of the free Gnat compiler were
> coming out at that time.

I'm afraid you read a bit too quickly: I discussed about finding a (_good_) 
and (cheap or free) compiler in 1995. GNAT needed a few years to become really 
good, IHMO.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: How come Ada isn't more popular?

[Markus E Leypold]

Gautier <gautier@fakeaddress.nil> writes:

>>     Also, there was the Janus Ada compiler which was pretty cheap at
>> something like $100, and the early versions of the free Gnat compiler were
>> coming out at that time.
>
> I'm afraid you read a bit too quickly: I discussed about finding a
> (_good_) and (cheap or free) compiler in 1995. GNAT needed a few years
> to become really good, IHMO.

Given, that I recently found in 3.15p (which is not the newest one, I know):

  - Really bad bugs handling Read and Write of discrimated records,

  - Race conditions in the runtime system when trying to catch
    interrupts,

  - No way to catch the console break under windows with the interupts
    mechanism (i.e. a design error in my opinion),


I wonder wether GNAT was good even in, say 2002 (or whatever was
3.15p's release date).

And all those problems are really expensive to circumvent (partly
because the runtime system insists on fiddling with the signal
handlers).


Regards -- Markus

Re: How come Ada isn't more popular?

[Stephen Leake]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Given, that I recently found in 3.15p (which is not the newest one, I know):
>
>
>   - Really bad bugs handling Read and Write of discrimated records,
>
>   - Race conditions in the runtime system when trying to catch
>     interrupts,
>
>   - No way to catch the console break under windows with the interupts
>     mechanism (i.e. a design error in my opinion),
>
>
> I wonder wether GNAT was good even in, say 2002 (or whatever was
> 3.15p's release date).

It was good, in my opinion; at that time, I was far more productive
writting real applications using GNAT 3.15p than Borland C++.

> And all those problems are really expensive to circumvent (partly
> because the runtime system insists on fiddling with the signal
> handlers).

But to be fair, you have to say how easy the solution was in Ada, vs
the solution to the same problem in some other language. 

What is the equivalent of Discriminated_Record'Write in C? The concept
doesn't even exist!

-- 
-- Stephe

Re: How come Ada isn't more popular?

[Markus E Leypold]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Given, that I recently found in 3.15p (which is not the newest one, I know):
>>
>>
>>   - Really bad bugs handling Read and Write of discrimated records,
>>
>>   - Race conditions in the runtime system when trying to catch
>>     interrupts,
>>
>>   - No way to catch the console break under windows with the interupts
>>     mechanism (i.e. a design error in my opinion),
>>
>>
>> I wonder wether GNAT was good even in, say 2002 (or whatever was
>> 3.15p's release date).
>
> It was good, in my opinion; at that time, I was far more productive
> writting real applications using GNAT 3.15p than Borland C++.
>
>> And all those problems are really expensive to circumvent (partly
>> because the runtime system insists on fiddling with the signal
>> handlers).
>
> But to be fair, you have to say how easy the solution was in Ada, vs
> the solution to the same problem in some other language.

Unfortunately that's not been the case that Ada was cheaper here:

 - Read/Write Bug (see below).

 - Races with interrupts / catching break -- well, catching INT or
   TERM in C or console breaks is really dead easy. With GNAT you've
   first to remove all interrupt handling, then re-attach the
   interrupts and introduce a race at the begin of the program (which
   makes the program freeze -- aborting properly at that point would
   be OK, but a freeze is not). And catching the windows console break
   in C just takes a C procedure call. Since in the GNAT RTS it's not
   mapped to an interrupt (design error, IMHO), you'll have to write a
   C stub and do some magic there (see, C again, only more effort).


> What is the equivalent of Discriminated_Record'Write in C? The concept
> doesn't even exist!

Partly the circumvention was not to use discriminated records together
with controlled types, meaning instead of having a string in an
discrimated part, the string was set to empty when it would have been
hidden by the discriminant. I could have done that in C. The other
part was to write 'Write myself and do the right thing. I could also
have done the same in C.

And C has union types. Of course they are not type safe (as C always
is), but the same effect can be achieved when writing a proper
handling procedure that depend on some discriminating field.

Look I do not want to promote C (far from it). And I'm not talking
about embedded programming or aerospace, but end user PC
applications. So in this not uncommon case / market my hypothesis is
(has been now for some time) that the ecological niche for Ada has
been closed by the development of languages and tools during the last
20 years:

  - Some low level stuff is still better done in C, since the
    operating systems and their interface libraries are written in C
    and often fit better to that language (I've the impression that
    there are some problems with the GNAT tasking runtime, since it
    introduce a new layer above the host operating system's
    philosophy). 


  - Other languages are also type safe and have become really
    fast. They have a more "expressive" and powerful type system (I'm
    basically talking about the Hindley-Milner type system here and
    OCaml or SML, not about Java, mind you. If I look at the new Java
    generics (there's a paper by Wadler about it) and compare the new
    subtyping polymorphism there with the Hindley-Milner type system,
    I just begin to see how impossible it is to write really useful
    container libraries without polymorphism of that kind. No, Ada
    doesn't have it and C doesn't have it. And the absence of useful
    generics and the absolute impossibility to get those with
    preprocessing in C is in my eyes a much more important argument
    against C as an application programming language than the buffer
    overflow problems. And yes, that applies to Java up to 1.4 also).

  - Other languages have garbage collection.

  - Even C has acquired a number of new tools (splint, valgrind, C
    Cured) that make reasonable reliable programming (we are not
    talking about autopilots and not about rockets here, at least I
    don't!) in C much more feasible.


  - The vendor situation ...

Overall I'm haunted by the impression that C + some high level
language of your choice with a proper FFI makes more sense for day to
day development of (a) complete PC applications, (b) Web software and
(c) small tools (say: "scripting").

I'm not alone with that, AFAIK. But note: I don't say this to
disparage Ada. Ada, to me, is some kind of super-Pascal. But for
historical reasons that has not played out (between Turbo Pascal being
traditional on Micros and having the community Ada didn't have at that
time and the Ada compilers coming just a bit too late), and now the
situation has changed. The time of the Pascals is over. Their "mind
share" has been swallowed by Python, Ocaml, Java, dependent on to
which paradigm of programming those people adhere.
 
If you look upon the number of books sold by O'Reilly, the big
contender is not C (and not C++ anymore). They are Java (basically for
people with a C++ mind that have seen the light and don't want to do
manual memory management any more), Python, Pearl and Ruby (no pointers, no
types, but GC) and of course C#.

The trend I see, is that GC is a must, clumsy pointer handling is out
and types are an option for those that can understand them.

I admit I'm not completely sure how all that fits together. But the
perception that it is C vs. Ada is IMHO wrong. That particular fight
was -- in a sense -- already lost when Turbo Pascal and Modula lost
out against C. (Examining that part of history should answer the OPs
question). Perhaps the answer in general is, that unreliability
doesn't matter so much in most software (MS Office i.e. has become
pretty stable despite being written in C AFAIK), since it is not
embedded or not in aerospace.

Regards -- Markus

Re: How come Ada isn't more popular?

[Markus E Leypold]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> I admit I'm not completely sure how all that fits together. But the
> perception that it is C vs. Ada is IMHO wrong. That particular fight

To complement that: My impression (which I've already expressed in one
those mails that went into the black hole), is, that a number of
protagonists arguing for Ada here in this thread, argue as if Ada was
the famous silver bullet of software engineering.

But as we all know (or should), that is not true:

 - There is no silver bullet.

 - The development process has a lot of influence on the quality of
   code produced.

 - You cannot just compare languages: You need to compare the language
   in the context of existing culture / community and the market of
   tools provided for that language and the quality of thos tools.

 - There is no way to get really high quality code w/o a formal code
   review.


So now, that the pressure is of to take Ada under every circumstance
and we have recognized that Ada is just one of many factors
contributing to quality and competitiveness of a project, we are
perhaps open to see why some project might decide (have decided)
against Ada or for that against any "exotic" language for purely
economic reasons.

Just one more consideration: It might be true that Ada avoids costs in
the long run. This doesn't help if the project has a limited budget
and the primary consideration need to be to get the initial up front
costs (tools, training) below a certain limit.

We have to scenarios:

  1. Aim for high quality, spent a lot of money at the beginning for tools and
    training, but after longish preparations bring a product into the
    market which has hardly any bugs and doesn't cost much maintaining.

    Now you can have 

       (a) Success: All customers buy your product, install it and
           finally forget you, since the product works flawlessly.

       (b) Failure: Product doesn't fly. The users don't like
           it. You've lost lots of money.


  2. Aim for acceptable quality (how ever low that is). Spent some money
   for tools and hire programmers for a mainstream language. Some are
   not really good and have to be trained, but you can either fire
   them in time or train them. At least you don't have to train them
   much. Then push the product to the market as fast as possible.

   Now you can have 

       (a) Failure: You lost money, but not as much as in 1.a. 

       (b) Success: Customers like your product. Unfortunately they
           have to patch it now and then, but that makes you look good
           actually: You provide a service for your customers and they
           remember you because they have an on-going relation to your
           company.

           Eventually they buy / have to buy new versions, so become
           customers a second time (if you don't annoy them too much,
           that is just the definition of "acceptable quality").

           Of course the overall costs are higher, they have to be
           financed from the sales of the software. But that is money
           you now have.


And now pretend you're an investor: Which approach would you like
best? (1) or (2)? Note that the success is mostly dependent on wether
the customer likes your product or not -- basically the same in with
acceptable and outstanding code quality (like means: makes a good
impression at the first look). So in (1) the risk*money is higher than
in (2).

Furthermore consider now you don't have the money to pull through
(1). You can only go for (2) now. That of course costs in the long run,
but then you spent money later that you have later and don't try to
spent money now you don't have (and perhaps won't get from an
investor).

I think that is basically what has been happening in the PC software
industry for the last 20 years. Many software engineers cannot
understand why one would not ensure quality as early as possible in
the development process, since fixing bugs later costs much more than
fixing them early. But this way to look upon things assumes that the
product succeeds. If you think in terms of risk or sometimes only in
terms of liquid assets the perspective changes.

No, I certainly don't like it very much. But I suggest one should take
these factors into consideration before wondering that Ada is not more
popular then C and attributing everything to the presumed fact that
those people that make the other decision are just morons.

 - There are other languages than C around. The success of C has been
   largely the result of historical circumstances.

 - It is not technical merit alone on which languages succeed (wether
   generally or wether in single projects).

Hope this text isn't too disjoint.


Regards -- Markus

Re: How come Ada isn't more popular?

[Ray Blaak]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> No, I certainly don't like it very much. But I suggest one should take
> these factors into consideration before wondering that Ada is not more
> popular then C and attributing everything to the presumed fact that
> those people that make the other decision are just morons.
> 
>  - There are other languages than C around. The success of C has been
>    largely the result of historical circumstances.
> 
>  - It is not technical merit alone on which languages succeed (wether
>    generally or wether in single projects).
> 
> Hope this text isn't too disjoint.

Excellent actually. It is always good to be reminded that the real reasons
things succeed or fail often (usually?) have nothing to do with sound logical
principles, but instead everything to do with those confusing irrational
behaviours people tend to engage in: politics, emotions, first impressions,
the insanity of the marketplace in general.

It is not enough or even economical to be "right".

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

 > They are Java (basically for
> people with a C++ mind that have seen the light and don't want to do
> manual memory management any more

Sorry, but that's a misconception - I don't remember when I was the last 
time I was messing with manual memory management in a regular C++ code. 
I estimate that in my current programming I call delete (or free or 
whatever) once in 5-10 kLOC.
Is Java going to save me from this *nightmare*? Wow, I'm impressed.

> The trend I see, is that GC is a must, clumsy pointer handling is out
> and types are an option for those that can understand them.

Indeed, looks like everybody is going in that direction.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>  > They are Java (basically for
>> people with a C++ mind that have seen the light and don't want to do
>> manual memory management any more
>
> Sorry, but that's a misconception - I don't remember when I was the
> last time I was messing with manual memory management in a regular C++
> code. I estimate that in my current programming I call delete (or free
> or whatever) once in 5-10 kLOC.

OK. I'll have to reconsider this statement. I usually couldn't trim
down 'automatic' allocation to that extent, but that might have been
my application area. What I remember though, is the difficulty to
recover from exceptions in the presence of automatic (scope bound)
memory management. (I hope I'm making sense here, else I'd really have
to go back to my C++ mind and notes and try to retrieve the right
vocabulary and reasoning and -- well -- I don't really want to have a
C++ discussion in c.l.a. :-). If we must, let's shift that to personal
mail or to another group ...).

> Is Java going to save me from this *nightmare*? Wow, I'm impressed.

Good for you, if it is not a nightmare. But from what I remember in
the 1997s to 1998s (that was when there still were problems with STLs,
exceptions and the string libraries in C++ and when there was no
standard and Java was new), that this was one of the motivations that
people shifted to Java (either from C++ or from C). The other
motivation was the "portable GUI" which, I think, mostly disappointed
the expectations.

Of course I might be wrong. This is just teh impression I got "from
the trenches" and I might be missing a mor global point of view. It
perhaps does not apply today where C++ and the understanding of C++
has matured a bit (there is even an embedded subset of C++ which will
annoy folks here no end :-).


>> The trend I see, is that GC is a must, clumsy pointer handling is out
>> and types are an option for those that can understand them.
>
> Indeed, looks like everybody is going in that direction.

And certainly. Why should advances in hardware only buy more spiffy
GUIs and not something to ease the everyday pain for the everyday
software developer :-).

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

>> Sorry, but that's a misconception - I don't remember when I was the
>> last time I was messing with manual memory management in a regular C++
>> code. I estimate that in my current programming I call delete (or free
>> or whatever) once in 5-10 kLOC.
> 
> OK. I'll have to reconsider this statement. I usually couldn't trim
> down 'automatic' allocation to that extent, but that might have been
> my application area. What I remember though, is the difficulty to
> recover from exceptions in the presence of automatic (scope bound)
> memory management. (I hope I'm making sense here, else I'd really have
> to go back to my C++ mind and notes and try to retrieve the right
> vocabulary and reasoning and -- well -- I don't really want to have a
> C++ discussion in c.l.a. :-).

Why not having C++ discussions on the list where people claim that C++ 
sucks? :-)

> If we must, let's shift that to personal
> mail or to another group ...).

Yes, please feel free to contact me with regard to the above (follow the 
links in my signature).

> But from what I remember in
> the 1997s to 1998s

Most programming languages were terrible at that time, that's true.

> (that was when there still were problems with STLs,
> exceptions and the string libraries in C++ and when there was no
> standard and Java was new), that this was one of the motivations that
> people shifted to Java (either from C++ or from C).

Yes, I know that. And I will keep stating that this motivation resulted 
from common misconceptions, further amplified by Java marketing.
I've even heard that Java is better, because it has a String class and 
there is no need to use char* as in C++ (!). FUD can buy a lot.

> The other
> motivation was the "portable GUI"

Yes.

> which, I think, mostly disappointed
> the expectations.

Still, GUI that sucks was better than no standard GUI at all for lost of 
  people. Both C++ and Ada are in the same camp in this aspect. I'm not 
claiming that these languages should have standard GUI, but not having 
it definitely scared many.

> Of course I might be wrong. This is just teh impression I got "from
> the trenches" and I might be missing a mor global point of view. It
> perhaps does not apply today where C++

Well, there is still no standard GUI for C++, but the choice with 
non-standard ones is quite impressive:

http://www.free-soft.org/guitool/

> and the understanding of C++
> has matured a bit

Yes. Sadly, too late for those who already changed their mind.

> (there is even an embedded subset of C++ which will
> annoy folks here no end :-).

I think that at the end of the day the embedded C++ will disappear from 
the market as the "full" C++ gets wider compiler support on embedded 
platforms. There will simply be no motivation for using subsets.
Subsetting C++ would be beneficial in the sense similar to Ravenscar or 
by extracting some core and using it with formal methods (sort of 
"SPARK++"), but I doubt it will ever happen.

>>> The trend I see, is that GC is a must, clumsy pointer handling is out
>>> and types are an option for those that can understand them.
>> Indeed, looks like everybody is going in that direction.
> 
> And certainly. Why should advances in hardware only buy more spiffy
> GUIs and not something to ease the everyday pain for the everyday
> software developer :-).

The interesting thing is that memory management is *said* to be painful. 
C++ and Ada are similar in this regard - the majority of the regular 
code don't need manual memory management (local objects!) or can have it 
encapsulated (containers!), so there are no problems that would need to 
be solved. Reference-oriented languages have completely different ratio 
of "new per kLOC" so GC is not a feature there, it's a must. But then 
the question is not whether GC is better, but whether reference-oriented 
languages are better than value-oriented ones. Many people get seduced 
by GC before they even start asking such questions.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>>> Sorry, but that's a misconception - I don't remember when I was the
>>> last time I was messing with manual memory management in a regular C++
>>> code. I estimate that in my current programming I call delete (or free
>>> or whatever) once in 5-10 kLOC.
>> OK. I'll have to reconsider this statement. I usually couldn't trim
>> down 'automatic' allocation to that extent, but that might have been
>> my application area. What I remember though, is the difficulty to
>> recover from exceptions in the presence of automatic (scope bound)
>> memory management. (I hope I'm making sense here, else I'd really have
>> to go back to my C++ mind and notes and try to retrieve the right
>> vocabulary and reasoning and -- well -- I don't really want to have a
>> C++ discussion in c.l.a. :-).
>
> Why not having C++ discussions on the list where people claim that C++
> sucks? :-)

Because of the level of detail? Because I haven't really swapped in my
C++-personality yet, I'm wary to do it and fear I'll slip up in public
claiming the wrong things about C++? :-)

Jokes aside, I feel a bit off topic with this and the fervour in this
thread seems to have diminished somewhat anyway ...

>
>> But from what I remember in
>> the 1997s to 1998s
>
> Most programming languages were terrible at that time, that's true.

Not Ada 95 ... :-). Actually I think it was that time when history
branched and Ada missed to become main stream, but that is not a
historians claim only a personal impression.

>
>> (that was when there still were problems with STLs,
>> exceptions and the string libraries in C++ and when there was no
>> standard and Java was new), that this was one of the motivations that
>> people shifted to Java (either from C++ or from C).
>
> Yes, I know that. And I will keep stating that this motivation
> resulted from common misconceptions, further amplified by Java
> marketing.

Oh yes, misconceptions perhaps. But I'v only been talking about
peoples motivations (which say a lot about their perceived problems).

> I've even heard that Java is better, because it has a String class and
> there is no need to use char* as in C++ (!). FUD can buy a lot.

As far as that goes I have seen people getting tripped up really bad
by string::c_str(). And I think you need it, if you don't program pure
C++, which at that time nobody did. The implementation I saw there
might have been strange/faulty though -- s.c_str() returned a pointer
into some internal data structure of s which promptly changed when s
was modified. The only "safe" way to use it was strdup(s.c_str()) and
that is not threadsafe as anybody can see. I see "the need to use
char* in C++" rumour as the result of people having been burned
by similarly quirks at that time.

>
>> The other
>> motivation was the "portable GUI"
>
> Yes.
>
>> which, I think, mostly disappointed
>> the expectations.
>
> Still, GUI that sucks was better than no standard GUI at all for lost
> of people. 

"portable" not "standard". There were always standard GUIs on Unix and
on Win32, only they where not exchangeable.

> Both C++ and Ada are in the same camp in this aspect. I'm
> not claiming that these languages should have standard GUI, but not
> having it definitely scared many.

Let's say it the other way round: Java certainly attracted a number of
people because of the "standard GUI". And since I firmly believe that
a GUI does NOT belong into a language standard but rather in a
separate standard for a runtime environment, I wonder a bit which kind
of people those were.

>> Of course I might be wrong. This is just teh impression I got "from
>> the trenches" and I might be missing a mor global point of view. It
>> perhaps does not apply today where C++
>
> Well, there is still no standard GUI for C++, but the choice with
> non-standard ones is quite impressive:

I haven't been talking about the standard GUI here, but about the
memory managment issues I hinted at earlier. I see, I've been jumping
a bit here.

>
> http://www.free-soft.org/guitool/
>
>> and the understanding of C++
>> has matured a bit
>
> Yes. Sadly, too late for those who already changed their mind.
>
>> (there is even an embedded subset of C++ which will
>> annoy folks here no end :-).

> I think that at the end of the day the embedded C++ will disappear
> from the market as the "full" C++ gets wider compiler support on
> embedded platforms. 

That is no question of compiler support, as I understand it, but of
verifiability and safety. A bit like Ravenscar, but -- of course --
not as highly integer (ahem ... :-).

> There will simply be no motivation for using subsets.

But there will -- see above.

> Subsetting C++ would be beneficial in the sense similar to Ravenscar
> or by extracting some core and using it with formal methods (sort of
> "SPARK++"), but I doubt it will ever happen.

It already did (and perhaps died)

   http://en.wikipedia.org/wiki/Embedded_C++


>>>> The trend I see, is that GC is a must, clumsy pointer handling is out
>>>> and types are an option for those that can understand them.
>>> Indeed, looks like everybody is going in that direction.
>> And certainly. Why should advances in hardware only buy more spiffy
>> GUIs and not something to ease the everyday pain for the everyday
>> software developer :-).
>
> The interesting thing is that memory management is *said* to be
> painful. C++ and Ada are similar in this regard - the majority of the
> regular code don't need manual memory management (local objects!) or
> can have it encapsulated (containers!), so there are no problems that
> would need to be solved. 

I disagree. The only-downward-closures style of C++ and Ada, which
allows only to mimic "upward closures" by using classes, heavily
influences the way the programmer thinks. Higher level abstractions
(as in functional languages) would require full closure -- and since
this means that memory life time cannot bound to scope any more, this
would be the point where manual memory management becomes painful.

Furthermore I've been convinced that manual memory management hinders
modularity.

> Reference-oriented languages have completely
> different ratio of "new per kLOC" so GC is not a feature there, it's a
> must. 


I wonder, if it is really possible to do OO without being
reference-oriented. I somewhat doubt it.

> But then the question is not whether GC is better, but whether
> reference-oriented languages are better than value-oriented ones. Many
> people get seduced by GC before they even start asking such questions.

Value-oriented in my world would be functional -- languages which all
heavily rely on GC. 

I also admit being one of the seduced, but that is not surprising
since my main focus is not in embedded programming and in everything
else it's sheer folly not to have GC. The arguments against GC often
read like arguments against virtual memory, against high level
languages as opposed to assembler, against filesystems (yes there was
a time when some people thought that the application would best do
allocation of disc cylinders itself since it knows its access patterns
better than the FS).

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

>>> But from what I remember in
>>> the 1997s to 1998s
>> Most programming languages were terrible at that time, that's true.
> 
> Not Ada 95 ... :-).

Ada 95 *is* terrible. It doesn't have containers nor unbounded strings 
and it cannot even return limited types from functions. Yuck! ;-)

> Oh yes, misconceptions perhaps. But I'v only been talking about
> peoples motivations (which say a lot about their perceived problems).

Everybody has full rights to use misconceptions as a basis for 
perception and motivation. That's a natural limitation of human brain.

>> I've even heard that Java is better, because it has a String class and
>> there is no need to use char* as in C++ (!). FUD can buy a lot.
> 
> As far as that goes I have seen people getting tripped up really bad
> by string::c_str(). And I think you need it, if you don't program pure
> C++, which at that time nobody did.

Good point. It is true that people get tripped when interfacing with old 
C code. What about interfacing with old C code *from Java*? Are there 
less opportunities for getting tripped, or what?
Another misconception.
Interfacing to old C is tricky from Ada as well.

(Strangely, in "pure" C++ you have to use .c_str() even when opening a 
file stream, because fstream constructor does not understand string - 
that's real oops, but actually I've never seen anybody getting tripped 
here.)

> s.c_str() returned a pointer
> into some internal data structure of s which promptly changed when s
> was modified.

Yes.

> The only "safe" way to use it was strdup(s.c_str())

No, the only "safe" way to use it is making an immutable copy of the string:

string someString = "Hello";
const string safeCopy(someString);
some_old_C_function(safeCopy.c_str());

// modify someString here without influencing anything
// ...

 > and
> that is not threadsafe as anybody can see.

Why? There is nothing about threads here.

> I see "the need to use
> char* in C++" rumour as the result of people having been burned
> by similarly quirks at that time.

Yes, I understand it. Still, most of the rumour comes from misconceptions.


>> I think that at the end of the day the embedded C++ will disappear
>> from the market as the "full" C++ gets wider compiler support on
>> embedded platforms. 
> 
> That is no question of compiler support, as I understand it, but of
> verifiability and safety. A bit like Ravenscar, but -- of course --
> not as highly integer (ahem ... :-).

I agree with it, but restrictions for embedded C++ are not catering for 
the same objectives as those of Ravenscar. For example: EC++ does not 
have templates. Nor even namespaces (:-|). Does it have anything to do 
with schedulability or necessary runtime support? No. Result - some 
people got frustrated and invented this:

http://www.iar.com/p7371/p7371_eng.php

Funny?

That's why I believe that Embedded C++ will die.

>> Subsetting C++ would be beneficial in the sense similar to Ravenscar
>> or by extracting some core and using it with formal methods (sort of
>> "SPARK++"), but I doubt it will ever happen.
> 
> It already did (and perhaps died)
> 
>    http://en.wikipedia.org/wiki/Embedded_C++

Exactly. It will die, because it's just a subset. If it was a subset 
extended with annotations ("SPARK++") or with anything else, the 
situation would be different, because it would provide new possibilities 
instead of only limiting them.


>> The interesting thing is that memory management is *said* to be
>> painful.

> I disagree. The only-downward-closures style of C++ and Ada, which
> allows only to mimic "upward closures" by using classes, heavily
> influences the way the programmer thinks. Higher level abstractions
> (as in functional languages) would require full closure -- and since
> this means that memory life time cannot bound to scope any more, this
> would be the point where manual memory management becomes painful.

You can have it by refcounting function frames (and preserving some 
determinism of destructors). GC is not needed for full closures, as far 
as I perceive it (with all my misconceptions behind ;-) ).

On the other hand, GC is convincing with some lock-free algorithms.
Now, *this* is a tough subject for Ada community, right? ;-)

> Furthermore I've been convinced that manual memory management hinders
> modularity.

Whereas I say that I don't care about manual memory management in my 
programs. You can have modularity without GC.

(And if I think about all these funny GC-related effects like 
resurrection of objects in Java, then I'm not sure what kind of 
modularity you are referring to. ;-) )

>> Reference-oriented languages have completely
>> different ratio of "new per kLOC" so GC is not a feature there, it's a
>> must. 
> 
> I wonder, if it is really possible to do OO without being
> reference-oriented. I somewhat doubt it.

Why? OO is about encapsulation and polymorphism, these don't need 
references everywhere.

>> But then the question is not whether GC is better, but whether
>> reference-oriented languages are better than value-oriented ones. Many
>> people get seduced by GC before they even start asking such questions.
> 
> Value-oriented in my world would be functional -- languages which all
> heavily rely on GC. 

What about maintainability and reasoning?

> I also admit being one of the seduced, but that is not surprising
> since my main focus is not in embedded programming and in everything
> else it's sheer folly not to have GC.

I disagree. I'm not seduced.

> The arguments against GC often
> read like arguments against virtual memory, against high level
> languages as opposed to assembler, against filesystems (yes there was
> a time when some people thought that the application would best do
> allocation of disc cylinders itself since it knows its access patterns
> better than the FS).

Valid points. Still, Blue Gene/L uses real addressing scheme in each 
node and more advanced database servers use raw disk access bypassing 
the features provided by FS. Guess why.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Alex R. Mosteo]

Maciej Sobczak wrote:

> Markus E Leypold wrote:
> 
>>>> But from what I remember in
>>>> the 1997s to 1998s
>>> Most programming languages were terrible at that time, that's true.
>> 
>> Not Ada 95 ... :-).
> 
> Ada 95 *is* terrible. It doesn't have containers nor unbounded strings
> and it cannot even return limited types from functions. Yuck! ;-)

Well, well, it *has* unbounded strings, you bad guy! ;)

> (snip)

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Alex R. Mosteo wrote:

>> Ada 95 *is* terrible. It doesn't have containers nor unbounded strings
>> and it cannot even return limited types from functions. Yuck! ;-)
> 
> Well, well, it *has* unbounded strings, you bad guy! ;)

Oops, indeed. :-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>>>> But from what I remember in
>>>> the 1997s to 1998s
>>> Most programming languages were terrible at that time, that's true.
>> Not Ada 95 ... :-).
>
> Ada 95 *is* terrible. It doesn't have containers nor unbounded strings
> and it cannot even return limited types from functions. Yuck! ;-)

Can't it? Wasn't there a trick with renaming somewhere? Like

   A : Limited_Type renames some_function(...);

I seem to remember something like this. Might be mistaken: I usually
end up to eliminate limited types in my programs against my will,
since they play bad with unlimited base classes (like found in
GtkAda).
   
>> Oh yes, misconceptions perhaps. But I'v only been talking about
>> peoples motivations (which say a lot about their perceived problems).
>
> Everybody has full rights to use misconceptions as a basis for
> perception and motivation. That's a natural limitation of human brain.

Exactly. And we talked about "Why isn't Ada more popular?". This is
basically about how Ada is perceived, not about "technical truth",
i.e. is Ada really as it is perceived. 

>>> I've even heard that Java is better, because it has a String class and
>>> there is no need to use char* as in C++ (!). FUD can buy a lot.

>> As far as that goes I have seen people getting tripped up really bad
>> by string::c_str(). And I think you need it, if you don't program pure
>> C++, which at that time nobody did.
>
> Good point. It is true that people get tripped when interfacing with
> old C code. 


> What about interfacing with old C code *from Java*? Are

They don't. And that is the interesting things. The people transitioning
C->Java where a totally different class from those doing (almost at the
same time, not exactly, but almost) the C->C++ transition. 

The C++ adopters were often (not necessarily) always motivated by
being able to integrate their existing code base and take their
C-knowhow with them. They felt that they didn't get more removed from
the system, but still had all the interfaces and libraries
available. In a sense this was a no-brainer for the applications
folks. They thought they got OO for free (no downside). Of course the
downside was that old hand C programmers don't necessarily make good
C++ programmers or good OO developers.

The Java adopters on the other side knew that they were giving up
their legacy code (if they had any) but on the up side were rewarded
with a much more complete standard runtime library. Adopting Java
removed you a further step from your host system, so old know-how was
only partly applicable if at all (yes, there is JNI, but it wasn't
commonly used). So Java was adopted by people who (a) thought the win
worth the price they had to pay (basically start from the beginning),
(b) people who realized that their existing code base was crap anyway
:-) and (c) newcomers (companies or students who didn't have any
specific know-how yet and decided to get that know-how in Java. 

The last point in my eyes accounts for relatively high numbers of
clueless look-what-we-have-newly-invented (old win in new bottles)
newbies in the Java sector who gave Java a bad name. I still have the
reflex to groan deeply when I hear the words: "We now we are trying to
re-implement this in Java". It's probably unjustified these days but
some years ago that sentence to me was the typical hallmark of a
buzzword chasing newbie who thought that by choosing his favourite
language (probably only his 1st or 2nd one), all problems would
magically go away.

(Sorry, no proofs or sources here, folks. I think the recent history of
programming language development and adoption would bear some more
research. You might apply at my e-mail address to sponsor this
research :-)

When I talk about all those transitions, I see, that there was no
C->Ada transition, at least no mass movement. So we come back to the
C->initial question: Why not? 

I think some of the posts here have already given answers to that:
Historical reasons. 

Those transitions would have had to happen around 1995-2000 which in
my eyes was a period where people were looking for new languages (GUI
development in C and all this became rather unfeasible at the
time). But a process of bringing the candidate languages into the
public awareness would have to have started earlier. Was the Ada 95
standard just a tiny bit too late (it is understandable that Ada 83
was not a serious contender for this, people were looking for OO
really urgently)? Or was it the vendor situation? GCC has had C++ for
some time, but did GNAT come too late? 

I think this is very much the case of being "at the right place at the
right time" -- when people were looking for ways out of their pain,
Java and C++ were (more or less) ready to at least promise
salvation. I wonder if Ada was ready ... -- at least it wasn't in
public discussion then.

> What about interfacing with old C code *from Java*? Are
> there less opportunities for getting tripped, or what?

As I said: It's less part of the overall migration strategy usually
associated with a transition to Java.

> Another misconception.  Interfacing to old C is tricky from Ada as
> well.

Yes :-). I never denied that. But then you're less tempted to mix Ada
and C freely, as you're in C++/C. So in Ada (and in Java and in every
other language with a useful foreign function call interface) you get
a clear interface (in the original as in the programming sense of the
word) to C. In C++ the temptation / opportunity to get messed up is
much greater.


> (Strangely, in "pure" C++ you have to use .c_str() even when opening a
> file stream, because fstream constructor does not understand string -
> that's real oops, but actually I've never seen anybody getting tripped
> here.)

If you just do f(s.c_str()) and f _is_ properly behaved, that is, only
reads from the pointer or does a strdup(), everything is fine, but, I
note, not thread safe. I wouldn't exclude the possibility that the
resulting race condition is hidden in a nice number of C++ programs
out there.

>> s.c_str() returned a pointer
>> into some internal data structure of s which promptly changed when s
>> was modified.
>
> Yes.
>
>> The only "safe" way to use it was strdup(s.c_str())
>
> No, the only "safe" way to use it is making an immutable copy of the string:
>
> string someString = "Hello";
> const string safeCopy(someString);
> some_old_C_function(safeCopy.c_str());

Brr. Yes, that's another way to solve this problem.

>
> // modify someString here without influencing anything
> // ...
>
>  > and
>> that is not threadsafe as anybody can see.

> Why? There is nothing about threads here.

Your solution is thread safe, if the strings package is (which it
wasn't in the past). My "solution" isn't since, if any other thread
holds a reference to the string in question and modifies it between
c_str() and strdup() we're not working only with suddenly modified
data (which shouldn't happen), but with pointers to invalid memory.

That means: The race has the potential not to be just a race, but to
break type safety! Which is an interaction between the presence of
threads and the semantics of a program which is just so bad bad bad.

>> I see "the need to use
>> char* in C++" rumour as the result of people having been burned
>> by similarly quirks at that time.
>

> Yes, I understand it. Still, most of the rumour comes from misconceptions.

I think this is not about, that you/someone _can_ handle C++
safely. It's about how probable that is to happen without having to
study up on arcane knowledge, by just doing the next best "reasonable"
thing. And that is the area where C++ will trip up, yes, especially
the newcomer.


>>> I think that at the end of the day the embedded C++ will disappear
>>> from the market as the "full" C++ gets wider compiler support on
>>> embedded platforms.
>> That is no question of compiler support, as I understand it, but of
>> verifiability and safety. A bit like Ravenscar, but -- of course --
>> not as highly integer (ahem ... :-).
>
> I agree with it, but restrictions for embedded C++ are not catering
> for the same objectives as those of Ravenscar. For example: EC++ does
> not have templates. Nor even namespaces (:-|). Does it have anything
> to do with schedulability or necessary runtime support? No. Result -

But perhaps with trying to attach at least a feeble resemblance of
semantics to the remaining language and avoid -- heuristically -- the
most common handling errors (namespaces + overloading + "last
identifier defined wins" make a nice mess in C++).

> some people got frustrated and invented this:
>
> http://www.iar.com/p7371/p7371_eng.php

Obviously another market: Minus verifiability (well, of a sort), plus
the ability to compile to really small targets. Useful.

>
> Funny?
>
> That's why I believe that Embedded C++ will die.

That might be.


>>> Subsetting C++ would be beneficial in the sense similar to Ravenscar
>>> or by extracting some core and using it with formal methods (sort of
>>> "SPARK++"), but I doubt it will ever happen.
>> It already did (and perhaps died)
>>    http://en.wikipedia.org/wiki/Embedded_C++

> Exactly. It will die, because it's just a subset. If it was a subset
> extended with annotations ("SPARK++") or with anything else, the
> situation would be different, because it would provide new
> possibilities instead of only limiting them.

There is some truth in that.

>
>>> The interesting thing is that memory management is *said* to be
>>> painful.
>
>> I disagree. The only-downward-closures style of C++ and Ada, which
>> allows only to mimic "upward closures" by using classes, heavily
>> influences the way the programmer thinks. Higher level abstractions
>> (as in functional languages) would require full closure -- and since
>> this means that memory life time cannot bound to scope any more, this
>> would be the point where manual memory management becomes painful.


> You can have it by refcounting function frames (and preserving some
> determinism of destructors). GC is not needed for full closures, as
> far as I perceive it (with all my misconceptions behind ;-) ).

Yes, one could do it like that. Ref-counting is rumoured to be
inefficient, but if you don't have too many closure that might just
work.


> On the other hand, GC is convincing with some lock-free algorithms.
> Now, *this* is a tough subject for Ada community, right? ;-)

:-).

>
>> Furthermore I've been convinced that manual memory management hinders
>> modularity.

> Whereas I say that I don't care about manual memory management in my
> programs. You can have modularity without GC.

Certainly. But you can have more with GC. George Bauhaus recently
refered to the "A Critique of Standard ML" by Andrew W. Appel. 

   http://www.cs.princeton.edu/research/techreps/TR-364-92

I re-read that paper cursorily and noticed that there a some nice
points about the desirability of GC in there (approx. 1 page) I
suggest you read that: It says it better than I could say it, that w/o
GC the responsibility for freeing/disposing of allocated storage is
always/often a difficult question in general.

People who don't have GC often say that they can do anything with
manual memory management. I humbly suggest that might be, because they
already think about their solutions in terms compatible with manual
memory management. Which means, they are missing the perception of
those opportunities where GC would buy a vastly simpler architecture /
solution / whatever.

> (And if I think about all these funny GC-related effects like
> resurrection of objects in Java, then I'm not sure what kind of
> modularity you are referring to. ;-) )

Resurrection? You're talking about finalization in Java? Well -- the
way this is designed it's just a perversion.


>>> Reference-oriented languages have completely
>>> different ratio of "new per kLOC" so GC is not a feature there, it's a
>>> must.

>> I wonder, if it is really possible to do OO without being
>> reference-oriented. I somewhat doubt it.


> Why? OO is about encapsulation and polymorphism, these don't need
> references everywhere.

Yes, but -- you want to keep, say, a list of Shape(s). Those can be
Triangle(s), Circle(s) etc, which are all derived from class
Shape. How do you store this list? An array of Shape'Class is out of
question because of the different allocation requirements for the
descendants of Shape(s).

>>> But then the question is not whether GC is better, but whether
>>> reference-oriented languages are better than value-oriented ones. Many
>>> people get seduced by GC before they even start asking such questions.

>> Value-oriented in my world would be functional -- languages which all
>> heavily rely on GC.

> What about maintainability and reasoning?

What about it? It's easy with value-oriented languages (i.e. languages
that just produce new values from old ones in a non-destructive
fashion). Functional languages do this therefore reasoning is a well
developed art there. But the representations of all those values
(trees, lists, ...) (a) rely heavily on representation sharing and (b)
use references because of that. They need and use GC.

>> I also admit being one of the seduced, but that is not surprising
>> since my main focus is not in embedded programming and in everything
>> else it's sheer folly not to have GC.
>
> I disagree. I'm not seduced.

So stay pure. :-)

Reminds me a bit to the folks in youth who didn't want to use high
level languages like (gasp) C or Pascal, and insisted on Assembler,
because they (a) wanted to be efficient all the time, (b) didn't trust
the compiler.

I've decided, if I want to deliver any interesting functionality to
the end user, my resources (developer time) are limited, I have to
leave everything I can to automation (i.e. compilers, garbage
collectors, even libraries), to be able to reach my lofty goals.

>> The arguments against GC often read like arguments against virtual
>> memory, against high level languages as opposed to assembler,
>> against file systems (yes there was a time when some people thought
>> that the application would best do allocation of disc cylinders
>> itself since it knows its access patterns better than the FS).

> Valid points. Still,

> Blue Gene/L uses real addressing scheme in each
> node and more advanced database servers use raw disk access bypassing
> the features provided by FS. Guess why.

Yes. Certainly. The point is to know when to optimise, not to do it
always. Like I said elsewhere: I advocate the use of a type safe,
garbage collected language more in the functional sector, probably,
together with a good foreign function call interface and a real low
level language for interfacing and, perhaps, hot spot
optimisation.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 14:57:17 +0100, Markus E Leypold wrote:

> Can't it? Wasn't there a trick with renaming somewhere? Like
> 
>    A : Limited_Type renames some_function(...);

You can return a limited object within the same scope.
 
> I seem to remember something like this. Might be mistaken: I usually
> end up to eliminate limited types in my programs against my will,
> since they play bad with unlimited base classes (like found in
> GtkAda).

Yes, I still can't understand why they made collected objects (widgets)
non-limited. For packing my limited objects into widgets I am using handles
to. A handle is non-limited. This is quite in GTK+ spirit.

> When I talk about all those transitions, I see, that there was no
> C->Ada transition, at least no mass movement. So we come back to the
> C->initial question: Why not? 

How much popular was C that time? I am asking this question because I
learned C after Ada. My personal transition was FORTRAN-IV/PL/1 -> Ada 83.

> I think some of the posts here have already given answers to that:
> Historical reasons. 
> 
> Those transitions would have had to happen around 1995-2000 which in
> my eyes was a period where people were looking for new languages (GUI
> development in C and all this became rather unfeasible at the
> time). But a process of bringing the candidate languages into the
> public awareness would have to have started earlier. Was the Ada 95
> standard just a tiny bit too late (it is understandable that Ada 83
> was not a serious contender for this, people were looking for OO
> really urgently)? Or was it the vendor situation? GCC has had C++ for
> some time, but did GNAT come too late? 

I think so. GNAT was a quite poor compiler for too long. Another important
thing was (is) a lack of good IDE. C++ vendors paid much attention to
design IDE, much more than to compiler quality... This is the first thing a
newcomer sees.

>> Why? OO is about encapsulation and polymorphism, these don't need
>> references everywhere.
> 
> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
> Triangle(s), Circle(s) etc, which are all derived from class
> Shape. How do you store this list? An array of Shape'Class is out of
> question because of the different allocation requirements for the
> descendants of Shape(s).

Why should this worry you (and me)? It should Randy and Robert! (:-))

The language does not require array implementation to be contiguous. Randy
told once that Janus Ada is practically ready for

   type X is array (...) of Y'Ckass;

>> What about maintainability and reasoning?
> 
> What about it? It's easy with value-oriented languages (i.e. languages
> that just produce new values from old ones in a non-destructive
> fashion). Functional languages do this therefore reasoning is a well
> developed art there. But the representations of all those values
> (trees, lists, ...) (a) rely heavily on representation sharing and (b)
> use references because of that. They need and use GC.

You are mixing by-value vs. by-reference semantics with no-identity vs.
has-identity. These are two semantically different things. One is about
implementation another is about properties of the domain. "Premature
optimization" is you know what... If identity is in question, then objects
should be made limited and could then be accessed through referential
objects. But that alone does not require GC. I might also require no
reference object if self-recursive types supported.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 02 Feb 2007 14:57:17 +0100, Markus E Leypold wrote:

>> When I talk about all those transitions, I see, that there was no
>> C->Ada transition, at least no mass movement. So we come back to the
>> C->initial question: Why not? 
>
> How much popular was C that time? I am asking this question because I

Really popular, at least in Europe and the US, I think. Pascal was a
real contender on micros in the eighties but it had practically lost
out in the nineties despite there being still a good number of Delphi
shops/people/developers around.

> learned C after Ada. My personal transition was FORTRAN-IV/PL/1 -> Ada 83.

> I think so. GNAT was a quite poor compiler for too long. Another important

GNAT is still annoying the hell out of me in fringe areas of the
language. And the errors are so fundamental, that I begin to think
that it will take a long time to smoke them out. 

Furthermore I believe there is simply no incentive for AdaCore (who as
I understand maintain most of the GNAT code in the GCC repository) to
establish a good or stable baseline in the publicly accessible
repository.

> thing was (is) a lack of good IDE. C++ vendors paid much attention to
> design IDE, much more than to compiler quality... This is the first thing a
> newcomer sees.

There is something in that. Additionally there is/was a number
additional tools missing like lint/splint/cscope etc. 


>>> Why? OO is about encapsulation and polymorphism, these don't need
>>> references everywhere.
>> 
>> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
>> Triangle(s), Circle(s) etc, which are all derived from class
>> Shape. How do you store this list? An array of Shape'Class is out of
>> question because of the different allocation requirements for the
>> descendants of Shape(s).
>
> Why should this worry you (and me)? It should Randy and Robert! (:-))
>
> The language does not require array implementation to be contiguous. Randy
> told once that Janus Ada is practically ready for
>
>    type X is array (...) of Y'Ckass;

OK, then But non contigous representation of arrays will really stress
memory management, fragment the heap (we can't do that on the stack
AFAIS). And what about mapping of C arrays to Ada arrays (or is that
not possible anyway -- I admit I'd have to read that up)

>>> What about maintainability and reasoning?
>> 
>> What about it? It's easy with value-oriented languages (i.e. languages
>> that just produce new values from old ones in a non-destructive
>> fashion). Functional languages do this therefore reasoning is a well
>> developed art there. But the representations of all those values
>> (trees, lists, ...) (a) rely heavily on representation sharing and (b)
>> use references because of that. They need and use GC.

> You are mixing by-value vs. by-reference semantics with no-identity vs.
> has-identity. 

No. Values have no "identity". "Object identity" smacks heavily of
storage and memory chunks. 

I fail to see how "identity" comes into the question of
"value-oriented" languages (your term, BTW) and represenation
sharing. GC is about references (to memory) and representation sharing
works with references to parts of another "value" (see lisp
lists). Represnattion sharing needs either reference counting
(inefficient, is also just some kind of instant GC) or GC.

> These are two semantically different things. One is about
> implementation another is about properties of the domain. "Premature
> optimization" is you know what... If identity is in question, then objects
> should be made limited and could then be accessed through referential
> objects. But that alone does not require GC. I might also require no
> reference object if self-recursive types supported.

I admit I cannot follow you into your rather foreign and, I have to
say, closed and self referential world of programming language
design. But that doesn't matter much: I also have forgotten why we're
discussing this. "Maintainability and reasoning" was somewhere
there. But did you answer my answer (quoted above) or did you just
declare it as invalid, because you have a different terminology?
Seems, we've actually stopped communicating ...

So ... -- I summarize: In your opinion GC is bad, and I don't
aunderstand your reasoning, in mine it's indispensable in a world were
program sizes have grown and we desire to program on different levels
of abstractions than we did 10 or 20 years ago.

We should leave it at that.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sat, 03 Feb 2007 15:51:33 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 02 Feb 2007 14:57:17 +0100, Markus E Leypold wrote:
> 
>>> When I talk about all those transitions, I see, that there was no
>>> C->Ada transition, at least no mass movement. So we come back to the
>>> C->initial question: Why not? 
>>
>> How much popular was C that time? I am asking this question because I
> 
> Really popular, at least in Europe and the US, I think. Pascal was a
> real contender on micros in the eighties but it had practically lost
> out in the nineties despite there being still a good number of Delphi
> shops/people/developers around.
> 
>> learned C after Ada. My personal transition was FORTRAN-IV/PL/1 -> Ada 83.
> 
>> I think so. GNAT was a quite poor compiler for too long. Another important
> 
> GNAT is still annoying the hell out of me in fringe areas of the
> language. And the errors are so fundamental, that I begin to think
> that it will take a long time to smoke them out. 

Well, visibility in generics is still a great problem. 

> Furthermore I believe there is simply no incentive for AdaCore (who as
> I understand maintain most of the GNAT code in the GCC repository) to
> establish a good or stable baseline in the publicly accessible
> repository.

Yes, at least a publicly available bug tracking system. I have an
impression that the same bugs come and go over and over again.

>>>> Why? OO is about encapsulation and polymorphism, these don't need
>>>> references everywhere.
>>> 
>>> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
>>> Triangle(s), Circle(s) etc, which are all derived from class
>>> Shape. How do you store this list? An array of Shape'Class is out of
>>> question because of the different allocation requirements for the
>>> descendants of Shape(s).
>>
>> Why should this worry you (and me)? It should Randy and Robert! (:-))
>>
>> The language does not require array implementation to be contiguous. Randy
>> told once that Janus Ada is practically ready for
>>
>>    type X is array (...) of Y'Ckass;
> 
> OK, then But non contigous representation of arrays will really stress
> memory management, fragment the heap (we can't do that on the stack
> AFAIS).

Maybe, but it is no different from what would happen in any other
implementation. Note that there is a sufficiently different case, when all
Y'Class are of the same shape. For this I propose Tag discriminants:

    type X (Shape : Y'Class'Tag.) is array (...) of Y'Ckass (Shape);

Here the compiler can allocate X in one chunk of memory.

> And what about mapping of C arrays to Ada arrays 

That were not possible, but it also were no problem. When you apply pragma
Convention to an array type, the compiler should tell you that you can't
have dynamic bounds and elements. You cannot pass String down to C, but you
could try String(1..20). [If there were no Interfaces.C of course.]

>>>> What about maintainability and reasoning?
>>> 
>>> What about it? It's easy with value-oriented languages (i.e. languages
>>> that just produce new values from old ones in a non-destructive
>>> fashion). Functional languages do this therefore reasoning is a well
>>> developed art there. But the representations of all those values
>>> (trees, lists, ...) (a) rely heavily on representation sharing and (b)
>>> use references because of that. They need and use GC.
> 
>> You are mixing by-value vs. by-reference semantics with no-identity vs.
>> has-identity. 
> 
> No. Values have no "identity".

It depends. Polymorphic value has an identity. But I understand what you
mean, and that meaning is correct.

> "Object identity" smacks heavily of
> storage and memory chunks. 

No. Identity is just a function id:X->I, where I is some set of comparable
values. No magic. X'Address or X'Access can serve as an identity function.
Or not, if you have relocatable objects, for instance. In general nothing
in objects requires X'Address. There are other kinds of identity. For
example id:X->T, where T is the type of X.

> I fail to see how "identity" comes into the question of
> "value-oriented" languages (your term, BTW) and represenation
> sharing. GC is about references (to memory) and representation sharing
> works with references to parts of another "value" (see lisp
> lists). Represnattion sharing needs either reference counting
> (inefficient, is also just some kind of instant GC) or GC.

The example you mentioned was a tree. Do you want to share subtrees between
other trees? When a subtree C of a tree A changes, should it ("it" is an
identity (:-)) in the tree B be changed as well? You cannot answer these
questions in terms of tree values. For all possible answers there exist
corresponding values of A, B, C, C in A, C in B, A/\B etc. It is a semantic
problem which has nothing to do with representation, be it
immutable-functional or shared. Identity is a way to express this
semantics. Value vs. reference is a semantically irrelevant implementation
detail.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:


>>>>> What about maintainability and reasoning?
>>>> 
>>>> What about it? It's easy with value-oriented languages (i.e. languages
>>>> that just produce new values from old ones in a non-destructive
>>>> fashion). Functional languages do this therefore reasoning is a well
>>>> developed art there. But the representations of all those values
>>>> (trees, lists, ...) (a) rely heavily on representation sharing and (b)
>>>> use references because of that. They need and use GC.
>> 
>>> You are mixing by-value vs. by-reference semantics with no-identity vs.
>>> has-identity. 
>> 
>> No. Values have no "identity".
>
> It depends. Polymorphic value has an identity. But I understand what you
> mean, and that meaning is correct.
>
>> "Object identity" smacks heavily of
>> storage and memory chunks. 
>
> No. Identity is just a function id:X->I, where I is some set of comparable
> values. No magic. X'Address or X'Access can serve as an identity function.

OK. In the context of your comment "You are mixing by-value
vs. by-reference semantics with no-identity vs.  has-identity" I had
the impression you were talking about the identities of objects. I
still do not understand your comment comment then: I'm ceratinly not
mixing up anything here.

> Or not, if you have relocatable objects, for instance. In general nothing
> in objects requires X'Address. There are other kinds of identity. For
> example id:X->T, where T is the type of X.
>
>> I fail to see how "identity" comes into the question of
>> "value-oriented" languages (your term, BTW) and represenation
>> sharing. GC is about references (to memory) and representation sharing
>> works with references to parts of another "value" (see lisp
>> lists). Represnattion sharing needs either reference counting
>> (inefficient, is also just some kind of instant GC) or GC.

> The example you mentioned was a tree. Do you want to share subtrees between
> other trees? 

That's the way it is usually done in the implementation of a
functional language.

> When a subtree C of a tree A changes, should it ("it" is an
> identity (:-)) in the tree B be changed as well? 

Change? There is no "change" in a functional world, only the
production of new values (i.e. new elements from a specific set, in
your case the set of all trees).

> You cannot answer these questions in terms of tree values.

It doesn't make sense in terms of tree values, that is, in a purely
functional world.

> For all possible answers there exist
> corresponding values of A, B, C, C in A, C in B, A/\B etc. 

> It is a semantic
> problem which has nothing to do with representation, be it
> immutable-functional or shared. 

> Identity is a way to express this semantics.

?? Given the context we started at, I'm not sure I understand what
you're talking about.

> Value vs. reference is a semantically irrelevant implementation
> detail.

Sementically, yes. If we are talking about a functional language. Not,
if we talk about some imperative language.

But we were talking about useful implementations of a functional
view: There sharing is unavoidable thus GC. (Of course if you don't
care for efficiency ...).

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sun, 04 Feb 2007 21:18:55 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Or not, if you have relocatable objects, for instance. In general nothing
>> in objects requires X'Address. There are other kinds of identity. For
>> example id:X->T, where T is the type of X.
>>
>>> I fail to see how "identity" comes into the question of
>>> "value-oriented" languages (your term, BTW) and represenation
>>> sharing. GC is about references (to memory) and representation sharing
>>> works with references to parts of another "value" (see lisp
>>> lists). Represnattion sharing needs either reference counting
>>> (inefficient, is also just some kind of instant GC) or GC.
> 
>> The example you mentioned was a tree. Do you want to share subtrees between
>> other trees? 
> 
> That's the way it is usually done in the implementation of a
> functional language.

They don't share subtrees they share memory (implementation), which is
casual to the program semantics.

>> When a subtree C of a tree A changes, should it ("it" is an
>> identity (:-)) in the tree B be changed as well? 
> 
> Change? There is no "change" in a functional world, only the
> production of new values (i.e. new elements from a specific set, in
> your case the set of all trees).

(New values? What is the difference between new and old values? Do values
carry RFID chips with timestamps? (:-))

No, you are wrong. In mathematics there is a notion of dependent and
independent variables. Mathematics is extremely "non-functional". Consider
a mapping between nodes of two trees which has to be preserved. Now a
function of the first tree is evaluated, what happens with the function of
the second tree?
       g
 A  ------>  B
 |           |
f|           | id = nothing happens
 |           |
 V     g     V
f(A) ------> B (broken invariant)

>> You cannot answer these questions in terms of tree values.
> 
> It doesn't make sense in terms of tree values, that is, in a purely
> functional world.

Of course it does. Consider a graph and its complement. Is it one value or
two? [To prevent a possible discussion, consider an incomputable g.]

>> Value vs. reference is a semantically irrelevant implementation
>> detail.
> 
> Sementically, yes. If we are talking about a functional language. Not,
> if we talk about some imperative language.

How so? Ada is imperative, yet Foo (A) should not depend on whether the
compiler passes A by value or by reference.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 04 Feb 2007 21:18:55 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Or not, if you have relocatable objects, for instance. In general nothing
>>> in objects requires X'Address. There are other kinds of identity. For
>>> example id:X->T, where T is the type of X.
>>>
>>>> I fail to see how "identity" comes into the question of
>>>> "value-oriented" languages (your term, BTW) and represenation
>>>> sharing. GC is about references (to memory) and representation sharing
>>>> works with references to parts of another "value" (see lisp
>>>> lists). Represnattion sharing needs either reference counting
>>>> (inefficient, is also just some kind of instant GC) or GC.
>> 
>>> The example you mentioned was a tree. Do you want to share subtrees between
>>> other trees? 
>> 
>> That's the way it is usually done in the implementation of a
>> functional language.
>
> They don't share subtrees they share memory (implementation), which is
> casual to the program semantics.

They share representation in the underlying system / VM / whatever you
call it. That is what I (expressing myself in shorthand) mean, by
saying they share subtrees. They (the trees) don't share memory.

>
>>> When a subtree C of a tree A changes, should it ("it" is an
>>> identity (:-)) in the tree B be changed as well? 
>> 
>> Change? There is no "change" in a functional world, only the
>> production of new values (i.e. new elements from a specific set, in
>> your case the set of all trees).
>
> (New values? What is the difference between new and old values? Do values
> carry RFID chips with timestamps? (:-))

Don't play dumb. There is certainly an order between value occuring in
a (functional) program.

> No, you are wrong. In mathematics there is a notion of dependent and
> independent variables. 

No. That must be physics you're talking about. In mathematics there
are only elements and names for elements. If it "depends", what people
mean is a function.

> Mathematics is extremely "non-functional". 

How is that?

> Consider a mapping between nodes of two trees which has to be
> preserved. Now a function of the first tree is evaluated, what
> happens with the function of the second tree?

>        g
>  A  ------>  B
>  |           |
> f|           | id = nothing happens
>  |           |
>  V     g     V
> f(A) ------> B (broken invariant)


The function of the second tree? What are you talking about? Let me
repeat: In pure functional languages nothing "changes".


>>> You cannot answer these questions in terms of tree values.
>> 
>> It doesn't make sense in terms of tree values, that is, in a purely
>> functional world.

(BTW: The quoting sucks a bit -- one cannot readily see that "what
makes sense" here, is the question "When a subtree C of a tree A
changes, should it ("it" is an identity (:-)) in the tree B be changed
as well?" -- and BTW2: "It" is not an identity. Not in any natural
language I know of. Linguists certainly have a better word for it, but
it is a context dependent reference.)

> Of course it does. Consider a graph and its complement. Is it one value or
> two? [To prevent a possible discussion, consider an incomputable g.]

They are 2 values. Two different elements (except in the case it's by
accident, the same ...). I didn't say wether you can "compute" it
(i.e. find it).

>>> Value vs. reference is a semantically irrelevant implementation
>>> detail.
>> 
>> Sementically, yes. If we are talking about a functional language. Not,
>> if we talk about some imperative language.


> How so? Ada is imperative, yet Foo (A) should not depend on whether the
> compiler passes A by value or by reference.

Arrgs.  You're just not listening, do you?  But look: It makes a
difference if you pass an access to a variable instead of passing the
variable as an in/out parameter and there is a difference if you
pass it as an in parameter. This is difference in the respective
semantics of the statements and passing an access is what is usually
called passing a reference. It's a completely different thing if
you're talking about references in the implementation of what the
compiler produces or about references in the languages. 

We are talking firstly about languages here and there is, let me
repeat, NO REFERENCES IN PURE FUNCTIONAL LANGUAGES (value oriented
languages as you said). In their semantics if you like.

But we are talking secondly about the usefulness of GC and when it is
needed in language design.  And there it is so, that functional
languages can only be _implemented_ by representation sharing between
values (simple example: The way lists work in a FP), because else a
lot of copying would have to take place. But representation sharing is
_implemented_ by pointers/references, and since sharing takes place,
multiple pointers often point to one shared "sub-representation". And
since we want to pass values freely around (there is no scope for
values, see the other sub-thread ...)  we hardly ever know statically
how long a particular sub-representation will live.

So a garbage collection mechanism is required. This might be reference
counting (which is indeed just some ad hoc kind of GC) or some more
advanced algorithm. As it turns out, suitably tuned advanced
algorithms, like e.g. a generational garbage collector are much more
efficient since they avoid the overhead of maintaining the reference
counter every time a reference is duplicated (passed up and down the
call stack) and instead do all the work every now and then.

We can, BTW, learn something form this discussion: It might be true
that it is possible to implement some kid of functional structures in
Ada or any other imperative language of the Algol family (i.e
structures you don't mutate to do date manipulation but instead
produce new structures from those you already have), but without a GC
already built in, it will always be inefficient (you either have to
copy representations gratuitously or you'll have to do reference
counting which is also not very efficient. 

But look: I'm just tired of this discussion. It's rather some time ago
since I've been reading up on the relevant vocabulary. But somehow I
doubt it is my inability to make myself understood that the discussion
with you somehow never comes to the point. Partly it's because we seem
to miss a goal in that discussion (what was the thing you wanted to
convince me of?), partly I suggest you read all that up in a book on
language design an implementation.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sun, 04 Feb 2007 23:33:40 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> They don't share subtrees they share memory (implementation), which is
>> casual to the program semantics.
> 
> They share representation in the underlying system / VM / whatever you
> call it.

Whatever. They are not shared in the sense of aliasing, when you have more
than one name for semantically same thing. 1+1 and 3-1 "share" 2. And this
is irrelevant to where 2 might be allocated or how it were encoded.

>>>> When a subtree C of a tree A changes, should it ("it" is an
>>>> identity (:-)) in the tree B be changed as well? 
>>> 
>>> Change? There is no "change" in a functional world, only the
>>> production of new values (i.e. new elements from a specific set, in
>>> your case the set of all trees).
>>
>> (New values? What is the difference between new and old values? Do values
>> carry RFID chips with timestamps? (:-))
> 
> Don't play dumb. There is certainly an order between value occuring in
> a (functional) program.

Values "occur"? [ You cannot fix the sentence above, it is semantically
broken. ]

>> Consider a mapping between nodes of two trees which has to be
>> preserved. Now a function of the first tree is evaluated, what
>> happens with the function of the second tree?
> 
>>        g
>>  A  ------>  B
>>  |           |
>> f|           | id = nothing happens
>>  |           |
>>  V     g     V
>> f(A) ------> B (broken invariant)
> 
> The function of the second tree? What are you talking about? Let me
> repeat: In pure functional languages nothing "changes".

Consider A = tree, B = its maximal path. When f(A) "occur," [a node is
removed] what happens with B? 

Answer: nothing happens, the program is broken. The programmer has to
manually evaluate Max_Path(f(A)). "Maximal path of" is non-functional.

> It makes a
> difference if you pass an access to a variable instead of passing the
> variable as an in/out parameter and there is a difference if you
> pass it as an in parameter.

It does because access T and T are different types! T is not passed, access
T is passed (by reference or by value).

You could save much time if you just said that you wanted referential
objects (pointers). Period.

Now my question again, what prevents you from collecting objects accessed
via controlled referential objects?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Harald Korneliussen]

> On Sun, 04 Feb 2007 23:33:40 +0100, Markus E Leypold wrote:
> > The function of the second tree? What are you talking about? Let me
> > repeat: In pure functional languages nothing "changes".

On 5 Feb, 10:20, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Consider A = tree, B = its maximal path. When f(A) "occur," [a node is
> removed] what happens with B?
>
> Answer: nothing happens, the program is broken.

With respect, Dmitry, this is nonsense. There is no way of removing a
node from A at all (this is a feature of pure functional languages,
like Haskell and Clean), and so you are sure that B will always be the
maximal path of A. A can not be redefined. What you can do is define a
new tree, which is a function of the old tree. Naturally, this new
tree may have another maximal path. You will not find that path in B,
as B is the path of A, not the path of f(A)! That A and f(A) may share
structure in the implementation is irrelevant for the correctness of
the program. It is relevant for memory use, certainly, but since the
structures are immutable, it does not affect correctness, and the
program is absolutely not "broken".

> The programmer has to manually evaluate Max_Path(f(A)). "Maximal path of" is non-functional.

"Maximal path of" is a function. It takes a tree, and returns the
maximal path of that tree. It does not take a reference to a mutable
data structure or something. If it did, it would not be a function,
because it could give different results when passed the same
reference. But yes, once you have a new value, this does not update
your old values in any way, so perhaps you have to "manually" derive
some further values from this.

(It's also quite reasonable to speak of "newer" and "older" values in
functional languages, as in mathemathics. If value B is derived from
value A, of course value A must be computed first, and A is the "old"
value, B is the "new". A is still very much around, however!)

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On 5 Feb 2007 04:16:05 -0800, Harald Korneliussen wrote:

>> On Sun, 04 Feb 2007 23:33:40 +0100, Markus E Leypold wrote:
>>> The function of the second tree? What are you talking about? Let me
>>> repeat: In pure functional languages nothing "changes".
> 
> On 5 Feb, 10:20, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Consider A = tree, B = its maximal path. When f(A) "occur," [a node is
>> removed] what happens with B?
>>
>> Answer: nothing happens, the program is broken.
> 
> With respect, Dmitry, this is nonsense. There is no way of removing a
> node from A at all (this is a feature of pure functional languages,

Yes, it is broken per feature of FP. (:-))

[...]

Note there is nothing wrong with that. No language keeps all invariants all
the time. The point is that what you describe as sharing etc, is not
automatically the program sematic. It is a language feature given to you to
express the semantics, like the relation above.

A and B above are functions:

A : S -> T
B : S -> T

Here S is the set of execution states. T is the set of trees. "B is max
path of A" is a constraint:

forall s in S
   B(s) = Max_Path (A(s))

>> The programmer has to manually evaluate Max_Path(f(A)). "Maximal path of" is non-functional.
> 
> "Maximal path of" is a function.

In this context it is a relation between values of two objects. The
constraint is that this relation should hold in all observable execution
states.

> (It's also quite reasonable to speak of "newer" and "older" values in
> functional languages, as in mathemathics. If value B is derived from
> value A, of course value A must be computed first, and A is the "old"
> value, B is the "new". A is still very much around, however!)

Really? What is newer e or pi? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 04 Feb 2007 23:33:40 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> They don't share subtrees they share memory (implementation), which is
>>> casual to the program semantics.
>> 
>> They share representation in the underlying system / VM / whatever you
>> call it.
>
> Whatever. They are not shared in the sense of aliasing, when you have more
> than one name for semantically same thing. 1+1 and 3-1 "share" 2. And this
> is irrelevant to where 2 might be allocated or how it were encoded.
>
>>>>> When a subtree C of a tree A changes, should it ("it" is an
>>>>> identity (:-)) in the tree B be changed as well? 
>>>> 
>>>> Change? There is no "change" in a functional world, only the
>>>> production of new values (i.e. new elements from a specific set, in
>>>> your case the set of all trees).
>>>
>>> (New values? What is the difference between new and old values? Do values
>>> carry RFID chips with timestamps? (:-))
>> 
>> Don't play dumb. There is certainly an order between values occuring in
>> a (functional) program.

If let x = f y, I suggest that the parlance "x occurs after y" in the
sense of "order in which values are produced during evaluation" is
certainly legal.

>
> Values "occur"? [ You cannot fix the sentence above, it is semantically
> broken. ]

You're playing dumb. Can't help you there.

>>> Consider a mapping between nodes of two trees which has to be
>>> preserved. Now a function of the first tree is evaluated, what
>>> happens with the function of the second tree?
>> 
>>>        g
>>>  A  ------>  B
>>>  |           |
>>> f|           | id = nothing happens
>>>  |           |
>>>  V     g     V
>>> f(A) ------> B (broken invariant)
>> 
>> The function of the second tree? What are you talking about? Let me
>> repeat: In pure functional languages nothing "changes".
>
> Consider A = tree, B = its maximal path. When f(A) "occur," [a node is
> removed] what happens with B? 

'occur' -- your way to read what I said is certainly semantically
broken.


> Answer: nothing happens, the program is broken. The programmer has to
> manually evaluate Max_Path(f(A)). "Maximal path of" is non-functional.

LOL.

>
>> It makes a
>> difference if you pass an access to a variable instead of passing the
>> variable as an in/out parameter and there is a difference if you
>> pass it as an in parameter.
>
> It does because access T and T are different types! T is not passed, access
> T is passed (by reference or by value).
>
> You could save much time if you just said that you wanted referential
> objects (pointers). Period.
>
> Now my question again, what prevents you from collecting objects accessed
> via controlled referential objects?

I do not even know any more what you're talking about. You introduced
the "references don't matter, its a question of implementation not
semantics". Since you also fail to understand how representation
sharing is implemented in (most functional languages) you are bound to
fail to understand how that makes GC a necessity in FP. That AFAIR was
my last train of clear thought in this sub-thread. What that has to do
with "controlled referential objects" I don't know, since I certainly
didn't talk about them.

I now have to go to my brain engineer and let him overhaul some areas
of my brain. Talking to to you has, sometimes, a rather destructive
effect.


Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

[I agree with what you say on historical perspective on language 
transitions and the probabilistic effects that languages have on 
newbies, so this part was cut.]

> If you just do f(s.c_str()) and f _is_ properly behaved, that is, only
> reads from the pointer or does a strdup(), everything is fine, but, I
> note, not thread safe. I wouldn't exclude the possibility that the
> resulting race condition is hidden in a nice number of C++ programs
> out there.

If you have a race condition because of some thread is modifying a 
string object *while* some other thread is using it, then you have a 
heavy design problem. This is absolutely not related to interfacing with C.

> Your solution is thread safe, if the strings package is (which it
> wasn't in the past).

Strings package cannot make it any better, because the granularity of 
thread-safety results from the program logic, not from the package 
interface. String is too low-level (it's a general utility) to be 
thread-safe in any useful sense. That's why: a) it should not be 
thread-safe on its own, b) you still have a design problem.

Interestingly, Ada doesn't make it any better. Neithe does Java. You 
always need to coordinate threads/tasks/whatever on some higher 
conceptual level than primitive string operations.


[about closures]

>> You can have it by refcounting function frames (and preserving some
>> determinism of destructors). GC is not needed for full closures, as
>> far as I perceive it (with all my misconceptions behind ;-) ).
> 
> Yes, one could do it like that. Ref-counting is rumoured to be
> inefficient

Which relates to cascading destructors, not to function frames.

> but if you don't have too many closure that might just
> work.

If you have too many closures, then well, you have too many closures. :-)

We've been talking not only about performance, but also about 
readability and maintenance. ;-)

>>> Furthermore I've been convinced that manual memory management hinders
>>> modularity.
> 
>> Whereas I say that I don't care about manual memory management in my
>> programs. You can have modularity without GC.
> 
> Certainly. But you can have more with GC.

In a strictly technical sense of the word, yes. But then there comes a 
question about possible loses in other areas, like program structure or 
clarity.

Being able to just drop things on the floor is a nice feature when 
considered in isolation, but not necessarily compatible with other 
objectives that must be met at the same time.

> People who don't have GC often say that they can do anything with
> manual memory management.

And I say that this is misconception. I don't have/use GC and I don't 
bother with *manual* memory management neither. That's the point. In Ada 
this point is spelled [Limited_]Controlled (it's a complete mess, but 
that's not the fault of the concept) and in C++ it's spelled automatic 
storage duration.
Today manual memory management is a low-level thingy that you don't have 
to care about, unless you *really* want to (and then it's really good 
that you can get it). And as I've already pointed out, in my regular 
programming manual memory management is a rarity.

On the other hand, most languages with GC get it wrong by relying *only* 
on GC, everywhere, whereas it is useful (if at all) only for memory. The 
problem is that few programs rely on only memory and in a typical case 
there are lots of resources that are not memory oriented and they have 
to be managed, somehow. When GC is a shiny center of the language, those 
other kinds of resources suffer from not having appropriate support. In 
practical terms, you don't have manual management of memory, but you 
have *instead* manual management of *everything else* and the result is 
either code bloat or more bugs (or both, typically).

Languages like Ada or C++ provide more general solution, which is 
conceptually not related to any kind of resource and can be therefore 
applied to every one. The result is clean, short and uniform code, which 
is even immune to extensions in the implementation of any class. Think 
about adding a non-memory resource to a class that was up to now only 
memory oriented - if it requires any modification on the client side, 
like adding tons of finally blocks and calls to 
close/dispose/dismiss/etc. methods *everywhere*, then in such a language 
the term "encapsulation" is a joke.

An ideal solution seems to be a mix of both (GC and automatic objects), 
but I think that the industry needs a few generations of failed attempts 
to get this mix right. We're not yet there.


>> OO is about encapsulation and polymorphism, these don't need
>> references everywhere.
> 
> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
> Triangle(s), Circle(s) etc, which are all derived from class
> Shape. How do you store this list? An array of Shape'Class is out of
> question because of the different allocation requirements for the
> descendants of Shape(s).

Why should I bother?

Note also that I didn't say that references/pointers should be dropped. 
I say that you don't need them everywhere. That's a difference.


> I've decided, if I want to deliver any interesting functionality to
> the end user, my resources (developer time) are limited, I have to
> leave everything I can to automation (i.e. compilers, garbage
> collectors, even libraries), to be able to reach my lofty goals.

I also leave everything I can to automation. It's spelled 
[Limited_]Controlled in Ada and automatic storage duration in C++.
I cannot imagine reaching my lofty goals otherwise. ;-)

> The point is to know when to optimise, not to do it
> always.

I didn't even mention the word "optimization". I'm taling about structure.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
> [I agree with what you say on historical perspective on language
> transitions and the probabilistic effects that languages have on
> newbies, so this part was cut.]
>
>> If you just do f(s.c_str()) and f _is_ properly behaved, that is, only
>> reads from the pointer or does a strdup(), everything is fine, but, I
>> note, not thread safe. I wouldn't exclude the possibility that the
>> resulting race condition is hidden in a nice number of C++ programs
>> out there.
>
> If you have a race condition because of some thread is modifying a
> string object *while* some other thread is using it, then you have a
> heavy design problem. This is absolutely not related to interfacing
> with C.

Yes, I realize that. Still, providing a pointer to a the inner state
of an object, that only stays valid until I touch the object for the
next time is not only not thread safe (which I realized is not the
problem) but it's not type safe: A error in programming leads to
erronous execution, i.e. reading and writing invalid memory. That is
worse.

I think there was talk once about a thread safe string library, but at
the moment I fail to see how that relates to the problem in question.
>
>> Your solution is thread safe, if the strings package is (which it
>> wasn't in the past).
>
> Strings package cannot make it any better, because the granularity of
> thread-safety results from the program logic, not from the package
> interface. String is too low-level (it's a general utility) to be
> thread-safe in any useful sense. That's why: a) it should not be
> thread-safe on its own, b) you still have a design problem.

Yes. I realize that. Don't know what made me write that :-).

> Interestingly, Ada doesn't make it any better. Neithe does Java. You
> always need to coordinate threads/tasks/whatever on some higher
> conceptual level than primitive string operations.

So forgive me. Let's ditch the thread safety aspect and instead:
Giving pointers to internal state of objects violates (a)
encapsulation (it fixes a specific implementation) and (b) is not type
safe. I'm sure we can hang c_str() on account of this charge alone and
can drop the thread-unsafety allegation.

> [about closures]
>
>>> You can have it by refcounting function frames (and preserving some
>>> determinism of destructors). GC is not needed for full closures, as
>>> far as I perceive it (with all my misconceptions behind ;-) ).
>> Yes, one could do it like that. Ref-counting is rumoured to be
>> inefficient
>
> Which relates to cascading destructors, not to function frames.

My impression was it relates to both. Especially since both are
interlocked: In a world with closure objects (from OO) and variables
can refer to closures (function frames) and vice versa).

>> but if you don't have too many closure that might just
>> work.
>
> If you have too many closures, then well, you have too many closures. :-)

Yes :-). Only in a ref counted implementation even too many might not
be enough.

> We've been talking not only about performance, but also about
> readability and maintenance. ;-)

Of this thread? :-)

>
>>>> Furthermore I've been convinced that manual memory management hinders
>>>> modularity.
>>
>>> Whereas I say that I don't care about manual memory management in my
>>> programs. You can have modularity without GC.
>> Certainly. But you can have more with GC.
>
> In a strictly technical sense of the word, yes. But then there comes a
> question about possible loses in other areas, like program structure
> or clarity.

I think the absence of manual memory management code actually furthers
clarity.

>
> Being able to just drop things on the floor is a nice feature when
> considered in isolation, but not necessarily compatible with other
> objectives that must be met at the same time.

Which?


>> People who don't have GC often say that they can do anything with
>> manual memory management.
>
> And I say that this is misconception. I don't have/use GC and I don't
> bother with *manual* memory management neither. That's the point. In
> Ada this point is spelled [Limited_]Controlled (it's a complete mess,
> but that's not the fault of the concept) and in C++ it's spelled
> automatic storage duration.

My impression was that Ada Controlled storage is actually quite a
clean concept compared to C++ storage duration.

But both tie allocation to program scope, synchronous with a stack. I
insist that is not always desirable: It rules out some architecture,
especially those where OO abounds.

The problem with Controlled, BTW, is that it seems to interact with
the rest of the language in such a way that GNAT didn't get it right
even after ~10 years of development. Perhaps difficult w/o a formal
semantics.

> Today manual memory management is a low-level thingy that you don't
> have to care about, unless you *really* want to (and then it's really
> good that you can get it). And as I've already pointed out, in my
> regular programming manual memory management is a rarity.

> On the other hand, most languages with GC get it wrong by relying
> *only* on GC, everywhere, whereas it is useful (if at all) only for
> memory. 

I've heard that complaint repeatedly, but still do not understand it.

> The problem is that few programs rely on only memory and in a
> typical case there are lots of resources that are not memory oriented
> and they have to be managed, somehow. 

> When GC is a shiny center of the
> language, those other kinds of resources suffer from not having
> appropriate support. In practical terms, you don't have manual
> management of memory, but you have *instead* manual management of
> *everything else* and the result is either code bloat or more bugs (or
> both, typically).

Now, now. Having GC doesn't preclude you from managing ressources
unrelated to memory in a manual fashion. Apart from that languages
with GC often provide nice tricks to tie external ressources to their
memory proxy and ditch them when the memory proxy is unreachable
(i.e. the programm definitely won't use the external ressource any
longer). Examples: IO channels (only sometimes useful), temporary
files, files locks, shared memory allocations. Even if you manage
ressources manually, GC still limits the impact of leaks. And BTW - in
fcuntional langauges you can do more against ressource leaks, sicne
you can "wrap" functions:


  (with_file "output" (with_file "out_put" copy_data))

It's not always done, but a useful micro pattern.

> Languages like Ada or C++ provide more general solution, which is
> conceptually not related to any kind of resource and can be
> therefore applied to every one.

Since you're solving a problem here, which I deny that it exists, I
can't follow you here. But I notice, that

 "Languages like C provide a more general solution (with regard to
  accessing memory), which is conceptually not related to any kind of
  fixed type system and can therefore implement any type and data model"

would become a valid argument if I agreed with you. It's the
generality we are getting rid of during the evolution of programming
languages. Assembler is the "most general" solution, but we are
getting structured programming, typesystems amd finally garbage
collection.


> The result is clean, short and uniform code,
>which is even immune to extensions in the implementation of any
>class. Think about adding a non-memory resource to a class that was
>up to now only memory oriented - if it requires any modification on
>the client side, like adding tons of finally blocks and calls to
>close/dispose/dismiss/etc. methods *everywhere*, then in such a
>language the term "encapsulation" is a joke.

Well, you think Ada here. In an FP I write (usually) something like:

     with_lock "/var/foo/some.lck" (fun () -> do_something1 (); do_something2 param;  ...).

The fact that Ada and C++ don't have curried functions and cannot
construct unnamed functions or procedures is really limiting in this
case and probably causal to your misconception that it would be
necessary to add tons of exceaption handling at the client side.

And BTW: In Ada I would encapsulate the ressource in a Controlled
object (a ressource proxy or handle) and get the same effect (tying it
to a scope). Indeed I have already done so, to make a program which
uses quite a number of locks, to remove locks when it terminated or
crashes. Works nicely.

> An ideal solution seems to be a mix of both (GC and automatic
> objects), but I think that the industry needs a few generations of
> failed attempts to get this mix right. We're not yet there.


>>> OO is about encapsulation and polymorphism, these don't need
>>> references everywhere.
>> Yes, but -- you want to keep, say, a list of Shape(s). Those can be
>> Triangle(s), Circle(s) etc, which are all derived from class
>> Shape. How do you store this list? An array of Shape'Class is out of
>> question because of the different allocation requirements for the
>> descendants of Shape(s).

> Why should I bother?
>
> Note also that I didn't say that references/pointers should be
> dropped. I say that you don't need them everywhere. That's a
> difference.

OK, so you need them _almost_ everywhere :-). I take your point.


>> I've decided, if I want to deliver any interesting functionality to
>> the end user, my resources (developer time) are limited, I have to
>> leave everything I can to automation (i.e. compilers, garbage
>> collectors, even libraries), to be able to reach my lofty goals.
>
> I also leave everything I can to automation. It's spelled
> [Limited_]Controlled in Ada and automatic storage duration in C++.
> I cannot imagine reaching my lofty goals otherwise. ;-)

Good. 'Controlled' buys you a lot in Ada, but there are 2 problems

 (a) AFAIS (that is still my hypothesis, binding storage to scope is
     not alway possible (esp. when doing GUIs and MVC and this
     like). I cannot prove but from what I experienced I rather
     convinced of it.

 (b) AFAIR there are restrictions on _where_ I can define controlled
     types. AFAIR that was a PITA.


>> The point is to know when to optimise, not to do it
>> always.

> I didn't even mention the word "optimization". I'm taling about structure.

OK. But how does a program become less structured by removing the
manual memory management? The GC is not magically transforming the
program into spaghetti code ...

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

> Let's ditch the thread safety aspect and instead:
> Giving pointers to internal state of objects violates (a)
> encapsulation (it fixes a specific implementation) and (b) is not type
> safe.

That's right. This is a result of the fact that C-style strings are not 
encapsulated at all and interfacing to them means stepping down to the 
common ground.

>> We've been talking not only about performance, but also about
>> readability and maintenance. ;-)
> 
> Of this thread? :-)

:-)

>>>>> Furthermore I've been convinced that manual memory management hinders
>>>>> modularity.
>>>> Whereas I say that I don't care about manual memory management in my
>>>> programs. You can have modularity without GC.
>>> Certainly. But you can have more with GC.
>> In a strictly technical sense of the word, yes. But then there comes a
>> question about possible loses in other areas, like program structure
>> or clarity.
> 
> I think the absence of manual memory management code actually furthers
> clarity.

I believe so. And I stress again - GC is not the only solution for 
manual memory management.

>> Being able to just drop things on the floor is a nice feature when
>> considered in isolation, but not necessarily compatible with other
>> objectives that must be met at the same time.
> 
> Which?

Determinism in both timing and resource consumption?

>>> People who don't have GC often say that they can do anything with
>>> manual memory management.
>> And I say that this is misconception. I don't have/use GC and I don't
>> bother with *manual* memory management neither. That's the point. In
>> Ada this point is spelled [Limited_]Controlled (it's a complete mess,
>> but that's not the fault of the concept) and in C++ it's spelled
>> automatic storage duration.
> 
> My impression was that Ada Controlled storage is actually quite a
> clean concept compared to C++ storage duration.

Clean? It adds tag to the type, which then becomes a controlling type in 
every primitive operation. I got bitten by this recently.
Adding a destructor to C++ class never has any side effects like this.

Apart from this, the bare existence of *two* base types Controlled and 
Limited_Controlled means that the concepts of controlled and limited are 
not really orthogonal in the sense that adding one of these 
meta-properties affects the interface that is "shared" by the other aspect.

It's a mess. Actually, it prevents me from thinking clearly about what I 
want to achieve.

> But both tie allocation to program scope, synchronous with a stack. I
> insist that is not always desirable: It rules out some architecture,
> especially those where OO abounds.

What architecture?

> The problem with Controlled, BTW, is that it seems to interact with
> the rest of the language in such a way that GNAT didn't get it right
> even after ~10 years of development. Perhaps difficult w/o a formal
> semantics.

You see.

>> On the other hand, most languages with GC get it wrong by relying
>> *only* on GC, everywhere, whereas it is useful (if at all) only for
>> memory. 

> Now, now. Having GC doesn't preclude you from managing ressources
> unrelated to memory in a manual fashion.

Of course. No, thank you. I prefer a language which enables me to use 
the same logic for all resources, so I *don't have to* manage *anything* 
manually.
In other words, it's very nice that GC doesn't preclude me from doing 
some stuff manually, but that's not enough.

> Apart from that languages
> with GC often provide nice tricks to tie external ressources to their
> memory proxy and ditch them when the memory proxy is unreachable

These "nice tricks" are not so nice. Most of all, they provide no 
guarantee whatsoever, even that they will be invoked at all.
A friend of mine spent long evenings recently hunting for database 
connection leaks in a big Java application. That's telling something.

> And BTW - in
> fcuntional langauges you can do more against ressource leaks, sicne
> you can "wrap" functions:
> 
>   (with_file "output" (with_file "out_put" copy_data))
> 
> It's not always done, but a useful micro pattern.

Yes, it basically emulates something that is just natural in those 
languages that provide scope-based lifetime out of the box.

>> Languages like Ada or C++ provide more general solution, which is
>> conceptually not related to any kind of resource and can be
>> therefore applied to every one.
> 
> Since you're solving a problem here, which I deny that it exists

You might wish to tell this to my friend - the one hunting database 
connection leaks. :-)

> But I notice, that
> 
>  "Languages like C provide a more general solution (with regard to
>   accessing memory), which is conceptually not related to any kind of
>   fixed type system and can therefore implement any type and data model"
> 
> would become a valid argument if I agreed with you.

Except that it's not the point I'm making.

> In an FP I write (usually) something like:
> 
>      with_lock "/var/foo/some.lck" (fun () -> do_something1 (); do_something2 param;  ...).
> 
> The fact that Ada and C++ don't have curried functions and cannot
> construct unnamed functions or procedures is really limiting in this
> case and probably causal to your misconception that it would be
> necessary to add tons of exceaption handling at the client side.

Tons of exception handling (and not only - every way to leave a scope 
needs to be guarded, not only by exception) are necessary in those 
languages that rely on GC without providing the above possibility at the 
same time. The other possibility is to rely on scoped lifetime in the 
first place, where neither GC nor the above tricks are necessary to 
achieve proper cleanup.

> And BTW: In Ada I would encapsulate the ressource in a Controlled
> object (a ressource proxy or handle) and get the same effect (tying it
> to a scope).

Yes.

> Indeed I have already done so, to make a program which
> uses quite a number of locks, to remove locks when it terminated or
> crashes. Works nicely.

Of course. That's my point.
(except, maybe, the crashing part, when likely there is nobody to handle 
the cleanup)

>> Note also that I didn't say that references/pointers should be
>> dropped. I say that you don't need them everywhere. That's a
>> difference.
> 
> OK, so you need them _almost_ everywhere :-). I take your point.

No, you don't. I agree for references/pointers in polymorphic 
collections. That's not even close to "almost everywhere" for me, but 
your application domain may differ.

> 'Controlled' buys you a lot in Ada, but there are 2 problems
> 
>  (a) AFAIS (that is still my hypothesis, binding storage to scope is
>      not alway possible (esp. when doing GUIs and MVC and this
>      like). I cannot prove but from what I experienced I rather
>      convinced of it.

I don't follow this.

>  (b) AFAIR there are restrictions on _where_ I can define controlled
>      types. AFAIR that was a PITA.

That's a mess. I'm sorry to repeat that.

> But how does a program become less structured by removing the
> manual memory management? The GC is not magically transforming the
> program into spaghetti code ...

You get spathetti once you start adding finalizers - the spaghetti is 
then formed in both time (when something is invoked) and space (where 
the code is).

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

>> I think the absence of manual memory management code actually
>> furthers
>> clarity.
>
> I believe so. And I stress again - GC is not the only solution for
> manual memory management.

OK. I accept that for the moment. I'm just not convinced you can do
everything you need with scope bound memory and if you introduce
manual MM again, you'll be back to confusing manual memory
management. I say this just to restate my point of view clearly once
again -- not that I think that either of us can prove his position at
the moment.

>>> Being able to just drop things on the floor is a nice feature when
>>> considered in isolation, but not necessarily compatible with other
>>> objectives that must be met at the same time.

>> Which?
>
> Determinism in both timing and resource consumption?

Which brings me back to what I said repeatedly to other people: 

 (1) That this determinism is very often not a requirement (outside of
     embdedded programming)

 (2) The determinism is shot anyway by using a heap, not by using
     GC. Even better: GC can introduce detereminism in space
     consumption by compacting the heap, which naive heaps with manual
     MM don't do because of fragementation.

 (3) What is often needed are upper limits not determinism and thos
     upper limits can be guaranteed with GC or with an appropriate
     collector.

>>>> People who don't have GC often say that they can do anything with
>>>> manual memory management.

>>> And I say that this is misconception. 

Good. :-)

>>> Ada this point is spelled [Limited_]Controlled (it's a complete mess,
>>> but that's not the fault of the concept) and in C++ it's spelled
>>> automatic storage duration.
>> My impression was that Ada Controlled storage is actually quite a
>> clean concept compared to C++ storage duration.

> Clean? It adds tag to the type, which then becomes a controlling type
> in every primitive operation. 

> I got bitten by this recently.  Adding a destructor to C++ class
> never has any side effects like this.

I understand. But the Ada OO way is peculiar, but not unmanagable.


> Apart from this, the bare existence of *two* base types Controlled and
> Limited_Controlled means that the concepts of controlled and limited
> are not really orthogonal in the sense that adding one of these
> meta-properties affects the interface that is "shared" by the other
> aspect.

Still. Being able to add a Finalize means you need to have a tagged
type. I see no alternative.

> It's a mess. Actually, it prevents me from thinking clearly about what
> I want to achieve.

Wow.

>
>> But both tie allocation to program scope, synchronous with a stack. I
>> insist that is not always desirable: It rules out some architecture,
>> especially those where OO abounds.
>
> What architecture?

I already say in another post: That is difficult to show with a toy
system. It only shows in larger systems where you really can't / don't
want to say in any give subsystem module how long a certain peice of
data lives. So none of those can be burdened with deallocating it.

>> The problem with Controlled, BTW, is that it seems to interact with
>> the rest of the language in such a way that GNAT didn't get it right
>> even after ~10 years of development. Perhaps difficult w/o a formal
>> semantics.

> You see.

Yes, I see. But GNAT is also a political problem (see the role of
AdaCore, formerly ACT), so (public) GNAT not getting things right
might well not indicate a problem with reading the Ada standard, but
in the release politics for public version. My hint: There is no
incentive to release a high quality public version GNAT.

>>> On the other hand, most languages with GC get it wrong by relying
>>> *only* on GC, everywhere, whereas it is useful (if at all) only for
>>> memory.
>
>> Now, now. Having GC doesn't preclude you from managing ressources
>> unrelated to memory in a manual fashion.
>
> Of course. No, thank you. I prefer a language which enables me to use
> the same logic for all resources, so I *don't have to* manage
> *anything* manually.

Which as you said yourself, is difficult to do. And memory is
ressource used most frequently, whereas the temptation to e.g. drop
file descriptors is much less.

> In other words, it's very nice that GC doesn't preclude me from doing
> some stuff manually, but that's not enough.

I'm appalled: You don't want GC, but no, it doesn't do enough for you?
Of yourse YMMV. but when I have it, it works really well for me.

>> Apart from that languages
>> with GC often provide nice tricks to tie external ressources to their
>> memory proxy and ditch them when the memory proxy is unreachable
>
> These "nice tricks" are not so nice. Most of all, they provide no
> guarantee whatsoever, even that they will be invoked at all.

That's not quite true. Those tricks are building blocks to implement
ressources that are automatically finalized when becoming
unreachable. But it's up to the library author to write a complete
implementation.

> A friend of mine spent long evenings recently hunting for database
> connection leaks in a big Java application. That's telling something.

Well -- so he was naive and should have handled / understood that part
of the system better. A friend of mine spent half a month with finding
problems with manual allocation/deallocation and sneaking heap
corruption. Does that prove anything? I don't think so.

>> And BTW - in
>> fcuntional langauges you can do more against ressource leaks, sicne
>> you can "wrap" functions:
>>   (with_file "output" (with_file "out_put" copy_data))
>> It's not always done, but a useful micro pattern.

> Yes, it basically emulates something that is just natural in those
> languages that provide scope-based lifetime out of the box.

This is no emulation, but how FP does "scope based". Without the
necessity to add exception handling at the client side or without
having to introduce tagged types / classes. Isn't THAT nice? :-)

>
>>> Languages like Ada or C++ provide more general solution, which is
>>> conceptually not related to any kind of resource and can be
>>> therefore applied to every one.

>> Since you're solving a problem here, which I deny that it exists

> You might wish to tell this to my friend - the one hunting database
> connection leaks. :-)

Yes, I'll hold that up. Your friend got bitten by believing in a
mechanism where he shouldn't while I deny the the necessity to manage
other ressources by GC for the general case. It's a nice trick
sometimes, but one doesn't need it.

>> But I notice, that
>>  "Languages like C provide a more general solution (with regard to
>>   accessing memory), which is conceptually not related to any kind of
>>   fixed type system and can therefore implement any type and data model"
>> would become a valid argument if I agreed with you.
>
> Except that it's not the point I'm making.

No, but the structure of the argument is basically the same. The
analogy should help to show why it is (IMHO) invalid.

>
>> In an FP I write (usually) something like:
>>      with_lock "/var/foo/some.lck" (fun () -> do_something1 ();
>> do_something2 param;  ...).
>> The fact that Ada and C++ don't have curried functions and cannot
>> construct unnamed functions or procedures is really limiting in this
>> case and probably causal to your misconception that it would be
>> necessary to add tons of exceaption handling at the client side.

> Tons of exception handling (and not only - every way to leave a scope
> needs to be guarded, not only by exception) are necessary in those
> languages that rely on GC without providing the above possibility at
> the same time. 

No. I've done the same in Ada w/o controlled objects, but using a
generic procedure.

  procedure mark_data_records is new process_cache_with_lock( Operation => mark_record, ... );

  begin
    mark_data_records(...);
  end;


The client side has no burden with exceaption handling.


> The other possibility is to rely on scoped lifetime in
> the first place, where neither GC nor the above tricks are necessary
> to achieve proper cleanup.

Always assumed that works as a general apporach. Personally I cherish
the additional freedom I get from GC.

>> And BTW: In Ada I would encapsulate the ressource in a Controlled
>> object (a ressource proxy or handle) and get the same effect (tying it
>> to a scope).
>
> Yes.
>
>> Indeed I have already done so, to make a program which
>> uses quite a number of locks, to remove locks when it terminated or
>> crashes. Works nicely.
>
> Of course. That's my point.
> (except, maybe, the crashing part, when likely there is nobody to
> handle the cleanup)

By "crashes" I mean uncaught exceptions propagating back to the main
procedure. In those cases Finalize() runs.

I've BTW, done the same on OCaml (library for automatically
deallocating locks), so I don't see how GC prevents me from doing so.


>>> Note also that I didn't say that references/pointers should be
>>> dropped. I say that you don't need them everywhere. That's a
>>> difference.

>> OK, so you need them _almost_ everywhere :-). I take your point.

> No, you don't. I agree for references/pointers in polymorphic
> collections. That's not even close to "almost everywhere" for me, but
> your application domain may differ.

Yes. it does, abviously. You might not be aware, but code destined for
mere consumers (as opposed to embedded code and code destined as tools
for other developers) has a large amount of GUI code in it.

>> 'Controlled' buys you a lot in Ada, but there are 2 problems
>>  (a) AFAIS (that is still my hypothesis, binding storage to scope is
>>      not alway possible (esp. when doing GUIs and MVC and this
>>      like). I cannot prove but from what I experienced I rather
>>      convinced of it.
>
> I don't follow this.
>
>>  (b) AFAIR there are restrictions on _where_ I can define controlled
>>      types. AFAIR that was a PITA.
>
> That's a mess. I'm sorry to repeat that.

Yes. But does C++ do it better? The Ada restrictions AFAIK come from
the necessity of separate linking and compilation (you must be able to
relink w/o looking at the body) and C++ treats that against the
ability to add finalizers everyhwere.


>> But how does a program become less structured by removing the
>> manual memory management? The GC is not magically transforming the
>> program into spaghetti code ...

> You get spathetti once you start adding finalizers - the spaghetti is
> then formed in both time (when something is invoked) and space (where
> the code is).

No. Neither GC nore finalizers make code incomprehensible. I can only
assert it again, since are not discussing proofs here ore specific
examples.

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

>> And I stress again - GC is not the only solution for
>> manual memory management.
> 
> OK. I accept that for the moment. I'm just not convinced you can do
> everything you need with scope bound memory

Sure. But for the sake of discussion completeness, you might wish to 
throw an example of a situation where scoped lifetime will not make it.

>> Determinism in both timing and resource consumption?
> 
> Which brings me back to what I said repeatedly to other people: 
> 
>  (1) That this determinism is very often not a requirement (outside of
>      embdedded programming)

Java programmer wrote a loop where he opened database cursors, released 
in the cursor finalizer. All was working like a charm, unless put into 
production, when in one case the loop had to spin many more times than 
he ever cared to test. GC did not clean up the abandoned cursor objects 
fast enough and the number of unnecessarily opened cursors hit the 
server limit. That was the end of this application.

The fix was easy: write explicit close/dispose/dismiss/whatever at the 
end of the loop, so that effectively there was never more than one open 
cursor. In fact, this was *manual* resource management.

The above would be avoided altogether with scoped lifetime.

You are right that determinism is very often not a requirement. It is 
just the life that very often shows that the initial requirements were 
not complete.

>  (2) The determinism is shot anyway by using a heap, not by using
>      GC. Even better: GC can introduce detereminism in space
>      consumption by compacting the heap, which naive heaps with manual
>      MM don't do because of fragementation.

There is nothing particular in scoped lifetime that would prohibit 
compacting heaps and there is nothing particular in GC that guarantees 
it. It's just the statistics based on popular implementations, not a rule.
I can perfectly imagine compacting heaps managed by scoped lifetime.

>  (3) What is often needed are upper limits not determinism and thos
>      upper limits can be guaranteed with GC or with an appropriate
>      collector.

This refers to memory consumption only, whereas I clearly stated 
deterministic *time* as a second (first, actually) goal.

>>> My impression was that Ada Controlled storage is actually quite a
>>> clean concept compared to C++ storage duration.
> 
>> Clean? It adds tag to the type, which then becomes a controlling type
>> in every primitive operation. 
> 
>> I got bitten by this recently.  Adding a destructor to C++ class
>> never has any side effects like this.
> 
> I understand. But the Ada OO way is peculiar, but not unmanagable.

OK, I accept the word "peculiar". I only oppose "quite a clean concept" 
in your previous post. :-)

>> Apart from this, the bare existence of *two* base types Controlled and
>> Limited_Controlled means that the concepts of controlled and limited
>> are not really orthogonal in the sense that adding one of these
>> meta-properties affects the interface that is "shared" by the other
>> aspect.
> 
> Still. Being able to add a Finalize means you need to have a tagged
> type. I see no alternative.

You might want to take a look at C++.

>>> But both tie allocation to program scope, synchronous with a stack. I
>>> insist that is not always desirable: It rules out some architecture,
>>> especially those where OO abounds.
>> What architecture?
> 
> I already say in another post: That is difficult to show with a toy
> system. It only shows in larger systems where you really can't / don't
> want to say in any give subsystem module how long a certain peice of
> data lives. So none of those can be burdened with deallocating it.

OK. What about refcounting with smart pointers?

>>> The problem with Controlled, BTW, is that it seems to interact with
>>> the rest of the language in such a way that GNAT didn't get it right
>>> even after ~10 years of development. Perhaps difficult w/o a formal
>>> semantics.
> 
>> You see.
> 
> Yes, I see. But GNAT is also a political problem (see the role of
> AdaCore, formerly ACT), so (public) GNAT not getting things right
> might well not indicate a problem with reading the Ada standard, but
> in the release politics for public version. My hint: There is no
> incentive to release a high quality public version GNAT.

I get the message. Clear enough.

>> In other words, it's very nice that GC doesn't preclude me from doing
>> some stuff manually, but that's not enough.
> 
> I'm appalled: You don't want GC, but no, it doesn't do enough for you?

Exactly. It's not enough, because it doesn't solve the problem of 
resource management in a general way.

> Of yourse YMMV. but when I have it, it works really well for me.

I acknowledge that there might be some applications which are strictly 
memory-oriented. They are just not the ones I usually write.

>>> Apart from that languages
>>> with GC often provide nice tricks to tie external ressources to their
>>> memory proxy and ditch them when the memory proxy is unreachable
>> These "nice tricks" are not so nice. Most of all, they provide no
>> guarantee whatsoever, even that they will be invoked at all.
> 
> That's not quite true. Those tricks are building blocks to implement
> ressources that are automatically finalized when becoming
> unreachable. But it's up to the library author to write a complete
> implementation.

I don't understand. If the is no guarantee that the finalizer will be 
*ever* called, then what kind of building block it is?

>> A friend of mine spent long evenings recently hunting for database
>> connection leaks in a big Java application. That's telling something.
> 
> Well -- so he was naive and should have handled / understood that part
> of the system better.

Sure. In other words, be prepared that with GC you have to 
handle/understand some parts of the sytem better.

> A friend of mine spent half a month with finding
> problems with manual allocation/deallocation and sneaking heap
> corruption. Does that prove anything? I don't think so.

It does prove that your friend did not benefit from the language that 
provides scoped lifetime.

>>> And BTW - in
>>> fcuntional langauges you can do more against ressource leaks, sicne
>>> you can "wrap" functions:
>>>   (with_file "output" (with_file "out_put" copy_data))
>>> It's not always done, but a useful micro pattern.
> 
>> Yes, it basically emulates something that is just natural in those
>> languages that provide scope-based lifetime out of the box.
> 
> This is no emulation, but how FP does "scope based". Without the
> necessity to add exception handling at the client side or without
> having to introduce tagged types / classes. Isn't THAT nice? :-)

Same thing with scoped lifetime, as implemented in C++. No need for 
exception handling (unless handling is actually meaninful), nor for 
changes in the interface. That's nice, I agree.
The difference is that in languages with scoped lifetime the lifetime 
management is a property of the type (and so applies to all instances), 
whereas the "FP-trick" above is a property of the use-side. Which one is 
more robust and less prone to bugs?

BTW - please show me an example involving 10 objects of different kinds. :-)

>>> But I notice, that
>>>  "Languages like C provide a more general solution (with regard to
>>>   accessing memory), which is conceptually not related to any kind of
>>>   fixed type system and can therefore implement any type and data model"
>>> would become a valid argument if I agreed with you.
>> Except that it's not the point I'm making.
> 
> No, but the structure of the argument is basically the same. The
> analogy should help to show why it is (IMHO) invalid.

Ok, but please elaborate on the above first, so I'm sure that it relates 
to my point.

>> Tons of exception handling (and not only - every way to leave a scope
>> needs to be guarded, not only by exception) are necessary in those
>> languages that rely on GC without providing the above possibility at
>> the same time. 
> 
> No. I've done the same in Ada w/o controlled objects, but using a
> generic procedure.
> 
>   procedure mark_data_records is new process_cache_with_lock( Operation => mark_record, ... );
> 
>   begin
>     mark_data_records(...);
>   end;
> 
> The client side has no burden with exceaption handling.

Could you explain this example a bit?

>> I agree for references/pointers in polymorphic
>> collections. That's not even close to "almost everywhere" for me, but
>> your application domain may differ.
> 
> Yes. it does, abviously. You might not be aware, but code destined for
> mere consumers (as opposed to embedded code and code destined as tools
> for other developers) has a large amount of GUI code in it.

Yes.

>>>  (b) AFAIR there are restrictions on _where_ I can define controlled
>>>      types. AFAIR that was a PITA.
>> That's a mess. I'm sorry to repeat that.
> 
> Yes. But does C++ do it better? The Ada restrictions AFAIK come from
> the necessity of separate linking and compilation (you must be able to
> relink w/o looking at the body) and C++ treats that against the
> ability to add finalizers everyhwere.

I don't understand. Adding a finalizer/destructor to the type that 
didn't have it before means changes in both specs and the body. 
Relinking is not enough.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>>> And I stress again - GC is not the only solution for
>>> manual memory management.
>> OK. I accept that for the moment. I'm just not convinced you can do
>> everything you need with scope bound memory
>
> Sure. But for the sake of discussion completeness, you might wish to
> throw an example of a situation where scoped lifetime will not make it.

Model-View-Controller in GUIs. Especially trying to adapt that to GTKAda.

Sorry for being so short on this, but detailing this example would be
very long and after all perhaps not very convincing. At every local
vie of the situation one could argue that it would just be possible to
... whatever. But in the whole it is really hard to build a reusable
toolkit this way without reference counting or GC. Certainly it is
impossible (I'm convinced) with scope bound live time. Unfortunately
failure (or at least tremendous difficulties) to build something in s
specific fashion w/o a (semi-) formal proof or at least the
possibility to strip that down to a minimal example is not very
convincing, since you could always assume that more research would
have found a solution. (In my case I was happy to build a specialized
solution and note for later reference the susspicion that controlled
objects would be needed for a general one and scope bound life
wouldn't suffice).

I always intended to look a bit deeper into this issue but until now
other things were more important.

>>> Determinism in both timing and resource consumption?
>> Which brings me back to what I said repeatedly to other people:  (1)
>> That this determinism is very often not a requirement (outside of
>>      embdedded programming)
>
> Java programmer wrote a loop where he opened database cursors,
> released in the cursor finalizer. All was working like a charm, unless
> put into production, when in one case the loop had to spin many more
> times than he ever cared to test.

I'm not surprised. GC'ing ressources that are bounded doesn't spare
you knowing about the way GC works. My suggestion would have been to
either close the cursor explicitely (since I know about the problem)
or wrap the production of a new cursor in a module/class which also
looks at the number of already opened cursors and collects before
reaching certain limits (in effect introducing a new, additional,
threshold for GC).

> GC did not clean up the abandoned
> cursor objects fast enough and the number of unnecessarily opened
> cursors hit the server limit. That was the end of this application.

:-)

>
> The fix was easy: write explicit close/dispose/dismiss/whatever at the
> end of the loop, so that effectively there was never more than one
> open cursor. In fact, this was *manual* resource management.

Yes. As I said: GC can be made into an instrument to manage other
ressources, but it has to be done right. Sometimes you're just better
of assisting this mechanism by manually disposing of external
ressources at the right places. You're approach "I want it all, and if
I can't have both (memory management AND general ressource collection)
I don't want neither" is somewhat counterproductive. 

But you might well continue to believe in your policy here. I,
personally, find that it brings me a big step nearer to salvation if I
can have GC, even if I do only manual MM with it. After all: I don't
have this much other (external) ressources to care about and if I do,
it pays to have a careful look at their structure and then wrap some
abstraction around them.

> The above would be avoided altogether with scoped lifetime.

In this case yes. See -- I do not deny the advantages of 'scoped
lifetime'. It is a useful pattern, I've myself given some examples in
my last answer. But your approach is, since somebody had problems
misusing GC in a specific case in which scoped lifetime would have
worked fine, that therefore GC is useless and scoped lifetime
rules. Personally I prefer to have both approaches at hand, they are
complementary, but I certainly wouldn't want to miss GC in some
languages.

As far as the usability of GC goes, it even helps with controlled
objects: Controlled objects might be highly structured and the usual
(i.e. Ada) apporach is, that you hide the details of building and
later deallocating the structure under the hodd of the abstraction
barrier. Fine. That works. But with GC I don't even have to write a
tear-it-down procedure for everything a scoped object allocates under
the hood. I just make sure to close (e.g.) the filehandle and let the
rest to the GC.

> You are right that determinism is very often not a requirement. It is
> just the life that very often shows that the initial requirements were
> not complete.
>
>>  (2) The determinism is shot anyway by using a heap, not by using
>>      GC. Even better: GC can introduce detereminism in space
>>      consumption by compacting the heap, which naive heaps with manual
>>      MM don't do because of fragementation.
>
> There is nothing particular in scoped lifetime that would prohibit
> compacting heaps and there is nothing particular in GC that guarantees

No. But without having 3/4ths of a GC anyway compaction is pretty
pointless.

> it. It's just the statistics based on popular implementations, not a
> rule.

Sorry, that is nonsense. There are garbage collectors that are
designed to be compacting. They are moving objects around. This is
absolutely deterministic and not statistical. Whereas manual
allocation and deallocation as in Ada or C will fragment the heap and
you have NO guarantee (only statistics) about the ratio of allocated
(used) memory and presently unusable hole. None. Hows that about
reliability if you can't give space guarantees even if you know about
the memory your algorithms need, since unfortunately you cannot
perdict the exact sequence of allocations?

> I can perfectly imagine compacting heaps managed by scoped lifetime.

Yes you can do that. Since you're following pointers than and reqrite
them you might as well go the whole way and deollaocate unusable
memory while you're at it.

>
>>  (3) What is often needed are upper limits not determinism and thos
>>      upper limits can be guaranteed with GC or with an appropriate
>>      collector.


> This refers to memory consumption only, whereas I clearly stated
> deterministic *time* as a second (first, actually) goal.

This refers to both, there are real time compatible GC
algorithms. Development didn't stop in the last 20 years.

>>>> My impression was that Ada Controlled storage is actually quite a
>>>> clean concept compared to C++ storage duration.
>>
>>> Clean? It adds tag to the type, which then becomes a controlling type
>>> in every primitive operation.
>>
>>> I got bitten by this recently.  Adding a destructor to C++ class
>>> never has any side effects like this.
>> I understand. But the Ada OO way is peculiar, but not unmanagable.

> OK, I accept the word "peculiar". I only oppose "quite a clean
> concept" in your previous post. :-)

Tha Ada OO way. 'Controlled' is just the logical consequence and on
top of tagged types quite clean. 

>>> Apart from this, the bare existence of *two* base types Controlled and
>>> Limited_Controlled means that the concepts of controlled and limited
>>> are not really orthogonal in the sense that adding one of these
>>> meta-properties affects the interface that is "shared" by the other
>>> aspect.

>> Still. Being able to add a Finalize means you need to have a tagged
>> type. I see no alternative.
>
> You might want to take a look at C++.

I know C++ rather well. :-)


>>>> But both tie allocation to program scope, synchronous with a stack. I
>>>> insist that is not always desirable: It rules out some architecture,
>>>> especially those where OO abounds.
>>> What architecture?

>> I already say in another post: That is difficult to show with a toy
>> system. It only shows in larger systems where you really can't / don't
>> want to say in any give subsystem module how long a certain peice of
>> data lives. So none of those can be burdened with deallocating it.

> OK. What about refcounting with smart pointers?

(1) It ties lifetime to multiple scopes (instead of one), (2) its not
efficient, (3) It stille doesn't work for the general case, since
there is still a place where you have to decide that you don't need
that pointer copy any more, which is unscoped.

>>>> The problem with Controlled, BTW, is that it seems to interact with
>>>> the rest of the language in such a way that GNAT didn't get it right
>>>> even after ~10 years of development. Perhaps difficult w/o a formal
>>>> semantics.
>>
>>> You see.

>> Yes, I see. But GNAT is also a political problem (see the role of
>> AdaCore, formerly ACT), so (public) GNAT not getting things right
>> might well not indicate a problem with reading the Ada standard, but
>> in the release politics for public version. My hint: There is no
>> incentive to release a high quality public version GNAT.
>
> I get the message. Clear enough.

:-) Good. Whereas A. mightily profits by all the improvements in the
GCC backend, which IMHO was their prime motivation to support and
actively push reintegration into the GCC tree (they would have been
stuck with a GCC 2.8 based compiler else). Their is another theory
that they did it all out of the goodness of their hearts, but I don't
subscribe to that.

>>> In other words, it's very nice that GC doesn't preclude me from doing
>>> some stuff manually, but that's not enough.

>> I'm appalled: You don't want GC, but no, it doesn't do enough for
>> you?

> Exactly. It's not enough, because it doesn't solve the problem of
> resource management in a general way.

Poor misguided friend. :-)


>> Of yourse YMMV. but when I have it, it works really well for me.
>
> I acknowledge that there might be some applications which are strictly
> memory-oriented. They are just not the ones I usually write.

It also works for apps that are not "memory-oriented". I think you're
missing that e.g. filehandles are really simpler and differently
structured ressource from memory. A filehandle does not contain
references to memory or other filehandle. Memory does. That vastly
simplifies the problem of managing file handles indeed so much that
I'm convinced that you don't need buitlin support for this.


>>>> Apart from that languages
>>>> with GC often provide nice tricks to tie external ressources to their
>>>> memory proxy and ditch them when the memory proxy is unreachable
>>> These "nice tricks" are not so nice. Most of all, they provide no
>>> guarantee whatsoever, even that they will be invoked at all.
>> That's not quite true. Those tricks are building blocks to implement
>> ressources that are automatically finalized when becoming
>> unreachable. But it's up to the library author to write a complete
>> implementation.
>
> I don't understand. If the is no guarantee that the finalizer will be
> *ever* called, then what kind of building block it is?
>
>>> A friend of mine spent long evenings recently hunting for database
>>> connection leaks in a big Java application. That's telling something.
>> Well -- so he was naive and should have handled / understood that
>> part
>> of the system better.
>
> Sure. In other words, be prepared that with GC you have to
> handle/understand some parts of the sytem better.

So?

>
>> A friend of mine spent half a month with finding
>> problems with manual allocation/deallocation and sneaking heap
>> corruption. Does that prove anything? I don't think so.

> It does prove that your friend did not benefit from the language that
> provides scoped lifetime.

In that case, yes. But since there is a new-Operator in Ada, leaking
would have been the same problem.

>>>> And BTW - in
>>>> fcuntional langauges you can do more against ressource leaks, sicne
>>>> you can "wrap" functions:
>>>>   (with_file "output" (with_file "out_put" copy_data))
>>>> It's not always done, but a useful micro pattern.
>>
>>> Yes, it basically emulates something that is just natural in those
>>> languages that provide scope-based lifetime out of the box.
>> This is no emulation, but how FP does "scope based". Without the
>> necessity to add exception handling at the client side or without
>> having to introduce tagged types / classes. Isn't THAT nice? :-)
>
> Same thing with scoped lifetime, as implemented in C++. No need for
> exception handling (unless handling is actually meaninful), nor for
> changes in the interface. That's nice, I agree.
> The difference is that in languages with scoped lifetime the lifetime
> management is a property of the type (and so applies to all
> instances), whereas the "FP-trick" above is a property of the
> use-side. Which one is more robust and less prone to bugs?

This is, forgive me, nonsense. I might want to use a file handle in a
scoped way here and in a free floating way there. It still afile
handel. And no -- the FP way is not "more prone to bugs" and as with
George Bauhaus I simply refuse this kind of discussion (FUD and
ContraFUD).

> BTW - please show me an example involving 10 objects of different kinds. :-)

All at the same time? Well -- bad programming. You don't do everything
at the same time in FP (and in Ada ...) and I hardly ever have
functions involving 10 parameters. 


>>>> But I notice, that
>>>>  "Languages like C provide a more general solution (with regard to
>>>>   accessing memory), which is conceptually not related to any kind of
>>>>   fixed type system and can therefore implement any type and data model"
>>>> would become a valid argument if I agreed with you.
>>> Except that it's not the point I'm making.

>> No, but the structure of the argument is basically the same. The
>> analogy should help to show why it is (IMHO) invalid.
>
> Ok, but please elaborate on the above first, so I'm sure that it
> relates to my point.

You refuse mor automation and abstraction on the pretext of generality
and better control. That exactly is the point that has been made
against: Compiled languages, structured programming, type systems,
modularization, OO, etc -- name any advance you want, it has been
opposed with arguments of exactly that kind. What is missing from them
is, though, some kind of argument that the "loss of control" or "the
loss of generaity" actually is bad, or better: Does cost more than it
pays for. Your argument, I admit, might be permissible, but it needs
more groundwork.

>>> Tons of exception handling (and not only - every way to leave a scope
>>> needs to be guarded, not only by exception) are necessary in those
>>> languages that rely on GC without providing the above possibility at
>>> the same time.
>> No. I've done the same in Ada w/o controlled objects, but using a
>> generic procedure.
>>   procedure mark_data_records is new process_cache_with_lock(
>> Operation => mark_record, ... );
>>   begin
>>     mark_data_records(...);
>>   end;
>> The client side has no burden with exceaption handling.
>
> Could you explain this example a bit?

Later. Don't hesitate to ask again. I'll just cut+paste the complete
code too, but it takes some time (which I don't have now).

>>> I agree for references/pointers in polymorphic
>>> collections. That's not even close to "almost everywhere" for me, but
>>> your application domain may differ.

>> Yes. it does, abviously. You might not be aware, but code destined
>> for
>> mere consumers (as opposed to embedded code and code destined as tools
>> for other developers) has a large amount of GUI code in it.
>
> Yes.
>
>>>>  (b) AFAIR there are restrictions on _where_ I can define controlled
>>>>      types. AFAIR that was a PITA.
>>> That's a mess. I'm sorry to repeat that.

>> Yes. But does C++ do it better? The Ada restrictions AFAIK come from
>> the necessity of separate linking and compilation (you must be able to
>> relink w/o looking at the body) and C++ treats that against the
>> ability to add finalizers everyhwere.


> I don't understand. Adding a finalizer/destructor to the type that
> didn't have it before means changes in both specs and the
> body. Relinking is not enough.

I thought you talked about the restriction where a Controlled type can
be defined.


Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Tue, 06 Feb 2007 16:44:17 +0100, Markus E Leypold wrote:

> Maciej Sobczak <no.spam@no.spam.com> writes:
> 
>> Sure. But for the sake of discussion completeness, you might wish to
>> throw an example of a situation where scoped lifetime will not make it.
> 
> Model-View-Controller in GUIs. Especially trying to adapt that to GTKAda.

I am not sure what you mean, but

1. GTK+ uses reference counting. GtkAda just follows it in that respect. So
all GtkAda interface objects are access to class-wide record. These objects
are scoped. Because GtkAda is thin bindings its objects are not controlled
(neither they are in GTK+). It would be quite easy to make them controlled
and perform Unref upon Finalization.

2. MVC tree view is not different in that respect and does not impose any
additional difficulties except usual awkward interfacing with C.

You can find custom tree view models for GtkAda here:

   http://www.dmitry-kazakov.de/ada/gtkada_contributions.htm#2.1

and custom cell renderers here:

   http://www.dmitry-kazakov.de/ada/gtkada_contributions.htm#2.3

>> OK, I accept the word "peculiar". I only oppose "quite a clean
>> concept" in your previous post. :-)
> 
> Tha Ada OO way. 'Controlled' is just the logical consequence and on
> top of tagged types quite clean. 

Controlled is a hack. It is the logical consequence of an apparent desire
to leave this issue open for future language extensions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

>> Sure. But for the sake of discussion completeness, you might wish to
>> throw an example of a situation where scoped lifetime will not make it.
> 
> Model-View-Controller in GUIs. Especially trying to adapt that to GTKAda.

I will not repeat Dmitry's arguments here.

>> Java programmer wrote a loop where he opened database cursors,
[...]

> I'm not surprised. GC'ing ressources that are bounded doesn't spare
> you knowing about the way GC works.

Exactly. That's why I say that the solution is incomplete. If you have 
to think about the mechanics of some solution, then that solution is not 
entirely/properly automated.

> You're approach "I want it all, and if
> I can't have both (memory management AND general ressource collection)
> I don't want neither" is somewhat counterproductive. 

I find it counterproductive to apply different management strategies 
with regard to *implementation details* of different types.
I prefer solutions which enable me to hide implementation details from 
clients (sotware engineering?). If clients have to treat different types 
differently just because their implementation details differ, then it 
means that these implementation details leak out in the form of distinct 
handling methods. I want to treat String and DatabaseCursor in the same 
way - that's the prerequisite for being productive for me.

> But you might well continue to believe in your policy here.

Thanks. :-)

> I,
> personally, find that it brings me a big step nearer to salvation if I
> can have GC, even if I do only manual MM with it. After all: I don't
> have this much other (external) ressources to care about and if I do,
> it pays to have a careful look at their structure and then wrap some
> abstraction around them.

OK, I understand it. We just agree that GC is a valid solution for 
*some* class of computing problems.
So why people claim that GC-oriented languages are general-purpose?

> But your approach is, since somebody had problems
> misusing GC in a specific case

No, that's not the point. The point is that languages which are build 
around GC tend to drop the proper support for other types of resources 
altogether. It's not the particular programmer who misused GC in a 
specific case - it's language designers who closed themselves in the GC 
cage and cranked a language that fails to provide good support for wider 
class of problems.
As I've already said, the ideal would be to have both GC and scoped 
lifetime. The problem is that there is no reliable industry experience 
with such a mix, unless we treat Boehm's GC as one.

> As far as the usability of GC goes, it even helps with controlled
> objects
[...]
> I just make sure to close (e.g.) the filehandle and let the
> rest to the GC.

Of course. But then it's up to the designer of the type to decide how to 
treat each component of that type - it should be implementation detail. 
This decision should not be put on the shoulders of the final user, 
which is now the case in mainstream GC-oriented languages. This is what 
is broken.

>> There is nothing particular in scoped lifetime that would prohibit
>> compacting heaps and there is nothing particular in GC that guarantees
> 
> No. But without having 3/4ths of a GC anyway compaction is pretty
> pointless.

Why? If the goal of compaction is to avoid fragmentation, then what is 
pointless in having compacted heaps managed by scoped lifetime?

>> it. It's just the statistics based on popular implementations, not a
>> rule.
> 
> Sorry, that is nonsense. There are garbage collectors that are
> designed to be compacting.

So what? This is exactly the statistics I'm talking about, that does not 
prove that GC guarantees compacting or that the lack of GC prevents it.

> They are moving objects around. This is
> absolutely deterministic and not statistical.

By statistics I mean the number of language implementations on the 
market that choose to use compacting GC vs. the number of languages that 
use non-compacting heaps. :-)

 > Whereas manual
> allocation and deallocation as in Ada or C will fragment the heap and
> you have NO guarantee (only statistics) about the ratio of allocated
> (used) memory and presently unusable hole.

If that bothers you, then use non-fragmenting allocators.

> Hows that about
> reliability if you can't give space guarantees even if you know about
> the memory your algorithms need, since unfortunately you cannot
> perdict the exact sequence of allocations?

I use non-fragmenting allocator and I get my guarantees.

>> I can perfectly imagine compacting heaps managed by scoped lifetime.
> 
> Yes you can do that. Since you're following pointers than and reqrite
> them you might as well go the whole way and deollaocate unusable
> memory while you're at it.

Yes. Note that scoped lifetime does not preclude GC on some lower level.
Scoped lifetime provides a hook for deterministic "good bye" action - 
there is nothing more to it. Even if that "good bye" action calls 
free/delete/whatever on some memory block, there is nothing that forces 
the runtime to return the given block of memory right back to the 
operating system. Actually, none of the self-respecting allocators do 
this systematically - instead they keep the memory around for a while in 
anticipation of future allocations. I have nothing against GC at this 
level, really (and I've seen such implementations - in fact, a fully 
standard-compliant implementation of the C language could provide 
*empty* free function and GC underneath; and fully conformant C++ 
implementation could just call destructors as a result of delete and 
leave the raw memory to GC).

What I'm against is a GC "paradigm" that prevents me from having 
deterministic "good bye" hooks for scoped lifetime. The problem is that 
most GC-oriented languages I'm aware of do have this "issue".

In other words, for me GC is acceptable as an implementation detail of 
the dynamic memory allocator. I don't care *how* the allocator deals 
with memory that I free in the same sense that I don't care *how* the 
operating system deals with files that I remove from the filesystem. 
What I care about are hooks and scoped lifetime is an obvious answer for 
this.

>>>  (3) What is often needed are upper limits not determinism and thos
>>>      upper limits can be guaranteed with GC or with an appropriate
>>>      collector.
> 
>> This refers to memory consumption only, whereas I clearly stated
>> deterministic *time* as a second (first, actually) goal.
> 
> This refers to both, there are real time compatible GC
> algorithms.

I'm interested in what is their target audience. I would expect any 
decent RT system to *refrain* from using dynamic memory except in the 
initialization phase (so that the "mission phase" is performed with 
constant set of objects), in which case RT GC would be just an answer to 
the question that nobody asked.
Experts might wish to correct me and elaborate on this.

>> OK. What about refcounting with smart pointers?
> 
> (1) It ties lifetime to multiple scopes (instead of one)

With GC tracing pointers you have the same, just the tracing is hidden.

> (2) its not
> efficient

Why?

> (3) It stille doesn't work for the general case

Neither does GC, as seen in examples. :-)

>> I acknowledge that there might be some applications which are strictly
>> memory-oriented. They are just not the ones I usually write.
> 
> It also works for apps that are not "memory-oriented". I think you're
> missing that e.g. filehandles are really simpler and differently
> structured ressource from memory. A filehandle does not contain
> references to memory or other filehandle. Memory does. That vastly
> simplifies the problem of managing file handles indeed so much that
> I'm convinced that you don't need buitlin support for this.

Somehow this idea didn't work for database cursors, as already described.

>> Sure. In other words, be prepared that with GC you have to
>> handle/understand some parts of the sytem better.
> 
> So?

So the implementation details of *some* types leak out in the sense that 
they force me to understand their internal mechanics. I don't want to.
I want to say this:

declare
     Sql : Session := Open_Session("some parameters");
     Str : String := "Hello";
begin
     -- ...
end;

instead of this:

declare
     Sql : Session := Open_Session("some parameters");
     Str : String := "Hello";
begin
     -- ...
     -- damn, I have to do *something* with *some* stuff here
end;

[about FP]
>> The difference is that in languages with scoped lifetime the lifetime
>> management is a property of the type (and so applies to all
>> instances), whereas the "FP-trick" above is a property of the
>> use-side. Which one is more robust and less prone to bugs?
> 
> This is, forgive me, nonsense. I might want to use a file handle in a
> scoped way here and in a free floating way there.

What about readability and maintainability of such code?

> And no -- the FP way is not "more prone to bugs"

Unless you use a handle in a free floating way and find later that in 
production your code was called in a loop causing handles to pile up?
I have the practical example (already described) that this way of 
thinking can lead to failures. The programmer wanted to use a database 
cursor in a free floating way. That was fine. Later his code was used in 
a loop. Ah, yes - his code was used in a loop written by another 
programmer, so his judgement about whether it's OK to use anything in a 
free floating way was misguided from the very beginning.

> and as with
> George Bauhaus I simply refuse this kind of discussion (FUD and
> ContraFUD).

OK. We will just stay unconvinced. :-)

>> BTW - please show me an example involving 10 objects of different kinds. :-)
> 
> All at the same time?

Yes.

> Well -- bad programming.

I knew you would answer this. :-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

GC in Ada

[Martin Krischik]

Maciej Sobczak schrieb:

> Yes. Note that scoped lifetime does not preclude GC on some lower level.
> Scoped lifetime provides a hook for deterministic "good bye" action - 
> there is nothing more to it. Even if that "good bye" action calls 
> free/delete/whatever on some memory block, there is nothing that forces 
> the runtime to return the given block of memory right back to the 
> operating system. Actually, none of the self-respecting allocators do 
> this systematically - instead they keep the memory around for a while in 
> anticipation of future allocations.

I believe in most systems memory is never returned.

If I understood Unix file management right only memory at the end of the 
heap can be returned. Without compaction a no go.

And on Windows I know that only the full block allocated with MemAlloc 
can be returned. Blocks are always page sized (multiple of 4kb). A smart 
Memory manager might reserve a full block for large allocations but all 
those tiny 20 byte allocations will never be returned to the OS.

> What I'm against is a GC "paradigm" that prevents me from having 
> deterministic "good bye" hooks for scoped lifetime. The problem is that 
> most GC-oriented languages I'm aware of do have this "issue".

But isn't that exactly what "Unchecked_Deallocation" and "pragma 
Controlled" is all about? Has Ada - by your rationale - not got GC right?

Martin

Re: GC in Ada

[Markus E Leypold]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Maciej Sobczak schrieb:
>
>> Yes. Note that scoped lifetime does not preclude GC on some lower level.
>> Scoped lifetime provides a hook for deterministic "good bye" action
>> -
>> there is nothing more to it. Even if that "good bye" action calls
>> free/delete/whatever on some memory block, there is nothing that
>> forces the runtime to return the given block of memory right back to
>> the operating system. Actually, none of the self-respecting
>> allocators do this systematically - instead they keep the memory
>> around for a while in anticipation of future allocations.
>
> I believe in most systems memory is never returned.
>
> If I understood Unix file management right only memory at the end of
> the heap can be returned. Without compaction a no go.

You're partly right. It depends on the heap implementation. If done
using sbrk() you're right. If done using mmap() you'd have --
theoretically -- the possibility wo return sufficiently large holes to
the OS. 

Regards -- Markus

Re: GC in Ada

[Maciej Sobczak]

Martin Krischik wrote:

>> What I'm against is a GC "paradigm" that prevents me from having 
>> deterministic "good bye" hooks for scoped lifetime. The problem is 
>> that most GC-oriented languages I'm aware of do have this "issue".
> 
> But isn't that exactly what "Unchecked_Deallocation" and "pragma 
> Controlled" is all about? Has Ada - by your rationale - not got GC right?

By my rationale Ada and C++ got it perfectly right ([Limited_]Controlled 
mess aside).

The only difference between them in this regard is that Ada explicitly 
allows GC on the low level without requiring it (so that implementations 
can ignore the whole idea) and that C++ is traditionally silent about 
the concept altogether (so that implementations can provide it). ;-)

(Note that GC will likely be formalized in the upcoming C++ standard.)

My criticism is targeted at those languages which bring GC to the top 
level obstructing the visible part of the object model.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Martin Krischik]

Maciej Sobczak schrieb:
> Martin Krischik wrote:
> 
>>> What I'm against is a GC "paradigm" that prevents me from having 
>>> deterministic "good bye" hooks for scoped lifetime. The problem is 
>>> that most GC-oriented languages I'm aware of do have this "issue".
>>
>> But isn't that exactly what "Unchecked_Deallocation" and "pragma 
>> Controlled" is all about? Has Ada - by your rationale - not got GC right?
> 
> By my rationale Ada and C++ got it perfectly right ([Limited_]Controlled 
> mess aside).
> 
> The only difference between them in this regard is that Ada explicitly 
> allows GC on the low level without requiring it (so that implementations 
> can ignore the whole idea) and that C++ is traditionally silent about 
> the concept altogether (so that implementations can provide it). ;-)

Only that C++ does not have pragma Controlled to switch the collector 
off. And Unchecked_Deallocation should deallocate even when a collector 
is present.

> (Note that GC will likely be formalized in the upcoming C++ standard.)

Which could solve the above.

> My criticism is targeted at those languages which bring GC to the top 
> level obstructing the visible part of the object model.

On my Weblogic course I could not stop shaking my head about all the 
problems which brings the "all is pointer" concept of Java.

Martin

Re: GC in Ada

[Markus E Leypold]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Maciej Sobczak schrieb:
>> Martin Krischik wrote:
>>
>>>> What I'm against is a GC "paradigm" that prevents me from having
>>>> deterministic "good bye" hooks for scoped lifetime. The problem is
>>>> that most GC-oriented languages I'm aware of do have this "issue".
>>>
>>> But isn't that exactly what "Unchecked_Deallocation" and "pragma
>>> Controlled" is all about? Has Ada - by your rationale - not got GC
>>> right?
>> By my rationale Ada and C++ got it perfectly right
>> ([Limited_]Controlled mess aside).
>> The only difference between them in this regard is that Ada
>> explicitly allows GC on the low level without requiring it (so that
>> implementations can ignore the whole idea) and that C++ is
>> traditionally silent about the concept altogether (so that
>> implementations can provide it). ;-)
>
> Only that C++ does not have pragma Controlled to switch the collector
> off. And Unchecked_Deallocation should deallocate even when a
> collector is present.
>
>> (Note that GC will likely be formalized in the upcoming C++ standard.)
>
> Which could solve the above.
>
>> My criticism is targeted at those languages which bring GC to the
>> top level obstructing the visible part of the object model.
>
> On my Weblogic course I could not stop shaking my head about all the
> problems which brings the "all is pointer" concept of Java.

Fortunately you can ignore this "all is pointer" by exposing only a
read-only interface to the client and leaving the rest to the GC. That
feels exactly like passing records around with in, out and in/out.  I
don't see the problem. Not to doubt your experience on this, but just
because I'm curious: Can you provide a hint or example what the
problems are?

Regards -- Markus

Re: GC in Ada

[Martin Krischik]

Markus E Leypold schrieb:

> Martin Krischik <krischik@users.sourceforge.net> writes:

>> Maciej Sobczak schrieb:

>> On my Weblogic course I could not stop shaking my head about all the
>> problems which brings the "all is pointer" concept of Java.

> Fortunately you can ignore this "all is pointer" by exposing only a
> read-only interface to the client and leaving the rest to the GC

Only Java has no const keyword. It is supposed to get one but how long 
until it is actually used?

> That
> feels exactly like passing records around with in, out and in/out.  I
> don't see the problem. Not to doubt your experience on this, but just
> because I'm curious: Can you provide a hint or example what the
> problems are?

I can give you the solution, which is not used all that widely because 
of the performance impact:

class X
   {
   Date date = new Date;

   Date
   get_Date ()
      {
      return new Date (date);
      }

   void
   set_Date (Date new_Date)
      {
      date = new Date (new_Date);
      }
   }

Got it? If get_Date would just return date it would return a modifiable 
pointer - which could be used and - well - modified almost everywhere.

As said the solution above is not used all that often and so the 
interesting part in the weblogic course was that the hard core java 
programmers had to learn that for remote call object those object might 
be copied behind the scenes and not passes by (non const) reference. And 
so to those objects modifications might be lost!

This was the moment where a hole horror scenario unfolded to me: 
programmers which actually modified objects returned by a geta function 
instead of using the appropriate seta function!

Martin

Re: GC in Ada

[Markus E Leypold]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Markus E Leypold schrieb:
>
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>
>>> Maciej Sobczak schrieb:
>
>>> On my Weblogic course I could not stop shaking my head about all the
>>> problems which brings the "all is pointer" concept of Java.
>
>> Fortunately you can ignore this "all is pointer" by exposing only a
>> read-only interface to the client and leaving the rest to the GC

> Only Java has no const keyword. It is supposed to get one but how long
> until it is actually used?


Excuse me, but ... "a read only interface" means:

   (a) make all field of objects private 
   (b) allow access only my methods
   (c) provide only Get_*-methods, no Set_*-methods

(a+b) is actually standard good practice in software engineering,
since it allows to hide representation and allows for maintaining
cached attributes/data (which direct access to fields won't allow).

Regards -- Markus

Re: GC in Ada

[Martin Krischik]

Markus E Leypold schrieb:

>> Only Java has no const keyword. It is supposed to get one but how long
>> until it is actually used?
> 
> Excuse me, but ... "a read only interface" means:
> 
>    (a) make all field of objects private 
>    (b) allow access only my methods
>    (c) provide only Get_*-methods, no Set_*-methods

you mean as in:

java.lang.Date
get_Date ()
   {
   return this.date;
   }

True enough, with a Get_*-method like this you never need a Set_*-method 
;-).

Martin

Re: GC in Ada

[Georg Bauhaus]

On Thu, 2007-02-08 at 10:33 +0100, Markus E Leypold wrote:
> 
> Martin Krischik <krischik@users.sourceforge.net> writes:

> > Only Java has no const keyword. It is supposed to get one but how long
> > until it is actually used?
> 
> 
> Excuse me, but ... "a read only interface" means:
> 
>    (a) make all field of objects private 
>    (b) allow access only my methods

What Eiffel does by design.

>    (c) provide only Get_*-methods, no Set_*-methods

This lets programmers design type interfaces and wrappers so that
objects are effectively read-only.
Wouldn't it be nice to just export a constant view where
needed? Like C++'s const& or Ada's access-to-constant?
Or to have C++ const view and Ada in mode parameters
that extend to the referred object?

procedure a is

    type J is
        record
            x: Integer;
        end record;

    procedure nope(this: in J; new_x: Integer) is
    begin
        this.x := new_x; -- compile time error
    end nope;

begin
    nope(42);
end a;


struct J
{
  int x;
};

int main()
{
  J wj;
  const J rj = wj;

  wj.x = 42;
  rj.x = 42;  // compile time error
  return 0;
}

Re: GC in Ada

[Maciej Sobczak]

Georg Bauhaus wrote:

> Or to have C++ const view and Ada in mode parameters
> that extend to the referred object?

>   J wj;
>   const J rj = wj;
            ^

const J &rj = wj;
         ^

I guess you wanted to use const reference. This is closer to the concept 
of "view".

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Georg Bauhaus]

On Fri, 2007-02-09 at 16:29 +0100, Maciej Sobczak wrote:
> Georg Bauhaus wrote:

> >   J wj;
> >   const J rj = wj;
>             ^
> 
> const J &rj = wj;
>          ^
> 
> I guess you wanted to use const reference. This is closer to the concept 
> of "view".

Yes, thanks for the patch.

Re: GC in Ada

[Maciej Sobczak]

Martin Krischik wrote:

> And Unchecked_Deallocation should deallocate even when a collector 
> is present.

I don't understand. There is no legal way for the program to verify that 
anything was indeed deallocated, so it doesn't make much sense to say 
that this behaviour is required.

As far as I understand it, Unchecked_Deallocation is allowed to do 
nothing. That wouldn't be a very competitive language implementation, 
but AARM does not require it either. :-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Martin Krischik]

Maciej Sobczak schrieb:

> Martin Krischik wrote:

>> And Unchecked_Deallocation should deallocate even when a collector is 
>> present.

> I don't understand. There is no legal way for the program to verify that 
> anything was indeed deallocated, so it doesn't make much sense to say 
> that this behaviour is required.

should /= must

> As far as I understand it, Unchecked_Deallocation is allowed to do 
> nothing. That wouldn't be a very competitive language implementation, 
> but AARM does not require it either. :-)

Just read it up [1] and Unchecked_Deallocation may not be a no-op - you 
forgot finalization. Apart from that:

---------------------
Implementation Advice

For a standard storage pool, Free should actually reclaim the storage.
---------------------

Again "Should /= must" and - you are right - there are no references as 
to when reclaim should happen.

Martin

[1] http://www.adaic.com/standards/05rm/html/RM-13-11-2.html

Re: GC in Ada

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Martin Krischik wrote:
>
>> And Unchecked_Deallocation should deallocate even when a collector
>> is present.
>
> I don't understand. There is no legal way for the program to verify
> that anything was indeed deallocated, so it doesn't make much sense to
> say that this behaviour is required.

Oh yes. Deallocating immeditately and deallocating later makes a
difference in time and space behaviour -- which IS measurable outside
the program (BTW: Exactly what you've been harping upon in you
opposition against GC :-)) )

Regards -- Markus

Re: GC in Ada

[Maciej Sobczak]

Markus E Leypold wrote:

>>> And Unchecked_Deallocation should deallocate even when a collector
>>> is present.
>> I don't understand. There is no legal way for the program to verify
>> that anything was indeed deallocated, so it doesn't make much sense to
>> say that this behaviour is required.
> 
> Oh yes. Deallocating immeditately and deallocating later makes a
> difference in time and space behaviour -- which IS measurable outside
> the program

With a small issues that this possibility is not formalized by the 
language standard (please read carefully my sentence above: "there is no 
*legal* way *for the program*").

And that is why it is *not* measurable, because there is no sensible way 
to define at which level of memory management it should be measured.

As was already pointed out in this thread, with some operating systems 
memory reclamation might not be meaningful at all unless the whole 
program is terminated.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

>> Oh yes. Deallocating immeditately and deallocating later makes a
>> difference in time and space behaviour -- which IS measurable outside
>> the program
>
> With a small issues that this possibility is not formalized by the
> language standard (please read carefully my sentence above: "there is
> no *legal* way *for the program*").
>
> And that is why it is *not* measurable, because there is no sensible
> way to define at which level of memory management it should be
> measured.

You said:

>>> I don't understand. There is no legal way for the program to verify
>>> that anything was indeed deallocated, so it doesn't make much sense to
>>> say that this behaviour is required.

This is a 'non sequitur', since it makes sense to say the behaviour is
required to fix certain real time properties. Regardless of wether it
can be detected in the program (and it could, by observing the wall
clock).

> As was already pointed out in this thread, with some operating systems
> memory reclamation might not be meaningful at all unless the whole
> program is terminated.

I don't even ask to be shown such an operating system...

Regards -- Markus

Re: GC in Ada

[Maciej Sobczak]

Markus E Leypold wrote:

>>>> I don't understand. There is no legal way for the program to verify
>>>> that anything was indeed deallocated, so it doesn't make much sense to
>>>> say that this behaviour is required.
> 
> This is a 'non sequitur', since it makes sense to say the behaviour is
> required to fix certain real time properties. Regardless of wether it
> can be detected in the program (and it could, by observing the wall
> clock).

Observing the wall clock does not help much in a language where even 
null; can raise exceptions. Standard does not even guarantee that any 
given sequence of instructions will give consistent timings when run twice.

Definitely, observice the wall clock is of no use to verify memory 
deallocation, since deallocation might have positive effect on the 
timing as well as negative or none at all.

>> As was already pointed out in this thread, with some operating systems
>> memory reclamation might not be meaningful at all unless the whole
>> program is terminated.
> 
> I don't even ask to be shown such an operating system...

On systems with virtual memory, deallocations that don't span at least 
one full page (that condition can be met after joining with other free 
blocks, though) will certainly not deallocate anything to the operating 
system.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>>>>> I don't understand. There is no legal way for the program to verify
>>>>> that anything was indeed deallocated, so it doesn't make much sense to
>>>>> say that this behaviour is required.
>> This is a 'non sequitur', since it makes sense to say the behaviour
>> is
>> required to fix certain real time properties. Regardless of wether it
>> can be detected in the program (and it could, by observing the wall
>> clock).
>
> Observing the wall clock does not help much in a language where even
> null; can raise exceptions. Standard does not even guarantee that any
> given sequence of instructions will give consistent timings when run
> twice.
>
> Definitely, observice the wall clock is of no use to verify memory
> deallocation, since deallocation might have positive effect on the
> timing as well as negative or none at all.

If you don't deallocate memory "really" in Unchecked_Deallocation then
you aither run out of memory sooner or later (verifiable and it makes
sense to require that this doesn't occur) or you have a garbage
collector and intermittend garbage collection runs which are visible
in the real time behaviour. So it makes sense to say the behaviour
(real deallocation to return memory to the free list) is required and
checkable, regardless of the question wether _the program_ can verify this. 

And as I said, from "no legal way for the program to verify" to
"doesn't make much sense to say that this behaviour is required" is a
non sequitur since behaviour might entail aspects that cannot only be
described in the production of data.

>>> As was already pointed out in this thread, with some operating systems
>>> memory reclamation might not be meaningful at all unless the whole
>>> program is terminated.
>> I don't even ask to be shown such an operating system...
>
> On systems with virtual memory, deallocations that don't span at least
> one full page (that condition can be met after joining with other free
> blocks, though) will certainly not deallocate anything to the
> operating system.

Excuse me: I misread "memory reclamation might not be meaningful at
all unless the whole program is terminated" as: No memory is ever
deallocated. Which is still the only meaningful reading of your
sentence since deallocation to the internal free block list is still
meaningful and not a no-op.

Regards -- Markus

Re: GC in Ada

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> As far as I understand it, Unchecked_Deallocation is allowed to do 
> nothing. That wouldn't be a very competitive language implementation, 
> but AARM does not require it either. :-)

Unchecked_Deallocation has to set its parameter to null.

The Rolm-Data General compiler, the 1st validated Ada-83 compiler, did 
only that. The argument was that every program had a 4 GB virtual memory 
space, so there was no need to actually reclaim memory.

In reality, I think it was skipped to save time so they could have the 
1st validated compiler.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: GC in Ada

[Jean-Pierre Rosen]

Jeffrey R. Carter a �crit :

> The Rolm-Data General compiler, the 1st validated Ada-83 compiler
Although DG claimed that, their certificate shows #2.
#1 was Ada-ED, from NYU, as everybody should know.


-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GC in Ada

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Jeffrey R. Carter a �crit :
>
>> The Rolm-Data General compiler, the 1st validated Ada-83 compiler
> Although DG claimed that, their certificate shows #2.
> #1 was Ada-ED, from NYU, as everybody should know.

I think it's fair to say that Ada-ED was the first validated
implementation of Ada 83, and that the Rolm-Data General implementation
was the first validated Ada compiler for Ada 83.

- Bob

Re: GC in Ada

[Jean-Pierre Rosen]

Robert A Duff a �crit :
> Jean-Pierre Rosen <rosen@adalog.fr> writes:
> I think it's fair to say that Ada-ED was the first validated
> implementation of Ada 83, and that the Rolm-Data General implementation
> was the first validated Ada compiler for Ada 83.
> 
I fail to see why Ada-ED does not deserve the name "compiler". I may 
admit that Rolm was the first /industrial/ compiler, i.e. usable for 
real programs...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GC in Ada

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Robert A Duff a �crit :
>> Jean-Pierre Rosen <rosen@adalog.fr> writes:
>> I think it's fair to say that Ada-ED was the first validated
>> implementation of Ada 83, and that the Rolm-Data General implementation
>> was the first validated Ada compiler for Ada 83.
>>
> I fail to see why Ada-ED does not deserve the name "compiler". 

Because the Ada-ED implementation was highly interpretive.

>...I may
> admit that Rolm was the first /industrial/ compiler, i.e. usable for
> real programs...

- Bob

Re: GC in Ada

[Jean-Pierre Rosen]

Robert A Duff a �crit :
>> I fail to see why Ada-ED does not deserve the name "compiler". 
> 
> Because the Ada-ED implementation was highly interpretive.
> 
So what? You still have to transform source text into another 
representation, and do numerous checks at the same time. That's what I 
call "compiling".

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GC in Ada

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
>
> So what? You still have to transform source text into another 
> representation, and do numerous checks at the same time. That's what I 
> call "compiling".

Then your definition differs from mine, Duff's, and numerous other people's.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: GC in Ada

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
> 
> Although DG claimed that, their certificate shows #2.
> #1 was Ada-ED, from NYU, as everybody should know.

Ada-ED was an interpreter, not a compiler, as everybody should know.

-- 
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

Re: GC in Ada

[Martin Krischik]

Jeffrey R. Carter wrote:

> Jean-Pierre Rosen wrote:
>> 
>> Although DG claimed that, their certificate shows #2.
>> #1 was Ada-ED, from NYU, as everybody should know.
> 
> Ada-ED was an interpreter, not a compiler, as everybody should know.

Ada interpreter, cool.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: GC in Ada

[Pascal Obry]

Jeffrey R. Carter a �crit :
> Jean-Pierre Rosen wrote:
>>
>> Although DG claimed that, their certificate shows #2.
>> #1 was Ada-ED, from NYU, as everybody should know.
> 
> Ada-ED was an interpreter, not a compiler, as everybody should know.

Well one could argue that Ada-ED was a compiler to a virtual machine.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GC in Ada

[Jeffrey R. Carter]

Pascal Obry wrote:
> 
> Well one could argue that Ada-ED was a compiler to a virtual machine.

I never used it, but my understanding is that that isn't an accurate 
description.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: GC in Ada

[Pascal Obry]

Jeffrey R. Carter a �crit :
> Pascal Obry wrote:
>>
>> Well one could argue that Ada-ED was a compiler to a virtual machine.
> 
> I never used it, but my understanding is that that isn't an accurate
> description.

I've used it... log time ago and IIRC it was using a kind of p-code a-la
Pascal. This is just a kind of virtual machine to me...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GC in Ada

[Jeffrey R. Carter]

Pascal Obry wrote:
> 
> I've used it... log time ago and IIRC it was using a kind of p-code a-la
> Pascal. This is just a kind of virtual machine to me...

I guess it's a matter of semantics. If the program reads the source and 
performs the actions required by it, I consider it an interpreter. What 
activities it uses internally to perform that interpretation are an 
elephant.

If the program converts the source into another form which can later be 
executed by appropriate HW or an emulator, then I call it a compiler. 
UCSD Pascal had a Pascal-to-P-code compiler. The P-code could be 
executed later, on a P-code machine or, more commonly, through an 
emulator. (I'm not aware of there ever being a P-code machine, which is 
why it's often referred to as a virtual machine. But there's no reason 
there couldn't have been one.) Java works similarly.

My understanding is that Ada-Ed was in the former category.

-- 
Jeff Carter
"C++ is like giving an AK-47 to a monk, shooting him
full of crack and letting him loose in a mall and
expecting him to balance your checking account
'when he has the time.'"
Drew Olbrich
52

Re: GC in Ada

[Jean-Pierre Rosen]

Jeffrey R. Carter a �crit :
> The P-code could be 
> executed later, on a P-code machine or, more commonly, through an 
> emulator. (I'm not aware of there ever being a P-code machine, which is 
> why it's often referred to as a virtual machine. But there's no reason 
> there couldn't have been one.) 
There was one, by Western-Digital:
http://en.wikipedia.org/wiki/Pascal_MicroEngine

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GC in Ada

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
> There was one [P-code machine], by Western-Digital:
> http://en.wikipedia.org/wiki/Pascal_MicroEngine

Cool.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: GC in Ada

[Robert A Duff]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> If the program converts the source into another form which can later be
> executed by appropriate HW or an emulator, then I call it a
> compiler.

Well, Ada requires certain errors to be detected at compile time,
so it is impossible to write a _pure_ interpreter for Ada -- something
like a Unix shell, which executes the first line before even looking
at the second line.  An Ada implementation has to look at the entire
program before running it.

But still, the part of Ada-Ed that runs the SETL structures or the bytes
or whatever, is an interpreter.  I claim Ada-Ed is a hybrid
implementation of Ada -- neither pure interpreter nor pure compiler.

- Bob

Re: GC in Ada

[Jean-Pierre Rosen]

Pascal Obry a �crit :
> Jeffrey R. Carter a �crit :
>> Pascal Obry wrote:
>>> Well one could argue that Ada-ED was a compiler to a virtual machine.
>> I never used it, but my understanding is that that isn't an accurate
>> description.
> 
> I've used it... log time ago and IIRC it was using a kind of p-code a-la
> Pascal. This is just a kind of virtual machine to me...
> 
Since we are in historical mode...

The first version of Ada-ED was interpreting directly SETL structures. 
The second one generated code for a virtual machine.

If you are really interested, the description of the virtual machine can 
be found in the PhD thesis of P. Kruchten and J-P. Rosen ;-). Only 
available on paper, though (this was in 1985).
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GC in Ada

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
> 
> The first version of Ada-ED was interpreting directly SETL structures. 
> The second one generated code for a virtual machine.

I guess the question, then, is which version received certificate #1?

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: GC in Ada

[Jean-Pierre Rosen]

Jeffrey R. Carter a �crit :
> Jean-Pierre Rosen wrote:
>>
>> The first version of Ada-ED was interpreting directly SETL structures. 
>> The second one generated code for a virtual machine.
> 
> I guess the question, then, is which version received certificate #1?
> 
It was the full SETL version. I don't argue that it was interpreted. I 
just mean that a "compiler" is any tool that processes a programming 
language (which term would you use instead?).

The difference between HW code generation or "interpretation" is a very 
thin implementation detail. As mentionned before, is P-Code 
interpretation? What if P-Code is cast in hardware? And isn't a "true" 
processor something that interprets its own code with micro-instructions?

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GC in Ada

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
>>
> It was the full SETL version. I don't argue that it was interpreted. I 
> just mean that a "compiler" is any tool that processes a programming 
> language (which term would you use instead?).

That's a pretty broad definition. It covers pretty printers and 
AdaSubst, for example.

I don't have a term for any tool that processes a programming language.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: GC in Ada

[Dmitry A. Kazakov]

On Wed, 07 Feb 2007 12:53:27 +0100, Martin Krischik wrote:

> On my Weblogic course I could not stop shaking my head about all the 
> problems which brings the "all is pointer" concept of Java.

Which is the same sort of rubbish as "all is object."

Clearly it is impossible to have all types referents. I don't mean here
small fundamental types like Boolean etc, but the pointers themselves. To
incorporate then one needs to introduce pointers-to-pointers, then
pointers-to-pointers-to-pointers ad infinitum, which is impossible. The
"concept" leaks. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GC in Ada

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

>> On my Weblogic course I could not stop shaking my head about all the 
>> problems which brings the "all is pointer" concept of Java.
> 
> Which is the same sort of rubbish as "all is object."
> 
> Clearly it is impossible to have all types referents. I don't mean here
> small fundamental types like Boolean etc, but the pointers themselves. To
> incorporate then one needs to introduce pointers-to-pointers, then
> pointers-to-pointers-to-pointers ad infinitum, which is impossible. The
> "concept" leaks. 

Not only it leaks, but combined with other defficiencies often leads to 
"consciusness split".

Consider: int, Integer, IntHolder.
That gives three types for the same logical domain.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Martin Krischik]

Dmitry A. Kazakov schrieb:
> On Wed, 07 Feb 2007 12:53:27 +0100, Martin Krischik wrote:
> 
>> On my Weblogic course I could not stop shaking my head about all the 
>> problems which brings the "all is pointer" concept of Java.
> 
> Which is the same sort of rubbish as "all is object."
> 
> Clearly it is impossible to have all types referents. I don't mean here
> small fundamental types like Boolean etc, but the pointers themselves. To
> incorporate then one needs to introduce pointers-to-pointers, then
> pointers-to-pointers-to-pointers ad infinitum, which is impossible. The
> "concept" leaks. 

Well, really it is "all objects and arrays handled by reference". But 
still a silly concept.

Martin

Re: GC in Ada

[Dmitry A. Kazakov]

On Fri, 09 Feb 2007 11:07:44 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov schrieb:
>> On Wed, 07 Feb 2007 12:53:27 +0100, Martin Krischik wrote:
>> 
>>> On my Weblogic course I could not stop shaking my head about all the 
>>> problems which brings the "all is pointer" concept of Java.
>> 
>> Which is the same sort of rubbish as "all is object."
>> 
>> Clearly it is impossible to have all types referents. I don't mean here
>> small fundamental types like Boolean etc, but the pointers themselves. To
>> incorporate then one needs to introduce pointers-to-pointers, then
>> pointers-to-pointers-to-pointers ad infinitum, which is impossible. The
>> "concept" leaks. 
> 
> Well, really it is "all objects and arrays handled by reference". But 
> still a silly concept.

But what is so special in Boolean which makes it non-object? Such
irregularities are always language design faults.

[ As for Ada there should be Boolean'Class. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GC in Ada

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Martin Krischik wrote:
>
>>> What I'm against is a GC "paradigm" that prevents me from having
>>> deterministic "good bye" hooks for scoped lifetime. The problem is
>>> that most GC-oriented languages I'm aware of do have this "issue".
>> But isn't that exactly what "Unchecked_Deallocation" and "pragma
>> Controlled" is all about? Has Ada - by your rationale - not got GC
>> right?
>
> By my rationale Ada and C++ got it perfectly right
> ([Limited_]Controlled mess aside).
>
> The only difference between them in this regard is that Ada explicitly
> allows GC on the low level without requiring it (so that
> implementations can ignore the whole idea) and that C++ is
> traditionally silent about the concept altogether (so that
> implementations can provide it). ;-)
>
> (Note that GC will likely be formalized in the upcoming C++ standard.)
>
> My criticism is targeted at those languages which bring GC to the top
> level obstructing the visible part of the object model.

You mean like Smalltalk -- a language which carries the label OO
wrongly, because it's GC obstructs the object model.

Hm.

Actually I think, real OO (as opposed to tagged types) need GC and
unbounded life time of objects. That's indeed all OO is about.

Regards -- Markus

Re: GC in Ada

[Maciej Sobczak]

Markus E Leypold wrote:

> Actually I think, real OO (as opposed to tagged types) need GC and
> unbounded life time of objects. That's indeed all OO is about.

That is quite novel definition of OO. Any references?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: GC in Ada

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:

>> Actually I think, real OO (as opposed to tagged types) need GC and
>> unbounded life time of objects. That's indeed all OO is about.

> That is quite novel definition of OO. Any references?

Ian Graham: "Object-Oriented Methods: Principles & Practice". 

Footnotes and general comments there make that quite clear I
think. (But I can't quote chapter and verse here, since I DON'T intend
to spent the rest of the morning with researching literature). I
remeber that this was not the first source which noted that a delete
operator is quite contrary to the spirit of stateful OOP (as opposed
to the functional OO models proposed by Abadi and others (Cardelli?).

And then of course there is me, myself, as a source :-). The reasoning
fo the assertion above is basically that OO is about having
(projected) views of a total system. In no view you can say that an
object leaves the view -- you can only say that it becomes unimportant
for the view (goes into the kernel of the projection). And that is so
for all views -- whose sum only gives the complete system. Then (when
viewing the whole system) you can decide where to delete. Object
deletion is a global property/function. Rooting it in any subsystem
will destroy modularity in the OO sense (which is different from
modularity in the modula2 or Ada-sense, which is derived from the
ideas of structured programming).

But note that I'm not really interested in discussing these
propositions. Either you profit from it or you don't -- I don't think
that it is easy to see what I mean and it was hard for me to get that
insights at the beginning (since there is really lots of bad
literature on OO (mostly the ad-hoc approach) and few usable formal or
semi-formal approaches). Discussing those on a serious level would take
lots of time. So I have just to assert my guru status here for lack of
more time :-).

Regards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Wed, 2007-02-07 at 09:55 +0100, Maciej Sobczak wrote:

> So the implementation details of *some* types leak out in the sense that 
> they force me to understand their internal mechanics. I don't want to.
> I want to say this:
> 
> declare
>      Sql : Session := Open_Session("some parameters");
>      Str : String := "Hello";
> begin
>      -- ...
> end;

Another data point: with JDBC, the recommendation is to leave database
cursor/statement handling to the implementation and have it finish for
you.
A notable exception to the rule is when the RDBMS is Oracle.
Then you have to:

> declare
>      Sql : Session := Open_Session("some parameters");
>      Str : String := "Hello";
> begin
>      -- ...
>      -- damn, I have to do *something* with *some* stuff here
> end;

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>>> Sure. But for the sake of discussion completeness, you might wish to
>>> throw an example of a situation where scoped lifetime will not make it.
>> Model-View-Controller in GUIs. Especially trying to adapt that to
>> GTKAda.
>
> I will not repeat Dmitry's arguments here.


Which was

 1) I am not sure what you mean,

and then

 2) "I'm now talking about reference counting". 

Which latter you might notice is a specialiced garbage collection
scheme and not objects with scoped lifetime. Seems to support my view.

>
>>> Java programmer wrote a loop where he opened database cursors,
> [...]
>
>> I'm not surprised. GC'ing ressources that are bounded doesn't spare
>> you knowing about the way GC works.
>
> Exactly. That's why I say that the solution is incomplete. If you have
> to think about the mechanics of some solution, then that solution is
> not entirely/properly automated.

I'd call that nonsense. Let me explain by analogy and then bury that
argument, since I obviously have another approach to that and we've
rehashed the respective arguments enough and seem not to be able to
agree.

Analogy: I don't think all the time about the way the compiler
generates code, but if I want to optimze, e.g. a loop, I have to think
about the mechanics of compilation. Certainly: A super-duper compiler
with artificial intelligence woul have seen right away the way I
optimze my loop now and would have it done qithout my interference
(actually many compilers today do quite a good job in this respect),
but that they didn't in the past didn't keep people from using
compilers and

I still experience using compilers AND using GC as tools as a vast
simplification of my work w/o many downsides. You can't deny _my_
experience but YMMV, And since you insist you cannot see my point or
do not want to use GC we're stuck :-).


>> You're approach "I want it all, and if
>> I can't have both (memory management AND general ressource collection)
>> I don't want neither" is somewhat counterproductive.
>
> I find it counterproductive to apply different management strategies
> with regard to *implementation details* of different types.

Unfortunately external ressource are no types in the type theoretic
sense, since they are not implemented in memory only. And whereas,
i.e. I produce and drop data with every function call, I find myself
opening and closing files or creating temporary file much less
often. So I profit vom GC as it is w/o feeling much of the mental pain
you seem to experience from the concept.

> I prefer solutions which enable me to hide implementation details from
> clients (sotware engineering?). If clients have to treat different

I fail to see how using no GC helps you in that, whereas using GC as
it is today hinders you.

> types differently just because their implementation details differ,
> then it means that these implementation details leak out in the form
> of distinct handling methods. I want to treat String and
> DatabaseCursor in the same way - that's the prerequisite for being
> productive for me.

If purity in any sense is your prerequisite for being productive, you
should take up Haskell.

>> But you might well continue to believe in your policy here.
>
> Thanks. :-)
>
>> I,
>> personally, find that it brings me a big step nearer to salvation if I
>> can have GC, even if I do only manual MM with it. After all: I don't
>> have this much other (external) ressources to care about and if I do,
>> it pays to have a careful look at their structure and then wrap some
>> abstraction around them.
>
> OK, I understand it. We just agree that GC is a valid solution for
> *some* class of computing problems.

For some really large class. I know, e.g. , it wouldn't solve the
halting problem.

> So why people claim that GC-oriented languages are general-purpose?

Because they can write all kinds of programs with them? I'm not trying
to sell a GC-oriented langauge to you. I'm convinced it fits many of
my problems at it does fro other people and I'm contend to leave the
rest to evolution of a sorts: If i'm wrong I'll meet sooner or later
"the unsolvable problem" whereas if you're wrong you'll never write
programs on a level of beauty and simplicity as I do.

Not that I'm a multi tool person of sorts. I've been developing
seriously in quite a number of languages, so I expect to be able to
fall back on the tool I think that is the best for the job at
hand. You, on the other side insist on excluding a tool because it
does not SEEM perfect to you (you never worked with a GC'ed language,
I gather?). Forgive me this word, but it _seems_ narrow minded to
me. But of course it's your decision.

>
>> But your approach is, since somebody had problems
>> misusing GC in a specific case
>
> No, that's not the point. The point is that languages which are build
> around GC tend to drop the proper support for other types of resources
> altogether. 

As if manual managment could be called proper support in this respect ...

> It's not the particular programmer who misused GC in a specific case
> - it's language designers who closed themselves in the GC cage and
> cranked a language that fails to provide good support for wider
> class of problems.

Big words, but given the choice between

 1) Manual ressource management
 2) GC with (according to you) imperfect support for other kinds of ressources
 3) The hypothetical system you propose should exist

I'll always prefer to go with (2) and bear the intellectual friction.

> As I've already said, the ideal would be to have both GC and scoped
> lifetime. The problem is that there is no reliable industry experience
> with such a mix, unless we treat Boehm's GC as one.

You know, the (functional) with_ressource wrappers have been around
for some time -- dating even back to Lisp -- and since Lisp has been
used quite extensively "in the industry" for some time, I'd say there
is reilable industry experience. You're just inventing problems where
none exist.

>
>> As far as the usability of GC goes, it even helps with controlled
>> objects
> [...]
>> I just make sure to close (e.g.) the filehandle and let the
>> rest to the GC.
>
> Of course. But then it's up to the designer of the type to decide how
> to treat each component of that type - it should be implementation
> detail. This decision should not be put on the shoulders of the final
> user, which is now the case in mainstream GC-oriented languages. This

"Treat each component of the type?" We're not talking about
components, but closing file handles, that is, switching over to
scoped ressource management in case where you know the automatic
collection won't be up to it, because your consumption will hit a
limit before the next collection is triggers and that there is no
trigger tied to this particular ressource limit.

> is what is broken.

And it will stay broken, since there are enough cases where we don't
want to trigger a major GC cylce every 64 file open()s only because
the programmer is dropping file descriptors on the floor in a
loop. Awareness to ressource restriction cannot be give up altogether
since the naive approach of first openeing 500 files and storing their
handles in an array seems also possible for a programmer who isn't
aware of the restriction -- and GC won't be able to fix that problem
anyway.

>
>>> There is nothing particular in scoped lifetime that would prohibit
>>> compacting heaps and there is nothing particular in GC that guarantees
>> No. But without having 3/4ths of a GC anyway compaction is pretty
>> pointless.
>
> Why? If the goal of compaction is to avoid fragmentation, then what is
> pointless in having compacted heaps managed by scoped lifetime?

Heap(s) -- I even resent the plural here -- are not about scoped but
about indeterminate lifetime. And a "compacted" heap has all the
unpredictability (in timing) as that of a garbage collector and would
provide garbage collection almost for free. 

So you want the downside -- perhaps loose real time capability (with
som algorithms) -- pay for it in moving memory object (makes the FFI
more complicated) and the you don't want to have the advantage of
freeing unused memory?

Strange...


>
>>> it. It's just the statistics based on popular implementations, not a
>>> rule.
>> Sorry, that is nonsense. There are garbage collectors that are
>> designed to be compacting.
>
> So what? This is exactly the statistics I'm talking about, that does

No no no no no.

> not prove that GC guarantees compacting or that the lack of GC
> prevents it.

2-space garbage collectors are compacting. Full stop.

Forgive me, I know you're only uninformed, but what youre spouting is
exactly the kind of FUD that has hindered the wide spread adoption of
GC into the main stream for years. People don't know how GC works,
don't know what it does, but they are somehow convinced that (a) it
disenfranchises them of the control of the computer, (b) cannot cope
with real time requiremens (as if they had any) and (c) is statistical
and unpredictable.

I'm sure I've forgotten some points on the list, but you get my
drift. FUD. And it's not even that you're selling a system w/o GC for
money.

>> They are moving objects around. This is
>> absolutely deterministic and not statistical.
>
> By statistics I mean the number of language implementations on the
> market that choose to use compacting GC vs. the number of languages
> that use non-compacting heaps. :-)

And that proves what?

>
>  > Whereas manual
>> allocation and deallocation as in Ada or C will fragment the heap and
>> you have NO guarantee (only statistics) about the ratio of allocated
>> (used) memory and presently unusable hole.
>
> If that bothers you, then use non-fragmenting allocators.


There are, as I can see, no non-fragmenting (heap) allocators for
unpredictable allocation patterns.

>> Hows that about
>> reliability if you can't give space guarantees even if you know about
>> the memory your algorithms need, since unfortunately you cannot
>> perdict the exact sequence of allocations?
>
> I use non-fragmenting allocator and I get my guarantees.

See above. Apart from the fact that there are no nonfragmenting
allocators being shipped with, e.g. Ada. So do it yourself. Wow: Avoid
compacting GC, get more work, do it by hand. You can see why that
doesn't attract me.

>>> I can perfectly imagine compacting heaps managed by scoped lifetime.
>> Yes you can do that. Since you're following pointers than and reqrite
>> them you might as well go the whole way and deollaocate unusable
>> memory while you're at it.
>
> Yes. Note that scoped lifetime does not preclude GC on some lower level.

You admit it, finally?

> Scoped lifetime provides a hook for deterministic "good bye" action -
> there is nothing more to it. Even if that "good bye" action calls
> free/delete/whatever on some memory block, there is nothing that
> forces the runtime to return the given block of memory right back to
> the operating system. Actually, none of the self-respecting allocators
> do this systematically - instead they keep the memory around for a
> while in anticipation of future allocations. I have nothing against GC
> at this level, really (and I've seen such implementations - in fact, a
> fully standard-compliant implementation of the C language could
> provide *empty* free function and GC underneath; and fully conformant
> C++ implementation could just call destructors as a result of delete
> and leave the raw memory to GC).

> What I'm against is a GC "paradigm" that prevents me from having
> deterministic "good bye" hooks for scoped lifetime. The problem is

There is no such GC paradigm. I wonder what we were talking about the
whole time.

> that most GC-oriented languages I'm aware of do have this "issue".
>
> In other words, for me GC is acceptable as an implementation detail of
> the dynamic memory allocator. I don't care *how* the allocator deals

Unfortunately GC is no implementation detail, since you see wether
there a free() or dispose() calls in the source.

> with memory that I free in the same sense that I don't care *how* the
> operating system deals with files that I remove from the
> filesystem. What I care about are hooks and scoped lifetime is an
> obvious answer for this.
>
>>>>  (3) What is often needed are upper limits not determinism and thos
>>>>      upper limits can be guaranteed with GC or with an appropriate
>>>>      collector.
>>
>>> This refers to memory consumption only, whereas I clearly stated
>>> deterministic *time* as a second (first, actually) goal.

>> This refers to both, there are real time compatible GC
>> algorithms.

> I'm interested in what is their target audience. I would expect any
> decent RT system to *refrain* from using dynamic memory except in the
> initialization phase (so that the "mission phase" is performed with
> constant set of objects), in which case RT GC would be just an answer
> to the question that nobody asked.

Yes, that is the old answer.

> Experts might wish to correct me and elaborate on this.

Ask Ray Blaake.

>>> OK. What about refcounting with smart pointers?
>> (1) It ties lifetime to multiple scopes (instead of one)
>
> With GC tracing pointers you have the same, just the tracing is hidden.

Yeah, but -- you had problems with that, you wanted true and pure
scoped lifetime, I don't. And if I don't want that I don't use smart
pointers as a hidden GC scheme: I just use GC and do away with
reference counting.

>
>> (2) its not
>> efficient
>
> Why?

See other posts in this thread. 

>> (3) It stille doesn't work for the general case
>
> Neither does GC, as seen in examples. :-)

Yes, but smart pointers where YOUR better answer to GC. You were
dissatisfied with GC. GC doesn't work for you, since it's not general
enough etc etc. Then you come up with smart pointers and ref counting
as an alternative -- which doesn't work either. Ooops. Why bother at
all, then?

>
>>> I acknowledge that there might be some applications which are strictly
>>> memory-oriented. They are just not the ones I usually write.
>> It also works for apps that are not "memory-oriented". I think you're
>> missing that e.g. filehandles are really simpler and differently
>> structured ressource from memory. A filehandle does not contain
>> references to memory or other filehandle. Memory does. That vastly
>> simplifies the problem of managing file handles indeed so much that
>> I'm convinced that you don't need buitlin support for this.

> Somehow this idea didn't work for database cursors, as already described.

Somehow ... you missed my point. It did work. File handles are in my view not
supposed to be handled by GC since they are structurally and
semantically different from memory. They should be closes explicitely.


>>> Sure. In other words, be prepared that with GC you have to
>>> handle/understand some parts of the sytem better.

>> So?

> So the implementation details of *some* types leak out in the sense
> that they force me to understand their internal mechanics. I don't
> want to.

No. You just need to stick to the rules. Close your ***** filehandles
manually. All the time.

If you want to be smart, though, it pays to think about the
interaction with underlying system (the implementation). Same as with
the loop optimization. And



> I want to say this:
>
> declare
>      Sql : Session := Open_Session("some parameters");
>      Str : String := "Hello";
> begin
>      -- ...
> end;
>
> instead of this:
>
> declare
>      Sql : Session := Open_Session("some parameters");
>      Str : String := "Hello";
> begin
>      -- ...
>      -- damn, I have to do *something* with *some* stuff here
> end;
>
> [about FP]


>>> The difference is that in languages with scoped lifetime the lifetime
>>> management is a property of the type (and so applies to all
>>> instances), whereas the "FP-trick" above is a property of the
>>> use-side. Which one is more robust and less prone to bugs?
>> This is, forgive me, nonsense. I might want to use a file handle in a
>> scoped way here and in a free floating way there.
>
> What about readability and maintainability of such code?

Nothing. It's OK. 

  with_file "foo" ( fun fd -> ... );;

or

  let blaba = ... 
  and fd    = file_open "..."
  in
    yadda ();
    blubb ();
    let oops = ... 
    in ...
       fileclose();
       oops             (* that's the return value for non ML programmers *)

So?

>
>> And no -- the FP way is not "more prone to bugs"
>

> Unless you use a handle in a free floating way and find later that in
> production your code was called in a loop causing handles to pile up?

I didn't do that, so I can't defend against it. Perhaps your friend
simply is not the Java software engineer he wants to be. I never did
have that problem ... -- so can I stop now defending my approach to
programming against errors other people have committed in another
language because they didn't read the JDBC reference manual?

> I have the practical example (already described) that this way of
> thinking can lead to failures.

If you think you never need to use a file handle in a scoped type, you
_can_ wrap it either in a with_file_do wrapper or into a scoped
type. But given e.g. the question how to build other primitives like
open_server_connection() from file handles I doubt it's a winning
situation to do that from the beginning.

And BTW: Excluding human error is only possible to certain extend. I
see Controlled and scoped life times only a tool to structure programs
in an understandable way but by no account as a way to enforce
programming _style_. Quality is better served by (a) reviews and (b)
coaching structures within larger teams. Both probably would have
caught your friends mistake.

That said, it probably would be a good idea to flag objects as
containing external resources with additional resource limits and
generate a compiler warning if the user doesn't deinitialize them
within the scope or doesn't return them.


> The programmer wanted to use a database
> cursor in a free floating way. That was fine. Later his code was used
> in a loop. 

Reusing code in another context without re-viewing it, was what cost
the ESA that famous Ariane 5 launch.

> Ah, yes - his code was used in a loop written by another
> programmer, so his judgement about whether it's OK to use anything in
> a free floating way was misguided from the very beginning.

Reviews, reviews, reviews. Understand what you use!

>> and as with
>> George Bauhaus I simply refuse this kind of discussion (FUD and
>> ContraFUD).
>
> OK. We will just stay unconvinced. :-)

:-) I think so. We just don't have a common basis to slug it out and
come to a rational decision. Not surprising, give that Ada and C++ are
still around AND the GCed languages are also living

>
>>> BTW - please show me an example involving 10 objects of different kinds. :-)
>> All at the same time?
>
> Yes.
>
>> Well -- bad programming.
>
> I knew you would answer this. :-)

let foozle a b c = with_thingy1 a (frobnicate b c);;

let foobar x y   = with_thingy2 y x (defrobnicate (foozle a b));;

... 


let do_it_now = with_thingy10 "/etc/passwd"
                   (bla "thing1" 12 13)
                   (baz "thing2" (troon "thing3 123 123) unfroth))
;;


I think you get the drift: It depends on the structure of the problem ...

Regards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Wed, 2007-02-07 at 11:56 +0100, Markus E Leypold wrote:
> Maciej Sobczak <no.spam@no.spam.com> writes:

> >> and as with
> >> George Bauhaus I simply refuse this kind of discussion (FUD and
> >> ContraFUD).
> >
> > OK. We will just stay unconvinced. :-)
> 
> :-) I think so. We just don't have a common basis to slug it out and
> come to a rational decision. Not surprising, give that Ada and C++ are
> still around AND the GCed languages are also living

My favorite Ada compiler produces GCing programs.


  -- Georg 

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

I will cut ad-persona ramblings and your suggestions about my 
competence, and try to restate major points.

>> I prefer solutions which enable me to hide implementation details from
>> clients (sotware engineering?). If clients have to treat different
> 
> I fail to see how using no GC helps you in that, whereas using GC as
> it is today hinders you.

You probably didn't read my previous posts in detail.
I claimed that mainstream GCed languages put so much faith in the GC 
concept that they drop scoped lifetime altogether. *This* hinders me 
from solving my problems in a uniform way.
I'm not happier with "no GC" and having GC is irrelevant to my problems.
What is relevant to my problems is scoped lifetime and this is missing 
from mainstream GCed languages. Got the point?

>> So why people claim that GC-oriented languages are general-purpose?
> 
> Because they can write all kinds of programs with them?

Assembly language has this property as well. Actually, computational 
completeness can be achieved with two instructions only, but I don't 
consider it as a valid argument for being general-purpose.

>> The point is that languages which are build
>> around GC tend to drop the proper support for other types of resources
>> altogether. 
> 
> As if manual managment could be called proper support in this respect ...

Then I will restate it again: the world is not partitioned between GC 
and manual management. As I've already pointed, you will not find manual 
management of anything in my regular code and since I'm also not using 
GC, then your view must be incomplete.

// warning: this is not Ada
{
     Session sql(oracle, "some-params");
     string name;
     sql << "select name from persons where id=7", into(name);
     cout << name << '\n';
}

Do you see *any* manual management of anything in the above? I stare at 
this code and I don't. Do you see GC here? I don't.
Then please stop building your arguments on the presumption that only 
these two options are possible.

Do you require from the user the understanding of implementation details 
of any of the above constructs? I don't.
We (software engineers) call it encapsulation.

> Big words, but given the choice between
> 
>  1) Manual ressource management
>  2) GC with (according to you) imperfect support for other kinds of ressources
>  3) The hypothetical system you propose should exist

The point is that you are not given only these choices.


> Heap(s) -- I even resent the plural here -- are not about scoped but
> about indeterminate lifetime. And a "compacted" heap has all the
> unpredictability (in timing) as that of a garbage collector and would
> provide garbage collection almost for free. 

Yes. My point is that compacting abilities are not restricted to GC.

> People don't know how GC works,
> don't know what it does

It does not matter. What does matter is that not having scoped lifetime 
doesn't work. If you want to sell GC without scoped lifetime, I won't 
buy it.

>>> Whereas manual
>>> allocation and deallocation as in Ada or C will fragment the heap and
>>> you have NO guarantee (only statistics) about the ratio of allocated
>>> (used) memory and presently unusable hole.
>> If that bothers you, then use non-fragmenting allocators.
> 
> There are, as I can see, no non-fragmenting (heap) allocators for
> unpredictable allocation patterns.

There are. Write on a piece of paper all the reasons that in conjunction 
lead to heap fragmentation and think how to get rid of at least one of 
them. That's actually easy.

> Apart from the fact that there are no nonfragmenting
> allocators being shipped with, e.g. Ada. So do it yourself. Wow: Avoid
> compacting GC, get more work, do it by hand. You can see why that
> doesn't attract me.

You see, the point is that in Ada or C++ I *can* and *know how* to 
improve anything I want based on the foundations that these languages 
give me (even if that means work), whereas in languages that have no 
support for scoped lifetime there is simply no foundation on which any 
improvements might be built on. Wow: Prevent people from achieving their 
goals, so they have less to do. You can see why that doesn't attract me.

>> Note that scoped lifetime does not preclude GC on some lower level.
> 
> You admit it, finally?

Admit what? Scoped lifetime does not preclude GC on some lower level. 
The lack of scoped lifetime sucks, no matter whether GC is provided or not.

> Unfortunately GC is no implementation detail, since you see wether
> there a free() or dispose() calls in the source.

You admit it, finally?

Then look again at the snipped I provided above. Do you see *any* free() 
or dispose() calls in the source? I don't. We call it encapsulation.

> Yes, but smart pointers where YOUR better answer to GC.

No. My answer is scoped lifetime. Look again at the snipped above, there 
are no smart pointers in sight.

Smart pointers are useful as a solution for resource management built on 
top of scoped lifetime in cases where the resource is not tied to a 
single scope. I use them, but *very* rarely.

> You were
> dissatisfied with GC.

I'm dissatified with languages that provide GC *instead of* scoped 
lifetime. The focus should be put on "addition", not "instead".

> File handles are in my view not
> supposed to be handled by GC since they are structurally and
> semantically different from memory. They should be closes explicitely.

Bingo. But do you explicitly operate on all file handles that your 
program manages? Then you must be using some extremeley low-level language.
Consider a class ConfigurationData (or whatever). Do you have to 
explicitly dispose of it? Hm... That depends on what ConfigurationData 
has *inside*. If it's bound to some file handle (say, using simple 
persistency scheme based on filesystem), then yes.
This means that your reasoning has to be transitively closed based on 
the relations between implementation details of all dependent entities.
Do you call it encapsulation?

Consider another complication. A team that is responsible for 
ConfigurationData ships the 1.0 version of the package with in-memory 
database as a backend. They specify the interface.
Some time later they ship 2.0 with files as backends. The specs didn't 
change (wow! that's what encapsulation is supposed to look like, no?), 
so according to software engineering practices you are not obliged to 
change anything in your code. Oops. Where's encapsulation?

> No. You just need to stick to the rules. Close your ***** filehandles
> manually. All the time.

Thank you for clearly describing this paradigm. No, I'm not convinced.

> If you want to be smart, though, it pays to think about the
> interaction with underlying system (the implementation).

I don't want to be smart. I want to be productive and have less bugs in 
my code. I noticed that scoped lifetime allows me to achieve this more 
effectively than without it.

> I didn't do that, so I can't defend against it. Perhaps your friend
> simply is not the Java software engineer he wants to be. I never did
> have that problem ... -- so can I stop now defending my approach to
> programming against errors other people have committed in another
> language because they didn't read the JDBC reference manual?

Should the user of ConfigurationData read the JDBC manual? Should he 
ever need to be aware that JDBC is used *somewhere there* deep in the 
bowels of ConfigurationData?

> Reusing code in another context without re-viewing it, was what cost
> the ESA that famous Ariane 5 launch.

Good point, but where's encapsulation here? What about decoupling 
implementation from specification?

> Reviews, reviews, reviews. Understand what you use!

Then maybe we should drop this decoupling altogether?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
> I will cut ad-persona ramblings and your suggestions about my
> competence, and try to restate major points.

I actually cannot find those "ad-persona ramblings" in my post. I can
only imagine that you mean any of those 2 things:

 (a) You repeated popular misconceptions on GC (only statistical, does
     not compact, etc) and I called that FUD.

 (b) I asserted, that "We just don't have a common basis to slug it out and
     come to a rational decision."

Both are not very ad-hominem (indeed they aren't, since it's not an
insult to not have a common basis with me -- I might be a total crank
after all).

But since we are slowly drifting now into that meta-level of "you're
not arguing right, I accuse you of misbehaviour" (and yes the
"ad-persona ramblings" annoys me somewhat), we can as well stop the
discussion here to prevent more damage.

After all: We just don't have a common basis to slug it out and this
is all totally OT in c.l.a. Finally I don't think that repetition will
help to make anything clearer any more.

Regards -- Markus

Re: How come Ada isn't more popular?

[Ray Blaak]

Maciej Sobczak <no.spam@no.spam.com> writes:
> OK. What about refcounting with smart pointers?

This form of GC actually works against your determinism goal. It simply is a
poor form of GC, can't handle cycles, and has unpredictable execution times.

A "real" GC smoothes out the collection costs.

But your main points of needing scoped-based resource control I indeed agree
with. My thing is convenience: sometimes that is simple wrappers with
destructors to cleanup after any possible scope exit, sometimes that is the
"WithResource" wrapper function pattern.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Tue, 06 Feb 2007 17:47:25 GMT, Ray Blaak wrote:

> Maciej Sobczak <no.spam@no.spam.com> writes:
>> OK. What about refcounting with smart pointers?
> 
> This form of GC actually works against your determinism goal. It simply is a
> poor form of GC, can't handle cycles, and has unpredictable execution times.

Determinism /= time bounded.

For handling cycles there are weak pointers.

> A "real" GC smoothes out the collection costs.

Yes, garbage men won't come when you throw the bag out of the doors. They
will come tomorrow, or the day after tomorrow, or maybe never. But they
will send you the bill anyway... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 06 Feb 2007 17:47:25 GMT, Ray Blaak wrote:
>
>> Maciej Sobczak <no.spam@no.spam.com> writes:
>>> OK. What about refcounting with smart pointers?
>> 
>> This form of GC actually works against your determinism goal. It simply is a
>> poor form of GC, can't handle cycles, and has unpredictable execution times.
>
> Determinism /= time bounded.
>
> For handling cycles there are weak pointers.

No. For handling cycles there are GC algorithms that can handle
cycles. Weak pointers are for implementing caching of costly (in terms
of memory) but recomuptable objects/structurs.

You're again talking from a parallel universe.

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

>>> OK. What about refcounting with smart pointers?
>> This form of GC actually works against your determinism goal. It simply is a
>> poor form of GC, can't handle cycles, and has unpredictable execution times.
> 
> Determinism /= time bounded.

Bingo.

> For handling cycles there are weak pointers.

Not only. If you have cycles, then you'd better rethink the design.
The difference is between a) graph treated as a mesh (or mess) of nodes 
which "own" each other and b) graph treated as a collection of nodes.
The former might have ownership cycles between nodes, but not the 
latter, where ownership is an acyclic relation between graph and nodes.

I agree that this kind of restructuring is not always possible, but for 
me it is conceptually cleaner and worth trying from the beginning.

>> A "real" GC smoothes out the collection costs.
> 
> Yes, garbage men won't come when you throw the bag out of the doors. They
> will come tomorrow, or the day after tomorrow, or maybe never. But they
> will send you the bill anyway... (:-))

:-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Dmitry A. Kazakov wrote:

>
>> For handling cycles there are weak pointers.
>
> Not only. 

Not at all you wanted to say.

> If you have cycles, then you'd better rethink the design.

let rec fac n = if n = 0 then 1 else n * (fac (n-1));;

a) closure
b) cycle

:-). 

A lot of OO models with callback also require cycles. E.g. A knows B
and B registers a callback with A in certain situations.

> The difference is between a) graph treated as a mesh (or mess) of
> nodes which "own" each other and b) graph treated as a collection of
> nodes.

> The former might have ownership cycles between nodes, but not the
> latter, where ownership is an acyclic relation between graph and nodes.

> I agree that this kind of restructuring is not always possible, but
                                            ^^^^^^^^^^^^^^^^^^^^^

!!.

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

>> If you have cycles, then you'd better rethink the design.

> A lot of OO models with callback also require cycles. E.g. A knows B
> and B registers a callback with A in certain situations.

That's not an ownership cycle.
I have no problems with callbacks. Interestingly, "a lot of OO models" 
(in particular those which depend on callbacks) don't even require 
dynamic allocation, so I don't see what this argument has to do with GC.

>> I agree that this kind of restructuring is not always possible, but
>                                             ^^^^^^^^^^^^^^^^^^^^^
> 
> !!.

??

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Wed, 07 Feb 2007 08:54:58 +0100, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>> For handling cycles there are weak pointers.
> 
> Not only. If you have cycles, then you'd better rethink the design.
> The difference is between a) graph treated as a mesh (or mess) of nodes 
> which "own" each other and b) graph treated as a collection of nodes.
> The former might have ownership cycles between nodes, but not the 
> latter, where ownership is an acyclic relation between graph and nodes.
> I agree that this kind of restructuring is not always possible, but for 
> me it is conceptually cleaner and worth trying from the beginning.

I would say that in all cases all references within it should be
non-controlled. The argumentation could go as follows:

A controlled reference (subject of GC) expresses the life-time relation
"not before me." [*] This relation is obviously transitive (due to nature
of time). Ergo, there cannot be any cycles, per definition.

From this stand point I would claim that a cycle of controlled references
manifests either a bug or a design problem. That a buggy program continues
to function as-if there were no bug, barely should be attributed as an
advantage of GC systems.

-----------------
*  One cannot say that the relation is "before or together with me,"
because nothing can happen simultaneous. Even if two [collection] actions A
and B could happen concurrently, then A and B were independent, thus there
could be no any time constraint between them. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

>>> For handling cycles there are weak pointers.
>> Not only. If you have cycles, then you'd better rethink the design.
>> The difference is between a) graph treated as a mesh (or mess) of nodes 
>> which "own" each other and b) graph treated as a collection of nodes.
>> The former might have ownership cycles between nodes, but not the 
>> latter, where ownership is an acyclic relation between graph and nodes.
>> I agree that this kind of restructuring is not always possible, but for 
>> me it is conceptually cleaner and worth trying from the beginning.
> 
> I would say that in all cases all references within it should be
> non-controlled. The argumentation could go as follows:
> 
> A controlled reference (subject of GC) expresses the life-time relation
> "not before me." [*] This relation is obviously transitive (due to nature
> of time). Ergo, there cannot be any cycles, per definition.
> 
> From this stand point I would claim that a cycle of controlled references
> manifests either a bug or a design problem. That a buggy program continues
> to function as-if there were no bug, barely should be attributed as an
> advantage of GC systems.

Amen!

Still, there is a strong argument is that for some class of algorithms 
it might be beneficial to be able to "drop on the floor" a bigger part 
of the graph altogether. Consider a situation where an algorithm breaks 
a connection between two nodes in a graph and just looses the interest 
in the part that was on the other side of the broken connecion. It might 
be a single node, but it might be as well million, with mesh (mess) of 
connections between them. Reclaiming that abandoned part might require 
implementing the same tracking logic that GC already provides out of the 
box and therefore the argument goes that the use of off-the-shelf GC can 
be beneficial for the memory-management aspect of such an algorithm. 
(Any thoughts on this?)

Personally, I accept this reasoning and I'm happy that I *can* plug for 
example the Boehm collector if I find it useful - but at the same time I 
don't find this class of algorithms to be so widespread as to justify GC 
as a general "paradigm", worth exposure as a driving language feature.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 09 Feb 2007 09:17:47 +0100, Maciej Sobczak wrote:

> Still, there is a strong argument is that for some class of algorithms 
> it might be beneficial to be able to "drop on the floor" a bigger part 
> of the graph altogether. Consider a situation where an algorithm breaks 
> a connection between two nodes in a graph and just looses the interest 
> in the part that was on the other side of the broken connecion. It might 
> be a single node, but it might be as well million, with mesh (mess) of 
> connections between them.

It is still broken, because when you remove a connection (non-directed)
between two nodes you don't know which of them should/may/can fall on the
floor. This information is locally missing. It could be deduced from some
transitive client-master/reference-target relation, but we have demolished
that relation just before by introducing cycles.

In essence, there are two graphs. G is the mesh-mess. R is the graph
induced by the reference-target relation. The problem is that these two
graphs are sufficiently different. R (=>GC) cannot work as a complete model
of G. It could, if it were a part of a larger model of G.

> Reclaiming that abandoned part might require 
> implementing the same tracking logic that GC already provides out of the 
> box and therefore the argument goes that the use of off-the-shelf GC can 
> be beneficial for the memory-management aspect of such an algorithm. 
> (Any thoughts on this?)
> 
> Personally, I accept this reasoning and I'm happy that I *can* plug for 
> example the Boehm collector if I find it useful - but at the same time I 
> don't find this class of algorithms to be so widespread as to justify GC 
> as a general "paradigm", worth exposure as a driving language feature.

I think that your initial point is perfectly valid here, GC is fine when it
is an implementation detail. GC as a "paradigm" could turn bad, because it
is too narrow to gasp all cases. Therefore any language which restricts
itself to GC is weakened per design. What is worse, it forces the
programmer to use inherently wrong abstractions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> It is still broken, because when you remove a connection (non-directed)
> between two nodes you don't know which of them should/may/can fall on the
> floor. This information is locally missing. It could be deduced from some
> transitive client-master/reference-target relation, but we have demolished
> that relation just before by introducing cycles.

Not really. You program according to a principle of locality of use. Some code
says "I no longer need this data", and lets go of it, without regard to
whether or not it is still in use somewhere else.

If every bit of code relinquishes its resources according to its local needs,
then the global effect via GC is that the resource is in fact properly
managed. The local effect is easier to prove and code to since at every local
step the "cleanup" work is much simpler in the presence of GC.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 09 Feb 2007 18:08:06 GMT, Ray Blaak wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> It is still broken, because when you remove a connection (non-directed)
>> between two nodes you don't know which of them should/may/can fall on the
>> floor. This information is locally missing. It could be deduced from some
>> transitive client-master/reference-target relation, but we have demolished
>> that relation just before by introducing cycles.
> 
> Not really. You program according to a principle of locality of use. Some code
> says "I no longer need this data", and lets go of it, without regard to
> whether or not it is still in use somewhere else.

The point is that "I don't need the node A here" /= "There is no link
between A and B."

> If every bit of code relinquishes its resources according to its local needs,
> then the global effect via GC is that the resource is in fact properly
> managed. The local effect is easier to prove and code to since at every local
> step the "cleanup" work is much simpler in the presence of GC.

No, it just does not follow. In question is very model of graph nodes as
"resources," because of the inequality above.

You are making a jump from resource management to program correctness. An
analogous statement would be: "every computation is correct because the CPU
does not make errors while summing numbers."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Fri, 09 Feb 2007 18:08:06 GMT, Ray Blaak wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> >> It is still broken, because when you remove a connection (non-directed)
> >> between two nodes you don't know which of them should/may/can fall on the
> >> floor. This information is locally missing. It could be deduced from some
> >> transitive client-master/reference-target relation, but we have demolished
> >> that relation just before by introducing cycles.
> > 
> > Not really. You program according to a principle of locality of use. Some code
> > says "I no longer need this data", and lets go of it, without regard to
> > whether or not it is still in use somewhere else.
> 
> The point is that "I don't need the node A here" /= "There is no link
> between A and B."

In practice it doesn't matter. A can easily "know" it is not using B. That B is
still using A is not an issue, at least in terms of memory management.

> You are making a jump from resource management to program correctness. An
> analogous statement would be: "every computation is correct because the CPU
> does not make errors while summing numbers."

I am not talking "program" correctness, only "resource" correctness.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[Ray Blaak]

Maciej Sobczak <no.spam@no.spam.com> writes:
> Still, there is a strong argument is that for some class of algorithms it
> might be beneficial to be able to "drop on the floor" a bigger part of the
> graph altogether. [...] Reclaiming that abandoned part might require
> implementing the same tracking logic that GC already provides out of the box
> and therefore the argument goes that the use of off-the-shelf GC can be
> beneficial for the memory-management aspect of such an algorithm. (Any
> thoughts on this?)

My thoughts: not "might", but "definitely". Also, the advantage is not
restricted to some class of algorithms -- it is in fact the common case.

You don't need a complex mesh for this kind of advantage to kick in, even
regular tree cleanup is greatly simplified: just let go of the subbranch you
no longer need, and avoid that whole cleanup traversal.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

RE: How come Ada isn't more popular?

[Randy Brukardt]

> Maciej Sobczak <no.spam@no.spam.com> writes:
> > Still, there is a strong argument is that for some class of algorithms
it
> > might be beneficial to be able to "drop on the floor" a bigger part of
the
> > graph altogether. [...] Reclaiming that abandoned part might require
> > implementing the same tracking logic that GC already provides out of the
box
> > and therefore the argument goes that the use of off-the-shelf GC can be
> > beneficial for the memory-management aspect of such an algorithm. (Any
> > thoughts on this?)
>
> My thoughts: not "might", but "definitely". Also, the advantage is not
> restricted to some class of algorithms -- it is in fact the common case.

YMMV, of course, but it's not my experience. It's rare to destroy only part
of a data structure; it's usually the entire structure that needs to be
discarded.

> You don't need a complex mesh for this kind of advantage to kick in, even
> regular tree cleanup is greatly simplified: just let go of the
> subbranch you no longer need, and avoid that whole cleanup traversal.

I'm primarily interested in destroying the entire structure, and often I
need no destruction at all: the structures exist until the termination of
the program. There's no point of earlier cleanup in such programs, and
surely no point in non-zero overhead to support such cleanup. I'm not aware
of any zero-overhead GC algorithm, because the basic tenet of GC is that you
can find all reachable objects: doing that requires some time and/or space
overhead.

                       Randy.

Re: How come Ada isn't more popular?

[Ray Blaak]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I'm primarily interested in destroying the entire structure, and often I
> need no destruction at all: the structures exist until the termination of
> the program. There's no point of earlier cleanup in such programs, and
> surely no point in non-zero overhead to support such cleanup. I'm not aware
> of any zero-overhead GC algorithm, because the basic tenet of GC is that you
> can find all reachable objects: doing that requires some time and/or space
> overhead.

I don't think anyone anywhere claims zero-overhead for GC. The whole point is
reasonable performance (in fact competitive with manual management) and a much
easier job for the programmer, in situations with highly dynamic memory usage
patterns.

At any rate, one uses the tools that fit their needs. If you find yourself in
situations with stable data structures, then it sounds like you don't need GC,
plain and simple, or maybe even any cleanup at all.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

RE: How come Ada isn't more popular?

[Randy Brukardt]

Ray Blaak writes:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> > I'm primarily interested in destroying the entire structure, and often I
> > need no destruction at all: the structures exist until the termination
of
> > the program. There's no point of earlier cleanup in such programs, and
> > surely no point in non-zero overhead to support such cleanup. I'm not
aware
> > of any zero-overhead GC algorithm, because the basic tenet of GC is that
you
> > can find all reachable objects: doing that requires some time and/or
space
> > overhead.
>
> I don't think anyone anywhere claims zero-overhead for GC. The whole point
is
> reasonable performance (in fact competitive with manual management) and a
much
> easier job for the programmer, in situations with highly dynamic
> memory usage patterns.

That's the crux of the disagrement, I think. You claim that "highly dynamic
memory usage" is the normal case; I think it is *not* the usual case (or, at
least, doesn't have to be the usual case - languages like Java make it that
unnecessarily).

> At any rate, one uses the tools that fit their needs. If you find yourself
in
> situations with stable data structures, then it sounds like you don't need
GC,
> plain and simple, or maybe even any cleanup at all.

Right, but then why should it be a required and central part of general
purpose programming languages. Surely, it should be available as an option
for types that need it, but it certainly should not apply to all types.

My programs tend to be plenty dynamic after all, but the dynamic is in the
construction of the data structures. Destruction of them is unusual, and
usually happens in a single operation (not piecemeal). And locals and
temporaries are on the stack - no action at all is required to destroy them
(you keep refering to this as "manual management", but there is nothing
manual about it -- the compiler does all of the work).

                               Randy.

Re: How come Ada isn't more popular?

[Ray Blaak]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> > At any rate, one uses the tools that fit their needs. If you find yourself
> > in situations with stable data structures, then it sounds like you don't
> > need GC, plain and simple, or maybe even any cleanup at all.
> 
> Right, but then why should it be a required and central part of general
> purpose programming languages. Surely, it should be available as an option
> for types that need it, but it certainly should not apply to all types.

GC should be a required and central part of general purpose language because
it saves the programmer so much time and effort, and does a better job at
memory cleanup, which means less bugs.

A simple way out of the problem is to have a language that readily provides
the options to do things either way.

The religious argument then boils down to whether it should be on by default
or not.

Or even better, one can have a language where one has GC for heap based
values, while still providing scope based constructs.

> And locals and temporaries are on the stack - no action at all is required
> to destroy them (you keep refering to this as "manual management", but there
> is nothing manual about it -- the compiler does all of the work).

I must clarify this. I fully understand how stack values work. I have used
them in Ada and in C++ after all.

What I refer to as manual management is for heap values, such that that for
every "new" one must remember eventually to call "deallocate".

When I refer to locals and memory management, I am talking about the
allocation of linked data structures assigned to local *pointers* and the need
to cleanup those pointers before returning.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[Harald Korneliussen]

On 9 Feb, 20:52, Ray Blaak <rAYbl...@STRIPCAPStelus.net> wrote:
> "Randy Brukardt" <r...@rrsoftware.com> writes:
> What I refer to as manual management is for heap values, such that that for
> every "new" one must remember eventually to call "deallocate".
>
And I think it should be an easy choice that _if_ you need such values
at all (never mind that the ati-GC folks claim that they hardly ever
need them, or that they are design faults - as if design not
structured around memory management was somehow sinful), then they
should be garbage collected. Relying on Unchecked_deallocation is
against the spirit of Ada, as it (re)introduces almost all the manual
memory management issues that make C/C++ such a pain.

As for the complaints that garbage collectors aren't general purpose
enough, I'm reminded of Babbage's (allegorical) lament when the
British government cut funding for the analytical engine: "Propose to
an Englishman any principle, or any instrument, however admirable, and
you will observe that the whole effort of the English mind is directed
to find a difficulty, a defect, or an impossibility in it. If you
speak to him of a machine for peeling a potato, he will pronounce it
impossible: if you peel a potato with it before his eyes, he will
declare it useless, because it will not slice a pineapple."
I've yet to see an explanation why higher-order wrappers for these
resources don't do the job well enough. You write a function F that
takes a filename and a function argument telling what to do with it. F
then opens the file, does its thing, and closes the file. In scheme
this is readily avaliable as the call-with-input-file / call-with-
output-file, in Haskell it's trivially done with the more general
bracket function.

Re: How come Ada isn't more popular?

[Robert A Duff]

"Harald Korneliussen" <vintermann@gmail.com> writes:

> As for the complaints that garbage collectors aren't general purpose
> enough, I'm reminded of Babbage's (allegorical) lament when the
> British government cut funding for the analytical engine: "Propose to
> an Englishman any principle, or any instrument, however admirable, and
> you will observe that the whole effort of the English mind is directed
> to find a difficulty, a defect, or an impossibility in it. If you
> speak to him of a machine for peeling a potato, he will pronounce it
> impossible: if you peel a potato with it before his eyes, he will
> declare it useless, because it will not slice a pineapple."

I like that quote!  Thank you!

GC is for managing memory, and it can work well in many situations.
It is indeed rather silly to complain that GC is no good because it
doesn't manage other resources very well.

On the other hand, it is a common occurrence in our industry that
somebody invents a good potato peeler, and then wants to throw out every
other tool, and use potato peelers for everything.  After all, "new"
means "improved", right?  ;-)

Java, Lisp, Smalltalk, etc do this with GC.  That is, once we have GC
available, we might was well allocate (almost) everything in the heap.
That makes GC less efficient (in cases where static or stack allocation
would work).  It leads to making everything aliased, which causes bugs
(except in a pure functional context -- i.e. none of the three languages
mentioned above).  And it leads to Java's completely broken notion of
finalization, which is just asking for race conditions.

Anyway, I claim that there is no single memory-management strategy that
is suitable in all situations.  We have GC (moving, nonmoving,
generational, incremental, ...), manual new/free, manual mark/release,
reference counting (deferred, nondeferred, ...), region-based (manual,
region inference), stack allocation, static allocation, etc.  You show
me a memory-management strategy, and I can show you a program that will
make that strategy look bad.  ;-)

> I've yet to see an explanation why higher-order wrappers for these
> resources don't do the job well enough.

I agree -- that technique can work just fine in many cases.
It would be a lot more tolerable in Ada if we had anonymous
functions (like "lambda" in Lisp).

- Bob

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Ray Blaak writes:
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> > I'm primarily interested in destroying the entire structure, and often I
>> > need no destruction at all: the structures exist until the termination
> of
>> > the program. There's no point of earlier cleanup in such programs, and
>> > surely no point in non-zero overhead to support such cleanup. I'm not
> aware
>> > of any zero-overhead GC algorithm, because the basic tenet of GC is that
> you
>> > can find all reachable objects: doing that requires some time and/or
> space
>> > overhead.
>>
>> I don't think anyone anywhere claims zero-overhead for GC. The whole point
> is
>> reasonable performance (in fact competitive with manual management) and a
> much
>> easier job for the programmer, in situations with highly dynamic
>> memory usage patterns.
>

> That's the crux of the disagrement, I think. 

Yes indeed.

> You claim that "highly dynamic memory usage" is the normal case; I

So do I: Therefore my initial suggestion that list processing and
support to do so efficiently matters for languages that want to play
in the arena of application programming.

> think it is *not* the usual case (or, at least, doesn't have to be
> the usual case - languages like Java make it that unnecessarily).


>> At any rate, one uses the tools that fit their needs. If you find yourself
> in
>> situations with stable data structures, then it sounds like you don't need
> GC,
>> plain and simple, or maybe even any cleanup at all.
>


> Right, but then why should it be a required and central part of general
> purpose programming languages. 

There I disagree, but we know that.

> Surely, it should be available as an option
> for types that need it, but it certainly should not apply to all types.
>
> My programs tend to be plenty dynamic after all, but the dynamic is in the
> construction of the data structures. Destruction of them is unusual, and
> usually happens in a single operation (not piecemeal). And locals and
> temporaries are on the stack - no action at all is required to destroy them
> (you keep refering to this as "manual management", but there is nothing
> manual about it -- the compiler does all of the work).
>
>                                Randy.

I think we should find an application case (example), but we'd
probably not agree wether it is typical. May I suggest XML processing?


Regards -- Markus

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>> Maciej Sobczak <no.spam@no.spam.com> writes:
>> > Still, there is a strong argument is that for some class of algorithms
> it
>> > might be beneficial to be able to "drop on the floor" a bigger part of
> the
>> > graph altogether. [...] Reclaiming that abandoned part might require
>> > implementing the same tracking logic that GC already provides out of the
> box
>> > and therefore the argument goes that the use of off-the-shelf GC can be
>> > beneficial for the memory-management aspect of such an algorithm. (Any
>> > thoughts on this?)
>>
>> My thoughts: not "might", but "definitely". Also, the advantage is not
>> restricted to some class of algorithms -- it is in fact the common case.
>
> YMMV, of course, but it's not my experience. It's rare to destroy only part
> of a data structure; it's usually the entire structure that needs to be
> discarded.

"it's usually the entire structure" => In a world without
representation sharing. In one with representation sharing (and that
makes the production of new trees from existing ones really
efficient), one would have to traverse the whole subtree any time a
tree referencing this subtree is deleted - if only to adjust the
reference counters. In a world with GC you just overwrite one
reference to some subtree. When the GC hits it just traverses the tree
once (and then perhaps decides which parts to deallocate). Dependend
on the application domain (e.g. if you produce and drop many shared
representions between GC cycles) that might be much more efficient.


>> You don't need a complex mesh for this kind of advantage to kick in, even
>> regular tree cleanup is greatly simplified: just let go of the
>> subbranch you no longer need, and avoid that whole cleanup traversal.
>
> I'm primarily interested in destroying the entire structure, and often I
> need no destruction at all: the structures exist until the termination of
> the program. 

This certainly is a special case? E.g a chess playing program (any
playing program) would have to create and destroy game trees at a
pretty good rate.

> There's no point of earlier cleanup in such programs, and
> surely no point in non-zero overhead to support such cleanup. I'm not aware
> of any zero-overhead GC algorithm, because the basic tenet of GC is that you
> can find all reachable objects: doing that requires some time and/or space
> overhead.

I can imagine to allocate some memory in a special, non garabage
collected heap. Furthermore generational garbage collection AFAIK has
the property to touch old objects seldom -- so there is not so much
cost (as it might seem at first glance) for keeping large structures
around unchanged. And if the program is short running you could also
increase the garbage collection threshold(s), so that the collection
never sets in.

Regards -- Markus

RE: How come Ada isn't more popular?

[Randy Brukardt]

Markus E Leypold writes:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> >> Maciej Sobczak <no.spam@no.spam.com> writes:
> >> > Still, there is a strong argument is that for some class of
algorithms it
> >> > might be beneficial to be able to "drop on the floor" a bigger part
of the
> >> > graph altogether. [...] Reclaiming that abandoned part might require
> >> > implementing the same tracking logic that GC already provides out of
the box
> >> > and therefore the argument goes that the use of off-the-shelf GC can
be
> >> > beneficial for the memory-management aspect of such an algorithm.
(Any
> >> > thoughts on this?)
> >>
> >> My thoughts: not "might", but "definitely". Also, the advantage is not
> >> restricted to some class of algorithms -- it is in fact the common
case.
> >
> > YMMV, of course, but it's not my experience. It's rare to destroy only
part
> > of a data structure; it's usually the entire structure that needs to be
> > discarded.
>
> "it's usually the entire structure" => In a world without
> representation sharing. In one with representation sharing (and that
> makes the production of new trees from existing ones really
> efficient), one would have to traverse the whole subtree any time a
> tree referencing this subtree is deleted - if only to adjust the
> reference counters. In a world with GC you just overwrite one
> reference to some subtree. When the GC hits it just traverses the tree
> once (and then perhaps decides which parts to deallocate). Dependend
> on the application domain (e.g. if you produce and drop many shared
> representions between GC cycles) that might be much more efficient.

In an imperative language like Ada (and this *is* the Ada newsgroup!),
representation sharing has to be done completely behind an abstraction that
presents the appearance of deep copying (that is, no sharing). Anything else
is a receipe for bugs, as modifications occuring to one tree that magically
appear in another (supposedly independent) cannot be tolarated. The net
effect is it can be used only in limited ways.

That's not horrible, since one of the goals of Ada is to provide the ability
(not the requirement, remember) to get the performance level of the machine.
For that to be possible, you cannot have distributed overhead (that is,
overhead from features that you don't use).

Deep copying of trees has unacceptable overhead, as you note. But GC has a
non-zero overhead on every reference in the program. That too can be an
unacceptable overhead - thus it cannot be mandated on all types.

> >> You don't need a complex mesh for this kind of advantage to kick in,
even
> >> regular tree cleanup is greatly simplified: just let go of the
> >> subbranch you no longer need, and avoid that whole cleanup traversal.
> >
> > I'm primarily interested in destroying the entire structure, and often I
> > need no destruction at all: the structures exist until the termination
of
> > the program.
>
> This certainly is a special case? E.g a chess playing program (any
> playing program) would have to create and destroy game trees at a
> pretty good rate.

I doubt that very much, at least one that is trying to maximize the
"thinking". This is a very performance dependent application, and "creating"
and "destroying" much of anything is likely to be overhead that you can't
afford.

I haven't written a Chess playing program, but I have written Freecell and
Solitare solvers (and, in the more distant past, programs for playing
Othello and a couple of other games). I'm pretty sure I've never created or
destroyed any trees. The Freecell solver is based on queues of pending moves
to try. The queues are implemented mainly with lists of arrays; the queue
blocks are never destroyed and new ones are allocated only if there are no
unused ones to use. Moves in the queues are ordered by heuristics so the
most likely ones that lead to a solution are tried first. Positions are
stored (compressed) in a large hash table in which each bucket is a pointer
to an array which is allocated from a custom storage pool that directly uses
Windows memory management (and supports expansion with a special call). It
can solve most initial positions in under a minute on a 500 MHZ machine with
256Meg memory (harder ones take longer, possibly much longer).

> > There's no point of earlier cleanup in such programs, and
> > surely no point in non-zero overhead to support such cleanup. I'm not
aware
> > of any zero-overhead GC algorithm, because the basic tenet of GC is that
you
> > can find all reachable objects: doing that requires some time and/or
space
> > overhead.
>
> I can imagine to allocate some memory in a special, non garabage
> collected heap. Furthermore generational garbage collection AFAIK has
> the property to touch old objects seldom -- so there is not so much
> cost (as it might seem at first glance) for keeping large structures
> around unchanged. And if the program is short running you could also
> increase the garbage collection threshold(s), so that the collection
> never sets in.

The overhead of GC that I'm worrying about here is not that of the collector
itself (which is trivial in this case because nothing will need to be
collected), but rather the part that is usually hand-waved in GC papers:
determining what is actually reachable. This is a non-trivial exercise which
requires time and space overhead for every reference - whether or not it
will ever be possible to collect anything.

As Ray said, you could argue whether or not GC should be the default. It's
not an argument for Ada -- it isn't the default, and would never be the
default simply because making existing programs run slower is not an option
in all but the most serious cases. I could see a predefined GC storage pool
being added to the language, or something like that. But the language would
need other fixes to really allow GC (although I doubt anyone will stop you
from implementing a GC in Ada, it's likely to be wrong in some subtle - some
would say pathological - cases).

                         Randy.

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Markus E Leypold writes:
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> >> Maciej Sobczak <no.spam@no.spam.com> writes:
>> >> > Still, there is a strong argument is that for some class of
> algorithms it
>> >> > might be beneficial to be able to "drop on the floor" a bigger part
> of the
>> >> > graph altogether. [...] Reclaiming that abandoned part might require
>> >> > implementing the same tracking logic that GC already provides out of
> the box
>> >> > and therefore the argument goes that the use of off-the-shelf GC can
> be
>> >> > beneficial for the memory-management aspect of such an algorithm.
> (Any
>> >> > thoughts on this?)
>> >>
>> >> My thoughts: not "might", but "definitely". Also, the advantage is not
>> >> restricted to some class of algorithms -- it is in fact the common
> case.
>> >
>> > YMMV, of course, but it's not my experience. It's rare to destroy only
> part
>> > of a data structure; it's usually the entire structure that needs to be
>> > discarded.
>>
>> "it's usually the entire structure" => In a world without
>> representation sharing. In one with representation sharing (and that
>> makes the production of new trees from existing ones really
>> efficient), one would have to traverse the whole subtree any time a
>> tree referencing this subtree is deleted - if only to adjust the
>> reference counters. In a world with GC you just overwrite one
>> reference to some subtree. When the GC hits it just traverses the tree
>> once (and then perhaps decides which parts to deallocate). Dependend
>> on the application domain (e.g. if you produce and drop many shared
>> representions between GC cycles) that might be much more efficient.
>
> In an imperative language like Ada (and this *is* the Ada newsgroup!),

Yes, yes. But I *had* the impression that we're now talking about
languages in general and general purpose languages. We've come to that
point from the discussion what distinguishes other contenders from
Ada, which in turn came from the question "Why isn't Ada more
popular?". Now we are discussing the up and downs of GC and those
opposed on GV discuss the problems on general ground -- I wonder why I
should now discuss the merits only on the grounds of how that would
fit into Ada :-).

> representation sharing has to be done completely behind an abstraction that
> presents the appearance of deep copying (that is, no sharing). 

Right. I've been talking about the implementation of this sharing, how
using representation sharing with reference counting compares with
using it in a GC'ed system.

I hope I've expressed myself clearly there, since I hate to be
criticized for errors I didn't make.

So the following doesn't apply to what I said ...

  > Anything else is a receipe for bugs, as modifications occuring to
  > one tree that magically appear in another (supposedly independent)
  > cannot be tolarated. The net effect is it can be used only in
  > limited ways.


  > That's not horrible, since one of the goals of Ada is to provide the ability
  > (not the requirement, remember) to get the performance level of the machine.
  > For that to be possible, you cannot have distributed overhead (that is,
  > overhead from features that you don't use).

> Deep copying of trees has unacceptable overhead, as you note. But GC has a

I did not talk about deep copying. Yes, it's unacceptable, but that
was taken as a given, I didn't discuss it. The problem I have been
talking about was the necessity of maintaining reference counters, but
I was wrong concerning the traversal (its not necessary, I've not been
paying attention, but after all that is not what you're criticizing
... :-) Still, AFAIK ref counting is less efficient than other GC
algorithms, but I'd like to point out, that ref counting is
essentially a specialized GC.

> non-zero overhead on every reference in the program. 

That is true. I suggested, though, that in generational GC the
overhead is not as large as it seems at first (long living structures
are less frequently traversed) and it would be possible to specially
allocate such structures outside the heap (my approach is somewhat
inverted from yours or Maciej's: I'd have GC as the default and scope
bound or manually managed memory allocated outside the GC'ed heap.

> That too can be an unacceptable overhead - thus it cannot be
> mandated on all types.

The limits, where "unacceptable" begins, vary. I doubt that many that
discuss GC as having way too much overhead actually have these
requirement.


>
>> >> You don't need a complex mesh for this kind of advantage to kick in,
> even
>> >> regular tree cleanup is greatly simplified: just let go of the
>> >> subbranch you no longer need, and avoid that whole cleanup traversal.
>> >
>> > I'm primarily interested in destroying the entire structure, and often I
>> > need no destruction at all: the structures exist until the termination
> of
>> > the program.
>>
>> This certainly is a special case? E.g a chess playing program (any
>> playing program) would have to create and destroy game trees at a
>> pretty good rate.

> I doubt that very much, at least one that is trying to maximize the
> "thinking". This is a very performance dependent application, and "creating"
> and "destroying" much of anything is likely to be overhead that you can't
> afford.


I think you're wrong, but I'm also sure other examples can be
found. Your position basically boils down to: Memory needs hardly ever
be deallocated and you can always leave it to the operating system to
destroy non-scoped memory. I don't think this position is really
tenable in general, but I don't see an approach to decide it
(here). All we can do, is to insist that our respective experience
suggests it.

> I haven't written a Chess playing program, but I have written Freecell and
> Solitare solvers (and, in the more distant past, programs for playing
> Othello and a couple of other games). I'm pretty sure I've never created or
> destroyed any trees.

Good. I do think this is a bit different from chess (the tree of
positions is actually the call tree of functions, which means,
positions in the future have to be recreated at every draw. I just
suspect that is not what one wants when playing chess or GO) -- but I
don't want to open up another avenue of discussion.


> The Freecell solver is based on queues of pending moves
> to try. The queues are implemented mainly with lists of arrays; the queue
> blocks are never destroyed and new ones are allocated only if there are no
> unused ones to use. Moves in the queues are ordered by heuristics so the
> most likely ones that lead to a solution are tried first. Positions are
> stored (compressed) in a large hash table in which each bucket is a pointer
> to an array which is allocated from a custom storage pool that directly uses
> Windows memory management (and supports expansion with a special call). It
> can solve most initial positions in under a minute on a 500 MHZ machine with
> 256Meg memory (harder ones take longer, possibly much longer).
>
>> > There's no point of earlier cleanup in such programs, and
>> > surely no point in non-zero overhead to support such cleanup. I'm not
> aware
>> > of any zero-overhead GC algorithm, because the basic tenet of GC is that
> you
>> > can find all reachable objects: doing that requires some time and/or
> space
>> > overhead.
>>
>> I can imagine to allocate some memory in a special, non garabage
>> collected heap. Furthermore generational garbage collection AFAIK has
>> the property to touch old objects seldom -- so there is not so much
>> cost (as it might seem at first glance) for keeping large structures
>> around unchanged. And if the program is short running you could also
>> increase the garbage collection threshold(s), so that the collection
>> never sets in.

> The overhead of GC that I'm worrying about here is not that of the collector
> itself (which is trivial in this case because nothing will need to be
> collected), but rather the part that is usually hand-waved in GC papers:
> determining what is actually reachable. 

I'm talking about exactly this: The process of determining what is
reachable. This involves traversing heap allocated memory and the
effort is (roughly) proportional to the allocated memory in the
heap. If there is no memory in the heap (no allocated blocks), there
is no overhead for traversal. So moving your large static structures
from GC'ed heap

> This is a non-trivial exercise which requires time and space
> overhead for every reference - whether or not it will ever be
> possible to collect anything.

I _do_ think that this concern for overhead in most cases is a case of
premature optimization. As I already noted in this thread: 

For all the increase in processing power we have seen in the last
decades I once would like to buy myself the convenient luxury of using
GC because it's easier on the developer (candy for developers). For
once I don't want to see that processing power go into useless
blinking and flickering of smooth GUIs (candy for users). After all
the users (indirectly) pay the development time and it's their money
that is being saved if the developers spent less time with getting the
memory manangement right.

BTW: Hoe large is the overhead really? Performance of OCaml compared
with C++/C compiled by Gcc suggest a factor of 2, measurements
performed by J Skaller suggest a factor of around 1.2 - 1.5 at first
glance for computation.

> As Ray said, you could argue whether or not GC should be the default. 

> It's not an argument for Ada -- it isn't the default, and would

Yes, the discussion is seriously OT, since we are mostly not
discussing how GC will be supported in Ada in future (or not), but the
general merits of GC.

> never be the default simply because making existing programs run
> slower is not an option in all but the most serious cases.

> I could see a predefined GC storage pool
> being added to the language, or something like that. But the language would
> need other fixes to really allow GC (although I doubt anyone will stop you
> from implementing a GC in Ada, it's likely to be wrong in some subtle - some
> would say pathological - cases).

Yes. Despite the standard allowing GC, it doesn't align too well with
the rest of Ada. 

Regards -- Markus

Re: How come Ada isn't more popular?

[Ray Blaak]

Maciej Sobczak <no.spam@no.spam.com> writes:
> On the other hand, most languages with GC get it wrong by relying *only* on
> GC, everywhere, whereas it is useful (if at all) only for memory. The problem
> is that few programs rely on only memory and in a typical case there are lots
> of resources that are not memory oriented and they have to be managed,
> somehow. When GC is a shiny center of the language, those other kinds of
> resources suffer from not having appropriate support. In practical terms, you
> don't have manual management of memory, but you have *instead* manual
> management of *everything else* and the result is either code bloat or more
> bugs (or both, typically).

This is a fair criticism, actually. I am not sure what the state of the art is
with regards to expanding the concept of a garbage collector to a more general
resource manager, of which memory is only a particular kind of resource.

> Think about adding a non-memory resource to a class that was up to now only
> memory oriented - if it requires any modification on the client side, like
> adding tons of finally blocks and calls to close/dispose/dismiss/etc.
> methods *everywhere*, then in such a language the term "encapsulation" is a
> joke.

I do a lot of coding, and I simply do not find this to be such a prevelant
problem in practice. The most common case is to do with the closing of open
files in a finally block, but one only does the open in a few places and the
majority of the code is not concerned with cleanup at all.

The other common case is getting access to system drawing contexts that must
be explicitly disposed of. Again, one tends to get it only in a few places,
and the occurrences of explicit clean up are few.

Still, when I use C++ after using C# or Java, I find myself immediately taking
advantage of the scope-based destructors for these situations.

> An ideal solution seems to be a mix of both (GC and automatic objects), but I
> think that the industry needs a few generations of failed attempts to get this
> mix right. We're not yet there.

Yes, when you need scope based cleanup, proper controlled types are useful.
We will see how it goes.

Still, with the existence of proper closures in a language, one can get scope
clean up already. In the C# example below, I can define a file open/close
helper that let's the grunt-work cleanup be specified only once, such that I
pass an "action" closure to perform the actual work on an open file (think of
"delegate" as closure/lambda/procedure, etc.):

  string path = "C:/temp/someFile.xml";
  string xmlData = null;
  WithOpenFile
    (path, 
     delegate (TextReader reader) 
     {
       xmlData = reader.ReadToEnd(); // note we can modify the local variable
     });

where WithOpenFile is defined as:

  public delegate void FileReader(TextReader reader);

  public void WithOpenFile(string path, FileReader fileReader)
  {
    TextReader reader = new TextReader(path);
    try
    {
       fileReader(reader);
    }
    finally
    {
       reader.Close();
    }
  }
-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[adaworks]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:eputhf$p8u$1@cernne03.cern.ch...
> Markus E Leypold wrote:
>
> Ada 95 *is* terrible. It doesn't have containers nor unbounded strings and it 
> cannot even return limited types from functions. Yuck! ;-)
>
Both statements are untrue.

There are numerous container libraries available for Ada 95.
However, there is no standard container library as part of
the language standard.

Three string libraries are available: Fixed, Bounded and Unbounded.

While the inability to return limited types from a function is a bit of
an inconvenience, it does not prevent one from writing subprograms
that support the equivalent kind of thing using an in out mode parameter
in a procedure.   Further, one is not required to use limited types when
they are inconvenient.  That being said, the recent change allowing
limited types in return statements is, potentially, an improvement.

Richard Riehle 

Re: How come Ada isn't more popular?

[Jean-Pierre Rosen]

adaworks@sbcglobal.net a �crit :
> While the inability to return limited types from a function is a bit of
> an inconvenience, ...
And you can always return a *pointer* to a limited type, which is what 
you would do in most other languages.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Jean-Pierre Rosen wrote:

>> While the inability to return limited types from a function is a bit of
>> an inconvenience, ...
> And you can always return a *pointer* to a limited type, which is what 
> you would do in most other languages.

Which is entirely missing the point.

The purpose of returning limited types from a function is to implement 
the constructor functionality for those types that are considered 
critical and cannot be left uninitialized.

Initialization by procedure is prone to bugs that cannot be checked at 
compile-time (forgetting or bypassing the initialization), same for 
initialization by pointer. Both "solutions" fail to meet the initial 
goal which is to enforce at compile time the proper initialization for 
selected important types.

The ideal solution is called "constructor", everything else is just 
patchwork. Returning limited types is a compromise that can be 
satisfying in most cases - that's why it's good that Ada 2005 provides 
at least this feature.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> The ideal solution is called "constructor", everything else is just
> patchwork. Returning limited types is a compromise that can be
> satisfying in most cases - that's why it's good that Ada 2005 provides
> at least this feature.

I presume by "constructor", you mean the C++ style feature, right?

Why is that superior to just using functions as constructors?
Ada has:

    type T(<>) is ...

to indicate that clients MUST call some constructor function when
creating objects.  And it now allows constructor functions (and
aggregates) for limited types.

I'm talking about Ada 2005, of course.  I agree that limited types were
rather painful in Ada 95.

- Bob

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 09 Feb 2007 07:50:43 -0500, Robert A Duff wrote:

> Maciej Sobczak <no.spam@no.spam.com> writes:
> 
>> The ideal solution is called "constructor", everything else is just
>> patchwork. Returning limited types is a compromise that can be
>> satisfying in most cases - that's why it's good that Ada 2005 provides
>> at least this feature.
> 
> I presume by "constructor", you mean the C++ style feature, right?
> 
> Why is that superior to just using functions as constructors?
> Ada has:
> 
>     type T(<>) is ...
> 
> to indicate that clients MUST call some constructor function when
> creating objects.  And it now allows constructor functions (and
> aggregates) for limited types.

Because it does not compose upon inheritance and aggregation.

When inherited the constructing function need to be overridden, even if
null record was the only thing added. Further one can barely publicly
derive anything from T, which breaks encapsulation.

When aggregated:

   type Outer  is record
      Inner : T .= Constructor_T (...);
   end 

there is no way to evaluate the parameters of T's constructing function
from ones of Outer.

IMO, the constructor concept is cleaner and more general than constructing
functions, which are as little functions as ":=" in X : T := 123; is an
assignment.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[adaworks]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1sh134r4r8piq$.wh1w0uitf99t$.dlg@40tude.net...
> On Fri, 09 Feb 2007 07:50:43 -0500, Robert A Duff wrote:
>
>> Maciej Sobczak <no.spam@no.spam.com> writes:
>>
>>
>> Why is that superior to just using functions as constructors?
>> Ada has:
>>
>>     type T(<>) is ...
>>
>> to indicate that clients MUST call some constructor function when
>> creating objects.  And it now allows constructor functions (and
>> aggregates) for limited types.
>
> Because it does not compose upon inheritance and aggregation.
>
> When inherited the constructing function need to be overridden, even if
> null record was the only thing added. Further one can barely publicly
> derive anything from T, which breaks encapsulation.
>
I guess I don't see this as a serious problem.    Perhaps this is because
I frequently take the Modula-2 approach and create opaque types.
These support extensible inheritance, enforce encapsulation, and
separate all the implementation details within the package body.

Granted, the use of opaque types requires the supporting capability
of access types.   But the use of access types in the pursuit of good
programming is no vice.  Rather, it is consistent with the counsel given
us over two score years ago by Maurice Wilkes.

From my perspective, opaque types solve a lot of problems that are
inherent in C++ and Java and support an increased level of separation
of concerns in my application architecture.  That being said, one can,
with a little effort, create C++ opaque types.   I have not thought about
how this would be done in Java. Pehaps through the interface mechanism.

Richard 

Re: How come Ada isn't more popular?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:
>
> From my perspective, opaque types solve a lot of problems that are
> inherent in C++ and Java and support an increased level of separation
> of concerns in my application architecture.  That being said, one can,
> with a little effort, create C++ opaque types.   I have not thought about
> how this would be done in Java. Pehaps through the interface mechanism.

That is what I would advocate.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sat, 10 Feb 2007 18:21:56 GMT, adaworks@sbcglobal.net wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1sh134r4r8piq$.wh1w0uitf99t$.dlg@40tude.net...
>> On Fri, 09 Feb 2007 07:50:43 -0500, Robert A Duff wrote:
>>
>>> Maciej Sobczak <no.spam@no.spam.com> writes:
>>>
>>>
>>> Why is that superior to just using functions as constructors?
>>> Ada has:
>>>
>>>     type T(<>) is ...
>>>
>>> to indicate that clients MUST call some constructor function when
>>> creating objects.  And it now allows constructor functions (and
>>> aggregates) for limited types.
>>
>> Because it does not compose upon inheritance and aggregation.
>>
>> When inherited the constructing function need to be overridden, even if
>> null record was the only thing added. Further one can barely publicly
>> derive anything from T, which breaks encapsulation.
>>
> I guess I don't see this as a serious problem.    Perhaps this is because
> I frequently take the Modula-2 approach and create opaque types.
> These support extensible inheritance, enforce encapsulation, and
> separate all the implementation details within the package body.
> 
> Granted, the use of opaque types requires the supporting capability
> of access types.   But the use of access types in the pursuit of good
> programming is no vice.  Rather, it is consistent with the counsel given
> us over two score years ago by Maurice Wilkes.
> 
> From my perspective, opaque types solve a lot of problems that are
> inherent in C++ and Java and support an increased level of separation
> of concerns in my application architecture.  That being said, one can,
> with a little effort, create C++ opaque types.   I have not thought about
> how this would be done in Java. Pehaps through the interface mechanism.

Opaque types are nice, but I don't think that they solve the problem.
Everything is OK as long as the types are independent. But when they are
not, one would like to have operations defined on access T be ones of
access S, (type S is new T with ...). The problem just reappears as
composition of constructing functions for access T and access S. For
example,

GtkAda represents a practical example of this problem. It goes as follows:

type Gtk_T_Record is ...;
type Gtk_T is access Gtk_T_Record'Class; -- The opaque type

procedure Gtk_New (X : out Gtk_T); -- Constructing "function"
procedure Initialize (X : access Gtk_T_Record'Class); -- Constructor
... -- All operations are defined in terms of access Gtk_T_Record.

-- The implementation of "constructors" goes as follows
procedure Gtk_New (X : out Gtk_T) is
begin
   X := new Gtk_T_Record;
   Initialize (X);
exception
   when others => -- We don't want it leaking
      Free (X);
      raise;
end Gtk_New;
procedure Initialize (X : access Gtk_T_Record'Class) is
begin
   ... -- Initialization
end Initialize;

Now with a derived type S:

type Gtk_S_Record is new Gtk_T_Record with ...;
type Gtk_S is access Gtk_s_Record'Class; -- The opaque type

procedure Gtk_New (X : out Gtk_S);
procedure Initialize (X : access Gtk_S_Record'Class);

procedure Gtk_New (X : out Gtk_S) is
begin
   X := new Gtk_S_Record;
   Initialize (X);
exception
   when others =>
      Free (X);
      raise;
end Gtk_New;

procedure Initialize (X : access Gtk_S_Record'Class) is
begin
   Parent_Package.Initialize (X);
   ... -- Custom initialization
end Initialize;

This all is quite boring, at least. Neither Gtk_New nor Initialize are
composable. Further, specifically to opaque types, it is impossible to hide
Gtk_T implementation as an access type, which breaks encapsulation by
exposing Gtk_T_Record to everybody.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Robert A Duff wrote:

> I presume by "constructor", you mean the C++ style feature, right?

The feature in general. C++ is just one example from many languages that 
got it right.

> Why is that superior to just using functions as constructors?

The constructor, as a language feature, more clearly describes its own 
purpose. It's also entirely independent on other properties of the type.

> Ada has:
> 
>     type T(<>) is ...
> 
> to indicate that clients MUST call some constructor function when
> creating objects.

This indicates that the type has unknown discriminants.
The concept of "discriminant" is completely irrelevant to the intent 
here, even though in this particular case the combination of this 
concept and other language features leads to the fact that there must be 
some constructor function called.

I treat it as an idiom that allows me to finally achieve the goal, but 
not as a direct support for the feature that would be most accurate.

> I'm talking about Ada 2005, of course.  I agree that limited types were
> rather painful in Ada 95.

Yes. And this answers your question why constructors are superior - they 
are superior, because as a direct feature related to value 
initialization it would be completely independent on other properties of 
the type, like whether it is limited or not. Ada 2005 has patched this, 
but with direct suppor for constructors there would be nothing to patch 
- constructor initializes the value "in place", not as a result of 
returning value from somewhere and special-casing it for limited types.

There is also a question of how to initialize a generic type. Again, the 
question is really about a direct language feature.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

RE: How come Ada isn't more popular?

[Randy Brukardt]

Maciej Sobczak writes:
...
> I treat it as an idiom that allows me to finally achieve the goal, but
> not as a direct support for the feature that would be most accurate.

Fair enough, but then why are you here? Ada is all about providing building
blocks that allow you to accomplish a purpose, rather than whiz-bang
features that provide the entire purpose in a neat but inflexible package.

There are many examples of that: tagged types, derivation, packages (which
combine to make a "class"), Finalization via controlled types, (<>),
protected types (which can be use to write a lock, but isn't a lock by
itself), etc.

                     Randy.

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Randy Brukardt wrote:

>> I treat it as an idiom that allows me to finally achieve the goal, but
>> not as a direct support for the feature that would be most accurate.
> 
> Fair enough, but then why are you here?

I don't understand. Is the fact that I miss some language feature 
disqualifying me from learning more about the language? :-)

> Ada is all about providing building
> blocks that allow you to accomplish a purpose, rather than whiz-bang
> features that provide the entire purpose in a neat but inflexible package.

Is a direct support for constructors a whiz-bang but inflexible package?
In what way?

> There are many examples of that: [...]

Sure, but there are also examples of missing features.
For every language there is at least one programmer that will miss 
something. I miss (for example) constructors in Ada.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

RE: How come Ada isn't more popular?

[Randy Brukardt]

Maciej Sobczak writes:
> Randy Brukardt wrote:
>
> >> I treat it as an idiom that allows me to finally achieve the goal, but
> >> not as a direct support for the feature that would be most accurate.
> >
> > Fair enough, but then why are you here?
>
> I don't understand. Is the fact that I miss some language feature
> disqualifying me from learning more about the language? :-)

Sorry, that comment seems harsher than I intended. All I meant to say is
that it is pointless to complain about one of the fundamental design choices
of Ada (or any other language). It makes as much sense as complaining that
it is hard to write an imperative program in a functional language.

> > Ada is all about providing building
> > blocks that allow you to accomplish a purpose, rather than whiz-bang
> > features that provide the entire purpose in a neat but
> inflexible package.
>
> Is a direct support for constructors a whiz-bang but inflexible package?
> In what way?

Because there is no single concept of a constructor. You need at a minimum a
copy-constructor and a default-constructor, and then you still have
flexibility issues. Ada chose to decompose these things into their
constituent parts.

Yes, Ada does have a problem with composition, but that is a general
language problem, not one that is specific to constructors or any other
specific feature. It would be much better to fix that composition problem
generally rather than to bolt on more special features that do compose,
while still leaving the general case unfixed.

> > There are many examples of that: [...]
>
> Sure, but there are also examples of missing features.
> For every language there is at least one programmer that will miss
> something. I miss (for example) constructors in Ada.

You haven't clearly explained what the difference between a function and a
constructor is. When we (the ARG) looked at this problem, we eventually
decided (at least from an Ada semantics perspective) that there was in fact
no difference. Thus we decided that it didn't make sense to have a special
feature for the purpose. (That certainly was not where we started out when
considering the issues.)

                           Randy.

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Randy Brukardt wrote:

>> Is a direct support for constructors a whiz-bang but inflexible package?
>> In what way?
> 
> Because there is no single concept of a constructor. You need at a minimum a
> copy-constructor and a default-constructor, and then you still have
> flexibility issues. Ada chose to decompose these things into their
> constituent parts.

I understand that.

> You haven't clearly explained what the difference between a function and a
> constructor is. When we (the ARG) looked at this problem, we eventually
> decided (at least from an Ada semantics perspective) that there was in fact
> no difference.

The difference (as I perceive it) is in the coupling that the "function" 
has with its corresponding type. If it is a function just as any other, 
then the fact that it is a constructor function is only a matter of 
convention. Sometimes it is just a naming convention (for example, when 
the function is called "Initialize" or "Create", etc. then it might be a 
hint that it is a constructor function), but the fact is the the term 
"constructor function" is used by Ada programmers and that means that 
they treat it in a somewhat special way. By coupling the constructor 
with the type, the intent is expressed more clearly and then the purpose 
is not a result of naming convention.
As an example, consider (C++):

template <class T, typename U>
void fun(const U &u)
{
     T t(u);

     // or:
     T *p = new T(u);

     // ...
}

This is truly generic with only two parameters - there is no need to 
drag around the name of the constructor function to instantiate the 
template.

> Thus we decided that it didn't make sense to have a special
> feature for the purpose.

Which I understand. Still, achieving the effect of forced initialization 
requires from me to jump somewhere else for concepts that are not 
directly related to the problem at hand.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Mon, 12 Feb 2007 14:56:39 -0600, Randy Brukardt wrote:

> Maciej Sobczak writes:

>> Is a direct support for constructors a whiz-bang but inflexible package?
>> In what way?
> 
> Because there is no single concept of a constructor.

Yes. There are constructors of the components, the constructors of the
specific types inherited from, the constructor of the specific type and
potentially the constructor of the class.

> You need at a minimum a
> copy-constructor and a default-constructor,

Well, but there is nothing to do about it. For that matter Ada.Finalization
too has Adjust and Initialize. The difference between creating a copy and
creating a new thing cannot be eliminated by any abstraction. They are
semantically different. What constructor offer is a sane way to express
initialization, by-value parameter passing and assignment.

BTW, I fully agree that there is no need to introduce constructors as a
special language object. It would be sufficient to declare their existence
and to allow definition some of parts of through user-defined primitive and
class-wide operations.

It is just so that we need a little more language support than
Ada.Finalization can offer, and, for all, it must be available for all
types without exceptions.

> Ada chose to decompose these things into their
> constituent parts.

Which was obviously impossible. For example, the assignment problem. Is it
a function or a procedure? How the constraints of the left side are
influenced by the right side? etc.
 
> Yes, Ada does have a problem with composition, but that is a general
> language problem, not one that is specific to constructors or any other
> specific feature.

Yes!

> It would be much better to fix that composition problem
> generally rather than to bolt on more special features that do compose,
> while still leaving the general case unfixed.

Certainly.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> "Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
> news:eputhf$p8u$1@cernne03.cern.ch...
>> Markus E Leypold wrote:
>>
>> Ada 95 *is* terrible. It doesn't have containers nor unbounded strings and it 
>> cannot even return limited types from functions. Yuck! ;-)
>>

Hey! Again I was not writing that ... I find that irritating -- I've
been arguing enough controversial positions without getting attributed
the statements of others.

Regards -- Markus

Re: How come Ada isn't more popular?

[Randy Brukardt]

"Gautier" <gautier@fakeaddress.nil> wrote in message
news:45b8361a_5@news.bluewin.ch...
...
> I'm afraid you read a bit too quickly: I discussed about finding a
(_good_)
> and (cheap or free) compiler in 1995. GNAT needed a few years to become
really
> good, IHMO.

"Good" is highly subjective, and what you think of as "good" may differ
widely from other people. I know Tom thinks Janus/Ada was pretty good, and
long before 1995...

Your opinion of good may differ, depending on what you want to do.

                      Randy.

Re: How come Ada isn't more popular?

[Gautier]

Randy Brukardt:

> "Good" is highly subjective, and what you think of as "good" may differ
> widely from other people. I know Tom thinks Janus/Ada was pretty good, and
> long before 1995...
> 
> Your opinion of good may differ, depending on what you want to do.
> 
>                       Randy.

I could not agree more. One could add that the quality (whatever subjectivity) 
of a given software fluctuates with the changes occurring around it. What was 
good long before 1995 was perhaps less good to make a popular Windows 95 + 
Ada95 product, since it is the subject of this discussion thread. I'm not a 
customer of Janus/Ada but I have some reliable 3rd-party comments :-).
On the "-" side, some limitations and rests from the DOS & Ada 83 version (I 
was told that the type Integer is on 16 bits ?!), persistent doubts about 
future developments, strange shipping media (floppy disks).
On the "+" side, an full compilation system for Ada, from source to 
executable, with smart linking, when GNAT has sometimes trouble with the gnu 
doing fuzzy things in the basement (e.g. sometimes absurd trace-backs...) and 
needs a longish and unreliable workaround (gnatelim) to achieve what a smart 
linker does in no supplemental time.
Perhaps the way Janus/Ada (95) is presented on the RR Software site is also 
misleading and hides the real virtues of the product. It seems like an Ada 83 
compiler for DOS doing a tentative trip towards Ada 95 (an "extension") and on 
other operating systems.
Anyway, it is never too late and Janus/Ada has certainly a big potential that 
relatively small details can release. A version of the CLAW demo that compiles 
with GNAT 3.15p (2002 !) or later wouldn't hurt, either, IMHO, since it's the 
pieces of RR Software people can try.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

Re: How come Ada isn't more popular?

[tmoran]

> A version of the CLAW demo that compiles
> with GNAT 3.15p (2002 !) or later wouldn't hurt, either,
   That's an error on the web page.  Of course Claw has worked with
Gnat 3.15p since the latter was released.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Gautier wrote:
> 
> The point is that neither CLAW nor GWindows were included in the Ada 
> standard, and it is a good thing. And promoting Ada for Windows 
> programming in an Ada conference is good, but that won't make that 
> language a lot more popular: you have to make promotion outside the 
> insider circle...

I think I may have been misunderstood. I wasn't talking about Ada 95 
including a standard library for MS Windows; I was talking about a 
portable standard windowing library. On MS Windows platforms, that 
library would target MS Windows.

> I'm afraid you read a bit too quickly: I discussed about finding a 
> (_good_) and (cheap or free) compiler in 1995. GNAT needed a few years 
> to become really good, IHMO.

Janus Ada was, and I'm sure still is, a good compiler. I used it for 
many years after winning a copy at the Tri-Ada programming contest.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: How come Ada isn't more popular?

[Ali Bendriss]

On Tuesday 23 January 2007 06:37, adaworks@sbcglobal.net wrote:
> <artifact.one@googlemail.com> wrote in message
> news:1169531612.200010.153120@38g2000cwa.googlegroups.com...
>
> > My question is: how come Ada isn't more popular?
>
> Ada suffered, in its early days, from a convergence of several
> things.  One is that the designers of the language did not anticipate
> the impact of the personal computer and the democratization of
> computing.   There were other factors, as well.
> [...]

Does the fact that there is no "public" operating system written in Ada is one 
of this factor ? 
I think about the closest link between the C language and the *nix systems.


-- 
Ali 

Re: How come Ada isn't more popular?

[Charles D Hixson]

Ali Bendriss wrote:
> On Tuesday 23 January 2007 06:37, adaworks@sbcglobal.net wrote:
>> <artifact.one@googlemail.com> wrote in message
>> news:1169531612.200010.153120@38g2000cwa.googlegroups.com...
>>
>>> My question is: how come Ada isn't more popular?
>> Ada suffered, in its early days, from a convergence of several
>> things.  One is that the designers of the language did not anticipate
>> the impact of the personal computer and the democratization of
>> computing.   There were other factors, as well.
>> [...]
> 
> Does the fact that there is no "public" operating system written in Ada is one 
> of this factor ? 
> I think about the closest link between the C language and the *nix systems.
> 
> 
That's a factor, but only a small one, and getting smaller as 
time goes on.  I, personally, think that one factor IS the 
lack of a standard garbage collector.  Related to this is the 
awkwardness of dealing with strings of varying lengths.

There are many features which aren't significant after you've 
learned how to work your way around them that can be sizeable 
blockages at the start.

Remember that at the start, Ada was competing solely against 
C.  C++ barely existed, and what did exist didn't bear that 
much resemblance to what we now call C++.  (I used to use C++ 
rather than C solely because of the typed constants.)  At that 
point C had to be cut down to compile on a micro-computer. 
Look up BSD C or Lifeboat C.  These were SUBSETS of C, but 
they could be used, and they could call themselves C.  (Once 
you started using them, you became well aware that they were 
subsets...works in progress as it were.)  Ada subsets couldn't 
use the name Ada.  Janus Ada couldn't call itself Ada for 
quite awhile.  And even Janus Ada couldn't run on most CP/M 
machines.  Too resource intensive.  I bought an Apple ][ to 
run UCSD Pascal, and was so disappointed that I saved up and 
installed a CP/M card so that I could run C.  Ada wasn't a 
possibility.  (I never seriously considered Basic.  It was too 
non-portable.  If I wanted non-portable, I'd go for assembler.)

Ada was HUGE and C++ was only a slight bit larger than C. 
(The times they DO change!)  At that time I was a PL/I 
programmer on a mainframe, and Ada had a reputation that 
caused me to both lust after it, and to fear it's 
complexities.  Actually, however, it was never a realistic 
possibility.  I couldn't run it on my home machine, and work 
sure wasn't going to pay the have the service bureau install 
it.  So I dreamed about it...and Algol68, and Snobol, and IPL, 
and APL, and LISP...and didn't take any of those dreams 
seriously.  But of those only Ada and Algol were frightening 
as well as lust provoking.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Charles D Hixson <charleshixsn@earthlink.net> writes:

> goes on.  I, personally, think that one factor IS the lack of a
> standard garbage collector.  Related to this is the awkwardness of
> dealing with strings of varying lengths.

Actually that is rather good compared to C or C++. The different
string package s make it possible to often use stack allocated storage
only or get the comfort of unbounded strings. After a while I really
started to like this.

> There are many features which aren't significant after you've learned
> how to work your way around them that can be sizeable blockages at the
> start.
>
> Remember that at the start, Ada was competing solely against C.  C++
> barely existed, and what did exist didn't bear that much resemblance
> to what we now call C++.  (I used to use C++ rather than C solely
> because of the typed constants.)  At that point C had to be cut down
> to compile on a micro-computer. Look up BSD C or Lifeboat C.  These
> were SUBSETS of C, but they could be used, and they could call
> themselves C.  


Yes. That is the availability issue again. I personally would have
wished that there where a suitable subset of Ada (without tasking)
that could be linked with C (or FORTRAN). That would have helped to
survive in a mixed environment a furthered slow migration from an
existing code base.

> (Once you started using them, you became well aware
> that they were subsets...works in progress as it were.)  

> Ada subsets couldn't use the name Ada.  Janus Ada couldn't call
> itself Ada for quite awhile.  And even Janus Ada couldn't run on
> most CP/M machines.  Too resource intensive.  I bought an Apple ][
> to run UCSD Pascal, and was so disappointed that I saved up and
> installed a CP/M card so that I could run C.  Ada wasn't a
> possibility.  (I never seriously considered Basic.  It was too
> non-portable.  If I wanted non-portable, I'd go for assembler.)


> Ada was HUGE and C++ was only a slight bit larger than C. (The times
> they DO change!)  At that time I was a PL/I programmer on a mainframe,
> and Ada had a reputation that caused me to both lust after it, and to
> fear it's complexities.  Actually, however, it was never a realistic
> possibility.  I couldn't run it on my home machine, and work sure
> wasn't going to pay the have the service bureau install it.  So I
> dreamed about it...and Algol68, and Snobol, and IPL, and APL, and
> LISP...and didn't take any of those dreams seriously.  But of those
> only Ada and Algol were frightening as well as lust provoking.

:-) Nice account.

Regards -- Markus

Re: How come Ada isn't more popular?

[Charles D Hixson]

Markus E Leypold wrote:
> Charles D Hixson <charleshixsn@earthlink.net> writes:
> 
>> goes on.  I, personally, think that one factor IS the lack of a
>> standard garbage collector.  Related to this is the awkwardness of
>> dealing with strings of varying lengths.
> 
> Actually that is rather good compared to C or C++. The different
> string package s make it possible to often use stack allocated storage
> only or get the comfort of unbounded strings. After a while I really
> started to like this.
> 
Note that "After a while"?  The first hour, the first day, the 
first week, and the first month are the most important for 
forming lasting impressions.  I still remember the extreme 
frustration I experienced the first time I tried to print a 
string...it was an unbounded string, and I hadn't used 
Ada.Text_IO.Unbounded...and I didn't have anyone I could ask 
"What does that silly error message MEAN!?!?"

It's easier to do simple things in Fortran, C, Pascal, Modula 
II, PL/I or even Snobol.  Oh, yes, and BASIC, too.  (The other 
current contenders weren't around then, I never learned Cobol, 
and it isn't easier in any assembler I ever learned.)
>...
>> only Ada and Algol were frightening as well as lust provoking.
> 
> :-) Nice account.
> 
> Regards -- Markus
> 
Thanks

Re: How come Ada isn't more popular?

[Markus E Leypold]

Charles D Hixson <charleshixsn@earthlink.net> writes:

> Markus E Leypold wrote:
>> Charles D Hixson <charleshixsn@earthlink.net> writes:
>>
>>> goes on.  I, personally, think that one factor IS the lack of a
>>> standard garbage collector.  Related to this is the awkwardness of
>>> dealing with strings of varying lengths.
>> Actually that is rather good compared to C or C++. The different
>> string package s make it possible to often use stack allocated storage
>> only or get the comfort of unbounded strings. After a while I really
>> started to like this.
>>
> Note that "After a while"?  

Yes. I couldn't decide at first when better to use Fixed and when
Unbounded strings. The problem got aggravated by my attempts to stay
minimalist and use fixed string where ever possible and also where
impossible. The insight that some algorithms are better not performed
with bounded buffers took a while to take hold.


> The first hour, the first day, the first week, and the first month
> are the most important for forming lasting impressions.

Yes, but it's not the "impressions" that count. I came from Pascal
background (after learning programming in BASIC and assembler) and
looking at Ada was love at the first glance -- as far as languages of
that family go. I often thought: Wow, there is a design decision where
everything has done right after a lot of thinking and not decided in
an ad hoc fashion.

I hope I'm not limited to my first expressions, though.

> I still remember the extreme frustration I experienced the first
> time I tried to print a string...it was an unbounded string, and I
> hadn't used Ada.Text_IO.Unbounded...and I didn't have anyone I could
> ask "What does that silly error message MEAN!?!?"

 :-). Fun, yes. The error messages of GNAT(e.g.)  are sometimes less
 than helpful. Fortunately I always had my copy of Barnes' book with
 me and from C/C++/SML etc I learned to compile often and morph
 programs through syntactically correct intermediate stages. So that
 couldn't trip me up too much :-).

> It's easier to do simple things in Fortran, C, Pascal, Modula II, PL/I
> or even Snobol.  Oh, yes, and BASIC, too.  (The other current

It's easier to do simple things with languages that have lists in
them. E.g. Lisp or Scheme (or Python for today programmers). No, I
disagree: It's not even easy to do simple things in C: Every time I'm
astounded by the contortions I've to go through for anything involving
strings of varying length (OK, I can work in large statically
allocated buffer, but this simply stinks, since it imposes arbitrary
limits). And very soon the wish comes up not to have to write out
specialized list processing code every time for 'list of ints', 'list
of floats', 'list of strings', 'list of lists of strings', 'list of
trees' etc -- and than you start to suffer and it never ends. There is
no way to write generics in C, to fake them or even graft them onto
the language as an afterthought and use a precompiler or a
preprocessor (I'm perhaps exaggerating here, but the pain is there
nonetheless. I've written those things (a generics "expander" for C
:-) and I think/hope I know about what I'm talking here).

> contenders weren't around then, I never learned Cobol, and it isn't
> easier in any assembler I ever learned.)

Well, that what all my recent posts to this group try to assert: That
there are languages beyond assembler (including C) and the pascalish
family (including Ada). Of course I'm posting to c.l.a. so I know that
this might develop into flame bait. But it wasn't me, starting to bash
C (It was J R Carter :-), and when we start to discuss the respective
merits and dis-merits of various languages than we can as well go the
whole way and accept the fact that development has not stopped with
imperative compiled languages. I'm also pining for the days when I
almost understood everything the compiler did and there was no VM and
no JIT and no whatever-optimization. If you're a control freak like
me, you just feel better if you understand everything at least in
principle and can say things like "this statement/call expands to the
following instruction sequence but ..., so if you compare you can ..."
and if you can -- in principle -- recreate your own tools (which is of
course an illusion). 

But those days are long gone and, if I think about it for a moment,
good riddance. Give me a modern functional languages with lot's of
complicated types and katamorphisms every day. I finally want to get
things done -- and I suggest to compare e.g. haskell.org or Jon
Harrop's demo source for OCaml with the list of "free projects" on the
ACT site (or where ever ...) and moreover the scope of ambition of
those projects and I'm starting to anticipate what an expressive
language can be. 

Let me put it like that: Trees and graphs are fundamental models in
computer science, mathematics and finally document processing (XML
...). An expressive language supports to manipulate those easily
without much ado, without wrapping objects or iterators or factory
patterns around a simple concept, without the need for explicit memory
management, preferably by recursive functions which are the natural
form of expressing a transformation of those structure.

How does Ada stand there? How does C? Both bad. Fixing the argument
(Why/where does Ada fail?) on C vs. Ada misses an important
point. Both languages are relatively good in shoveling bits from one
place (bus, memory, ports, interfaces) to another and doing not too
complicated things to those bits.  But that is not where the real
interesting things happen these days.  Say, in example, "scene
graph". Can you feel the complexity :-)? Do you want to maintain it
with explicit pointers and memory management in an imperative fashion?
I don't.

But whatever - YMMV (that applies to everyone on c.l.a. :-)

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:

> Charles D Hixson <charleshixsn@earthlink.net> writes:

>> It's easier to do simple things in Fortran, C, Pascal, Modula II, PL/I
>> or even Snobol.  Oh, yes, and BASIC, too.  (The other current
> 
> It's easier to do simple things with languages that have lists in
> them. E.g. Lisp or Scheme (or Python for today programmers). No, I
> disagree: It's not even easy to do simple things in C: Every time I'm
> astounded by the contortions I've to go through for anything involving
> strings of varying length (OK, I can work in large statically
> allocated buffer, but this simply stinks, since it imposes arbitrary
> limits). And very soon the wish comes up not to have to write out
> specialized list processing code every time for 'list of ints', 'list
> of floats', 'list of strings', 'list of lists of strings', 'list of
> trees' etc -- and than you start to suffer and it never ends. There is
> no way to write generics in C, to fake them or even graft them onto
> the language as an afterthought and use a precompiler or a
> preprocessor (I'm perhaps exaggerating here, but the pain is there
> nonetheless. I've written those things (a generics "expander" for C
> :-) and I think/hope I know about what I'm talking here).

Generics is a wrong answer and always was. As well as built-in lists you
are praising is, because what about trees of strings, trees of lists etc.
You cannot build every and each type of containers in.

Right answers should be a more powerful type system than Ada presently has.
In my view there are three great innovations Ada made, which weren't
explored at full:

1. Constrained subtypes (discriminants)
2. Implementation inheritance without values (type N is new T;)
3. Typed classes (T /= T'Class)

P.S. All strings have fixed length. It is just so that you might not know
the length at some point... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:
>
>> Charles D Hixson <charleshixsn@earthlink.net> writes:
>
>>> It's easier to do simple things in Fortran, C, Pascal, Modula II, PL/I
>>> or even Snobol.  Oh, yes, and BASIC, too.  (The other current
>> 
>> It's easier to do simple things with languages that have lists in
>> them. E.g. Lisp or Scheme (or Python for today programmers). No, I
>> disagree: It's not even easy to do simple things in C: Every time I'm
>> astounded by the contortions I've to go through for anything involving
>> strings of varying length (OK, I can work in large statically
>> allocated buffer, but this simply stinks, since it imposes arbitrary
>> limits). And very soon the wish comes up not to have to write out
>> specialized list processing code every time for 'list of ints', 'list
>> of floats', 'list of strings', 'list of lists of strings', 'list of
>> trees' etc -- and than you start to suffer and it never ends. There is
>> no way to write generics in C, to fake them or even graft them onto
>> the language as an afterthought and use a precompiler or a
>> preprocessor (I'm perhaps exaggerating here, but the pain is there
>> nonetheless. I've written those things (a generics "expander" for C
>> :-) and I think/hope I know about what I'm talking here).
>
> Generics is a wrong answer and always was. As well as built-in lists you
> are praising is, because what about trees of strings, trees of lists etc.
> You cannot build every and each type of containers in.

You missed my point. :-). A language with a Hinldey-Milner type system
has a 'tree of something' type where something can be anything in
every given instance of usage.

So you get 'tree of foo' from it and 'tree of bar' when you use it
like this, but there are no generics instantiated. There are trade
offs, of course (like that you probably can't design such a language
without GC and without loosing a certain degree of control of the
representation of types), but since C D Hixson and me have been
talking about usefuleness in a general sense, that doesn't count
here. A useful language needs to have lists, you must be able to write
recursive functions on lists and preferably in a functional way and
you should not need explicit instantiation declaration for every
instance (like 'of float', 'of int', 'of ...').

Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from
that ideal. Since a lot of programming these days is general list
manipulation, everyday jobs become painful. 

Has anybody here aver wondered about the popularity of "scripting",
like with Perl, PHP, Python and so on? As I see it, the presence of
lists and hashtables/dictionaries in those languages together with the
absence of memory management is a factor in this popularity. Which I
hope, if not proves, at least makes my point plausible. :-).


>
> Right answers should be a more powerful type system than Ada presently has.

Yes.

> In my view there are three great innovations Ada made, which weren't
> explored at full:
>
> 1. Constrained subtypes (discriminants)
> 2. Implementation inheritance without values (type N is new T;)
> 3. Typed classes (T /= T'Class)


Here 2 things are missing: 

  - parameterized types (see Java generics and the ML type system, the
    first is just borrowing from the latter).

  - Separation of implementation and type or to put it differently
    inheritance and subtyping compatibility. See the ocaml type system.

    I admit the contracts are weaker for allowing to instante a
    generic with a package with the "right type signature" as
    parameter instead of requiring an instance of another specific
    generic.

    But what is absolutely annoying, is, that the compatibility of
    objects is determined by inheritance instead by the type
    signature. This makes things like the factory pattern necessary
    and it really doesn't work in general case. (And yes, Java and C++
    share this defect).

I suggest that anyone trying to improve on the type system of
languages of the Algol family first should aquire a knowledge of the
Hindley-Milner type system, then read the part about objects and
classes in the OCAML manual (this is an extension of Hindley-Milner) 

  http://caml.inria.fr/pub/docs/manual-ocaml/manual005.html

and finally reads the tutorial on Java generics (introduced in 1.5):

  http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf


To me those three together were an eye opener. The Java generics
tutorial in I my eyes documents 2 things: (a) what has been really
sorely missing from Java for 10 years and (b) that you can complement
a type safe pascalish type system usefully with subtyping and
parameterized types.
      
   
> P.S. All strings have fixed length. It is just so that you might not know
> the length at some point... (:-))

Ah, well, thats splitting hairs. We are talking about 2 different
lengths (of strings in C) here: The one is the allocated storage, the
other the distance from the start to the first occurrence of the '\0'
delimiter. Since strlen() returns the latter ...

The problem I've been talking above, is of course to manage growing
strings that might outgrow the allocated storage.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:

>> Generics is a wrong answer and always was. As well as built-in lists you
>> are praising is, because what about trees of strings, trees of lists etc.
>> You cannot build every and each type of containers in.
> 
> You missed my point. :-). A language with a Hinldey-Milner type system
> has a 'tree of something' type where something can be anything in
> every given instance of usage.

You have X of Y. Granted, you can play with Y, but what about X?

The point is, the language should not have either X or Y built-in. What
should be built-in is "of". The type system should be able to handle
parallel type hierarchies of X's and Y's bound by the relation "of".

> So you get 'tree of foo' from it and 'tree of bar' when you use it
> like this, but there are no generics instantiated. There are trade
> offs, of course (like that you probably can't design such a language
> without GC and without loosing a certain degree of control of the
> representation of types),

It is not obvious. I saw to good arguments for GC, so far. (it tend to
repeat in c.l.a and comp.object, a lot of foam around mouths... (:-))  Note
that non-contiguous representations of objects is a way different issue. It
seems that you want the latter when you refer to GC. To me GC is about
indeterminable scopes, upward closures and other things I don't want to
have...

> but since C D Hixson and me have been
> talking about usefuleness in a general sense, that doesn't count
> here. A useful language needs to have lists, you must be able to write
> recursive functions on lists and preferably in a functional way and
> you should not need explicit instantiation declaration for every
> instance (like 'of float', 'of int', 'of ...').

Of course you need it. There cannot be a language with only first-class
objects. Let types-1 be values, make them values. Then they will need no
declarations, just literals. Soon you will discover some types-2 which
still require declarations. Make them values too. An so on. At some level n
you will have to stop. Now, rename type-n = "type". value, type-k<n =
"value". See? You are where you have started.

> Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from
> that ideal. Since a lot of programming these days is general list
> manipulation, everyday jobs become painful. 

There always was Lisp, for those who prefer declarations spelt in the form
of bracket structures...

> Has anybody here aver wondered about the popularity of "scripting",
> like with Perl, PHP, Python and so on?

I did.

> As I see it, the presence of
> lists and hashtables/dictionaries in those languages together with the
> absence of memory management is a factor in this popularity. Which I
> hope, if not proves, at least makes my point plausible. :-).

What about Excel? I have a theory. Look Turbo Pascal was hugely popular.
Why? That is simple, because it has 256 character long strings! Borland
made a great mistake lifting that limitation. Compare it with MS-Excel,
which is still limited to 32767 rows. That is the key to success! (:-))

>> In my view there are three great innovations Ada made, which weren't
>> explored at full:
>>
>> 1. Constrained subtypes (discriminants)
>> 2. Implementation inheritance without values (type N is new T;)
>> 3. Typed classes (T /= T'Class)
> 
> Here 2 things are missing: 
> 
>   - parameterized types (see Java generics and the ML type system, the
>     first is just borrowing from the latter).

See pos.1. The constraint is the parameter of. In rare cases you wanted
different values of parameters producing isolated types you would apply 2
to 1.

>   - Separation of implementation and type or to put it differently
>     inheritance and subtyping compatibility. See the ocaml type system.

That should be interface inheritance from concrete types. Yes, Ada misses
that.

>     I admit the contracts are weaker for allowing to instante a
>     generic with a package with the "right type signature" as
>     parameter instead of requiring an instance of another specific
>     generic.

There should be no generics at all...

>     But what is absolutely annoying, is, that the compatibility of
>     objects is determined by inheritance instead by the type
>     signature.

I see it otherwise. Because "compatibility" is undecidable (for both the
computer and the programmer), the language must be strongly and
manifestedly typed. 

>    This makes things like the factory pattern necessary
>     and it really doesn't work in general case. (And yes, Java and C++
>     share this defect).

I am not sure what you mean, but when 3 is considered as 1, then
dispatching on bare type tags might become possible.

>> P.S. All strings have fixed length. It is just so that you might not know
>> the length at some point... (:-))
> 
> Ah, well, thats splitting hairs. We are talking about 2 different
> lengths (of strings in C) here: The one is the allocated storage, the
> other the distance from the start to the first occurrence of the '\0'
> delimiter. Since strlen() returns the latter ...
> 
> The problem I've been talking above, is of course to manage growing
> strings that might outgrow the allocated storage.

No, the problem is lack of abstract interfaces. I don't care about memory
if I can make my object an implementation of an abstract array interface.
There is no distance beyond the difference between two index values of the
array. You cannot (may not) associate elements of an array and its indices
with any memory locations.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:
>
>>> Generics is a wrong answer and always was. As well as built-in lists you
>>> are praising is, because what about trees of strings, trees of lists etc.
>>> You cannot build every and each type of containers in.
>> 
>> You missed my point. :-). A language with a Hinldey-Milner type system
>> has a 'tree of something' type where something can be anything in
>> every given instance of usage.
>
> You have X of Y. Granted, you can play with Y, but what about X?

I don't understand the question ...

> The point is, the language should not have either X or Y built-in. What

Pursuing this argument further, a language also shouldn't have strings
built in etc. :-). 

What I think, is, that having at least lists in the "standard library"
and by that I mean functional lists, not arrays, not "containers",
helps tremendously because that is such a common use case.

> should be built-in is "of". The type system should be able to handle
> parallel type hierarchies of X's and Y's bound by the relation "of".

Yes. And exactly that is what a Hindley-Milner type system has built
in. The lists in Haskell and Ocaml are just in the standard library
(conceptually -- knowing that they are here, makes it easy to compile
them by special rules and get a more efficient implementation or have
special instructions in the underlying VM or reduction mechanism).

>> So you get 'tree of foo' from it and 'tree of bar' when you use it
>> like this, but there are no generics instantiated. There are trade
>> offs, of course (like that you probably can't design such a language
>> without GC and without loosing a certain degree of control of the
>> representation of types),
>
> It is not obvious. I saw to good arguments for GC, so far. (it tend to
> repeat in c.l.a and comp.object, a lot of foam around mouths... (:-))  

Foam, yes :-). But you have to admit, that allowing a GC without ever
having an actual implementation (execpt Martin Krischik's adaption of
the B�hm collector) just too much teasing: You could have it, but no,
it's not there.

> Note that non-contiguous representations of objects is a way
> different issue. It seems that you want the latter when you refer to
> GC. 

Not necessarily, but I think it does help a lot towards efficient
garabage collection. I might be mistaken, since I'm not really an
expert in designing garbage collectors.

> To me GC is about indeterminable scopes, upward closures and
> other things I don't want to have...

If yout have only downward scopes for "closures" and memory allocation
this will, finally, interact badly with the fact that "implicit
(i.e. static type safe) casting" of classes is also only possible
downwards. My impression is, that all these things together rule out
some useful designs, that would otherwise possible. Or to say it
differenty: Object orientation w/o indeterminable scopes, upward
closures and GC doesn't work well. Some abstractions cannot be
implemented.

This, of course is just a gut feeling. I do not know about research or
empiricial studies that examine the influence that these various
restrictions have on each other and how they act together.


>> but since C D Hixson and me have been
>> talking about usefuleness in a general sense, that doesn't count
>> here. A useful language needs to have lists, you must be able to write
>> recursive functions on lists and preferably in a functional way and
>> you should not need explicit instantiation declaration for every
>> instance (like 'of float', 'of int', 'of ...').

> Of course you need it. There cannot be a language with only first-class
> objects. 

Well, yes. In a sense java (up to 1.4) was such a language. The only
feasible way to built a general container was casting down to "Object"
type and casting up later again. With the possibility of runtime
casting errors. Bad.

> Let types-1 be values, make them values. Then they will need no
> declarations, just literals. Soon you will discover some types-2 which
> still require declarations. Make them values too. An so on. At some level n
> you will have to stop. Now, rename type-n = "type". value, type-k<n =
> "value". See? You are where you have started.

I do not understand your argument here. Care to give some example and
I'll try write down how it is down in i.e. OCaml? Perhaps we're
talking on cross purposes too, since I'm not sure I really wanted to
desire the thing you insist I want. :-)


>> Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from
>> that ideal. Since a lot of programming these days is general list
>> manipulation, everyday jobs become painful. 
>
> There always was Lisp, for those who prefer declarations spelt in the form
> of bracket structures...

I'm not talking about syntax. I'm talking about types. Which --
strictly speaking -- lisp hasn't. there is only one (static) type in a
dynamic type system, which is one large union (discriminant) type.

>> Has anybody here aver wondered about the popularity of "scripting",
>> like with Perl, PHP, Python and so on?
>
> I did.

And? What was the result of your considerations? :-)

>
>> As I see it, the presence of
>> lists and hashtables/dictionaries in those languages together with the
>> absence of memory management is a factor in this popularity. Which I
>> hope, if not proves, at least makes my point plausible. :-).

> What about Excel? I have a theory. Look Turbo Pascal was hugely popular.

Excel is just cancer of mind and organisation. People start to use it,
the "application" grows and they miss the point where to stop. I've
seen many "applications" that took away somewhere around 3-4 man
months and would have been easy to write as web application with say
Python or PHP and (God forgive me) MySQL in 1 month.

> Why? That is simple, because it has 256 character long strings! 

> Borland made a great mistake lifting that limitation. Compare it
> with MS-Excel, which is still limited to 32767 rows. That is the key
> to success! (:-))

You make me laugh :-). So what Ada should do, is to introduce a
String256 with appropriate restriction, and then we will succeed. Good
plan ... :-))).


>>> In my view there are three great innovations Ada made, which weren't
>>> explored at full:
>>>
>>> 1. Constrained subtypes (discriminants)
>>> 2. Implementation inheritance without values (type N is new T;)
>>> 3. Typed classes (T /= T'Class)
>> 
>> Here 2 things are missing: 
>> 
>>   - parameterized types (see Java generics and the ML type system, the
>>     first is just borrowing from the latter).
>
> See pos.1. The constraint is the parameter of. In rare cases you wanted
> different values of parameters producing isolated types you would apply 2
> to 1.

Again I do not know what you're denying here...


>>   - Separation of implementation and type or to put it differently
>>     inheritance and subtyping compatibility. See the ocaml type system.
>
> That should be interface inheritance from concrete types. Yes, Ada misses
> that.

No, what I want is even different. 2 values / objects in the OCaml way
of objects are just compatible if their type signatures (which are
calculated by the type inference engine) agree or better one is
contained in the other. This is a weaker contract than in Ada where at
least a behavioural part of the contract is implied by inheriting the
implementation, but which (except for generic packages) is useless,
since you can destroy behaviour by overwriting a method with a
misbehaved procedure.

Actually what are classes in other languages should perhaps better be
mapped to packages in Ada in the mind of the developer.


>>     I admit the contracts are weaker for allowing to instante a
>>     generic with a package with the "right type signature" as
>>     parameter instead of requiring an instance of another specific
>>     generic.
>
> There should be no generics at all...

I'm not sure. Generics provide a relatively stric contract model. I
like this. But the instantation requirement is cumbersome if compared
with the way parameterized types work in other langauges (and that is
exactly what I'm pulling from generics most of the time: parameterized
types). Parameterized types are now 1:1 substitute for generics. ML
has functors too, for a good reason. But they are what makes everyday
live bearable.

>
>>     But what is absolutely annoying, is, that the compatibility of
>>     objects is determined by inheritance instead by the type
>>     signature.
>
> I see it otherwise. Because "compatibility" is undecidable (for both the
> computer and the programmer), the language must be strongly and
> manifestedly typed.

Since the contract can be broken by new methods anyway, the only thing
that counts from a type safety point of view, is, not to break the
abstraction to the underlying processor / VM, that is, to be able to
call the methods with the right number of parameters and the right
representation of the parameters (at the machine level). So the type
signature is enough.

It's really bothersome that one cannot supply a class X which is
compatible to another class Y by just writing out the right methods. 

And BTW -- if inheritance is done right (the keyword here is binary
methods and co- and contravariance -- have a look into the OCaml users
manual), a class Y' derived from Y is not necessarily subtype
compatible. So inheritance of implementations doesn't guarantee
anything anyway. 


>>    This makes things like the factory pattern necessary
>>     and it really doesn't work in general case. (And yes, Java and C++
>>     share this defect).
>
> I am not sure what you mean, but when 3 is considered as 1, then
> dispatching on bare type tags might become possible.


3? 1? Please elaborate? Is "dispatching on bare type tags" a good or a
bad thing? You lost me there ... (my fault probably).


>
>>> P.S. All strings have fixed length. It is just so that you might not know
>>> the length at some point... (:-))
>> 
>> Ah, well, thats splitting hairs. We are talking about 2 different
>> lengths (of strings in C) here: The one is the allocated storage, the
>> other the distance from the start to the first occurrence of the '\0'
>> delimiter. Since strlen() returns the latter ...
>> 
>> The problem I've been talking above, is of course to manage growing
>> strings that might outgrow the allocated storage.

> No, the problem is lack of abstract interfaces. 

Ah! Here we agree! That is the deeper problem.

> I don't care about memory if I can make my object an implementation
> of an abstract array interface.

Yes. 

> There is no distance beyond the difference between two index values
> of the array. 

There is -- (I1 - I2) but it's abstract in number of elements, not in
units of memory.

> You cannot (may not) associate elements of an array and its indices
> with any memory locations.

ACK. 

But my dear Dmitry -- What does your sentence "All strings have fixed
length ..." mean than in this context, eh?

[laughing madly and leaving the stage]

Regards -- Markus

Re: How come Ada isn't more popular?

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> If yout have only downward scopes for "closures" and memory allocation
> this will, finally, interact badly with the fact that "implicit
> (i.e. static type safe) casting" of classes is also only possible
> downwards. My impression is, that all these things together rule out
> some useful designs, that would otherwise possible. Or to say it
> differenty: Object orientation w/o indeterminable scopes, upward
> closures and GC doesn't work well. Some abstractions cannot be
> implemented.

Why do we call these closures "downward" and "upward" instead of the
other way around?  A downward closure (allowed in Ada 2005, and to some
extent in Ada 83) is a procedure that is passed IN to another procedure,
which is toward the TOP of the call stack (up!).  An upward closure (not
directly supported in Ada, but supported in Lisp et al) is a procedure
that is passed OUT (return value, 'out' parameter, setting a global
variable) -- which means it's being passed DOWN toward the BOTTOM of the
call stack.  (Of course, the call stack is not quite a stack anymore, if
upward closures are allowed!)

It seems to me "inward" and "outward" closures would be clearer
terminology, for what are normally called "downward" and "upward",
respectively.

- Bob

Re: How come Ada isn't more popular?

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> If yout have only downward scopes for "closures" and memory allocation
>> this will, finally, interact badly with the fact that "implicit
>> (i.e. static type safe) casting" of classes is also only possible
>> downwards. My impression is, that all these things together rule out
>> some useful designs, that would otherwise possible. Or to say it
>> differenty: Object orientation w/o indeterminable scopes, upward
>> closures and GC doesn't work well. Some abstractions cannot be
>> implemented.
>
> Why do we call these closures "downward" and "upward" instead of the
> other way around?  

I don't know. It's a pathological condition anyway :-). I'm using this
vocabulary as I find it.


> A downward closure (allowed in Ada 2005, and to some
> extent in Ada 83) is a procedure that is passed IN to another procedure,
> which is toward the TOP of the call stack (up!).  

It's passed downward th call chain.


> An upward closure (not
> directly supported in Ada, but supported in Lisp et al) is a procedure
> that is passed OUT (return value, 'out' parameter, setting a global
> variable) -- which means it's being passed DOWN toward the BOTTOM of the
> call stack.  

> (Of course, the call stack is not quite a stack anymore, if
> upward closures are allowed!)

Depends. Just yesterday I've been imagining a system which basically
uses a stack, but when passing a "closure" upwards, copies parts of
the stack to the heap.

Chicken scheme I think, also uses a stack (in som unusal ways), but
still has closure.


> It seems to me "inward" and "outward" closures would be clearer
> terminology, for what are normally called "downward" and "upward",
> respectively.

What you call outward closures are just closure. There was a
discussion at comp.lang.functional which convinced me, that closure
should better be called procdures (because it's rathe the natural way
how things should work) and what is presently called downwards closure
should better be called somthing different, like, say stack bound
procedures (to indicate that their lifetime depends on the stack).

But it's certainly too late now to change established if misleading
terminology.

Regards -- Markus

Re: How come Ada isn't more popular?

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> (Of course, the call stack is not quite a stack anymore, if
>> upward closures are allowed!)
>
> Depends. Just yesterday I've been imagining a system which basically
> uses a stack, but when passing a "closure" upwards, copies parts of
> the stack to the heap.
>
> Chicken scheme I think, also uses a stack (in som unusal ways), but
> still has closure.

Well, yeah, that's the sort of thing I mean by "not quite a stack".
It's sort of like a stack, except some more-recently-pushed parts of
it need to survive longer, so the implementation copies things
to the heap, or allocates activation records in the heap in the
first place, or <various implementation strategies>.

>> It seems to me "inward" and "outward" closures would be clearer
>> terminology, for what are normally called "downward" and "upward",
>> respectively.
>
> What you call outward closures are just closure.

Well, if a language supports both inward and outward (or downward and
upward, of you prefer), then people say it supports "full closures".
It doesn't make a lot of sense to support the outward/upward ones
without also supporting the inward/downward ones, too.

>... There was a
> discussion at comp.lang.functional which convinced me, that closure
> should better be called procdures...

Yes, I saw part of that discussion.  Yes, "closure" really just means
"procedure".  We use "closure" (or "lexical closure") to emphasize the
fact that a "procedure" includes some environmental information in
addition to just the code.

"Closure" also emphasizes that there's something interesting about that
environment -- namely, that NESTED procedures may be passed around the
place (whether inward only, or both inward and outward).

>... (because it's rathe the natural way
> how things should work) and what is presently called downwards closure
> should better be called somthing different, like, say stack bound
> procedures (to indicate that their lifetime depends on the stack).

Perhaps.  Pascal programmers just call them "procedural parameters".

> But it's certainly too late now to change established if misleading
> terminology.

- Bob

Re: How come Ada isn't more popular?

[(see below)]

On 31/1/07 22:49, in article wcchcu6zu9d.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@shell01.TheWorld.com> wrote:

> Yes, I saw part of that discussion.  Yes, "closure" really just means
> "procedure".  We use "closure" (or "lexical closure") to emphasize the
> fact that a "procedure" includes some environmental information in
> addition to just the code.
> 
> "Closure" also emphasizes that there's something interesting about that
> environment -- namely, that NESTED procedures may be passed around the
> place (whether inward only, or both inward and outward).
...
> Pascal programmers just call them "procedural parameters".

Thread tie!

I invented the "procedural/functional parameter" terminology for
the BSI/ISO standard because we kept getting confused in committee
about what was meant when we spoke of "procedure parameters".
(Were "procedure parameters" the parameters OF procedures
or those that WERE procedures?)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: How come Ada isn't more popular?

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 31/1/07 22:49, in article wcchcu6zu9d.fsf@shell01.TheWorld.com, "Robert A
> Duff" <bobduff@shell01.TheWorld.com> wrote:
>
>> Yes, I saw part of that discussion.  Yes, "closure" really just means
>> "procedure".  We use "closure" (or "lexical closure") to emphasize the
>> fact that a "procedure" includes some environmental information in
>> addition to just the code.
>> 
>> "Closure" also emphasizes that there's something interesting about that
>> environment -- namely, that NESTED procedures may be passed around the
>> place (whether inward only, or both inward and outward).
> ...
>> Pascal programmers just call them "procedural parameters".
>
> Thread tie!
>
> I invented the "procedural/functional parameter" terminology for
> the BSI/ISO standard because we kept getting confused in committee
> about what was meant when we spoke of "procedure parameters".

Cool!

> (Were "procedure parameters" the parameters OF procedures
> or those that WERE procedures?)

Indeed.

Now tell me which of the following things called X is a "component of
type T"?

    type T is
        record
            X : Integer;
        end record;

    type Something is
        record
            X : T;
        end record;

;-)

- Bob

Re: How come Ada isn't more popular?

[(see below)]

On 31/1/07 23:18, in article wcc1wlazsy6.fsf@shell01.TheWorld.com, "Robert A
Duff" <bobduff@shell01.TheWorld.com> wrote:

> Now tell me which of the following things called X is a "component of
> type T"?
> 
>     type T is
>         record
>             X : Integer;
>         end record;
> 
>     type Something is
>         record
>             X : T;
>         end record;
> 
> ;-)

The RM seems to talk about components of objects rather than
components of types, so I'm *guessing* the second. 8-)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: How come Ada isn't more popular?

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>>> (Of course, the call stack is not quite a stack anymore, if
>>> upward closures are allowed!)
>>
>> Depends. Just yesterday I've been imagining a system which basically
>> uses a stack, but when passing a "closure" upwards, copies parts of
>> the stack to the heap.
>>
>> Chicken scheme I think, also uses a stack (in som unusal ways), but
>> still has closure.
>
> Well, yeah, that's the sort of thing I mean by "not quite a stack".

Ah yes, of course. I did understand "not quite" as a cute way to say
"actually the stack is a linked set of frames in the heap", but now I
understand that you indicated your awareness of the various twists
this issue can take (or can be made to take).

> It's sort of like a stack, except some more-recently-pushed parts of
> it need to survive longer, so the implementation copies things
> to the heap, or allocates activation records in the heap in the
> first place, or <various implementation strategies>.

Excactly. :-)

>
>>> It seems to me "inward" and "outward" closures would be clearer
>>> terminology, for what are normally called "downward" and "upward",
>>> respectively.
>>
>> What you call outward closures are just closure.
>
> Well, if a language supports both inward and outward (or downward and
> upward, of you prefer), then people say it supports "full closures".

> It doesn't make a lot of sense to support the outward/upward ones
> without also supporting the inward/downward ones, too.

Yes. I think the whole upward/downward magic talk is simply due to the
fact that there is a case when people don't want GC and have a
traditional stack and therefore do something like closures the cheap
way: Closure data stays valid as long as the stack is not popped. This
is the way downward closures come into the world. 

>
>>... There was a
>> discussion at comp.lang.functional which convinced me, that closure
>> should better be called procdures...
>
> Yes, I saw part of that discussion.  Yes, "closure" really just means
> "procedure".  We use "closure" (or "lexical closure") to emphasize the
> fact that a "procedure" includes some environmental information in
> addition to just the code.

Which in a mathematical sense should be the default. If I say 

 - let a = ...
 - let f(x) = a * proolify (x) ^ a

and later (much later) say something like


 - let's call the coefficient (k1 * k7 ^ p4) a.

nobody (no mathematician) would expect f to change.

> "Closure" also emphasizes that there's something interesting about that
> environment -- namely, that NESTED procedures may be passed around the
> place (whether inward only, or both inward and outward).

As should be the norm.

>>... (because it's rathe the natural way
>> how things should work) and what is presently called downwards closure
>> should better be called somthing different, like, say stack bound
>> procedures (to indicate that their lifetime depends on the stack).
>
> Perhaps.  Pascal programmers just call them "procedural parameters".

Even if they aren't passed around at the moment? Shouldn't a parameter
be something passed to a procedure call? 

Regards -- Markus

Re: How come Ada isn't more popular?

[Ed Falis]

Robert A Duff wrote:

> Why do we call these closures "downward" and "upward" instead of the
> other way around?

Because certain microprocessor architectures manage their stacks from
high to low addresses as things are pushed onto them?  Stupid, but
understandable how it may have happened.

Re: How come Ada isn't more popular?

[Robert A Duff]

Ed Falis <falis@verizon.net> writes:

> Robert A Duff wrote:
>
>> Why do we call these closures "downward" and "upward" instead of the
>> other way around?
>
> Because certain microprocessor architectures manage their stacks from
> high to low addresses as things are pushed onto them?

I think pretty-much all computer architectures have stacks that grow
downward in memory (if they have anything resembling a stack at all).
I still prefer to call the top of the stack "top", even if its address
is less than the address of the "bottom".

>...Stupid, but
> understandable how it may have happened.

Quite likely.

- Bob

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Mon, 29 Jan 2007 16:50:16 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:
>>
>>>> Generics is a wrong answer and always was. As well as built-in lists you
>>>> are praising is, because what about trees of strings, trees of lists etc.
>>>> You cannot build every and each type of containers in.
>>> 
>>> You missed my point. :-). A language with a Hinldey-Milner type system
>>> has a 'tree of something' type where something can be anything in
>>> every given instance of usage.
>>
>> You have X of Y. Granted, you can play with Y, but what about X?
> 
> I don't understand the question ...

X = tree, Y = something. What about X = something, Y = character.

Example: fixed size strings, unbounded strings, suffix tree. Here the
container (X) varies, the element does not. It is a quite common situation
when you wished to change the containers on the fly.

>> The point is, the language should not have either X or Y built-in. What
> 
> Pursuing this argument further, a language also shouldn't have strings
> built in etc. :-). 

Yes, sure. The standard library can provide them, but there must be no
magic in. The user should be able to describe string type in language terms
without loss of either performance or compatibility.

> What I think, is, that having at least lists in the "standard library"
> and by that I mean functional lists, not arrays, not "containers",
> helps tremendously because that is such a common use case.
> 
>> should be built-in is "of". The type system should be able to handle
>> parallel type hierarchies of X's and Y's bound by the relation "of".
> 
> Yes. And exactly that is what a Hindley-Milner type system has built
> in. The lists in Haskell and Ocaml are just in the standard library
> (conceptually -- knowing that they are here, makes it easy to compile
> them by special rules and get a more efficient implementation or have
> special instructions in the underlying VM or reduction mechanism).

I doubt it can. I am too lazy to check. (:-)) But the uncomfortable
questions you (the type system) should answer are like:

Y1 <: Y2 => X of Y1 <: X of Y2
   is container of subtypes a subtype?

X1 <: X2 => X1 of Y <: X2 of Y
   is sub-container a subtype?

There is no universal answer. Sometimes yes, sometimes not. Consider yes
examples:

   String vs. Wide_String (case 1)
   Unbounded_String vs. String  (case 2)
   Unbounded_String vs. Wide_String  (mixed case)
   
>>> So you get 'tree of foo' from it and 'tree of bar' when you use it
>>> like this, but there are no generics instantiated. There are trade
>>> offs, of course (like that you probably can't design such a language
>>> without GC and without loosing a certain degree of control of the
>>> representation of types),
>>
>> It is not obvious. I saw to good arguments for GC, so far. (it tend to
>> repeat in c.l.a and comp.object, a lot of foam around mouths... (:-))  
> 
> Foam, yes :-). But you have to admit, that allowing a GC without ever
> having an actual implementation (execpt Martin Krischik's adaption of
> the B�hm collector) just too much teasing: You could have it, but no,
> it's not there.

It was left open for those who might need it. It seems that nobody came...
(:-))

No seriously, I don't consider GC as a problem. Just give me "X of Y." Then
I would take X = access. An do whatever memory collection I want! See?
There is absolutely no need to have built-in GC, if you have abstract
referential (access) interfaces. Note additional advantage: you can have
different GC's handling objects of same types in the same application!

>> To me GC is about indeterminable scopes, upward closures and
>> other things I don't want to have...
> 
> If yout have only downward scopes for "closures" and memory allocation
> this will, finally, interact badly with the fact that "implicit
> (i.e. static type safe) casting" of classes is also only possible
> downwards. My impression is, that all these things together rule out
> some useful designs, that would otherwise possible. Or to say it
> differenty: Object orientation w/o indeterminable scopes, upward
> closures and GC doesn't work well. Some abstractions cannot be
> implemented.

Umm, I cannot tell. It is an interesting point. I am not sure if it is
true, because we already can return T'Class, and surely we should develop
the language towards making X of Y'Class possible. As a simple intermediate
stage we could allow X (T: Tag) of Y'Class (T). In Ada syntax:

type Coherent_Array (Element_Tag : <syntax sugar for Element'Class>) is
   array (Integer range <>) of
      Element'Class (Element_Type);

Here the discriminant of the array determines the specific types of all its
elements.

> This, of course is just a gut feeling. I do not know about research or
> empiricial studies that examine the influence that these various
> restrictions have on each other and how they act together.

My feeling is that upward closures destroy the idea of type. However,
somehow we surely need type objects in some form, for making distributed
systems, for instance (how to marshal non-objects?)

>> Let types-1 be values, make them values. Then they will need no
>> declarations, just literals. Soon you will discover some types-2 which
>> still require declarations. Make them values too. An so on. At some level n
>> you will have to stop. Now, rename type-n = "type". value, type-k<n =
>> "value". See? You are where you have started.
> 
> I do not understand your argument here. Care to give some example and
> I'll try write down how it is down in i.e. OCaml? Perhaps we're
> talking on cross purposes too, since I'm not sure I really wanted to
> desire the thing you insist I want. :-)

You have the following hierarchy:

values
type-1 = types (sets of values + operations)
type-2 = types of types (sets of types + operations to compose types)
type-3 = types of types of types (...)
...
type-n
...
type-oo

[ value-k = type-k-1 ]

As an example of type-2 you can consider parametrized types. Instances of
them are type-1 (=value-2). Types declared in generic Ada packages are
type-1. All of them considered together ("generic type") is a type-2.
Another example of type-2 in Ada is formal generic type:

generic
   type T is range <>;

"range <>" is type-2. The actual T is type-1 (=value-2).

>>> Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from
>>> that ideal. Since a lot of programming these days is general list
>>> manipulation, everyday jobs become painful. 
>>
>> There always was Lisp, for those who prefer declarations spelt in the form
>> of bracket structures...
> 
> I'm not talking about syntax. I'm talking about types. Which --
> strictly speaking -- lisp hasn't. there is only one (static) type in a
> dynamic type system, which is one large union (discriminant) type.

I think one could argue that types in Lisp are (), (()), ((())), ... but I
don't believe it deserves much attention. (:-))

>>> Has anybody here aver wondered about the popularity of "scripting",
>>> like with Perl, PHP, Python and so on?
>>
>> I did.
> 
> And? What was the result of your considerations? :-)

The Original Sin is the reason. They are sent upon us as a punishment...
(:-))

[...]
> You make me laugh :-). So what Ada should do, is to introduce a
> String256 with appropriate restriction, and then we will succeed. Good
> plan ... :-))).

Not in this life ... Use Ada and be saved... (:-))

>>>> In my view there are three great innovations Ada made, which weren't
>>>> explored at full:
>>>>
>>>> 1. Constrained subtypes (discriminants)
>>>> 2. Implementation inheritance without values (type N is new T;)
>>>> 3. Typed classes (T /= T'Class)
>>> 
>>> Here 2 things are missing: 
>>> 
>>>   - parameterized types (see Java generics and the ML type system, the
>>>     first is just borrowing from the latter).
>>
>> See pos.1. The constraint is the parameter of. In rare cases you wanted
>> different values of parameters producing isolated types you would apply 2
>> to 1.
> 
> Again I do not know what you're denying here...

I deny them as types-2. The huge advantage of pos.1 is that the result is
type-1. The consequence: you can have common values. With type-2 values
(value-1) of different values (type-1) of type-2 are of different types =>
you cannot put them into one container.

>>>   - Separation of implementation and type or to put it differently
>>>     inheritance and subtyping compatibility. See the ocaml type system.
>>
>> That should be interface inheritance from concrete types. Yes, Ada misses
>> that.
> 
> No, what I want is even different. 2 values / objects in the OCaml way
> of objects are just compatible if their type signatures (which are
> calculated by the type inference engine) agree or better one is
> contained in the other. This is a weaker contract than in Ada where at
> least a behavioural part of the contract is implied by inheriting the
> implementation, but which (except for generic packages) is useless,
> since you can destroy behaviour by overwriting a method with a
> misbehaved procedure.

I don't see difference yet. When you inherit only interface, you drop all
the implementation or its parts. This is one issue.

Type inference, if you mean that, is a different one. I doubt that
inference is a right way.

>>>     I admit the contracts are weaker for allowing to instante a
>>>     generic with a package with the "right type signature" as
>>>     parameter instead of requiring an instance of another specific
>>>     generic.
>>
>> There should be no generics at all...
> 
> I'm not sure. Generics provide a relatively stric contract model. I
> like this. But the instantation requirement is cumbersome if compared
> with the way parameterized types work in other langauges (and that is
> exactly what I'm pulling from generics most of the time: parameterized
> types). Parameterized types are now 1:1 substitute for generics. ML
> has functors too, for a good reason. But they are what makes everyday
> live bearable.

We don't need parametrized types (type-2). We can well do almost everything
with parametrized subtypes (type-1). That is the pos.1. Compare:

type String is array (Positive range <>) of Character;
   -- type-1, subtype is parametrized by the bounds

generic
   First : Positive;
   Last : Positive;
package
   type String is array (First..Last) of Character;
      -- type-2, type is parametrized by the bounds

I don't want the latter. Everything that can be made within type-1 must be
done there.

>>>     But what is absolutely annoying, is, that the compatibility of
>>>     objects is determined by inheritance instead by the type
>>>     signature.
>>
>> I see it otherwise. Because "compatibility" is undecidable (for both the
>> computer and the programmer), the language must be strongly and
>> manifestedly typed.
> 
> Since the contract can be broken by new methods anyway, the only thing
> that counts from a type safety point of view, is, not to break the
> abstraction to the underlying processor / VM, that is, to be able to
> call the methods with the right number of parameters and the right
> representation of the parameters (at the machine level). So the type
> signature is enough.

This is a strange argument. Yes, you cannot verify the semantics, exactly
therefore types come into play. Type only names the behavior, so that it
can be checked formally *without* looking into actual behavior.

> It's really bothersome that one cannot supply a class X which is
> compatible to another class Y by just writing out the right methods. 

This is interface inheritance + supertyping + inheritance. It works as
follows:

Given: X, Y independent types.

Required: To use Y where the interface of X is expected.

You create a supertype Z for Y which is a subtype of X. The compiler will
check the contract and require you to implement necessary adaptors. Done.

>>>    This makes things like the factory pattern necessary
>>>     and it really doesn't work in general case. (And yes, Java and C++
>>>     share this defect).
>>
>> I am not sure what you mean, but when 3 is considered as 1, then
>> dispatching on bare type tags might become possible.
> 
> 3? 1? Please elaborate? Is "dispatching on bare type tags" a good or a
> bad thing? You lost me there ... (my fault probably).

You can consider type tag as a discriminant so pos.3 is a case of pos.1.

When you make an abstract factory it is usually so that you know somehow
the type you want to create (=you have the tag of), but you don't have yet
any object of that type. I.e. you have to dispatch on the bare tag to the
factory function.

> But my dear Dmitry -- What does your sentence "All strings have fixed
> length ..." mean than in this context, eh?

That for any given X there exist a function X'Length. We should carefully
distinguish properties of values and types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 29 Jan 2007 16:50:16 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> 
>>>>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:
>>>
>>>>> Generics is a wrong answer and always was. As well as built-in lists you
>>>>> are praising is, because what about trees of strings, trees of lists etc.
>>>>> You cannot build every and each type of containers in.
>>>> 
>>>> You missed my point. :-). A language with a Hinldey-Milner type system
>>>> has a 'tree of something' type where something can be anything in
>>>> every given instance of usage.
>>>
>>> You have X of Y. Granted, you can play with Y, but what about X?
>> 
>> I don't understand the question ...
>
> X = tree, Y = something. What about X = something, Y = character.
>
> Example: fixed size strings, unbounded strings, suffix tree. Here the
> container (X) varies, the element does not. It is a quite common situation
> when you wished to change the containers on the fly.

This situation -- in my experience is much less common. But if you
have it, at the place where you do the manipulation you still need a
common "access protocol" for all thos containers, that is something
like

   for K in keys of container; loop

     do something with container.item(K);

   end loop;

That is what classes are good for (different from parametrized
types). The types of K could well be different here with a
Hindley-Milner type system.

If I consider your challenge in the context of a function programming
language, the situation you address might not arise as often since
you'd abstract of the iteration as well as probably construct the item
sequence at the location of calling the iteration.

   let l = list_of_x ...;;
   let t = tree_of_x ...;;


   let do_something = ...;;                  (* single iteration step *)

   let fooify_items = fold do_something u ;; (* define the iteration  *)

   ...

   ... fooify_items l 
   ... fooify_items (Tree.fringe t)  (* extract the list of items from t and iterate *)

Efficiency concerns are usually countered (a) by a really good garbage
collection and (b) by lazyiness.

>>> The point is, the language should not have either X or Y built-in. What
>> 
>> Pursuing this argument further, a language also shouldn't have strings
>> built in etc. :-). 
>
> Yes, sure. The standard library can provide them, but there must be no
> magic in. 

Here I disgree a bit: Separate syntax is a good thing for the most
common constructs. Else you could as well argue: "A language can
provide constructs for conditional processing or loops, but there must
be no magic" -- meaning that you would want only GOTOs and structured
programming exists only in the mind of the user (I've been programming
like this on micros twenty years ago ...).

And if I have extra syntax i can as well provide special optimization
rules.

> The user should be able to describe string type in language terms
> without loss of either performance or compatibility.

No. I think, strings and lists are so common, that their _semantics_
must be expressible in the core language, but the compiler should have
the license to provide special constructs and optimizations.

>> What I think, is, that having at least lists in the "standard library"
>> and by that I mean functional lists, not arrays, not "containers",
>> helps tremendously because that is such a common use case.
>> 
>>> should be built-in is "of". The type system should be able to handle
>>> parallel type hierarchies of X's and Y's bound by the relation "of".
>> 
>> Yes. And exactly that is what a Hindley-Milner type system has built
>> in. The lists in Haskell and Ocaml are just in the standard library
>> (conceptually -- knowing that they are here, makes it easy to compile
>> them by special rules and get a more efficient implementation or have
>> special instructions in the underlying VM or reduction mechanism).
>
> I doubt it can. I am too lazy to check. (:-)) But the uncomfortable

If it can't, then there os no need to forbid it, isn't there :-).

> questions you (the type system) should answer are like:
>
> Y1 <: Y2 => X of Y1 <: X of Y2
>    is container of subtypes a subtype?

No. Never.

> X1 <: X2 => X1 of Y <: X2 of Y
>    is sub-container a subtype?

Sub-container is a difficult concept. If it doesn't have binary
methods ... then the answer (off the top of my head) is yes.


> There is no universal answer. Sometimes yes, sometimes not. Consider yes
> examples:

Have a look at the Hindley-Milner type system and OCaml's OO
extensions. IMHO the answer doesn't vary at all: The only criterion is
wether the type safety (in the sense given in the Cardelli tutorial)
stays intact. Sometimes I think it is a mistake to mix interface
contracts with type systems: Type systems are too weak to express
contracts, the ad hoc way in which contracts often work, cripple type
systems (i.e. there has always been a minority who wanted termination
guarantees via the type system: Apart from the practical problems,
that doesn't belong into a type system, IMHO).


>    String vs. Wide_String (case 1)
>    Unbounded_String vs. String  (case 2)
>    Unbounded_String vs. Wide_String  (mixed case)
>    
>>>> So you get 'tree of foo' from it and 'tree of bar' when you use it
>>>> like this, but there are no generics instantiated. There are trade
>>>> offs, of course (like that you probably can't design such a language
>>>> without GC and without loosing a certain degree of control of the
>>>> representation of types),
>>>
>>> It is not obvious. I saw to good arguments for GC, so far. (it tend to
>>> repeat in c.l.a and comp.object, a lot of foam around mouths... (:-))  
>> 
>> Foam, yes :-). But you have to admit, that allowing a GC without ever
>> having an actual implementation (execpt Martin Krischik's adaption of
>> the B�hm collector) just too much teasing: You could have it, but no,
>> it's not there.
>
> It was left open for those who might need it. It seems that nobody came...
> (:-))

My impression was that implementing a full Ada 95 compiler was
diifficult enough. Then you don't want GC in embedded programming and
Ada has more or less drawn back from general programming in the last
whatever years. The absence of a GC implementation almost everywhere
is a clear indication of that in my eyes.

> No seriously, I don't consider GC as a problem. Just give me "X of Y." Then
> I would take X = access. An do whatever memory collection I want! See?

No?

> There is absolutely no need to have built-in GC, if you have abstract
> referential (access) interfaces. Note additional advantage: you can have
> different GC's handling objects of same types in the same application!

But there is. Only under very restricted circumstances the necessity
of deallocation can be decided locally. With reference sharing
(representation sharing) between values (think Lisp-like lists -- and
I think you need that for efficience reasons sooner or later -- you're
either back to a "manual" reference counting scheme (inefficient) or
you really need GC.

Let me repeat my mantra: Manual allocation and deallocation hinders
modularity. Not much, because you can survive without it in much the
same fashion as the old FORTRAN programmers survived with GOTOs only,
but ... the question is not wether I need it, but wether I want it in
2007. For, mind you, PC/workstation application programming (as
opposed to embedded in this case).

Ada could have been a nice language straddling a wide range of
application areas. But where other languages have developed, mutated
and where necessary spawned bastards (e.g. C#), with Ada I notice the
majority opinion seems to be that if I don't absolutely need it in
embedded programming, it should not be in the language. Well -- what
was the question again: "How come Ada isn't more popular?". Me thinks
the answer is: Because it don't want any more.


>>> To me GC is about indeterminable scopes, upward closures and
>>> other things I don't want to have...
>> 
>> If yout have only downward scopes for "closures" and memory allocation
>> this will, finally, interact badly with the fact that "implicit
>> (i.e. static type safe) casting" of classes is also only possible
>> downwards. My impression is, that all these things together rule out
>> some useful designs, that would otherwise possible. Or to say it
>> differenty: Object orientation w/o indeterminable scopes, upward
>> closures and GC doesn't work well. Some abstractions cannot be
>> implemented.

> Umm, I cannot tell. 

I think I can tell, but the discussion on this topic (what is
functional programming good for) does still rage on c.l.f and the
relevant mailing lists. I notice, that nobody that actually has tried
FP doubts the superiority of the style in general (they are bitching
about efficiency, sometimes, and availability of libraries, mor
often).

> It is an interesting point. 

> I am not sure if it is
> true, because we already can return T'Class, and surely we should develop
> the language towards making X of Y'Class possible. 

Yes, all languages in question are Turing complete. So you can always
write a Lisp-interpreter and embed it etc. That, though, is not the
point. It does not count wether I can do things "in principle" but how
I can do them and how well the applied abstractions can be seen at a
glance by somebody reading the code later. 

BTW -- another argument _for_ a builtin list syntax.

> As a simple intermediate
> stage we could allow X (T: Tag) of Y'Class (T). In Ada syntax:
>
> type Coherent_Array (Element_Tag : <syntax sugar for Element'Class>) is
>    array (Integer range <>) of
>       Element'Class (Element_Type);
>
> Here the discriminant of the array determines the specific types of all its
> elements.
>
>> This, of course is just a gut feeling. I do not know about research or
>> empiricial studies that examine the influence that these various
>> restrictions have on each other and how they act together.
>
> My feeling is that upward closures destroy the idea of type. However,

So how come that OCaml and Haskell have it? Those languages have a
static type system. Without even RTTI ... :-)

> somehow we surely need type objects in some form, for making distributed
> systems, for instance (how to marshal non-objects?)

Alice ML does it well. Usually they're just marschalling a cluster of
blocks on the heap, but some languages (Alice ML) are more
sophisticated.


>
>>> Let types-1 be values, make them values. Then they will need no
>>> declarations, just literals. Soon you will discover some types-2 which
>>> still require declarations. Make them values too. An so on. At some level n
>>> you will have to stop. Now, rename type-n = "type". value, type-k<n =
>>> "value". See? You are where you have started.
>> 
>> I do not understand your argument here. Care to give some example and
>> I'll try write down how it is down in i.e. OCaml? Perhaps we're
>> talking on cross purposes too, since I'm not sure I really wanted to
>> desire the thing you insist I want. :-)
>
> You have the following hierarchy:
>
> values

> type-1 = types (sets of values + operations)

type = types?

Either you have a type (IMHO) or types. A still fail to follow you here.

> type-2 = types of types (sets of types + operations to compose types)
> type-3 = types of types of types (...)
> ...
> type-n
> ...
> type-oo
>
> [ value-k = type-k-1 ]
>
> As an example of type-2 you can consider parametrized types. Instances of
> them are type-1 (=value-2). Types declared in generic Ada packages are
> type-1. All of them considered together ("generic type") is a type-2.
> Another example of type-2 in Ada is formal generic type:
>
> generic
>    type T is range <>;
>
> "range <>" is type-2. The actual T is type-1 (=value-2).


Perhaps the problem is that with parametrized types you try to express a restriction of the kind

  List of something where something is in the followin family of types
  ...


With parametrized types in an Hindley-Milner type systems things are
vastly more simple: There is a 'general' 'anything' type and ther are
concrete types. So we have:

 -  List of anything (really anything)

which becomes List of int, List of float, List of List of Tree of Int
at any give point of use.

Of course there are also types systems as you seem to decribe them but
I don't know much about them. Hindley-Milner is still simple enough to
be decidable and understandable and buys you a good deal of things.

If on the other side you want to express structured types (i.e. types
with associated operations) the thing to use in ML are modules and
functors. Which are not values but a "static", still typed, language
for constructing modules.

I fail to see how that brings me all back to the starting point. Are
we still talking about the same topic?


>>>> Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from
>>>> that ideal. Since a lot of programming these days is general list
>>>> manipulation, everyday jobs become painful. 
>>>
>>> There always was Lisp, for those who prefer declarations spelt in the form
>>> of bracket structures...
>> 
>> I'm not talking about syntax. I'm talking about types. Which --
>> strictly speaking -- lisp hasn't. there is only one (static) type in a
>> dynamic type system, which is one large union (discriminant) type.
>
> I think one could argue that types in Lisp are (), (()), ((())), ... but I
> don't believe it deserves much attention. (:-))

No. () and ((()) are given values of the same (static) type in Lisp,
because there is not static type checking that keeps you from passing
() where you passed a ((()) just 2 lines before. See?

>
>>>> Has anybody here aver wondered about the popularity of "scripting",
>>>> like with Perl, PHP, Python and so on?
>>>
>>> I did.
>> 
>> And? What was the result of your considerations? :-)
>
> The Original Sin is the reason. They are sent upon us as a punishment...
> (:-))

I agree at least as far as PHP is concerned. Perl pleads for some
mitigating circumstances: It has not started as Web language but as an
awk substitute and has striven hard to mitigate the problems it causes
with safemode and this like. The jury is still out on that. 

But PHP certainly: A punishment.


>>>>> In my view there are three great innovations Ada made, which weren't
>>>>> explored at full:
>>>>>
>>>>> 1. Constrained subtypes (discriminants)
>>>>> 2. Implementation inheritance without values (type N is new T;)
>>>>> 3. Typed classes (T /= T'Class)
>>>> 
>>>> Here 2 things are missing: 
>>>> 
>>>>   - parameterized types (see Java generics and the ML type system, the
>>>>     first is just borrowing from the latter).
>>>

>>> See pos.1. The constraint is the parameter of. In rare cases you wanted
>>> different values of parameters producing isolated types you would apply 2
>>> to 1.
>> 
>> Again I do not know what you're denying here...

> I deny them as types-2. The huge advantage of pos.1 is that the result is
> type-1. The consequence: you can have common values. With type-2 values
> (value-1) of different values (type-1) of type-2 are of different types =>
> you cannot put them into one container.

We must be talking on cross purposes. I admittedly do not understand
most of the terminology you're using here and certainly cannot apply
it here: Why come, the Hindley-Milner type systems have parametrized
types and don't seem to labor under that kind of problem?

>>>>   - Separation of implementation and type or to put it differently
>>>>     inheritance and subtyping compatibility. See the ocaml type system.

>>> That should be interface inheritance from concrete types. Yes, Ada misses
>>> that.


No, no, no. Inheritance should never ever decide on on a subtype
relationship. It can't. In the most general case (again, see the OCaml
manual on objects) objects of a class B derived per inheritance of a
class A cannot be subtypes of the objects of class A (their parent
class).

>> 
>> No, what I want is even different. 2 values / objects in the OCaml way
>> of objects are just compatible if their type signatures (which are
>> calculated by the type inference engine) agree or better one is
>> contained in the other. This is a weaker contract than in Ada where at
>> least a behavioural part of the contract is implied by inheriting the
>> implementation, but which (except for generic packages) is useless,
>> since you can destroy behaviour by overwriting a method with a
>> misbehaved procedure.

> I don't see difference yet. When you inherit only interface, you drop all
> the implementation or its parts. This is one issue.

I don't even need a implementation at the start. One point is, that
the type fitting into a slot in a functor or as a paramter of a
procedure might well never have been defined explicitely but is a
result of type inference. Why should anyone bother with inheriting
interfaces from an implementation (espcially if that wouldn't give a
guarantee as far as subtyping compatibility goes).


> Type inference, if you mean that, is a different one. I doubt that
> inference is a right way.

And I don't. I'm actually convinced it is the right way.

>
>>>>     I admit the contracts are weaker for allowing to instante a
>>>>     generic with a package with the "right type signature" as
>>>>     parameter instead of requiring an instance of another specific
>>>>     generic.
>>>
>>> There should be no generics at all...
>> 
>> I'm not sure. Generics provide a relatively strict contract model. I
>> like this. But the instantation requirement is cumbersome if compared
>> with the way parameterized types work in other langauges (and that is
>> exactly what I'm pulling from generics most of the time: parameterized
>> types). Parameterized types are now 1:1 substitute for generics. ML
>> has functors too, for a good reason. But they are what makes everyday
>> live bearable.

> We don't need parametrized types (type-2). We can well do almost everything
> with parametrized subtypes (type-1). That is the pos.1. Compare:

"Almost". There was a time when I thought I could do everything in
turbo pascal. After a while one dicovers abstracting over the elements
of a container. The need for generics is borne. And so it goes on and
on and on. Abstraction and the need to implement concepts in a
reusable way drive the development. 




> type String is array (Positive range <>) of Character;
>    -- type-1, subtype is parametrized by the bounds
>
> generic
>    First : Positive;
>    Last : Positive;
> package
>    type String is array (First..Last) of Character;
>       -- type-2, type is parametrized by the bounds
>
> I don't want the latter. Everything that can be made within type-1 must be
> done there.
>
>>>>     But what is absolutely annoying, is, that the compatibility of
>>>>     objects is determined by inheritance instead by the type
>>>>     signature.
>>>
>>> I see it otherwise. Because "compatibility" is undecidable (for both the
>>> computer and the programmer), the language must be strongly and
>>> manifestedly typed.
>> 
>> Since the contract can be broken by new methods anyway, the only thing
>> that counts from a type safety point of view, is, not to break the
>> abstraction to the underlying processor / VM, that is, to be able to
>> call the methods with the right number of parameters and the right
>> representation of the parameters (at the machine level). So the type
>> signature is enough.

> This is a strange argument. Yes, you cannot verify the semantics, exactly
> therefore types come into play. Type only names the behavior, so that it
> can be checked formally *without* looking into actual behavior.

But it can't: If B derives from A I have no guarantee, none that B
behaves a an A.

>> It's really bothersome that one cannot supply a class X which is
>> compatible to another class Y by just writing out the right methods. 
>
> This is interface inheritance + supertyping + inheritance. It works as
> follows:

Really cumbersome. Why not just use the type signatur to decide on the
compatibility?


> Given: X, Y independent types.
>
> Required: To use Y where the interface of X is expected.
>
> You create a supertype Z for Y which is a subtype of X. The compiler will
> check the contract and require you to implement necessary adaptors. Done.



>>>>    This makes things like the factory pattern necessary
>>>>     and it really doesn't work in general case. (And yes, Java and C++
>>>>     share this defect).
>>>
>>> I am not sure what you mean, but when 3 is considered as 1, then
>>> dispatching on bare type tags might become possible.
>> 
>> 3? 1? Please elaborate? Is "dispatching on bare type tags" a good or a
>> bad thing? You lost me there ... (my fault probably).

> You can consider type tag as a discriminant so pos.3 is a case of pos.1.

I still don't see the positions -- where is the numbering?

> When you make an abstract factory it is usually so that you know somehow
> the type you want to create (=you have the tag of), but you don't have yet
> any object of that type. I.e. you have to dispatch on the bare tag to the
> factory function.

Yes I know that. If you look into concrete application it rarely works
(well) as a mechanism to abstract over implementation (i.e. the true
base classes).

>
>> But my dear Dmitry -- What does your sentence "All strings have fixed
>> length ..." mean than in this context, eh?
>
> That for any given X there exist a function X'Length. We should carefully
> distinguish properties of values and types.

And in C this function is?

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 29 Jan 2007 16:50:16 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>> 
>>>>>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote:
>>>>
>>>>>> Generics is a wrong answer and always was. As well as built-in lists you
>>>>>> are praising is, because what about trees of strings, trees of lists etc.
>>>>>> You cannot build every and each type of containers in.
>>>>> 
>>>>> You missed my point. :-). A language with a Hinldey-Milner type system
>>>>> has a 'tree of something' type where something can be anything in
>>>>> every given instance of usage.
>>>>
>>>> You have X of Y. Granted, you can play with Y, but what about X?
>>> 
>>> I don't understand the question ...
>>
>> X = tree, Y = something. What about X = something, Y = character.
>>
>> Example: fixed size strings, unbounded strings, suffix tree. Here the
>> container (X) varies, the element does not. It is a quite common situation
>> when you wished to change the containers on the fly.
> 
> This situation -- in my experience is much less common. But if you
> have it, at the place where you do the manipulation you still need a
> common "access protocol" for all thos containers, that is something
> like
> 
>    for K in keys of container; loop
> 
>      do something with container.item(K);
> 
>    end loop;
>
> That is what classes are good for (different from parametrized
> types). The types of K could well be different here with a
> Hindley-Milner type system.

I am not sure what you mean, but it looks quite wrong. (:-)) The iteration
above is based on the interface of an abstract array. Period.

(not every container is array (ordered finite set with a mapping to another
ordered finite set called index)

> If I consider your challenge in the context of a function programming
> language, the situation you address might not arise as often since
> you'd abstract of the iteration as well as probably construct the item
> sequence at the location of calling the iteration.
> 
>    let l = list_of_x ...;;
>    let t = tree_of_x ...;;
> 
> 
>    let do_something = ...;;                  (* single iteration step *)
> 
>    let fooify_items = fold do_something u ;; (* define the iteration  *)
> 
>    ...
> 
>    ... fooify_items l 
>    ... fooify_items (Tree.fringe t)  (* extract the list of items from t and iterate *)
> 
> Efficiency concerns are usually countered (a) by a really good garbage
> collection and (b) by lazyiness.

But tree is not an array, it may have an interface of, but I don't see in
your program how that interface works.

As for the functional style I am not impressed. Array interfaces are much
more natural an easier to use. Consider a bunch of tasks concurrently
processing pieces of the same container, exchanging the positions in etc.
But again, it is a stylistic issue which are IMO irrelevant to the type
system.

>>>> The point is, the language should not have either X or Y built-in. What
>>> 
>>> Pursuing this argument further, a language also shouldn't have strings
>>> built in etc. :-). 
>>
>> Yes, sure. The standard library can provide them, but there must be no
>> magic in. 
> 
> Here I disgree a bit: Separate syntax is a good thing for the most
> common constructs. Else you could as well argue: "A language can
> provide constructs for conditional processing or loops, but there must
> be no magic" -- meaning that you would want only GOTOs and structured
> programming exists only in the mind of the user (I've been programming
> like this on micros twenty years ago ...).

And I would insist to do this, if it were possible. But plain gotos don't
work. You need conditionals (arithmetic gotos or stuff like that) and you
need things to handle scopes (loop indices). The result would be a
different language rather than a subset of.

> And if I have extra syntax i can as well provide special optimization
> rules.

... or loose some important optimizations.

>> The user should be able to describe string type in language terms
>> without loss of either performance or compatibility.
> 
> No. I think, strings and lists are so common, that their _semantics_
> must be expressible in the core language,

You mean *not* expressible. The only reason for having anything built-in is
because it cannot be expressed in other language terms. So it is postulated
there and expressed in a natural language of the Reference Manual.

>> questions you (the type system) should answer are like:
>>
>> Y1 <: Y2 => X of Y1 <: X of Y2
>>    is container of subtypes a subtype?
> 
> No. Never.

Which is a catastrophe in my eyes. Consider:

Y1 = Integer;
Y2 = Positive

X = access

Now we have

access Positive is unrelated to access Integer.

What would be of Ada if it were constructed this way?

>> X1 <: X2 => X1 of Y <: X2 of Y
>>    is sub-container a subtype?
> 
> Sub-container is a difficult concept. If it doesn't have binary
> methods ... then the answer (off the top of my head) is yes.

How are you going to pass string slices where strings are expected? And the
language I want is such that I could pass an array where a queue is
expected.

> The only criterion is
> wether the type safety (in the sense given in the Cardelli tutorial)
> stays intact. Sometimes I think it is a mistake to mix interface
> contracts with type systems: Type systems are too weak to express
> contracts, the ad hoc way in which contracts often work, cripple type
> systems 

Hmm, the language of contracts is not the object language where types live.
In that sense it is decoupled anyway. Therefore the point about type system
is trivially true. Nothing in the object language is strong enough to
express the meta language. You could say same about if-then-else or
integers. If you meant the program semantics/behavior when you talked about
contracts, then that is again true. Nothing can express program semantics
at full. In that sense, yes, LSP was an unrealistic program, which still
does not mean that types are useless. For all I don't see anything useful
proposed instead.

>> No seriously, I don't consider GC as a problem. Just give me "X of Y." Then
>> I would take X = access. An do whatever memory collection I want! See?
> 
> No?

You have a user-defined access type. You can control everything related to
that type. What else you need to design a collector for such pointers?

>> There is absolutely no need to have built-in GC, if you have abstract
>> referential (access) interfaces. Note additional advantage: you can have
>> different GC's handling objects of same types in the same application!
> 
> But there is. Only under very restricted circumstances the necessity
> of deallocation can be decided locally. With reference sharing
> (representation sharing) between values (think Lisp-like lists -- and
> I think you need that for efficience reasons sooner or later -- you're
> either back to a "manual" reference counting scheme (inefficient) or
> you really need GC.

I don't see how "manual" is different from "implemented by the compiler
vendor." There is no magical GC hardware around... Each GC is reference
counting, only the ways of counting differ.

> I notice, that nobody that actually has tried
> FP doubts the superiority of the style in general (they are bitching
> about efficiency, sometimes, and availability of libraries, mor
> often).

It is a very strong argument. FP is even more niche than Ada, for that
matter.

> Yes, all languages in question are Turing complete. So you can always
> write a Lisp-interpreter and embed it etc. That, though, is not the
> point. It does not count wether I can do things "in principle" but how
> I can do them and how well the applied abstractions can be seen at a
> glance by somebody reading the code later. 

Yes, I fully agree, AND I don't want Lisp!

> BTW -- another argument _for_ a builtin list syntax.

Hey, Ada already has ()-brackets. Maybe our Unicode fans would propose
special glyphs for )), ))), )))), ))))), )))))) etc. Is it what you mean as
special syntax? (:-)) 

>> My feeling is that upward closures destroy the idea of type. However,
> 
> So how come that OCaml and Haskell have it? Those languages have a
> static type system. Without even RTTI ... :-)

How can anything be statically checked being a result of run-time
computation?

[ I don't consider a hidden argument to popularity, for it is obviously
flawed. Example: Visual Basic. ]

>> somehow we surely need type objects in some form, for making distributed
>> systems, for instance (how to marshal non-objects?)
> 
> Alice ML does it well. Usually they're just marschalling a cluster of
> blocks on the heap, but some languages (Alice ML) are more
> sophisticated.

Sending bytes over socket = does it well?

>>>> Let types-1 be values, make them values. Then they will need no
>>>> declarations, just literals. Soon you will discover some types-2 which
>>>> still require declarations. Make them values too. An so on. At some level n
>>>> you will have to stop. Now, rename type-n = "type". value, type-k<n =
>>>> "value". See? You are where you have started.
>>> 
>>> I do not understand your argument here. Care to give some example and
>>> I'll try write down how it is down in i.e. OCaml? Perhaps we're
>>> talking on cross purposes too, since I'm not sure I really wanted to
>>> desire the thing you insist I want. :-)
>>
>> You have the following hierarchy:
>>
>> values
> 
>> type-1 = types (sets of values + operations)
> 
> type = types?
>
> Either you have a type (IMHO) or types. A still fail to follow you here.

An example of a type is Integer.
 
>> type-2 = types of types (sets of types + operations to compose types)
>> type-3 = types of types of types (...)
>> ...
>> type-n
>> ...
>> type-oo
>>
>> [ value-k = type-k-1 ]
>>
>> As an example of type-2 you can consider parametrized types. Instances of
>> them are type-1 (=value-2). Types declared in generic Ada packages are
>> type-1. All of them considered together ("generic type") is a type-2.
>> Another example of type-2 in Ada is formal generic type:
>>
>> generic
>>    type T is range <>;
>>
>> "range <>" is type-2. The actual T is type-1 (=value-2).
> 
> Perhaps the problem is that with parametrized types you try to express a restriction of the kind
> 
>   List of something where something is in the followin family of types
>   ...

Parametrizing is a mapping:

   X : P1 x P2 x...x PN -> T

Here Pi are parameters, T is the set of types (which was denoted as
types-1). Clearly X is not a member of T, X(P1, P2, ..., PN) is. So
parametrized types cannot be types, at least immediately. You need some
equilibristics to bring mappings to or their equivalents into T, as well as
making Pi also members of T. I doubt it were possible in any mathematically
sane way.

> With parametrized types in an Hindley-Milner type systems things are
> vastly more simple: There is a 'general' 'anything' type and ther are
> concrete types. So we have:
> 
>  -  List of anything (really anything)

Which is pretty useless, because "really anything" has no operations =>
cannot be used in ANY way. To start with, anything has neither a "copy
constructor" nor "take pointer to." You cannot have a list of.

But in reality, it is something lesser than anything, and inability to
state what it is, in more or less clear way, is an obvious weakness of the
language.

>> I deny them as types-2. The huge advantage of pos.1 is that the result is
>> type-1. The consequence: you can have common values. With type-2 values
>> (value-1) of different values (type-1) of type-2 are of different types =>
>> you cannot put them into one container.
> 
> We must be talking on cross purposes. I admittedly do not understand
> most of the terminology you're using here and certainly cannot apply
> it here: Why come, the Hindley-Milner type systems have parametrized
> types and don't seem to labor under that kind of problem?

Hmm, I am not mathematician, so it is just a guess. I suppose this is a
part of the problematic Russell-Whitehead type theory and similar address,
while Goedel results prevent us from having "systems of anything." All in
all I think it is quite hopeless.
 
>>>> That should be interface inheritance from concrete types. Yes, Ada misses
>>>> that.
> 
> No, no, no. Inheritance should never ever decide on on a subtype
> relationship. It can't.

It is!

>> I don't see difference yet. When you inherit only interface, you drop all
>> the implementation or its parts. This is one issue.
> 
> I don't even need a implementation at the start.

Nobody forces you. However, there is a lot of cases when you are given a
concrete type and what to adapt it to something else.

> One point is, that
> the type fitting into a slot in a functor or as a paramter of a
> procedure might well never have been defined explicitely but is a
> result of type inference.

Why bother with types if you can infer them? I suppose, because you only
think you can...

> Why should anyone bother with inheriting
> interfaces from an implementation (espcially if that wouldn't give a
> guarantee as far as subtyping compatibility goes).

I don't care about LSP. Neither I consider Liskov's subtyping as a useful
definition of, for the reason you have mentioned. It is never satisfied.

>> Type inference, if you mean that, is a different one. I doubt that
>> inference is a right way.
> 
> And I don't. I'm actually convinced it is the right way.

I think it is a fundamentally flawed idea. You cannot infer anything
non-trivial. That's the first objection. The second is - even if you could,
then per definition of non-trivial, the reader of the program would be
unable to understand it. Ergo: either you don't need programmers or
inference [or else programs... (:-))]

>>> Since the contract can be broken by new methods anyway, the only thing
>>> that counts from a type safety point of view, is, not to break the
>>> abstraction to the underlying processor / VM, that is, to be able to
>>> call the methods with the right number of parameters and the right
>>> representation of the parameters (at the machine level). So the type
>>> signature is enough.
> 
>> This is a strange argument. Yes, you cannot verify the semantics, exactly
>> therefore types come into play. Type only names the behavior, so that it
>> can be checked formally *without* looking into actual behavior.
> 
> But it can't: If B derives from A I have no guarantee, none that B
> behaves a an A.

So? If B is declared as a subtype of A, then you, the programmer, are
responsible for B to behave as A. The meaning of this is not the language
business. Does 1 apple behave as 1 orange? Such questions are meaningless.

>>> It's really bothersome that one cannot supply a class X which is
>>> compatible to another class Y by just writing out the right methods. 
>>
>> This is interface inheritance + supertyping + inheritance. It works as
>> follows:
> 
> Really cumbersome. Why not just use the type signatur to decide on the
> compatibility?

Because named compatibility is much simpler A=A. As a programmer I don't
want to compare signatures, it adds nothing but complexity. Is 1+1=2? What
is 1, 1, =, +, 2? Does 2 have a signature?

>>>> I am not sure what you mean, but when 3 is considered as 1, then
>>>> dispatching on bare type tags might become possible.
>>> 
>>> 3? 1? Please elaborate? Is "dispatching on bare type tags" a good or a
>>> bad thing? You lost me there ... (my fault probably).
> 
>> You can consider type tag as a discriminant so pos.3 is a case of pos.1.
> 
> I still don't see the positions -- where is the numbering?

Because you commented them out! Here they are:

"...
1. Constrained subtypes (discriminants)
2. Implementation inheritance without values (type N is new T;)
3. Typed classes (T /= T'Class)
..."

>>> But my dear Dmitry -- What does your sentence "All strings have fixed
>>> length ..." mean than in this context, eh?
>>
>> That for any given X there exist a function X'Length. We should carefully
>> distinguish properties of values and types.
> 
> And in C this function is?

strlen

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

<lots of things>

Dmitry -- I notice I'm missing a lot of time at the moment and we're
loosing more and more track of the argument since our respective
experiences differ so much (please try a functional language with a
Hindley-Milner type system some time :-). I'll try to come back to
parts of that withing the next days, don't hesitate to nudge me, if I
forget, but just now I can't.

Ragards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Thu, 2007-02-01 at 15:22 +0100, Dmitry A. Kazakov wrote:
> On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:

> > I notice, that nobody that actually has tried
> > FP doubts the superiority of the style in general (they are bitching
> > about efficiency, sometimes, and availability of libraries, mor
> > often).

FP is superior to what? I'm saying this having had some fun writing
small OCaml command line tools. There are many good
libraries. And some things are just easy to write.

Hm. The compiler error message are as helpful as you
would expect from inference machines (on a par with Hugs or C++
template error messages). GHC has been improved in this regard.

But how would you know that those who have tried FP don't doubt the
superiority of the style? Any statistics? What does "in general" mean
here?  Are they really thinking that the inferior crowd doesn't write
recursive functions? Well, perhaps that is true... GCC does try to
eliminate tail calls, though, so maybe we can see a shift from
loops and counter manipulation towards recursive subprograms some day.
;-)

One of the great new pieces of Ada 2007 is Ada.Containers in my view
precisely because it permits what is taken for granted with FP or
with scripting languages: lists, tables, and sets, and ways to
use or write generic algorithms involving all of them.
There isn't a lot of curry in there, but much else.

To me, many of the FP advocates seem to be mathematicians. If you
look closely, two phenomena appear frequently in e.g. OCaml programs:

(1) Either they use functions assembly language(!!!),
(2) or they use reference types and assignments almost exclusively.

-> (1) can be attributed to the programmer being a mathematician:
function assembly is a game in logic. Might be fun. Is it easy?
What about review, changes, maintenance?

-> (2) is a strange thing: These are imperative programs, written
in some allegedly functional language, and they are written this way
because they will then run faster most of the time.
What would Peter Naur have to say about this von Neumann style?

Among FP advocates, there is always someone who just forces computers
to be abstracted into a function instead of considering what a
programmer MUST do and what most actual programming is all about:
manipulating the machine in operation, not manipulating some model of
functions.

So why doesn't someone tell the FP people to advocate a theory of
functions that

(a) match empirical comput*ers* better than they match some model
of comput*ation*.

(b) are no harder to analyze WRT O(?) than plain old procedures?

Wait, Haskell is trying (a) by capturing imperative statements
in monads. The chapter on fusions in Bird's Haskell book lets me
think that you add simplicity by mixing FP with imperative style
when memory or speed are a consideration.


> > BTW -- another argument _for_ a builtin list syntax.
> 
> Hey, Ada already has ()-brackets. Maybe our Unicode fans would propose
> special glyphs for )), ))), )))), ))))), )))))) etc. Is it what you mean as
> special syntax? (:-)) 

Actually, a syntax that is used in a theory book is
{left/right paren}{subscript i}.
The different lists of statements of an Ada program are marked using
more or less different pairs of brackets (if .. end if, loop .. end
loop, do .. end, ...).

What does a list syntax buy us if there is no argument pattern matching,
or no data structure pattern matching in Ada? Brevity?


> > One point is, that
> > the type fitting into a slot in a functor or as a paramter of a
> > procedure might well never have been defined explicitely but is a
> > result of type inference.
> 
> Why bother with types if you can infer them? I suppose, because you only
> think you can...

It is considered good Haskell style to list the function
type before the function. I like it being able to write OCaml code
that does the same:

let inc: int -> (int -> int) =
   fun k x ->
      x + k     (* (+) forces int anyway *)

Actually, to be more general and stylish, I could have written

# let inc binop increment arg = binop increment arg;;
val inc : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>

Hm. I wanted binop taking two 'as - the implementation might
change and require that binop be symmetric. When people
have used my inc with a binop taking different types,
they will have to change their programs too. Ouch.

So maybe I can think of some trick to make the inference
circuits assume binop takes two arguments of type 'a.
Or just write what I want and name the types!

How is this FP style superior, besides being brief and full of
assumptions?
Sure the function is a value that can be passed around freely,
and can be used in currying. OK. This is another technical
facility that is powerful.


generic
   type T is private;
   with function "+"(a, b: T) return T;
   increment: T;
function Inc(arg: T) return T;

function Inc(arg: T) return T is
begin
   return increment + arg;
end Inc;

Looks like more code, and I hear an FP advocate saying, "in FP,
you just ...". Any sentence that starts with "You just ..."
is suspicious :-)

Can I have this without generics, please, Dmitry? ;-)

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Thu, 2007-02-01 at 15:22 +0100, Dmitry A. Kazakov wrote:
>> On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:
>
>> > I notice, that nobody that actually has tried
>> > FP doubts the superiority of the style in general (they are bitching
>> > about efficiency, sometimes, and availability of libraries, mor
>> > often).
>
> FP is superior to what? 

Superior to not having "full" closures. WRT to abstracting over parts
of an algorithm / solution / component. The full context of this
comment of mine was:

> > >> If yout have only downward scopes for "closures" and memory allocation
> > >> this will, finally, interact badly with the fact that "implicit
> > >> (i.e. static type safe) casting" of classes is also only possible
> > >> downwards. My impression is, that all these things together rule out
> > >> some useful designs, that would otherwise possible. Or to say it
> > >> differenty: Object orientation w/o indeterminable scopes, upward
> > >> closures and GC doesn't work well. Some abstractions cannot be
> > >> implemented.

> > > Umm, I cannot tell. 

> > I think I can tell, but the discussion on this topic (what is
> > functional programming good for) does still rage on c.l.f and the
> > relevant mailing lists. I notice, that nobody that actually has tried
> > FP doubts the superiority of the style in general (they are bitching
> > about efficiency, sometimes, and availability of libraries, mor
> > often).



> I'm saying this having had some fun writing
> small OCaml command line tools. There are many good
> libraries. And some things are just easy to write.
>
> Hm. The compiler error message are as helpful as you
> would expect from inference machines (on a par with Hugs or C++
> template error messages). GHC has been improved in this regard.

>
> But how would you know that those who have tried FP don't doubt the
> superiority of the style? 

Admittedly, I don't. It's only difficult to dicuss the question wether
one would want to have e.g. closures, with people who haven't tried
it. As I wrote elsewhere: All common programming languages are Turing
complet, so equivalent. There is nothing that can be done in one that
could not be done in the other -- in principle. So there is nothing
like a proof "you cannot do X in language L" or "without feature
F". There is just how "easy" it is to express things and this is, to
an extend highly subjective.

> Any statistics? What does "in general" mean here?

My private head count. OK. I haven't proved it. 

> Are they really thinking that the inferior crowd doesn't write
> recursive functions?

> Well, perhaps that is true... 

Well, see, ..


> GCC does try to
> eliminate tail calls, though, so maybe we can see a shift from
> loops and counter manipulation towards recursive subprograms some day.
> ;-)

... as you see yourself, the language has to provide some support to
make that efficient as a general technique.

> One of the great new pieces of Ada 2007 is Ada.Containers in my view
> precisely because it permits what is taken for granted with FP or
> with scripting languages: lists, tables, and sets, and ways to

Yes, but in an imperative way. Still, it's progress, I completely
agree.

> use or write generic algorithms involving all of them.

> There isn't a lot of curry in there, but much else.

Currying is somewhat overrated, but's it's hardly the essence of FP.


> To me, many of the FP advocates seem to be mathematicians. If you

I studied physics when I were young ... 

> look closely, two phenomena appear frequently in e.g. OCaml programs:
>
> (1) Either they use functions assembly language(!!!),

What do you mean by that?

> (2) or they use reference types and assignments almost exclusively.

Don't know who "they" is here. Certainly not me nor Richard Bird nor
the Haskell crowd in general.

Yes, Ocaml, because of it's imperative elements has some potential to
get abused. Writing reusable components though, is, IMHO, done by
embracing a functional style.


> -> (1) can be attributed to the programmer being a mathematician:
> function assembly is a game in logic. Might be fun. Is it easy?

It's rumored to be accessible to certain optimization techniques. I
assume you mean the so called "point free style"?

> What about review, changes, maintenance?

Since point free style works well together with equational reasoning: A
big yes on all counts :-). Side effect free FP also makes it possible
to keep the old version for reference and for testing slave the old
and the new version together.

  let foo_old x y z = ... ;;
  let foo_opt x y z = ... ;;  (* new foo function, optimized *)

  let foo x y z =

      let old = (foo x y z) 
      and opt = (foo_opt x y z) 
      in 
         if not (old == opt) then raise (Testing_error "foo_opt");
         opt


This technique is too expensive and cumbersome in imperative
programming (yes, I tried it, it sucks, even for simple stuff).

> -> (2) is a strange thing: These are imperative programs, written
> in some allegedly functional language, and they are written this way
> because they will then run faster most of the time.

No. they don't as a general rule, but don't tell them :-).

> What would Peter Naur have to say about this von Neumann style?
>
> Among FP advocates, there is always someone who just forces computers
> to be abstracted into a function instead of considering what a
> programmer MUST do and what most actual programming is all about:
> manipulating the machine in operation, not manipulating some model of
> functions.

Programming, IMO, is not, manipulating the machine, but processing
data. 

>
> So why doesn't someone tell the FP people to advocate a theory of
> functions that
>
> (a) match empirical comput*ers* better than they match some model
> of comput*ation*.

What's your problem with that? I actually don't even see the problem
you're trying to address. Care to elaborate?  And shall we shift that
thread to c.l.f :-)). It's a bit quiet there at the moment.

> (b) are no harder to analyze WRT O(?) than plain old procedures?

They aren't.

> Wait, Haskell is trying (a) by capturing imperative statements
> in monads. The chapter on fusions in Bird's Haskell book lets me
> think that you add simplicity by mixing FP with imperative style
> when memory or speed are a consideration.

No, you don't add simplicity. Monad style by sequencing state through
the "operations" is just a ticket to grant the underlying compilation
system the opportunity to do more optimization. Monads, IMO, are not
imperative. They are a cute trick to enforce data flow by the type
system in such a way that state (the state of the world in case of the
IO monad) can be updated destructively by the VM or run time system
instead of having to retain the old value on the heap. Which would be
a bit difficult in case of the world state, anyway.


>> > BTW -- another argument _for_ a builtin list syntax.
>> 
>> Hey, Ada already has ()-brackets. Maybe our Unicode fans would propose
>> special glyphs for )), ))), )))), ))))), )))))) etc. Is it what you mean as
>> special syntax? (:-)) 

No.

>
> Actually, a syntax that is used in a theory book is
> {left/right paren}{subscript i}.
> The different lists of statements of an Ada program are marked using
> more or less different pairs of brackets (if .. end if, loop .. end
> loop, do .. end, ...).
>
> What does a list syntax buy us if there is no argument pattern matching,
> or no data structure pattern matching in Ada? Brevity?

Nothing. If you don't have the infrastructure to deal with lists in a
flexible way (functional lists, not containers) it doesn't buy you
much.


>> > One point is, that
>> > the type fitting into a slot in a functor or as a parameter of a
>> > procedure might well never have been defined explicitly but is a
>> > result of type inference.
>> 
>> Why bother with types if you can infer them? I suppose, because you only
>> think you can...

(I don't know what that is supposed to mean: The OCaml people must be
dreaming.)

> It is considered good Haskell style to list the function
> type before the function. I like it being able to write OCaml code
> that does the same,

>
> let inc: int -> (int -> int) =
>    fun k x ->
>       x + k     (* (+) forces int anyway *)


Yes, but you certainly do not declare all types of intermediate
results. Annotating function types is a good style, but again not for
short functions like

  let dup = List.map (f x -> (x,x))

>
> Actually, to be more general and stylish, I could have written
>
> # let inc binop increment arg = binop increment arg;;
> val inc : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c = <fun>
>
> Hm. I wanted binop taking two 'as - the implementation might
> change and require that binop be symmetric. 

I've problems with that "require". :-). If you use 'inc' in a module
interface you'll have to state it's type (will not be interfered. So
you have to decide early on in this case. In the other case it's not
part of the module interface, so not part of reusable component. So
nobody cares if it changes. "People" will not use it.,

> When people have used my inc with a binop taking different types,
> they will have to change their programs too. Ouch.

> So maybe I can think of some trick to make the inference
> circuits assume binop takes two arguments of type 'a.
> Or just write what I want and name the types!

> How is this FP style superior, besides being brief and full of
> assumptions?

Have your way: It's not. I don't want to make unwilling converts to
FP. FP and more to the point the Hindley-Milner type systems were only
a point to illustrate some things in my discussion with Dimitry where
he said, that things cannot be done differently than (...) etc. They
can, SML/OCaml/Haskell are the living proof. If anybody decides he/she
doesn't want it -- be free to ignore FP. But we started out (somewhere
in the middle) with the statement of Dmitry that one "wouldn't want
closures" (I'm quoting from memory) and that as a general statement
doesn't hold water. Therefore and to illustrate what you can do with
closures and a different type system my continued references to OCaml.

If it didn't convince you -- probably my fault. Nonetheless I refuse
to discuss merits of languages ot a micro level like:

> So maybe I can think of some trick to make the inference
> circuits assume binop takes two arguments of type 'a.
> Or just write what I want and name the types!

> How is this FP style superior, besides being brief and full of
> assumptions?

That is not FP. That is, essentially, your style when interacting with
OCaml and your problem.

> Sure the function is a value that can be passed around freely,
> and can be used in currying. OK. This is another technical
> facility that is powerful.

Yes, passing functions around is powerful. Having a 'a type is also
powerful. That's basically all I have been asserting. 

It helps a tiny bit not to have to declare the types of lists (a
parameterized type) all the time like in

   let l1 = List.rev (...) in ...

or

   let l2 = 5 :: l1 in ...

which make the use of parameterized types much less clumsy than if you
had to. So type inference is useful too, but of course good
annotations are good style. You're not forbidden to annotate, where
you think it helps understandability.

>
> generic
>    type T is private;
>    with function "+"(a, b: T) return T;
>    increment: T;
> function Inc(arg: T) return T;
>
> function Inc(arg: T) return T is
> begin
>    return increment + arg;
> end Inc;
>
> Looks like more code, and I hear an FP advocate saying, "in FP,
> you just ...". Any sentence that starts with "You just ..."
> is suspicious :-)

And why is that so? I mean: My screen has only N (finite number)
lines. So more verbosity of that type actually diminishes by ability
to have a clear view at the code. Brevity can be a boon. (I don't say
it is always, but you can't dismiss it out of the hand).

To me any sentence that effectively says: "Look I can do that in X,
too" where X is something from {C, FORTRAN, Ada, Fortran, C++, Java,
Lisp, Scheme} is suspicious. Because, as I tried to explain above,
that is not the point: All languages are Turing complete. What really
counts is HOW you do it. And especially the Ada community should know
that, since Ada cannot do MORE things than C or C++: It only makes
doing the same things less error prone, supposedly.


> Can I have this without generics, please, Dmitry? ;-)

:-)) hehe.

Regards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Thu, 2007-02-01 at 18:36 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Thu, 2007-02-01 at 15:22 +0100, Dmitry A. Kazakov wrote:
> >> On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:
> >
> >> > I notice, that nobody that actually has tried
> >> > FP doubts the superiority of the style in general (they are bitching
> >> > about efficiency, sometimes, and availability of libraries, mor
> >> > often).
> >
> > FP is superior to what? 
> 
> Superior to not having "full" closures. WRT to abstracting over parts
> of an algorithm / solution / component. The full context of this
> comment of mine was:
> 
> > > >> If yout have only downward scopes for "closures" and memory allocation
> > > >> this will, finally, interact badly with the fact that "implicit
> > > >> (i.e. static type safe) casting" of classes is also only possible
> > > >> downwards. My impression is, that all these things together rule out
> > > >> some useful designs, that would otherwise possible. Or to say it
> > > >> differenty: Object orientation w/o indeterminable scopes, upward
> > > >> closures and GC doesn't work well. Some abstractions cannot be
> > > >> implemented.
> 
> > > > Umm, I cannot tell. 
> 
> > > I think I can tell, but the discussion on this topic (what is
> > > functional programming good for) does still rage on c.l.f and the
> > > relevant mailing lists. I notice, that nobody that actually has tried
> > > FP doubts the superiority of the style in general (they are bitching
> > > about efficiency, sometimes, and availability of libraries, mor
> > > often).
> 
> 
> 
> > I'm saying this having had some fun writing
> > small OCaml command line tools. There are many good
> > libraries. And some things are just easy to write.
> >
> > Hm. The compiler error message are as helpful as you
> > would expect from inference machines (on a par with Hugs or C++
> > template error messages). GHC has been improved in this regard.
> 
> >
> > But how would you know that those who have tried FP don't doubt the
> > superiority of the style? 
> 
> Admittedly, I don't. It's only difficult to dicuss the question wether
> one would want to have e.g. closures, with people who haven't tried
> it. As I wrote elsewhere: All common programming languages are Turing
> complet, so equivalent. There is nothing that can be done in one that
> could not be done in the other -- in principle. So there is nothing
> like a proof "you cannot do X in language L" or "without feature
> F". There is just how "easy" it is to express things and this is, to
> an extend highly subjective.
> 
> > Any statistics? What does "in general" mean here?
> 
> My private head count. OK. I haven't proved it. 
> 
> > Are they really thinking that the inferior crowd doesn't write
> > recursive functions?
> 
> > Well, perhaps that is true... 
> 
> Well, see, ..
> 
> 
> > GCC does try to
> > eliminate tail calls, though, so maybe we can see a shift from
> > loops and counter manipulation towards recursive subprograms some day.
> > ;-)
> 
> ... as you see yourself, the language has to provide some support to
> make that efficient as a general technique.
> 
> > One of the great new pieces of Ada 2007 is Ada.Containers in my view
> > precisely because it permits what is taken for granted with FP or
> > with scripting languages: lists, tables, and sets, and ways to
> 
> Yes, but in an imperative way. Still, it's progress, I completely
> agree.
> 
> > use or write generic algorithms involving all of them.
> 
> > There isn't a lot of curry in there, but much else.
> 
> Currying is somewhat overrated, but's it's hardly the essence of FP.
> 
> 
> > To me, many of the FP advocates seem to be mathematicians. If you
> 
> I studied physics when I were young ... 
> 
> > look closely, two phenomena appear frequently in e.g. OCaml programs:
> >
> > (1) Either they use functions assembly language(!!!),
> 
> What do you mean by that?
> 
> > (2) or they use reference types and assignments almost exclusively.
> 
> Don't know who "they" is here. Certainly not me nor Richard Bird nor
> the Haskell crowd in general.
> 
> Yes, Ocaml, because of it's imperative elements has some potential to
> get abused. Writing reusable components though, is, IMHO, done by
> embracing a functional style.
> 
> 
> > -> (1) can be attributed to the programmer being a mathematician:
> > function assembly is a game in logic. Might be fun. Is it easy?
> 
> It's rumored to be accessible to certain optimization techniques. I
> assume you mean the so called "point free style"?

Yes, though whether or not there a points and parentheses is not
important.

> Side effect free FP

This is a plus. However, if you mark the variables involved
in creating side effects, as is done in SPARK, you can match
the result with a synthesized pure function, I think.
A reasoning function that takes the global variable as input.


>   let foo x y z =
> 
>       let old = (foo x y z) 
>       and opt = (foo_opt x y z) 
>       in 
>          if not (old == opt) then raise (Testing_error "foo_opt");
>          opt
> 
> 
> This technique is too expensive and cumbersome in imperative
> programming (yes, I tried it, it sucks, even for simple stuff).

?

   function foo(x, y, z: natural) return Integer is
        old: integer renames foo_old(x, y, z);
        opt: integer renames foo_opt(x, y, z);
      begin
        if not (old = opt) then raise Testing_error with "foo_opt"; end if;
        return opt;
      end;


> Programming, IMO, is not, manipulating the machine, but processing
> data. 

Well, and what is processing data?


> > So why doesn't someone tell the FP people to advocate a theory of
> > functions that
> >
> > (a) match empirical comput*ers* better than they match some model
> > of comput*ation*.
> 
> What's your problem with that? I actually don't even see the problem
> you're trying to address. Care to elaborate?  And shall we shift that
> thread to c.l.f :-)). It's a bit quiet there at the moment.

de.c.l.f is probably even more silent, but there are some
important references to Ada here: the Ada language is about computers,
given all the systems programming stuff, all the rules about
what is happening and when, representation, order of elaboration,
addressing multiprocessor systems, time types, etc. etc..

OTOH, there is little reasoning about equations in the vicinity of
Ada, is there? And what _is_ reasoning about equations? It is us
at work. (When we are "computers" in the old sense of the word.)
We *operate* when we reason, even when we reason about equations,
we try to *follow* what is going on. There is always one of a number
of possible *orders* of "evaluation" in

foo r = pi * d
  where pi = 3.14159
        d = 2 * r

no matter whether we bother to concentrate on the where clause first
or start with concentrating on the main clause of the equation etc..

I hear the comput*ing* scientist and the Haskell fan say:
--- But this is the important thing in a equation, you needn't
    worry!
Then I say, 
--- But computers have 1 or more sequential processors, and one thing
    happens after another. There are *operations* inside a computer.
    They take time and space, and they have effects. I must coordinate
    these effects.
I hear,
--- Just use strict if you must! Or monads. Why do you want to reason
    about what is going on, anyway?
And here the comput*er* plays its part.
--- Because I don't have the luxury of abstracting time away. And not
    space either. If you can follow computing steps at leisure, fine.
    If you are done once you have declared the timeless static
    connection between two sets of values, and call it a function,
    fine. I'm not done yet.

The next answer I will get is, well, try fold_left, or fold_right,
depending on the situation, or try this finding, etc., we don't know
exactly what is going on but it usually suffices. And the result is
correct, provided it can be computed on this machine.
  Ada.Containers, or the STL are more helpful in this regard because
they allow some amount of predictability of runtime *behavior*.
That an input value corresponds to an output value of some function
is a necessary but not a sufficient precondition. It is not important
*that* it will be computed, but *how* it will be computed. Sad but
true. And not for reasons of optimization, but because time and
space are almost always an essential parts of a problem specification.

Time and space are not normally considered the hall mark
of equational reasoning in FP. I think it is safe to say that
when you write a real-time application in Ada, you will be
thinking about time and space all the time, and you want this
task to be straight forward. As few implicit things as possible.

> 
> > (b) are no harder to analyze WRT O(?) than plain old procedures?
> 
> They aren't.

I meant that the behavior of lazy programs is harder to analyze,
or has there been an advance recently?

> > Wait, Haskell is trying (a) by capturing imperative statements
> > in monads. The chapter on fusions in Bird's Haskell book lets me
> > think that you add simplicity by mixing FP with imperative style
> > when memory or speed are a consideration.
> 
> No, you don't add simplicity.

I meant, if you write some of the I/O parts in a systems programming
language like Ada, you increase simplicity and efficiency of the
resulting program when compared to an FP only program that uses
fusions.  I think that Ada *and* Haskell will make an interesting
combination on .NET.

>  Monads, IMO, are not
> imperative. They are a cute trick [...]
> that state [...]
> can be updated destructively .

Uh, I thought this very issue is what von Neumann style is about?
Hence what imperative is about.


> > How is this FP style superior, besides being brief and full of
> > assumptions?
> 
> Have your way: It's not. [...] be free to ignore FP.

I'm serious about this. I don't ignore FP. When I have to
make a change, when the module structure needs to be reworked, when
the program fails for some inputs, am I really more productive
using FP? I can't say right now.
  A more important reason not to ignore functional programming
is that it teaches a different programming style. Recursion
and its approach to iteration is well worth being studied,
as it helps simplifying some algorithms.

>  I refuse
> to discuss merits of languages ot a micro level like:

The "micro" level is the level of production, change, and correction.


> > How is this FP style superior, besides being brief and full of
> > assumptions?
> 
> That is not FP. That is, essentially, your style when interacting with
> OCaml and your problem.

FP is brief and full of assumption because they set out
to safely save the work of writing things down - technically.
It's also typical math style: what is "obvious" to the insider
needs not be said. What is "obviously" a complete expression
needs not be terminated. This leads to undecipherable error
messages when you forget to place one missing token to complete
an expression that is the last thing in a function definition.
This is part of the problem that is *made* my problem by a
functional language such as ML. ML's syntax is so terribly broken
that even Andrew Appel has added a few paragraphs to his Critique
explaining what parts of ML should really be dumped and replaced.

This costs time and money.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

<...>

Well another long reply which will have to be read and replied to
carefully. I won't have the time today, so just some asides that can
stay short.

> Time and space are not normally considered the hall mark
> of equational reasoning in FP. I think it is safe to say that
> when you write a real-time application in Ada, you will be
> thinking about time and space all the time, and you want this
> task to be straight forward. As few implicit things as possible.

Mayhaps when you write real-time application. I, at least, I'm not
talking about real-time application. AFAIR Ada was conceived as rather
general programming language. If we restrict ourselves to real-time
programming today -- fine -- then the question "How come Ada isn't
more popular?" is already answered in a sense. Additionally all that:
"Uuuh, look they (let's say: the open source people, as somebody in
this thread did) they are using C or C++. My God, how can they." All
that is quite supeflous than, since

In revers I conclude Ada programming is not about real-time
programming only. At least to me that seems seems to be the ambition a
significant number of people at c.l.a still have. At least in theory.

Regards -- Markus

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:


>> > (b) are no harder to analyze WRT O(?) than plain old procedures?
>> 
>> They aren't.
>
> I meant that the behavior of lazy programs is harder to analyze,
> or has there been an advance recently?

I doubt that it was so difficult generally. But I do not have any
privileged information about that.

Let me say it like this: The O(?) behaviour of a lazy construction in
general can be analyzed (I think) with the same degree of difficulty
as the behaviour of an imperative program. Actually you'd be surprised
how many simple imperative algorithms are at least not easy and
straight forward to analyse. As far as exact numbers go, you might be
right in that it is difficult to calculate exact coefficients. But
again that hardly does matter: The decision for an imperative languge
because it might easier to optimize or to analyse run time behaviour
is, in my eyes a typical case of prematuire optimization (as any
choice of language within a resonable base on base of opportunities to
optimize).

Regards -- Markus

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

>> > Wait, Haskell is trying (a) by capturing imperative statements
>> > in monads. The chapter on fusions in Bird's Haskell book lets me
>> > think that you add simplicity by mixing FP with imperative style
>> > when memory or speed are a consideration.
>> 
>> No, you don't add simplicity.
>
> I meant, if you write some of the I/O parts in a systems programming
> language like Ada, you increase simplicity and efficiency of the

> resulting program when compared to an FP only program that uses
> fusions.  I think that Ada *and* Haskell will make an interesting
> combination on .NET.

I wonder why one wouldn't just use Monads in most cases?

>
>>  Monads, IMO, are not
>> imperative. They are a cute trick [...]
>> that state [...]
>> can be updated destructively .
>
> Uh, I thought this very issue is what von Neumann style is about?
> Hence what imperative is about.


IMHO: no. Of course every functional interpreter / VM runs in an
imperative world: After all the past is really lost, that is,
destroyed. The question is how to maintain the (useful) functional
illusion when interacting with systems that can only be updated
destructively (e.g. the world). The IO Monad and its relatives are the answer.

But those Monads are not just an imperative kludge at the top of a
functional language as number of people seem to think. A Monad is a
beautiful thing. It contains only functions and rules to compose
functions and as such is purely functional. The typing just happens to
be arranged in a way the every world value can only be passed once to
a function and never be bound to an identifier. Thus it looks like
imperative programming but it is purely function -- or to put it
differently: The type systems restricts program construction to a
subset of the full functional language that is isomorphic to some
imperative language.


>
>
>> > How is this FP style superior, besides being brief and full of
>> > assumptions?
>> 
>> Have your way: It's not. [...] be free to ignore FP.
>
> I'm serious about this. I don't ignore FP. When I have to
> make a change, when the module structure needs to be reworked, when
> the program fails for some inputs, am I really more productive
> using FP? I can't say right now.

I think I can say. I've written and deployed programs in Ada, C, C++,
Perl and OCaml (among others). And I've played around with Haskell. I
think I'm more productive with FP than with C and Ada. I don't say
this to denigrate Ada: But I often do ad-hoc programming driven by
what works at the moment. What really appeals to me under those
circumstances is the way I can 'morph' working OCaml programs into
other equivalent OCaml programs. What also appeals to me (that is not
a property of FP per se, though Haskell, OCaml, most Schemes, have it)
is the ability to interact with the code (modules, libraries) I've
written in a command line to immediately test the results of changes
(have I broken anything just now?).

>  A more important reason not to ignore functional programming
> is that it teaches a different programming style. Recursion
> and its approach to iteration is well worth being studied,
> as it helps simplifying some algorithms.

Recursion is the least of those reasons. What is IMHO more important
is, that you start not to think about mutating variables but producing
new values from give ones (a slight shift in perspective, but with
real impact at the long run).


>>  I refuse
>> to discuss merits of languages ot a micro level like:
>
> The "micro" level is the level of production, change, and correction.

I think you just did that at least one level too far down. Defining
'inc' or stuff like this doesn't give you any insight into functional
programming. I'm at a loss, though, to teach or tell you what to do to
get that insight. As you have noticed, FP appeals to
mathematicians. I'Ve mathematical background and I've some wildly
different pasts, but one of them was concerned with formal
specification. FP just came naturally to me: It mirrors the way I
think about a problem and about the solution to problems. The rest is
optimization: Eliminating double evaluations or even mutating
variables if that is needed for efficiency. But the first draft is
functional and stays the point of reference.

>
>
>> > How is this FP style superior, besides being brief and full of
>> > assumptions?
>> 
>> That is not FP. That is, essentially, your style when interacting with
>> OCaml and your problem.

> FP is brief and full of assumption because they set out
> to safely save the work of writing things down - technically.

I fear your full of preconceptions. It's different from what you do in
Ada (or whatever your favourite imperative language is), so it must be
wrong or there must be something missing.

As an FP advocate, I suggest, that the things not written down, are
not necessary. So those "savings" you address as a defect are actually
a chance. 

But YMMV. As I said: I'm not in the business of convincing people WRT
FP. You already indicated that you would not accept the typical
reasoning of an FP protagonist. I can't offer you something different:
It's shorter, I can see the problem clearer, I can leave out redundant
information and so on.

Listening to you justifying that every, every variable must be
declared with type and all, one wonders hoe mathematics itself ever
could live without type declarations. But if

   Let V be a vectorspace. (* defining a name and its type *)

then

   Let v \n V

is just enough to know v is a vector. Saying

   Let v: Vector with v \ V.

is just superfluous. The same principle applies here: The type, what
the symbol is and in which context it is embedded, in which operations
it can occur, can be inferred. No need to declare more.

The same principle applies in FP. I fear it won't convince you.


> It's also typical math style: what is "obvious" to the insider
> needs not be said. What is "obviously" a complete expression

You can also hide what you want to express under a lot of superfluous
drivel (type declarations that can be inferred or at the worst be
queried from the interactive system). FP has set the cut off at a
different point than Ada. Question: Was that necessarily wrong? It
fits me. Does that make be a worse programmer / designer / software
engineer / mathematician? I don't think so.

> needs not be terminated. This leads to undecipherable error
> messages when you forget to place one missing token to complete
> an expression that is the last thing in a function definition.

I fear that hardly happens to me in OCaml. Partly because I compile
often and develop code over a number of intermediate scaffolding
stages which all type check properly. BTW: I had to use the same
approach with Ada, since in the presence of overloading and tagged
types the error messages can be become quit misleading, at least with
Gnat.

> This is part of the problem that is *made* my problem by a
> functional language such as ML. ML's syntax is so terribly broken

You know, I rather use OCaml for practical reasons (I like the object
system). But my experience is that it is the beginners that are most
obsessed with the "broken syntax". Related to that are the repeating
attempts on c.l.f. or c.l.l to suggest a new syntax surface for Lisp
"without all so parenthesis", implying that would hugely further the
proliferation of Lisp. There is, I think, already a c.l.l FAQ for
this. Though the attempts to reform ML syntax happen less often, they
happen and I count them under the same heading as those Lisp reform
attempts.

I think it would be rather simple to design a pascalish language whose
semantics is just declared by transformation to ML. I was tempted some
times to do it myself. But really: What would that buy me? Investing
the same time into understanding more ML / OCaml / Haskell will earn
me much more.

> that even Andrew Appel has added a few paragraphs to his Critique
> explaining what parts of ML should really be dumped and replaced.


Let me quote from the abstract of that paper:

   Standard ML is an excellent language for many kinds of
   programming. It is safe, efficient, suitably abstract and
   concise. There are many aspects of the language that work
   well. However, nothing is perfect: Standard ML has a few
   shortcomings. In some cases there are obvious solutions, and in
   other cases further research is required.

So we are talking about somebody intimately acquainted with the
language and the research on that language, striving for an
improvement. Talking that as ground (as a mere novice!) to say: "Nah,
that language is terrible, let's look for something different, at
least not start with this" strikes me as daring, even blind.

I suggest you really read the paper you quoted: He has some nice
things to say about the necessity of GC and the people who don't like
the "bizarre syntax" of ML. At the end of that paragraph he says: "But
in general, don't we have better things to argue about than syntax?".

Duh!

Actually the paper is a good defense why one should use an FP (or
something very similar) EXCEPT he/she explicitly has different
requirements.

Your approach seems to be more the Olde FORTRAN Programmer's approache:
I can do it in [...] so why must I use/learn another language.

I fortunately have learned FP at a time when I could see it as fun,
instead of having to defend myself against having to learn it. On the
other side I'm one of the perverts that sit down in a quiet hour and
write down mathematical proofs just for the joy of it. (Proves your
hypothesis about mathematicians and FP, probably.)

> This costs time and money.

Well -- every legacy feature does. Tell me, Ada has none :-).

Regards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Fri, 2007-02-02 at 00:40 +0100, Markus E Leypold wrote:
> 
> 
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
>   I think that Ada *and* Haskell will make an interesting
> > combination on .NET.
> 
> I wonder why one wouldn't just use Monads in most cases?

You wouldn't just use Haskell and monads for at least two reasons:

- used in a natural way, Haskell equations (incl. monads) still
  turn out to be comparatively slow. See Darcs (I am a Darcs user).

- control over what is going to happen at what time is easier using
  a systems programming language.


> I've written and deployed programs in Ada, C, C++,
> Perl and OCaml (among others). And I've played around with Haskell. I
> think I'm more productive with FP than with C and Ada.

It will be most interesting to learn the specifics of what makes
you more productive using OCaml instead of Ada etc, language-wise.


> >  A more important reason not to ignore functional programming
> > is [... ] Recursion

> Recursion is the least of those reasons. What is IMHO more important
> is, that you start not to think about mutating variables but producing
> new values from give ones (a slight shift in perspective, but with
> real impact at the long run).

Yes, you replace thinking about updates to a variable by
thinking about values passed, and their relations.
Now unless you write a straight line program, this won't
work without recursion :-)

Thinking about function values and their combinations
like map + filter is another good thing to learn (and use).

OTOH, FP style is sometimes just assignment in disguise.
It hides the variable as a parameter (and relies on TCElimination)
in a sense. I don't think this is always easier to follow:

  function Sum(L: Cursor; Variable: Integer := Initial_value)
      return Integer is
  begin
      if Has_Element(Cursor) then
          return Sum(Next(L), Variable + Element(L));
      else
          return Variable;
      end if;
  end Sum;

  function Sum(L: Cursor) return Integer is
      Variable: Integer := Initial_Value;
  begin
      while Has_Element(L) loop
          Variable := Variable + Element(L);
          Next(L);
      end loop;
      return Variable;
  end Sum;

(Yes, a true FP Sum function is composed, taking a binop as a parameter
for folding and you make it a base-case-step-macro in Lisp ;-)
I still think
that it is just a bit more difficult to follow the first Sum. If you
want to know how Sum is going to arrive at a result then you have to
follow the history of Variable through a series of function
calls with a series of changing arguments (the induction step).
In the second Sum you see the history of Variable without following
the mechanics of a function call and it is still just one place
where Variable is modified. It's less hidden behind the "function
call screen".
  Still I much prefer the recursive, nested narrowing
function in my Binary_Search -- even though the loop
based variant is faster with some Ada compilers :-)

It's certainly easier to see that the first Sum matches
a primitive recursive function if and when this is important.


> >>  I refuse
> >> to discuss merits of languages ot a micro level like:
> >
> > The "micro" level is the level of production, change, and correction.
> 
>  As you have noticed, FP appeals to
> mathematicians.

Yes, FP has a mathematical appeal. However, time and space
are not usually intrinsic parts of mathematical functions. This is
what I am trying to point out: a computer program operates in time
and space, it is not a mapping between two sets of values,
even though you can interpret the operating program this way.
  A "functional solution" is still very helpful as a reference,
just like you said. For example, a functional solution helps me stay
sane maintaining one of my longer Perl programs that takes about 35 min
on average to compute a number of rankings from some larger database
tables. :) But sometimes a functional solution is only a starting
point, a necessary precondition. It provides guidance when writing
the real thing.

At other times, a functional program is just fine, provided
the author follows the usual conventions: Don't leave out that
much, it won't hurt if you say what you mean.


> I'Ve mathematical background [...]. FP just came naturally to me:
> It mirrors the way I
> think about a problem and about the solution to problems.

For example, a Haskell program can be an executable specification.
Unfortunately, this may not be good enough because what you call the
"rest" is *not* optimization.
It is meeting the requirements, even when these requirements are
"Start no sooner than 22:00h, be ready before 23:00h."
Time and space are intrinsic parts of a solution. If the problem
specification includes time and space, a complete solution must
in effect provide time and space values as well. (Make self-referential
considerations WRT time and space when computing, so to speak.)

The meaning of the word "optimization" is, I think,
to improve existing solutions so they run faster, consume
less resources, are easier to understand, etc.
Optimization does *not* mean to turn something that isn't a solution
into a solution.

This is what mathematicians refuse to see, as far as I can tell.
The stigmatize time and space as being just "optimization" issues.
They are not. In programming, a function is more than an equation
over some field that excludes time and space.



> I fear your full of preconceptions. It's different from what you do in
> Ada (or whatever your favourite imperative language is), so it must be
> wrong or there must be something missing.

Why would I be writing programs in OCaml, then?

> As an FP advocate, I suggest, that the things not written down, are
> not necessary.

FP error messages get better in the presence of explicit types.
Redundant semicolons can help the functional compilers a lot
in figuring out where there is an error in the program text.
Not necessary?
Or are FP programmers of the compiler writer type who hardly
need a robust language?


>  So those "savings" you address as a defect are actually
> a chance. 
> 
> But YMMV. As I said: I'm not in the business of convincing people WRT
> FP. You already indicated that you would not accept the typical
> reasoning of an FP protagonist. I can't offer you something different:
> It's shorter, I can see the problem clearer, I can leave out redundant
> information and so on.

That's the point: it's you who sees clearly, you leave out what seems
redundant to you, etc.. But those other guys, trying to understand
your program, will have to repeat your arrival at a clear sight, 
they will have to iterate the learning process that makes things
seem redundant to you, etc..
The usual answer I got when asking about this is, well, I need
educated colleagues with skills at about the same level as mine.
Sometimes that seemed just true, sometimes that's snobbish,
in some cases it has seemed to express pride. It has also been
an attempt of a programmer to make himself irreplaceable.


> Listening to you justifying that every, every variable must be
that's an exaggeration
> declared with type and all, one wonders hoe mathematics itself ever
> could live without type declarations.

Mathematicians use explanatory sentences and bibliographic references
as a replacement for declarations. So they do declare.
Only the declarations are semi-formal in many cases like you show
in your example. After "Let V be a vectorspace", V is declared,
is in scope, and references to V will just name V of type vectorspace.


> The same principle applies in FP. I fear it won't convince you.

Where FP authors follow the conventions of good style, 
they list a function's type, or they add a semi-formal comment,
or both. Why would they do that if these things are redundant
and should therefore be left out?

> FP has set the cut off at a
> different point than Ada. Question: Was that necessarily wrong?

No, not wrong. It just has consequences to leave things out.

>  It
> fits me. Does that make be a worse programmer / designer / software
> engineer / mathematician? I don't think so.

Imagine an engineer writing programs and documenting his
assumptions even though he thinks they are redundant because
they can be inferred from some context. Worse or better? Why?

Imagine a script author who has to get some data laundry job
done. Would he/she be well advised to write a program that
can be reused, with all bells and whistles, good types, OO
encapsulation? Or just use a bunch of lists, tables, and
regular expressions? (What's the probability of a once-program
becoming an n-times-program, anyway, in reality?)



> > needs not be terminated. This leads to undecipherable error
> > messages when you forget to place one missing token to complete
> > an expression that is the last thing in a function definition.
> 
> I fear that hardly happens to me in OCaml.

I think it's really not important what happens to you and me here.
What is important is what happens to the amount of available
money to pay us until we arrive at an error-free solution.
How much time is spent by the programmers when correcting
mistakes, and how do OCaml and Ada compare in this case in
typical settings?

The error messages of the Erlang system can be even
more obscure. Some of them are printed at run time.
Sometimes there isn't a message at all ... Still, the language
is somewhat minimal and Erlang can help solve some problems
quickly provided the Erlang programmer knows the language, the
libraries, and the system and its quirks.

If you write Erlang programs, you *must* be able to say,
"I fear that hardly happens to me in" Erlang. Otherwise
you will be lost tackling errors you don't understand
because there is comparatively little "redundant" information
in Erlang programs.


> the presence of overloading and tagged
> types the error messages can be become quit misleading, at least with
> Gnat.

It can be.


>  But my experience is that it is the beginners that are most
> obsessed with the "broken syntax".

Of course the beginners complain! Just like when someone switches
from permissive C to unforgiving Ada. But is't not the syntax
of Ada that seems to cause difficulties.

>  Related to that are the repeating
> attempts on c.l.f. or c.l.l to suggest a new syntax surface for Lisp
> "without all so parenthesis", implying that would hugely further the
> proliferation of Lisp. There is, I think, already a c.l.l FAQ for
> this.

I know, and it has taken me some time an effort to make
some proponents of Lisp syntax see the problem in the first place.

(Usual suggestions: If you run into "syntax error at end
of file", just fire up your Lisp system's editor, some function
will look "skewed" and point you near to where a ')' is missing.
Well...)



>  Though the attempts to reform ML syntax happen less often, they
> happen and I count them under the same heading as those Lisp reform
> attempts.

You cannot take pride in having mastered a syntax that is no
challenge. :-)


> But really: What would that buy me? Investing
> the same time into understanding more ML / OCaml / Haskell will earn
> me much more.


> Let me quote from the abstract of that paper:
> 
> ...
> So we are talking about somebody intimately acquainted with the
> language and the research on that language, striving for an
> improvement.

That's why I quoted the paper. It does explain why ML is important.
And that too little attention has been given to syntax.


> I suggest you really read the paper you quoted:

I did, I usually read the papers I quote before I argue ;-)

>  He has some nice
> things to say about the necessity of GC and the people who don't like
> the "bizarre syntax" of ML. At the end of that paragraph he says: "But
> in general, don't we have better things to argue about than syntax?".

Syntax is structuring our communication.
We have important things to achieve, and just ignoring syntax
won't make us more effective. But since we are starting to throw
papers at each other, here is another, more or less empirical one,
talking about programmers discussing(!) irrelevant syntax:)

"Of the pretense (syntax is irrelevant) and the actual reaction
(syntax matters), the one to be believed is the actual reaction.
Not that haggling over parentheses is very productive, but
unsatisfactory syntax usually reflects deeper problems, often
semantic ones: form betrays contents.

"Experienced programmers, so the argument goes,
will never make the error. In fact they make it often.
A recent review of the BSD operating system source..."
-- Betrand Meyer, Principles of language design and evolution, §8

The last sentence is about '=' in C comparisons. '=' has caused a
problem in ML, too.  Hm, perhaps everything coming out of Bell
Labs must continue Bell Labs traditions. SNOBOL4 has '=', C has
it so C++ has it, Aleph has it, Limbo, too IIRC. So maybe ML has
had to have the '=' trouble maker, too.

> Your approach seems to be more the Olde FORTRAN Programmer's approache:
> I can do it in [...] so why must I use/learn another language.

Not at all. What makes you think so?

> > This costs time and money.
> 
> Well -- every legacy feature does. Tell me, Ada has none :-).

In the case of OCaml, there is at least camlp4. I understand nobody
seems to want the revised syntax? Not cool? Herd instinct?
Fear of change? "No, it's not necessary, we have learn-ed ouR
working in-group syntax."

I only wish someone could win the lottery and have some language
designers work on the formal principles of sound syntax for industry
programming languages.

Instead, legacy syntax is reintroduced again and again, by
the same people who argue it doesn't matter because they have
finally learned to work around the broken syntax.
So why not again use the broken syntax? Professional
programmers get bitten by the syntax bugs again and still
continue to claim this isn't important...

A few weeks ago a colleague explained he always writes

if (expr == false)
{

because a '!' can be hard to see. I told him he could always use

if (!!!expr)
{

...

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sat, 03 Feb 2007 17:54:53 +0100, Georg Bauhaus wrote:

> A few weeks ago a colleague explained he always writes
> 
> if (expr == false)
> {
> 
> because a '!' can be hard to see. I told him he could always use
> 
> if (!!!expr)
> {

Funny, I am almost always write

   if (0 == expr)
   { 

(and "false", that's not C anyway! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Fri, 2007-02-02 at 00:40 +0100, Markus E Leypold wrote:
>> 
>> 
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>>   I think that Ada *and* Haskell will make an interesting
>> > combination on .NET.
>> 
>> I wonder why one wouldn't just use Monads in most cases?
>
> You wouldn't just use Haskell and monads for at least two reasons:
>
> - used in a natural way, Haskell equations (incl. monads) still
>   turn out to be comparatively slow. See Darcs (I am a Darcs user).

Darcs is slow because it partly uses algorithms with O(n^k) with big
k's or even exponential run time. It's not a I/O or monad problem as I
have understood.

> - control over what is going to happen at what time is easier using
>   a systems programming language.

Sigh. I can't convince you here. There is no reason to assume the
necessary level of control cannot be achieved with a language like
Haskel. Given it has to me achieved at all.

But I also notice a loss of context. You were talking about fusions
and I said "I wonder why one wouldn't just use Monads in most
cases?". You way to quote that back on me somehow mangles that
context.

>> I've written and deployed programs in Ada, C, C++,
>> Perl and OCaml (among others). And I've played around with Haskell. I
>> think I'm more productive with FP than with C and Ada.
>
> It will be most interesting to learn the specifics of what makes
> you more productive using OCaml instead of Ada etc, language-wise.

How do I know? I just obeerve it, that it is so and I can of course
speculate why that is so. But what I experience is not a controlled
experiment and I will be met with responses that tell me, it can't be
that this is the reason or even that I'm more productive, because
<theory of your choice>.

My to points:

  - The ML-typesystem (specifically the OCaml way to integrate
    objects) is safe w/o forcing you to through contorsion in the more
    abstract cases as. i.e. Java or Ada in their way to implement
    classes. This seems to be an effect how classes work together and
    see each other and cannot be seen with examples involving only 1
    or 2 classes.

  - GC really is a boon if objects recursively refer to each other (A
    calls be an vice versa). Their life cycle is somehow coupled and
    there seems to be no general (!) way on deciding who needs to
    deallocate whom. 

  - What I like very much is type inference if used right. Parametric
    polymorphism allows be to concentrate on the aspect at hand and
    not to have to concern myself with properties of data that are not
    relevant for the algorithm.

  - It's really easy to refacto functional programs incrementally by
    morphing over a number of correct intermediate stages. 

>
>> >  A more important reason not to ignore functional programming
>> > is [... ] Recursion
>
>> Recursion is the least of those reasons. What is IMHO more important
>> is, that you start not to think about mutating variables but producing
>> new values from give ones (a slight shift in perspective, but with
>> real impact at the long run).
>
> Yes, you replace thinking about updates to a variable by
> thinking about values passed, and their relations.

About data flow, to be correct.

> Now unless you write a straight line program, this won't
> work without recursion :-)

Yes, but recursion is not the big eye opener here. You said "A more
important reason not to ignore functional programming is [... ]
Recursion". I say: Recursion is more at the surface here, but hardly
the big difference to imperative languages (which all can recur
:-). It's more at the surface, though.

> Thinking about function values and their combinations
> like map + filter is another good thing to learn (and use).

I've been starting to write a library like this in and for
Ada. Unfortunately I'm missing time and motivation to continue.

> OTOH, FP style is sometimes just assignment in disguise.  It hides
> the variable as a parameter (and relies on TCElimination) in a
> sense.

Man, it's not assignment that is BAD. It's just that the programmer
shouldn't program it and should keep to a language in which equational
reasoning is possible. The compiler on the other side is allowed to
optimize what it wants.


> I don't think this is always easier to follow:
>
>   function Sum(L: Cursor; Variable: Integer := Initial_value)
>       return Integer is
>   begin
>       if Has_Element(Cursor) then
>           return Sum(Next(L), Variable + Element(L));
>       else
>           return Variable;
>       end if;
>   end Sum;
>
>   function Sum(L: Cursor) return Integer is
>       Variable: Integer := Initial_Value;
>   begin
>       while Has_Element(L) loop
>           Variable := Variable + Element(L);
>           Next(L);
>       end loop;
>       return Variable;
>   end Sum;
>
> (Yes, a true FP Sum function is composed, taking a binop as a parameter
> for folding and you make it a base-case-step-macro in Lisp ;-)

Yes, a really terrible example: Pseudo FP with Ada syntax. I'm not
surprised you find it difficult to follow. 

  sum = fold (+) 1
 
How's that? And that really summarizes what a functional programmers
knows and wants to know about linear iteration with a state over some
linear collection of thingies. Another example: Revert a list.

  rev = fold (fun x xs -> x::xs) []

And now removing all element with certain properties (p) from a list

 remove_rev p = fold (fun x xs -> if (p x) then xs else x::xs) []

 remove p l   = rev (remove_rev p l)

Read fold as "iterate and do the following ... starting with ..." and
you got the essence.
       

> I still think that it is just a bit more difficult to follow the
> first Sum.

Because of the atrocious syntax: Not really suitable for the purpose.

> If you want to know how Sum is going to arrive at a result then you
> have to follow the history of Variable through a series of function
> calls with a series of changing arguments (the induction step).

"How do you know how Sum is going to arrive at a result when you have
 to follow the history of a variable through a series of iterations
 with a series of changing state variables"

To answer you question: Because most definitions of data
transformations a recursive in nature: Do a small step, the do the
rest. E.g. I don't see another way to work on trees (like XML
documents) without risking major fuck-ups.

> In the second Sum you see the history of Variable without following
> the mechanics of a function call and it is still just one place
> where Variable is modified. It's less hidden behind the "function
> call screen".
>   Still I much prefer the recursive, nested narrowing
> function in my Binary_Search -- even though the loop
> based variant is faster with some Ada compilers :-)
>
> It's certainly easier to see that the first Sum matches
> a primitive recursive function if and when this is important.

No.


>> >>  I refuse
>> >> to discuss merits of languages ot a micro level like:
>> >
>> > The "micro" level is the level of production, change, and correction.
>> 
>>  As you have noticed, FP appeals to
>> mathematicians.
>
> Yes, FP has a mathematical appeal. However, time and space
> are not usually intrinsic parts of mathematical functions. This is

No? What about State (t) = ...? Are mathematical functions somehow
against nature? Will my machine time shift or desintegrate when I
write pure functions? 

A no to all that questions. I hardly see why I should think about time
and space _all the time_. It's the compilers job to make something
from it and it does a good job of this. Data is evaluated when needed
(call by need ...). Not when passed and perhaps not needed. I'd even
venture there are enough (not IO bound) problems where eager language
evaluate much too many data items which are, finally not needed at
all. Functional is basically about need: When data is needed, it is
evaluated. 

And when I need to have interaction with space and time (i.e. the
outside world) and not just live in the data sphere, the IO monad
comes to the rescue.

Forgive me, I'm not one to cry FUD early, but your permanent
assertions that time and space complexity are so unmanageable in FP
are simply FUD and they reflect the state of FUD some 20 years ago. I
think there is even a paper of Wadler on that.

> what I am trying to point out: a computer program operates in time
> and space, it is not a mapping between two sets of values,
> even though you can interpret the operating program this way.

Yes, it'd not even manipulating numbers but levels voltage and
strength of current. I'm not programing with the voltmeter though --
we have stopped to do that in the fifties. This is progress. It's
called abstraction.

>   A "functional solution" is still very helpful as a reference,
> just like you said. 

Not only that, but I won't be able to convince you. I'm no purist,
though. We started with talking about the type system and I'm not
averse to writing imperative procedures in ocaml and using them
together with a functional library.

> For example, a functional solution helps me stay
> sane maintaining one of my longer Perl programs that takes about 35 min
> on average to compute a number of rankings from some larger database
> tables. :) But sometimes a functional solution is only a starting
> point, a necessary precondition. 

Sometimes ... -- But therefore FP is bad all the time because it is
not somehow tied to time and space? I'm starting to become confused.

> It provides guidance when writing the real thing.

Only that the unreal thing works perfectly most of the time. Why
should I rewrite?

> At other times, a functional program is just fine, provided
> the author follows the usual conventions: Don't leave out that
> much, it won't hurt if you say what you mean.
>
>
>> I'Ve mathematical background [...]. FP just came naturally to me:
>> It mirrors the way I
>> think about a problem and about the solution to problems.
>

> For example, a Haskell program can be an executable specification.

A Haskell program is program, not a spec. How can people confuse that?
A spec often has predicates that simply cannot be computed at all or
only at forbidding costs.

> Unfortunately, this may not be good enough because what you call the
> "rest" is *not* optimization.

?? rest ??

> It is meeting the requirements, even when these requirements are
> "Start no sooner than 22:00h, be ready before 23:00h."

> Time and space are intrinsic parts of a solution. 

Nonsense. Intrinsic? In the sense if I don't think always about it, my
functional program will not start when I tell it, but some time
araound last easter? Man, that are not even real problem you're
injuring up here! Apart from the fact that Monads provide the handling
you're trying to deny that it exists. q

> If the problem
> specification includes time and space,

That is, if we are talking about a real time problem. Fine. As I
repeatedly said, most of the things I'm talking about are not real
time problems. I simply refuse to throw away a suitable tool and
exchange it against an unsuitable one, simply because some problem
sets cannot (perhaps) be dealt with by the useful tool.

All arguments you gave can as well be applied to not using a compiled
language, but using assembler. "Sometimes you don't knoe about the
instractions the compiler generates.  If the problem specification
includes time and space, a complete solution must [...] -- let's all
use assembler where we have full control, all the time, also in
ordinary application prgramming".

> a complete solution must
> in effect provide time and space values as well. (Make self-referential
> considerations WRT time and space when computing, so to speak.)
>
> The meaning of the word "optimization" is, I think,
> to improve existing solutions so they run faster, consume
> less resources, are easier to understand, etc.
> Optimization does *not* mean to turn something that isn't a solution
> into a solution.
>
> This is what mathematicians refuse to see, as far as I can tell.

Well - how can I refute that? There is so much work (by
mathematicians) on specifying real time algorithms and giving real
time assureances) that your across-the-board accusation strikes me as
simply unjustified. There has also been work on realtime systems and
ML and furthermore only a small fraction of applications and problems
are real time oriented. Functional computation doesn't happen outside
of space and time and the space and time behaviour is mostly well
understood.

So I fail to see how FP should be bad because it doesn't refer to
space and time or doesn't specify sequencing of operations outside of
Monads or effect systems. You know, I don't see a time variable in C
or Ada either and as far as sequencing goes: You know that modern
compilers reorder the operations to achieve optimization?

> The stigmatize time and space as being just "optimization" issues.

? You must be dreaming. Perhaps your confusion stems from that you mix
up mathematicians, mathematically inclined software engineers and
functional programmers. I personally I'm wuite glad that, say, linear
algebra has not time+space component in it. But what has that to do
with our problem?

Or care to alaborate to which people you refer when you say
"mathematicians"?

> They are not. In programming, a function is more than an equation
> over some field that excludes time and space.

You mix up functions (a mathematical construct) and procedures (a
specification of an operation or computation to be performed by suitable computing
machine). 

Functional programming also specifies operations (not mathematical
functions) but the intresting part is, that it does so in a more
abstract way: It just says what has to be delivered when needed and
(in the lazy case) leaves the rest to the compiler / runtime system.

>> I fear your full of preconceptions. It's different from what you do in
>> Ada (or whatever your favourite imperative language is), so it must be
>> wrong or there must be something missing.
>
> Why would I be writing programs in OCaml, then?

Yes, I wonder, indeed.

>> As an FP advocate, I suggest, that the things not written down, are
>> not necessary.
>
> FP error messages get better in the presence of explicit types.

At the right places. Not at all places. It's that difference evrything
is about.

> Redundant semicolons can help the functional compilers a lot
> in figuring out where there is an error in the program text.

No. Redundant semicolons very probably make your ML/OCaml compiler
barf at you.

> Not necessary?

??

> Or are FP programmers of the compiler writer type who hardly
> need a robust language?

FUD. (a) what is a "robust" language. (b) what has it to do with
semicolons and (c) why don't I have the problem to understand my
compilers error messages?

I really wonder about your experiences.


>>  So those "savings" you address as a defect are actually
>> a chance. 
>> 
>> But YMMV. As I said: I'm not in the business of convincing people WRT
>> FP. You already indicated that you would not accept the typical
>> reasoning of an FP protagonist. I can't offer you something different:
>> It's shorter, I can see the problem clearer, I can leave out redundant
>> information and so on.


> That's the point: it's you who sees clearly, you leave out what seems
> redundant to you, etc.. But those other guys, trying to understand
> your program, will have to repeat your arrival at a clear sight, 
> they will have to iterate the learning process that makes things
> seem redundant to you, etc..

I wonder why you think, that Perl and Ada are readable and FP is not?

> The usual answer I got when asking about this is, well, I need
> educated colleagues with skills at about the same level as mine.
> Sometimes that seemed just true, sometimes that's snobbish,
> in some cases it has seemed to express pride. It has also been
> an attempt of a programmer to make himself irreplaceable.

Bullshit, man. What actually do you suggest? That I, I!, have to
program everything in e.g. C so that every other gonzo in the world
can understand all the programs I e.g. wrote for my use and
entertainment?

George, I give up on you. You don't understand -> it's my problem and
you don't give me enough clues to get you, well, clued in. You seem to
have had some real bad experiences with mathematicians and functional
programs. I can't help you there. FP, perhaps, is not for you. I'll
always be happy to answer specific questions, though. 

> That's the point: it's you who sees clearly, you leave out what seems
> redundant to you, etc.. But those other guys, trying to understand
> your program, will have to repeat your arrival at a clear sight, 

But I can't answer diatribe of this kind, expect with "I don't have
that problem, nobody I know of has it etc., I hardly have problems
reading other peoples OCaml programs etc...".



>> Listening to you justifying that every, every variable must be
> that's an exaggeration
>> declared with type and all, one wonders hoe mathematics itself ever
>> could live without type declarations.

> Mathematicians use explanatory sentences and bibliographic references
> as a replacement for declarations. So they do declare.


Well, we can suppose, that someon trying to understand a program in
Haskell or OCaml or even Perl has read parts of the reference manual,
can we?

> Only the declarations are semi-formal in many cases like you show
> in your example. After "Let V be a vectorspace", V is declared,
> is in scope, and references to V will just name V of type vectorspace.
>
>
>> The same principle applies in FP. I fear it won't convince you.
>
> Where FP authors follow the conventions of good style, 
> they list a function's type, or they add a semi-formal comment,

No, sorry, they don't, They do that for key functions, not for
functions with the status of lemmata. They do it for interfaces. And
you know what: The language requires it in interfaces,

> or both. 

> Why would they do that if these things are redundant
> and should therefore be left out?

This IS childish. Also because it depends on your made-up definition
of good style in FP, which is, incidentally, not true.

You quoted Appels ML critique -- have you actually read it?


>> FP has set the cut off at a
>> different point than Ada. Question: Was that necessarily wrong?
>
> No, not wrong. It just has consequences to leave things out.

Just some paragraps ago you said, good style doesn't leave that things
out. Necessarily leaving the out is bad style: So bad. Seems to me,
you said wrong.


>>  It
>> fits me. Does that make be a worse programmer / designer / software
>> engineer / mathematician? I don't think so.
>
> Imagine an engineer writing programs and documenting his
> assumptions even though he thinks they are redundant because
> they can be inferred from some context. Worse or better? Why?

What has that to do with type inference? 


> Imagine a script author who has to get some data laundry job
> done. Would he/she be well advised to write a program that
> can be reused, with all bells and whistles, good types, OO
> encapsulation? 

> Or just use a bunch of lists, tables, and
> regular expressions? 

> (What's the probability of a once-program
> becoming an n-times-program, anyway, in reality?)


What has that to do with type inference? 


>> > needs not be terminated. This leads to undecipherable error
>> > messages when you forget to place one missing token to complete
>> > an expression that is the last thing in a function definition.
>> 
>> I fear that hardly happens to me in OCaml.
>
> I think it's really not important what happens to you and me here.

But your anecdotal evidence is?

> What is important is what happens to the amount of available
> money to pay us until we arrive at an error-free solution.

Please, you use your tools, and I'll use mine.

> How much time is spent by the programmers when correcting
> mistakes, and how do OCaml and Ada compare in this case in
> typical settings?

How do they? 

> The error messages of the Erlang system can be even
> more obscure. Some of them are printed at run time.
> Sometimes there isn't a message at all ... Still, the language
> is somewhat minimal and Erlang can help solve some problems
> quickly provided the Erlang programmer knows the language, the
> libraries, and the system and its quirks.

Good idea. If you need an argument, pull it from another functional
language, (anecdotal evidence again) and pose it as typical. So all
faunctional langauges / programming systems have to hjustfy the
weaknesses of any of them. 

> If you write Erlang programs, you *must* be able to say,
> "I fear that hardly happens to me in" Erlang. Otherwise
> you will be lost tackling errors you don't understand
> because there is comparatively little "redundant" information
> in Erlang programs.

So saying this is an invalid argument. Unfortunately that also applies  to 

   "I find error messages of the Erlang system even be more obsure".

Not the I, I have been adding here. 


>
>> the presence of overloading and tagged
>> types the error messages can be become quit misleading, at least with
>> Gnat.
>
> It can be.
>
>
>>  But my experience is that it is the beginners that are most
>> obsessed with the "broken syntax".
>
> Of course the beginners complain! Just like when someone switches
> from permissive C to unforgiving Ada. But is't not the syntax
> of Ada that seems to cause difficulties.

So? So your complaints about ML syntax become a valid and important argument?

>>  Related to that are the repeating
>> attempts on c.l.f. or c.l.l to suggest a new syntax surface for Lisp
>> "without all so parenthesis", implying that would hugely further the
>> proliferation of Lisp. There is, I think, already a c.l.l FAQ for
>> this.
>
> I know, and it has taken me some time an effort to make
> some proponents of Lisp syntax see the problem in the first place.
>
> (Usual suggestions: If you run into "syntax error at end
> of file", just fire up your Lisp system's editor, some function
> will look "skewed" and point you near to where a ')' is missing.
> Well...)

Yes, well? So what? The Lispers seem not to have the problem you
have. What does that tell you? Probably: Typical FP advocates, they
just pretend that is not a problem and leave all other people outside
in the cold rain? Tell me; What does that tell you about your approach
to a new language or programming system? I got the impression now,
that you try to retrofit your Ada / Perl / C / whatever experience to
the new system and that you're peeved of than, if that doesn't work.

I notice we have been departed from teh discussion of technical
properties of languages and the possible implications for constructing
programs and have strayed in the realm of pure taste - Like "I don't
have the problem -- typical, that you would deny it" and bad analogies
"Imagine an engineer, who ...". 

Unfortunately I don't feel qualified and I'm not intrested to discuss
believes and tastes of that kind especially since have reached some kind of deadlock. 

So I suggest, we either shift that thread to a functional forum, group
or list or I'll at least stop participating in this particular sub
thread. It seems to be wast of time, since I really can't change or
influence your point of view.
>
>>  Though the attempts to reform ML syntax happen less often, they
>> happen and I count them under the same heading as those Lisp reform
>> attempts.
>
> You cannot take pride in having mastered a syntax that is no
> challenge. :-)

What is that supposed to mean?


>> But really: What would that buy me? Investing
>> the same time into understanding more ML / OCaml / Haskell will earn
>> me much more.
>
>
>> Let me quote from the abstract of that paper:
>> 
>> ...
>> So we are talking about somebody intimately acquainted with the
>> language and the research on that language, striving for an
>> improvement.
>
> That's why I quoted the paper. It does explain why ML is important.
> And that too little attention has been given to syntax.

Better reread that paragraph.


>
>> I suggest you really read the paper you quoted:
>
> I did, I usually read the papers I quote before I argue ;-)
>
>>  He has some nice
>> things to say about the necessity of GC and the people who don't like
>> the "bizarre syntax" of ML. At the end of that paragraph he says: "But
>> in general, don't we have better things to argue about than syntax?".
>
> Syntax is structuring our communication.

> We have important things to achieve, and just ignoring syntax
> won't make us more effective. 

So be free to continue arguing about syntax. I more agree with Appel
on that subject.

> But since we are starting to throw
> papers at each other, here is another, more or less empirical one,
> talking about programmers discussing(!) irrelevant syntax:)


> "Of the pretense (syntax is irrelevant) and the actual reaction
> (syntax matters), the one to be believed is the actual reaction.
> Not that haggling over parentheses is very productive, but
> unsatisfactory syntax usually reflects deeper problems, often
> semantic ones: form betrays contents.
>
> "Experienced programmers, so the argument goes,
> will never make the error. In fact they make it often.
> A recent review of the BSD operating system source..."
> -- Betrand Meyer, Principles of language design and evolution, �8
>
> The last sentence is about '=' in C comparisons. '=' has caused a
> problem in ML, too.  Hm, perhaps everything coming out of Bell
> Labs must continue Bell Labs traditions. SNOBOL4 has '=', C has
> it so C++ has it, Aleph has it, Limbo, too IIRC. So maybe ML has
> had to have the '=' trouble maker, too.

So C has problem with "=" and "==", which of course makes your
complaints about ML syntax valid...? 


>> Your approach seems to be more the Olde FORTRAN Programmer's approache:
>> I can do it in [...] so why must I use/learn another language.
>
> Not at all. What makes you think so?

I think there is a bit of context missing here.

>> > This costs time and money.
>> 
>> Well -- every legacy feature does. Tell me, Ada has none :-).

> In the case of OCaml, there is at least camlp4. 

So?

> I understand nobody
> seems to want the revised syntax? Not cool? Herd instinct?

No. Keyword is maintainability and tool support (this starts with
emacs modes. Tuareg + traditional syntax buys you more than revised
syntax.

> Fear of change? "No, it's not necessary, we have learn-ed ouR
> working in-group syntax."

I find that rather typical that you insinuate elitist motivation
here. Of course I can't help if you experience the world like that.

> I only wish someone could win the lottery and have some language
> designers work on the formal principles of sound syntax for industry
> programming languages.


> Instead, legacy syntax is reintroduced again and again, by
> the same people who argue it doesn't matter because they have
> finally learned to work around the broken syntax.

> So why not again use the broken syntax? Professional

Let me sing that again: Tool support, existing code, existing know how
and training.

> programmers get bitten by the syntax bugs again and still
> continue to claim this isn't important...

>
> A few weeks ago a colleague explained he always writes
>
> if (expr == false)

> {
>
> because a '!' can be hard to see. I told him he could always use
>
> if (!!!expr)
> {
>
> ...


Which langauge is that supposed to be? It ain't C, this much is
sure. And what does that prove?

Regards -- Markus

Re: How come Ada isn't more popular?

[Markus E Leypold]

Hi George,

First I'd like to sort of apologize for my long last message and the
sudden end (my refusal to continue the discussion). I'd like hold up
the statement that I don't have time to continue the discussion,
though. But I'd like you to understand that you're putting my in some
kind of double bind here: 

First you state your dissatisfaction with type inference and the
typical functional style of programming in highly subjective terms.

Than you assert that advocates of functional programming are all
elistist (they either pretend not to have the problems you have or
they are not having them, perhaps are only a minority in that, but
they find it cool that they have mastered something other people can't
and have nothing better to offer to you than to assert that you
problems are not real problem etc).

I rather don't see a way to help you in this situation. I could

 - say you're right. But what does that buy you, if I think you don't?
   It certainly doesn't solve you problem with FP.

 - assert that I don't have the problem, and even continue to
   understand yours and try to change you, but than I would fall under
   the second point (I'm a FP smart ass) or under the first point (I
   just pretend against better knowledge that those problem don't
   exists).

In my youth I've been discussing extreme religious beliefs with a
number of people and one thing we noticed, that a lot of belief
systems have a kind of self referentiality built in, which is called
self immunization: It's often core axiom that somebody that denies God
or the specific believe serves the devil (or whatever evil principle)
by that and therefore must have been incited by the devil to do it. Of
course arguments by people influenced by the devil need not to be
considered, since the devil lies and says anything just to unsettle
your belief.

I see a similar (though less radical) self immunization strategy here:
Whatever I say is just typical FP advocate and if what I say is not
expressible in Ada parlance it cannot be good, since Ada comprises
everything and does everything right (I'm perhaps a bit fuzzy and
unjust on the last point, my apologies, if so)

But something different and new can not be mapped to the already known
if it is really new. As far as I see a 'jump' of some sort always has
to be taken in learning something really knew -- there is no sure way
to bootstrap into a new "world of knowledge" or paradigm. 

In my opinion that is the basic learning function of the human brain
which has not been well understood so far, this sudden insight. The
sudden insight has probably something to do with experiencing new
things in action, so it's probably impossible to make somebody
entering into a new paradigm if he wants to be convinced beforehand
that it would be worth it. It's the characteristics of a new paradigm
that you cannot understand its explanations until you have entered it,
so nobody can convince you of the paradigm's value.

I know this sounds a bit religious and indeed the same argument can be
made (and has been made) for any esoteric pseudo science or belief
system. Obviously the choice to want to understand something really
new is motivated by something different than understanding the new
thing and learning its advantages beforehand. I think there is a
pre-rational selection mechanism (e.g. I refuse to even discuss
miracle healers or review the "proofs", even while I admit the
principal positivist restriction of natural sciences and "that we
cannot know everything"). So in a sense: Some things are just not for
some people.

I don't know wether functional programming (and the dratted type
inference) is really for your, which, in the light of the elaborations
above I wouldn't necessarily see as a negative judgement, though. I
don't really know, and the final person to decide on that are you.

My intention was to give some insight on modern type systems and things
that newer languages have, that perhaps make them popular. I do not
want (and from what I said simply cannot) convince anyone of the
usefulness of those features or of the desirability of FP (which is OT
here, but that's where e ended up).

I will be glad to be of assistance if you need to understand certain
_technical_ facets of FP, always assuming that I understand them
myself. I'm open to discussion on alternative (more elegance, better
performance, ...) implementations in functional languages for give
pieces of code. But I've begun to find general value judgements a bit
difficult, as well as the attempts to convince you on the general
value of things you seem not to want to look into.

Yes I have been guilty to indulge in them myself. Mea culpa :-). But
now I have to mend my sinful ways. :-)

Discussion of FP now, please, strictly off c.l.a. And shorter, if possible.

Regards -- Markus









 

 

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Mon, 2007-02-05 at 01:06 +0100, Markus E Leypold wrote:
> 
> Hi George,

> 
> First you state your dissatisfaction with type inference and the
> typical functional style of programming in highly subjective terms.

I can only speculate on how you can transform what I have written
into what you say I have written. I must try harder to choose my words
carefully. I will provide some simple facts and a frame of reference
for a reasonable discussion of why and when "explicitly referring" (Ada
style) is better than "inferred from context" (FP style). It will take
some time to sort out the arguments in more approachable terms.

The arguments won't stop me from using FP languages. They won't stop
me from arguing about the costly effects of syntax either.

For now:
Since Ada was born out of an attempt to provide a programming language
specifically addressing the needs of production in a large organization
paying attention to syntax vis-a-vis available industry standard
programmers has been an important design goal. Obviously.
I think it still is.

It is therefore necessary to always refer to how a language is
apparently used. Not to how you can use a language.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Mon, 2007-02-05 at 01:06 +0100, Markus E Leypold wrote:
>> 
>> Hi George,
>
>> 
>> First you state your dissatisfaction with type inference and the
>> typical functional style of programming in highly subjective terms.
>
> I can only speculate on how you can transform what I have written
> into what you say I have written. I must try harder to choose my words
> carefully. 

The way you say this, it becomes a rather one sided imposition of
interpretation on my part. Actually I only wrote my last response not
to just impolitely drop the discussion w/o further comment, since I
was, am, absolutely dissatisfied with it. I also tried honestly to
understand what went wrong ... but now I fear that just became a new
reproach in your eyes. Well -- we can't be perfect.

Let me state it like this: If you want to continue the discussion I
must have some open "corridor" for arguments left, not just that the
alternatives between shutting up or "typical FP advocate".

> I will provide some simple facts and a frame of reference
> for a reasonable discussion of why and when "explicitly referring" (Ada
> style) is better than "inferred from context" (FP style). It will take
> some time to sort out the arguments in more approachable terms.

> The arguments won't stop me from using FP languages. 

I don't want to stop you. I only had the impression you don't want
them.

> They won't stop me from arguing about the costly effects of syntax
> either.

Well -- it will stop me. I'm not interested in syntax discussions, since
I don't experience detrimental effects. Neither from ML syntax nor
from Ada syntax. I'm adaptable and as Appel consider most if not all
syntax discussion longer than a paragrap a complete waste of time.

> For now: Since Ada was born out of an attempt to provide a
> programming language specifically addressing the needs of production
> in a large organization paying attention to syntax vis-a-vis
> available industry standard programmers has been an important design
> goal. Obviously.

My suggestion (at the beginning of this thread) was that Ada in this
respect reflects the state of the art 20 years ago. Not necessarily
bad, but (a) application areas have changed and (b) the competitors
have changed. So, my suggestion was, perhaps the ecological niche in
which Ada lives has become more narrow: Those who want low level use C
(either misguided or very selectively) and those who want high level
use languages with more possibilities for abstraction, other type
systems and GC.

> I think it still is.

Is born :-)? 

> It is therefore necessary to always refer to how a language is
> apparently used. Not to how you can use a language.

OK. Ada is used in embedded programming. So the OP's question must be
answered with "Ada is not more popular because embedded programming is
not more popular". I regret to say, that this doesn't answer the
question, obviously. The OP's question was about "could have beens".

But I was serious when I said, I'm tired of this discussion, so I
_will_ stop here. I can't afford the time and see (momentarily) no
useful goal served either.

Regards -- Markus

Re: How come Ada isn't more popular?

[Harald Korneliussen]

>From what I have seen, I must give you (Bauhaus) right in this: space
usage can be hard to predict in a lazy language, and time usage is
probably also easier in a language closer to the hardware, like Ada.
Compiler error messages in Haskell are bad, I had not considered
before that the reason for this may be type inference, but it makes
sense. By comparison, the GNAT error messages are the best I've come
across.
But I suspect that the libraries haskell offers can free me from
worries of space usage, if they are well designed and documented.
Haskell certainly offers some very interesting libraries.
Equational reasoning with haskell code is suprisingly easy, and I
believe that for most applications, correctness is more important than
speed and memory usage. From my (admitably small) experience with
haskell, it seems that it's faster and easier to write correct
programs the first time. If it fails, though, it's back to making
sense of the compiler error messages, or much worse: trying to track
down that space leak!

Re: How come Ada isn't more popular?

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> ...As I wrote elsewhere: All common programming languages are Turing
> complet,

OK.

>... so equivalent.

Equivalent in some sense.

>... There is nothing that can be done in one that
> could not be done in the other -- in principle.

No, I won't agree with the "nothing in one than the other" idea.
For example, you can read the clock in standard Ada,
but you cannot in standard Pascal.
That's "something that can be done" in one language but
not the other.

Another example: one cannot write the garbage collector of a Java
implementation in Java.

I'm sure you know this -- I'm just quibbling with your wording:
things that can/cannot be done, versus functions that can/cannot be
computed (by Turing machines).

- Bob

Re: How come Ada isn't more popular?

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> ...As I wrote elsewhere: All common programming languages are Turing
>> complet,
>
> OK.
>
>>... so equivalent.
>
> Equivalent in some sense.
>
>>... There is nothing that can be done in one that
>> could not be done in the other -- in principle.
>
> No, I won't agree with the "nothing in one than the other" idea.
> For example, you can read the clock in standard Ada,
> but you cannot in standard Pascal.
> That's "something that can be done" in one language but
> not the other.
>
> Another example: one cannot write the garbage collector of a Java
> implementation in Java.
>
> I'm sure you know this -- I'm just quibbling with your wording:
> things that can/cannot be done, versus functions that can/cannot be
> computed (by Turing machines).

You're also missing my point somewhat :-): That equivalence "in
principle" that every program in L1 has a program in L2 which does the
same computation (and I/O if you like) is not the point. The point is,
in practical programming, _how_ things are done. Not their result, but
how much pain is inflicted and how comprehensible the end result
is. How long in absolute terms the way from the problem mind set to
the implementation of a solution is.

But I take your point. It's less the language though, but the standard
library (which in pascal is not seperable, I know).

Regards -- Markus.

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Thu, 01 Feb 2007 17:26:21 +0100, Georg Bauhaus wrote:

> On Thu, 2007-02-01 at 15:22 +0100, Dmitry A. Kazakov wrote:

>> On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:
> 
>>> BTW -- another argument _for_ a builtin list syntax.
>> 
>> Hey, Ada already has ()-brackets. Maybe our Unicode fans would propose
>> special glyphs for )), ))), )))), ))))), )))))) etc. Is it what you mean as
>> special syntax? (:-)) 
> 
> Actually, a syntax that is used in a theory book is
> {left/right paren}{subscript i}.

Great. The next step would be to introduce expression in subscripts: )2+1 =
)3 = ))). Right? Then we proceed to )f(...) where f is a free function that
determines the number of brackets. OK? Now the question is, is it still
syntax? (:-))

> What does a list syntax buy us if there is no argument pattern matching,
> or no data structure pattern matching in Ada? Brevity?

There is no need in pattern matching. What is actually required in Ada is
abstract aggregates, i.e. an ability do have user-defined constructor
functions with the parameter specified in the form of a list.

> generic
>    type T is private;
>    with function "+"(a, b: T) return T;
>    increment: T;
> function Inc(arg: T) return T;
> 
> function Inc(arg: T) return T is
> begin
>    return increment + arg;
> end Inc;
> 
> Looks like more code, and I hear an FP advocate saying, "in FP,
> you just ...". Any sentence that starts with "You just ..."
> is suspicious :-)
> 
> Can I have this without generics, please, Dmitry? ;-)

Sure you can:

type Additive is abstract;  -- Should be enough for an interface
function "+" (A, B : Additive) return Additive is abstract;

Here I am not sure about "increment" variable, because it is not
initialized. Anyway:

function Increment return Additive is abstract;
   -- Better be getter/setter pair. Unfortunately Ada does not have
   -- "abstract variable interface" it should have

function Inc (Arg : Additive'Class) return Additive'Class is
begin
   return Increment + Arg;
end Inc;

There is a very simple rule for all this:

1. Formal generic subroutines -> abstract primitive operations
2. Subroutines in the body -> class-wide operations.

This follows from even simpler rule:

generic <--> class-wide
instance <--> specific
------------------------------
= polymorphic

BTW, can you do the same for the case where Increment were Integer and Arg
were Float? [ You would need multiple dispatch in "+", that is the case
where any system without subtypes would quickly collapse. For a vivid
example see String/Unbounded_String/Wide_String/... mess in Ada.]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 01 Feb 2007 17:26:21 +0100, Georg Bauhaus wrote:
>
>> On Thu, 2007-02-01 at 15:22 +0100, Dmitry A. Kazakov wrote:
>
>>> On Wed, 31 Jan 2007 16:16:20 +0100, Markus E Leypold wrote:
>> 
>>>> BTW -- another argument _for_ a builtin list syntax.
>>> 
>>> Hey, Ada already has ()-brackets. Maybe our Unicode fans would propose
>>> special glyphs for )), ))), )))), ))))), )))))) etc. Is it what you mean as
>>> special syntax? (:-)) 
>> 
>> Actually, a syntax that is used in a theory book is
>> {left/right paren}{subscript i}.
>
> Great. The next step would be to introduce expression in subscripts: )2+1 =
> )3 = ))). Right? Then we proceed to )f(...) where f is a free function that
> determines the number of brackets. OK? Now the question is, is it still
> syntax? (:-))
>
>> What does a list syntax buy us if there is no argument pattern matching,
>> or no data structure pattern matching in Ada? Brevity?
>
> There is no need in pattern matching. What is actually required in Ada is
> abstract aggregates, i.e. an ability do have user-defined constructor
> functions with the parameter specified in the form of a list.
>
>> generic
>>    type T is private;
>>    with function "+"(a, b: T) return T;
>>    increment: T;
>> function Inc(arg: T) return T;
>> 
>> function Inc(arg: T) return T is
>> begin
>>    return increment + arg;
>> end Inc;
>> 
>> Looks like more code, and I hear an FP advocate saying, "in FP,
>> you just ...". Any sentence that starts with "You just ..."
>> is suspicious :-)
>> 
>> Can I have this without generics, please, Dmitry? ;-)
>
> Sure you can:
>
> type Additive is abstract;  -- Should be enough for an interface
> function "+" (A, B : Additive) return Additive is abstract;
>
> Here I am not sure about "increment" variable, because it is not
> initialized. Anyway:
>
> function Increment return Additive is abstract;
>    -- Better be getter/setter pair. Unfortunately Ada does not have
>    -- "abstract variable interface" it should have
>
> function Inc (Arg : Additive'Class) return Additive'Class is
> begin
>    return Increment + Arg;
> end Inc;
>
> There is a very simple rule for all this:
>
> 1. Formal generic subroutines -> abstract primitive operations
> 2. Subroutines in the body -> class-wide operations.


So you derive from Additive to get a specific implementation?

Like

  type Vector   is Additive with ...;
  type CountVal is Additive with ...;

Right? But then, you should note that with

  C: Countval;

  Inc(C).

returns an 'Additive', not a 'CountVal'. That is one problem. The
other is of course that Increment is not initialized. This is exactly
what generics are here to solve.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Sure you can:
>>
>> type Additive is abstract;  -- Should be enough for an interface
>> function "+" (A, B : Additive) return Additive is abstract;
>>
>> Here I am not sure about "increment" variable, because it is not
>> initialized. Anyway:
>>
>> function Increment return Additive is abstract;
>>    -- Better be getter/setter pair. Unfortunately Ada does not have
>>    -- "abstract variable interface" it should have
>>
>> function Inc (Arg : Additive'Class) return Additive'Class is
>> begin
>>    return Increment + Arg;
>> end Inc;
>>
>> There is a very simple rule for all this:
>>
>> 1. Formal generic subroutines -> abstract primitive operations
>> 2. Subroutines in the body -> class-wide operations.
> 
> So you derive from Additive to get a specific implementation?
> 
> Like
> 
>   type Vector   is Additive with ...;
>   type CountVal is Additive with ...;
> 
> Right? But then, you should note that with
> 
>   C: Countval;
> 
>   Inc(C).
> 
> returns an 'Additive', not a 'CountVal'.

No, it does Additive'Class! Thus, no problem.

(note that the goal was polymorphic Inc, if you wanted it covariant that
would automatically exclude polymorphism)

> That is one problem. The
> other is of course that Increment is not initialized. This is exactly
> what generics are here to solve.

As it was in Georg's example. But with inheritance covariant Increment
would be required to be overridden (praised be Ada). So an initialization
will be enforced anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Sure you can:
>>>
>>> type Additive is abstract;  -- Should be enough for an interface
>>> function "+" (A, B : Additive) return Additive is abstract;
>>>
>>> Here I am not sure about "increment" variable, because it is not
>>> initialized. Anyway:
>>>
>>> function Increment return Additive is abstract;
>>>    -- Better be getter/setter pair. Unfortunately Ada does not have
>>>    -- "abstract variable interface" it should have
>>>
>>> function Inc (Arg : Additive'Class) return Additive'Class is
>>> begin
>>>    return Increment + Arg;
>>> end Inc;
>>>
>>> There is a very simple rule for all this:
>>>
>>> 1. Formal generic subroutines -> abstract primitive operations
>>> 2. Subroutines in the body -> class-wide operations.
>> 
>> So you derive from Additive to get a specific implementation?
>> 
>> Like
>> 
>>   type Vector   is Additive with ...;
>>   type CountVal is Additive with ...;
>> 
>> Right? But then, you should note that with
>> 
>>   C: Countval;
>> 
>>   Inc(C).
>> 
>> returns an 'Additive', not a 'CountVal'.
>
> No, it does Additive'Class! Thus, no problem.

I've been expressing myself sloppily. It should return a CountVal, not
an Additive'Class. CountVal(s) could not be added to Vectors -- there
is a difference.

> (note that the goal was polymorphic Inc, if you wanted it covariant that

No. The goal was to have mechanism to write the algorithms once and
being able to pull various actual operators/procedures from that
without replicating the specification of the algorithm. I really think
you're mixing something up here, but the example is not really useful
to demonstrate the advantages of generics.

Let me suggest 1 other example for the usefulness of generics and than
1 example where generics (Ada-style) help, but parametric polymorphism
(what I have been talking about as parametrized types) would actually
bring an advantage.

Example 1:

  An abstract vector space is defined as a sets of vectors u,v,w,...
  and scalars a,b,c, ...  with a number of operations:
   
    - scalars are a field, i.e. have additions an multiplication with certain properties
    - there is amultiplication between scalars and vectors: a*v
    - there is an addition between vectors.

  A normalized vector space introduces the idea of distance between
  verctors, Again certain laws apply. For the programmer: There is a
  dist-functions which takes 2 vectors a parameters.

  You can do a really huge amount of mathematics with this
  axioms. Examples of vector spaces with thos properties would be
  certain subsets of functions, finite vectors (i.e. arrays of N
  components), polynomes, etc.

  One application would be, given a function on the vector space f : V
  -> Real_Numbers to find minima of this function.

  There is an algorithm that is not very efficient but works in a vast
  number of cases without having to use specific knowledge of the
  underlying vector space.

With Ada generics I'd define the vector space interface a generic and
instantiate accordingly. The algorithm to fin minima would be
implemented as generic and take a vector space package as generic
parameter.


Example 2

  Write a quicksort algorithm on arrays which can be reused for arrays
  of almost arbitrary elements, if a suitable order relationship is
  defined. Note that I might want to sort _the same_ elements with
  different orders (like insurance number or alphabetically ...).


> would automatically exclude polymorphism)
>
>> That is one problem. The
>> other is of course that Increment is not initialized. This is exactly
>> what generics are here to solve.
>
> As it was in Georg's example. 

Yes. But Georg used generics, so it worked. You said, you don't want
generics, but it doesn't work. I fail to see, how George has to use
select an example that makes your misguided hypothesis -- that
generics are not neeeded -- hold up. Quite the opposite.

> But with inheritance covariant Increment
> would be required to be overridden (praised be Ada). So an initialization
> will be enforced anyway.

I don't see how. And what is more: With generics I could istantiate a
Large_Step (increment by 100) and a Small_Step (increment by 1)
function from the generic. That would not work at all with your method. 

If suspect you're missing the respective application areas of generics
vs. inheritanc+overriding. As an software engineer I'd always prefer
generics, since they avoid polymorphism where no polymorphism is
required or intended. That is good, since it's nearer to the contract.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sat, 03 Feb 2007 15:16:21 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> Sure you can:
>>>>
>>>> type Additive is abstract;  -- Should be enough for an interface
>>>> function "+" (A, B : Additive) return Additive is abstract;
>>>>
>>>> Here I am not sure about "increment" variable, because it is not
>>>> initialized. Anyway:
>>>>
>>>> function Increment return Additive is abstract;
>>>>    -- Better be getter/setter pair. Unfortunately Ada does not have
>>>>    -- "abstract variable interface" it should have
>>>>
>>>> function Inc (Arg : Additive'Class) return Additive'Class is
>>>> begin
>>>>    return Increment + Arg;
>>>> end Inc;
>>>>
>>>> There is a very simple rule for all this:
>>>>
>>>> 1. Formal generic subroutines -> abstract primitive operations
>>>> 2. Subroutines in the body -> class-wide operations.
>>> 
>>> So you derive from Additive to get a specific implementation?
>>> 
>>> Like
>>> 
>>>   type Vector   is Additive with ...;
>>>   type CountVal is Additive with ...;
>>> 
>>> Right? But then, you should note that with
>>> 
>>>   C: Countval;
>>> 
>>>   Inc(C).
>>> 
>>> returns an 'Additive', not a 'CountVal'.
>>
>> No, it does Additive'Class! Thus, no problem.
> 
> I've been expressing myself sloppily. It should return a CountVal, not
> an Additive'Class. CountVal(s) could not be added to Vectors -- there
> is a difference.

When Inc returns CountVal then it is not a member of Additive in the
result. So you cannot reuse the result for other members of Additive.

>> (note that the goal was polymorphic Inc, if you wanted it covariant that
> 
> No. The goal was to have mechanism to write the algorithms once and
> being able to pull various actual operators/procedures from that
> without replicating the specification of the algorithm.

If you want to reuse Inc's algorithm in various specific Inc, then you
would use wrappers:

function Common_Inc (Arg : Additive'Class) return Additive'Class is
begin
   return Increment + Arg;
end Common_Inc;
function Inc (Arg : Additive) return Additive is abstract;

function Inc (Arg : CountVal) return CountVal is
begin
   return CountVal (Common_Inc (Arg));
end Inc;

However I don't understand the reason, why.

> Let me suggest 1 other example for the usefulness of generics and than
> 1 example where generics (Ada-style) help, but parametric polymorphism
> (what I have been talking about as parametrized types) would actually
> bring an advantage.
> 
> Example 1:
> 
>   An abstract vector space is defined as a sets of vectors u,v,w,...
>   and scalars a,b,c, ...  with a number of operations:
>    
>     - scalars are a field, i.e. have additions an multiplication with certain properties
>     - there is amultiplication between scalars and vectors: a*v
>     - there is an addition between vectors.
> 
>   A normalized vector space introduces the idea of distance between
>   verctors, Again certain laws apply. For the programmer: There is a
>   dist-functions which takes 2 vectors a parameters.
> 
>   You can do a really huge amount of mathematics with this
>   axioms. Examples of vector spaces with thos properties would be
>   certain subsets of functions, finite vectors (i.e. arrays of N
>   components), polynomes, etc.
> 
>   One application would be, given a function on the vector space f : V
>   -> Real_Numbers to find minima of this function.
> 
>   There is an algorithm that is not very efficient but works in a vast
>   number of cases without having to use specific knowledge of the
>   underlying vector space.
> 
> With Ada generics I'd define the vector space interface a generic and
> instantiate accordingly. The algorithm to fin minima would be
> implemented as generic and take a vector space package as generic
> parameter.

I am deeply unsatisfied with generics here, because this example is almost
exactly what I am doing. I have:

Over a real domain I have:

1. Scalars
2. Intervals
3. Fuzzy numbers with a partly linear membership function
4. Fuzzy numbers with membership function of a nested intervals
    + algebra of 1, 2, 3, 4 and between them

But that is not all:
5. Sets of 3
   + lattice over it

Not yet:

6. Dimensioned scalars
7. Dimensioned intervals
    + algebra
...
n. Sets of dimensioned numbers
   + lattice over it
   + algebra between dimensioned things and scalars
...
n+1 String I/O for all of them
   + names for the members of the sets
...
n+m+1 GTK widgets for them
...

Should I show you generic specifications of this mess? Can you imagine the
instantiations chain from Float down to GTK+ widget (provided your GNAT
would be able to eat it (:-()? I can give you a link...

I DON"T want it. I need a clean way to describe an algebra and a lattice
and then mix and bend them as I want. I want to be able to derive
everything from a scalar. There is always much talk about how mathematical
are generics and FP, it is amazing to me how readily people believe in
that.

> Example 2
> 
>   Write a quicksort algorithm on arrays which can be reused for arrays
>   of almost arbitrary elements, if a suitable order relationship is
>   defined. Note that I might want to sort _the same_ elements with
>   different orders (like insurance number or alphabetically ...).

No problem [with some extensions to Ada types system]. You need two
interfaces: Array and Weakly_Ordered. You could also sort same elements of
same container object using different orders. [However usually in such
cases one better uses a sorted view, rather than physically sorts.

> Yes. But Georg used generics, so it worked. You said, you don't want
> generics, but it doesn't work. I fail to see, how George has to use
> select an example that makes your misguided hypothesis -- that
> generics are not neeeded -- hold up. Quite the opposite.

generic
   type Element is private;
   with function "<" (Left, Right : Element)  return Boolean;
   with function "=" (Left, Right : Element)  return Boolean;
   type Container ...
procedure Quick_Sort (...);

How can this can sort the same container? This is a clear case where
generics don't work. You need "<" and "=" be passed as proper functions
rather than formal generic functions. [It is not static polymorphism
anymore.]

> As an software engineer I'd always prefer
> generics, since they avoid polymorphism where no polymorphism is
> required or intended.

? Generics = static polymorphism.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 03 Feb 2007 15:16:21 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> 
>>>>> Sure you can:
>>>>>
>>>>> type Additive is abstract;  -- Should be enough for an interface
>>>>> function "+" (A, B : Additive) return Additive is abstract;
>>>>>
>>>>> Here I am not sure about "increment" variable, because it is not
>>>>> initialized. Anyway:
>>>>>
>>>>> function Increment return Additive is abstract;
>>>>>    -- Better be getter/setter pair. Unfortunately Ada does not have
>>>>>    -- "abstract variable interface" it should have
>>>>>
>>>>> function Inc (Arg : Additive'Class) return Additive'Class is
>>>>> begin
>>>>>    return Increment + Arg;
>>>>> end Inc;
>>>>>
>>>>> There is a very simple rule for all this:
>>>>>
>>>>> 1. Formal generic subroutines -> abstract primitive operations
>>>>> 2. Subroutines in the body -> class-wide operations.
>>>> 
>>>> So you derive from Additive to get a specific implementation?
>>>> 
>>>> Like
>>>> 
>>>>   type Vector   is Additive with ...;
>>>>   type CountVal is Additive with ...;
>>>> 
>>>> Right? But then, you should note that with
>>>> 
>>>>   C: Countval;
>>>> 
>>>>   Inc(C).
>>>> 
>>>> returns an 'Additive', not a 'CountVal'.
>>>
>>> No, it does Additive'Class! Thus, no problem.
>> 
>> I've been expressing myself sloppily. It should return a CountVal, not
>> an Additive'Class. CountVal(s) could not be added to Vectors -- there
>> is a difference.
>
> When Inc returns CountVal then it is not a member of Additive in the
> result. So you cannot reuse the result for other members of Additive.

Exactly. So it should not return Additive'Class (which can be added to
other members of Additive'Class), but must return CountVal to prevent
this. But since you said

>>> No, it does Additive'Class! Thus, no problem.

that means your approach fails. Do you see the different type
structure the approach using generics produces as compared to your
class inheritance approach?


>>> (note that the goal was polymorphic Inc, if you wanted it covariant that
>> 
>> No. The goal was to have mechanism to write the algorithms once and
>> being able to pull various actual operators/procedures from that
>> without replicating the specification of the algorithm.
>
> If you want to reuse Inc's algorithm in various specific Inc, then you
> would use wrappers:

No I wouldn't. At the most I'd want to instantiate one generic. See:
We are not talking about one procedure. In general we are talking
about whole libraries (i.e. BTree manipulation and search) which
contain -- in extremis -- 10 to hundred procedures, and I certainly do
NOT want to wrap all of them for every new instance differently typed
instance of the problem.


> function Common_Inc (Arg : Additive'Class) return Additive'Class is
> begin
>    return Increment + Arg;
> end Common_Inc;
> function Inc (Arg : Additive) return Additive is abstract;
>
> function Inc (Arg : CountVal) return CountVal is
> begin
>    return CountVal (Common_Inc (Arg));
> end Inc;
>
> However I don't understand the reason, why.

Look at the vector space example.


>> Let me suggest 1 other example for the usefulness of generics and than
>> 1 example where generics (Ada-style) help, but parametric polymorphism
>> (what I have been talking about as parametrized types) would actually
>> bring an advantage.
>> 
>> Example 1:
>> 
>>   An abstract vector space is defined as a sets of vectors u,v,w,...
>>   and scalars a,b,c, ...  with a number of operations:
>>    
>>     - scalars are a field, i.e. have additions an multiplication with certain properties
>>     - there is amultiplication between scalars and vectors: a*v
>>     - there is an addition between vectors.
>> 
>>   A normalized vector space introduces the idea of distance between
>>   verctors, Again certain laws apply. For the programmer: There is a
>>   dist-functions which takes 2 vectors a parameters.
>> 
>>   You can do a really huge amount of mathematics with this
>>   axioms. Examples of vector spaces with thos properties would be
>>   certain subsets of functions, finite vectors (i.e. arrays of N
>>   components), polynomes, etc.
>> 
>>   One application would be, given a function on the vector space f : V
>>   -> Real_Numbers to find minima of this function.
>> 
>>   There is an algorithm that is not very efficient but works in a vast
>>   number of cases without having to use specific knowledge of the
>>   underlying vector space.
>> 
>> With Ada generics I'd define the vector space interface a generic and
>> instantiate accordingly. The algorithm to fin minima would be
>> implemented as generic and take a vector space package as generic
>> parameter.


> I am deeply unsatisfied with generics here, because this example is almost
> exactly what I am doing. I have:
>
> Over a real domain I have:
>
> 1. Scalars
> 2. Intervals
> 3. Fuzzy numbers with a partly linear membership function
> 4. Fuzzy numbers with membership function of a nested intervals
>     + algebra of 1, 2, 3, 4 and between them
>
> But that is not all:
> 5. Sets of 3
>    + lattice over it
>
> Not yet:
>
> 6. Dimensioned scalars
> 7. Dimensioned intervals
>     + algebra
> ...
> n. Sets of dimensioned numbers
>    + lattice over it
>    + algebra between dimensioned things and scalars
> ...
> n+1 String I/O for all of them
>    + names for the members of the sets
> ...
> n+m+1 GTK widgets for them
> ...

> Should I show you generic specifications of this mess? 

And it does become better with OO? I doubt that very much. Indeed the
trick is, not to have n+m+1 instances but package instances of
generics into libraries and instantiate whole "world" in one
stroke. Have a look into the Booch components as an example.

> Can you imagine the instantiations chain from Float down to GTK+
> widget (provided your GNAT would be able to eat it (:-()? I can give
> you a link...

I have solved similar "problems". So, thanks, no.

> I DON"T want it. I need a clean way to describe an algebra and a lattice
> and then mix and bend them as I want. 

I doubt OO is the way. And whereas the Ada generics are somewhat
cumbersome (as compared with parametric polymorphism + functors + type
inference, which George doesn't like), they are your best way out of
this mess if you don't want to use a ML-like type system. They are,
indeed, good. 

> I want to be able to derive everything from a scalar. There is
> always much talk about how mathematical are generics and FP, it is
> amazing to me how readily people believe in that.

So they are wrong? :-)) Perhaps a big conspiracy, like the big C/C++
conspiracy and the big Java conspiracy.

People, you make me laugh. Isn't it avantgarde enough just to use Ada?
Must everyone else in this world be a misguided moron or an evil
propagandist?



>> Example 2
>> 
>>   Write a quicksort algorithm on arrays which can be reused for arrays
>>   of almost arbitrary elements, if a suitable order relationship is
>>   defined. Note that I might want to sort _the same_ elements with
>>   different orders (like insurance number or alphabetically ...).
>

> No problem [with some extensions to Ada types system]. 

A yes, certainly. They are already here thos extension. Their name is
-- da da da daaamm! -- generics!!!

> You need two interfaces: Array and Weakly_Ordered. 

Which forced me to use tagged type all day long and all the way, where
simply traditional array access would suffice. Let's have a look at
verifiability: I'm sure, generics can be verified better and easier. I
heard something about tagged types being really out in that sector,
and by the way, I agree. The dispatch over 13 subclasses mess
"patterns" introduce is just spagetthi programming with a big
name. (Not to disparage pattern, but making something OO doesn't make
it modular or structured per se).

> You could also sort same elements of same container object using
> different orders. [However usually in such cases one better uses a
> sorted view, rather than physically sorts.

That you can do, but I still could just sort accesses to the
elements. Withou the OO mess.


>> Yes. But Georg used generics, so it worked. You said, you don't want
>> generics, but it doesn't work. I fail to see, how George has to use
>> select an example that makes your misguided hypothesis -- that
>> generics are not neeeded -- hold up. Quite the opposite.


> generic
>    type Element is private;
>    with function "<" (Left, Right : Element)  return Boolean;
>    with function "=" (Left, Right : Element)  return Boolean;
>    type Container ...
> procedure Quick_Sort (...);

> How can this can sort the same container?

Which "same container"?

> This is a clear case where
> generics don't work. 

 Have you recently had a look to Ada.Containers? There is a generic array sort. So? 
 And BTW, you don't need "=".

> You need "<" and "=" be passed as proper functions
> rather than formal generic functions. [It is not static polymorphism
> anymore.]

And, what is the problem with that.

>> As an software engineer I'd always prefer
>> generics, since they avoid polymorphism where no polymorphism is
>> required or intended.
>
> ? Generics = static polymorphism.

No. Query negative response indicated. READY> [].

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sun, 04 Feb 2007 21:44:17 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 03 Feb 2007 15:16:21 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote:
>>>>
>>> I've been expressing myself sloppily. It should return a CountVal, not
>>> an Additive'Class. CountVal(s) could not be added to Vectors -- there
>>> is a difference.
>>
>> When Inc returns CountVal then it is not a member of Additive in the
>> result. So you cannot reuse the result for other members of Additive.
> 
> Exactly. So it should not return Additive'Class (which can be added to
> other members of Additive'Class), but must return CountVal to prevent
> this.

If that was the only reason, then that worked perfectly in Ada 83, before
Ada 95 broke it for tagged types [there were some reasons, though]:

type Isolated_CountVal is new CountVal; -- Done

>>>> No, it does Additive'Class! Thus, no problem.
> 
> that means your approach fails. Do you see the different type
> structure the approach using generics produces as compared to your
> class inheritance approach?

First, what was the problem? Moving target is a difficult thing to track.

>>>> (note that the goal was polymorphic Inc, if you wanted it covariant that
>>> 
>>> No. The goal was to have mechanism to write the algorithms once and
>>> being able to pull various actual operators/procedures from that
>>> without replicating the specification of the algorithm.
>>
>> If you want to reuse Inc's algorithm in various specific Inc, then you
>> would use wrappers:
> 
> No I wouldn't. At the most I'd want to instantiate one generic. See:
> We are not talking about one procedure. In general we are talking
> about whole libraries (i.e. BTree manipulation and search) which
> contain -- in extremis -- 10 to hundred procedures, and I certainly do
> NOT want to wrap all of them for every new instance differently typed
> instance of the problem.

That indeed looks like type X is new Y; Compare ONE line vs. hundred
instantiations!

BTW, there is no generic libraries in a sane sense of this word. Only
instantiations of generic libraries are libraries. (:-))
 
>> Should I show you generic specifications of this mess? 
> 
> And it does become better with OO? I doubt that very much.

Nobody tied. If the efforts spent on fixing Ada generics were invested into
the type system, who knows.

> Indeed the
> trick is, not to have n+m+1 instances but package instances of
> generics into libraries and instantiate whole "world" in one
> stroke.

I does not work, because it is not a world it is a multiverse of
interconnected worlds of different types.

The great idea of Ada numeric types with its ranges and accuracy gets lost,
because for any of them you have to instantiate all this pathetic mess. It
ends up with C-ish everything is double.

Generics is not Ada!

>> I DON"T want it. I need a clean way to describe an algebra and a lattice
>> and then mix and bend them as I want. 
> 
> I doubt OO is the way.

Nobody seriously tried it. Ironically, but C++ which was started as "C with
classes" suddenly turned into #define++!

>> I want to be able to derive everything from a scalar. There is
>> always much talk about how mathematical are generics and FP, it is
>> amazing to me how readily people believe in that.
> 
> So they are wrong? :-)) Perhaps a big conspiracy, like the big C/C++
> conspiracy and the big Java conspiracy.

An argumentation to popularity? (:-))

> People, you make me laugh.

I don't speak for Ada community. I bet the silent majority is rather with
you than with me.

> Isn't it avantgarde enough just to use Ada?
> Must everyone else in this world be a misguided moron or an evil
> propagandist?

Huh, c.l.a is a quite tolerant group, IMO.

>> You need two interfaces: Array and Weakly_Ordered. 
> 
> Which forced me to use tagged type all day long and all the way, where
> simply traditional array access would suffice.

All types shall be tagged, including Boolean.

> Let's have a look at
> verifiability: I'm sure, generics can be verified better and easier. I
> heard something about tagged types being really out in that sector,
> and by the way, I agree. The dispatch over 13 subclasses mess
> "patterns" introduce is just spagetthi programming with a big
> name. (Not to disparage pattern, but making something OO doesn't make
> it modular or structured per se).

What about 13 generic packages?

>> You could also sort same elements of same container object using
>> different orders. [However usually in such cases one better uses a
>> sorted view, rather than physically sorts.
> 
> That you can do, but I still could just sort accesses to the
> elements. Withou the OO mess.

1. It is not a generic solution.
2. Elements must be aliased, which changes the container type.
3. You can do that with OO.

Class-wide (OO), generic, functional are orthogonal approaches which can be
mixed in different proportions. In a proper type system they all will
converge because both generics and procedures will become proper types and
values. I fail to see the reason why this so irritates you.

>>> Yes. But Georg used generics, so it worked. You said, you don't want
>>> generics, but it doesn't work. I fail to see, how George has to use
>>> select an example that makes your misguided hypothesis -- that
>>> generics are not neeeded -- hold up. Quite the opposite.
> 
> 
>> generic
>>    type Element is private;
>>    with function "<" (Left, Right : Element)  return Boolean;
>>    with function "=" (Left, Right : Element)  return Boolean;
>>    type Container ...
>> procedure Quick_Sort (...);
> 
>> How can this can sort the same container?
> 
> Which "same container"?

Of the same type and the same object.

>> This is a clear case where generics don't work. 
> 
>  Have you recently had a look to Ada.Containers? There is a generic array sort. So? 

What is generic there? How polymorphism of comparison is achieved.
Statically, dynamically, ad-hoc?

>> You need "<" and "=" be passed as proper functions
>> rather than formal generic functions. [It is not static polymorphism
>> anymore.]
> 
> And, what is the problem with that.

That it is not generic. You cannot call a car solar just because you carry
wrist-watch with solar cells while driving it...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 04 Feb 2007 21:44:17 +0100, Markus E Leypold wrote:
>

> I don't speak for Ada community. I bet the silent majority is rather with
> you than with me.

I guess the silent majority is slightly surprised about this recent
flurry of off topic mails but bears it with good grace. I've noticed
this: They are slow in c.l.a. to quench of OT threads (a good thing I
think, but which I now want to stop abusing -- if anybody wants to
continue this discussion (with me) it needs a hypothesis / subject
first and another group).

>> Isn't it avantgarde enough just to use Ada?
>> Must everyone else in this world be a misguided moron or an evil
>> propagandist?
>
> Huh, c.l.a is a quite tolerant group, IMO.

Indeed. There are, though, people, who have at least implied that the
use of C is somewhere between sheer incompetence and crime. OK,
perhaps I read that wrong. I only had the impression that few are
interested in the reasons why -- well, C and C++ (e.g.) are more often
used than Ada -- and that there is at least a sub group which is more
interested in reassuring themselves that this is due to the injustice
of the world -- rather than trying to understand the factors
involved. I admit -- that certainly is not the majority here, which
kept their own counsel :-).

Never mind: I usually like the level of competence in c.l.a., but I
certainly get some strange vibration when the some issues are
touched. The paragraph quoted above was unjust though.

>>> You need two interfaces: Array and Weakly_Ordered. 
>> 
>> Which forced me to use tagged type all day long and all the way, where
>> simply traditional array access would suffice.
>
> All types shall be tagged, including Boolean.

I'm already out of the discussion, but my brain just started to curdle.

> converge because both generics and procedures will become proper types and
> values. I fail to see the reason why this so irritates you.

Because your approach does not work? I'm actually less irritated the
flabbergasted.

<more incomprehensible stuff snipped :->

Regards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Fri, 2007-02-02 at 10:20 +0100, Dmitry A. Kazakov wrote:
> On Thu, 01 Feb 2007 17:26:21 +0100, Georg Bauhaus wrote:

> > Actually, a syntax that is used in a theory book is
> > {left/right paren}{subscript i}.
> 
> Great. The next step would be to introduce expression in subscripts: )2+1 =
> )3 = ))). Right? Then we proceed to )f(...) where f is a free function that
> determines the number of brackets. OK? Now the question is, is it still
> syntax? (:-))

In Lisp, yes, every Lisp programmer creates his or her own
syntax anyway. :-) In the text book this only serves to point
out that a left bracket must match a right bracket on the
stack. The index prevents mixing parens.


> type Additive is abstract;  -- Should be enough for an interface
> function "+" (A, B : Additive) return Additive is abstract;
> 
> Here I am not sure about "increment" variable, because it is not
> initialized. Anyway:

That's the point: you create instances of functions
that return the sum of their one argument plus an Increment.
The Increment is bound to a value at the point of instantiation.


So that we have

  function next is
     new Inc(T => Integer, Increment => 1);
  function next_but_one is
     new Inc(T => Integer, Increment => 2);

  pragma assert(next_but_one(1) = 1 + next(x));

This isn't exactly like 

(define inc
 (lambda (Increment)
   (lambda (x)
     (+ Increment x))))

(defined next (inc 1))
(defined next-but-one (inc 2))

because next and next_but_one cannot be passed outwards in
Ada. (Which I understand you don't want anyway ;-)


Or similarly, but not creating function instances,

   type Section(Increment: Additive) is new Additive with private;
   function inc(x: Section) return Integer;

   next: Section(Increment => 1);
   next_but_one: Section(Increment => 2);

   pragma assert(inc(next_but_one) = 1 + inc(next));

And you cannot pass these objects outwards, either.

> function Increment return Additive is abstract;
>    -- Better be getter/setter pair. Unfortunately Ada does not have
>    -- "abstract variable interface" it should have

You could start by declaring

   type Integer is new Controlled
                   and Accessors
                   and Additive with private;


> BTW, can you do the same for the case where Increment were Integer and Arg
> were Float? [ You would need multiple dispatch in "+",

Why would I need multiple dispatch? I could just as well state
the requirement in the generic "+" function(s), taking arguments
of type Integer and Float.

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 15:27:22 +0100, Georg Bauhaus wrote:

> So that we have
> 
>   function next is
>      new Inc(T => Integer, Increment => 1);
>   function next_but_one is
>      new Inc(T => Integer, Increment => 2);
> 
>   pragma assert(next_but_one(1) = 1 + next(x));
> 
> This isn't exactly like 
> 
> (define inc
>  (lambda (Increment)
>    (lambda (x)
>      (+ Increment x))))
> 
> (defined next (inc 1))
> (defined next-but-one (inc 2))
> 
> because next and next_but_one cannot be passed outwards in
> Ada. (Which I understand you don't want anyway ;-)

That depends on what you mean 
>
> Or similarly, but not creating function instances,
> 
>    type Section(Increment: Additive) is new Additive with private;
>    function inc(x: Section) return Integer;
> 
>    next: Section(Increment => 1);
>    next_but_one: Section(Increment => 2);
> 
>    pragma assert(inc(next_but_one) = 1 + inc(next));
> 
> And you cannot pass these objects outwards, either.

Why should I pass them outwards? It seems like three mixed issues:

1. Types of subprograms (Ada should have them, but it does not)
2. Specialization, a sugar for wrappers (It could be useful too)
3. Upward closures (Bad idea, why next should be visible in places where 1
does not exist?)

>> function Increment return Additive is abstract;
>>    -- Better be getter/setter pair. Unfortunately Ada does not have
>>    -- "abstract variable interface" it should have
> 
> You could start by declaring
> 
>    type Integer is new Controlled
>                    and Accessors
>                    and Additive with private;

You don't need to specify all interfaces in advance:

type Integer_For_Foo is new Integer and Interface_For_Foo;

(Multiple inheritance from concrete types shall be.)

>> BTW, can you do the same for the case where Increment were Integer and Arg
>> were Float? [ You would need multiple dispatch in "+",
> 
> Why would I need multiple dispatch? I could just as well state
> the requirement in the generic "+" function(s), taking arguments
> of type Integer and Float.

Geometric explosion of variants. Then you defeat the very idea of generic
programming, which was to talk in terms of Additive, rather than in all
concrete instances of in this concrete program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> >> There is absolutely no need to have built-in GC, if you have abstract
> >> referential (access) interfaces. Note additional advantage: you can have
> >> different GC's handling objects of same types in the same application!
> > 
> > But there is. Only under very restricted circumstances the necessity
> > of deallocation can be decided locally. With reference sharing
> > (representation sharing) between values (think Lisp-like lists -- and
> > I think you need that for efficience reasons sooner or later -- you're
> > either back to a "manual" reference counting scheme (inefficient) or
> > you really need GC.
> 
> I don't see how "manual" is different from "implemented by the compiler
> vendor." There is no magical GC hardware around... Each GC is reference
> counting, only the ways of counting differ.

Are you saying this seriously? The difference, of course, is the amount of
programmer effort involved.

If the compiler does it, then GC is implemented "correctly" (or at least more
correctly than the programmer's efforts) without the programmer needing to
redo it all the time.

Even if you have a reusable GC library, I would still assert that you cannot
do your own GC properly at the application level. It is not that magical GC
hardware is needed, it is instead that the compiler has all the low level
hooks so as to provide the GC with the information needed to know when data is
in use or not.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: How come Ada isn't more popular?

[Randy Brukardt]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message
news:ubqkd8yk3.fsf@STRIPCAPStelus.net...
...
> Even if you have a reusable GC library, I would still assert that you
cannot
> do your own GC properly at the application level. It is not that magical
GC
> hardware is needed, it is instead that the compiler has all the low level
> hooks so as to provide the GC with the information needed to know when
data is
> in use or not.

I don't agree. Ada provides those hooks to the user code in the form of
controlled types and finalization. It's always possible for an object to
know that it is about to be destroyed. Combined with using local objects as
much as possible (so that they can be destroyed automatically) and avoiding
references as much as possible, there is no particular problem, and no GC is
necessary.

The only time you need GC is when the owner of an object looses any
connection to it without destroying it. I think that represents a program
bug - a manifestation of sloppy programming.

In any case, I think GC is just a stopover on the road to general
persistence. At some point in the future, we'll have enough space that we
won't ever destroy objects. That will give everything the value of a good
version control system -- older versions will always be available. GC is
unnecessary in this system (and quite possibly interferes with it), and
forcing support for it isn't helpful. It's like encoding other forms of
obsolete technology into your programming languages; because of
compatibility you can never get rid of them.

                                 Randy.

in defense of GC (was Re: How come Ada isn't more popular?)

[Ray Blaak]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I don't agree. Ada provides those hooks to the user code in the form of
> controlled types and finalization. It's always possible for an object to
> know that it is about to be destroyed. Combined with using local objects as
> much as possible (so that they can be destroyed automatically) and avoiding
> references as much as possible, there is no particular problem, and no GC is
> necessary.

Doing GC by marking scope exits is a fundamentally inefficient way of doing
GC. This is the classical performance hit that reference counting schemes
suffer from, which can result in "waves" of cascading cleanups.

Modern GC algorithms do things by "finding" unused objects at collection
time. In between the GC is not running, which leads to faster and more
predictable execution times. And collection time does not necessarily imply a
huge performance spike either, as collection is amortized into future
collections.

Furthermore, finalization-based GC only lets the programmer have control over
their own types. If GC is part of the runtime one has the confidence that all
memory in the system is being properly managed (outside of unsafe areas,
interfaces to foreign functions, etc.).

Modern GC systems simply do a better job at it them people do.

> The only time you need GC is when the owner of an object looses any
> connection to it without destroying it. I think that represents a program
> bug - a manifestation of sloppy programming.

It is only sloppy programming in the context of manual clean up. With a valid
GC you do not have to clean up at all. One simply stops using objects when
they no longer need them, just "dropping them on the floor", leaving it up to
the GC to eventually collect it.

This considerably simplifies many algorithms and application code, and the
"sloppiness" in fact becomes an advantage: cleaner, easier to maintain code.

> In any case, I think GC is just a stopover on the road to general
> persistence. At some point in the future, we'll have enough space that we
> won't ever destroy objects. 

No way. As long as you have finite memories and long running algorithms, you
will need to clean up. Just leave that clean up to an automatic system.

Anyway, even "destroy nothing" is a form of GC, assuming that a process'
memory gets reclaimed by the OS when it terminates.

The point is that the programmer is freed from the error prone tedium of
explicitly managing memory.

> GC is unnecessary in this system (and quite possibly interferes with it),
> and forcing support for it isn't helpful. It's like encoding other forms of
> obsolete technology into your programming languages; because of
> compatibility you can never get rid of them.

GC is one of the modern advances of computing science, period, akin to the use
of high level languages vs assembly, lexical scoping vs dynamic scoping,
strong typing vs no typing, etc.

It should be used by default and turned off only in unusual situations.

Of course, in this group, those circumstances are probably the usual
case, what with the use of Ada for realtime and embedded programming.

Still, given recent realtime GC algorithms, I would consider the use of GC for
any system I was responsible for, and would give it up reluctantly, only if
timing and space constraints were too tight for a given application.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 01:37:26 GMT, Ray Blaak wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:

[...]
> Modern GC systems simply do a better job at it them people do.

Maybe, but that does not explain why such GC should be hard-wired. Note you
are talking about systems (plural), but wired could be only one. Why do you
want to forbid me to use my GC?

[...]
> The point is that the programmer is freed from the error prone tedium of
> explicitly managing memory.

This is a misconception. There are two fundamentally different issues:

1. Object scopes
2. Memory management

The second issue is less and less relevant as Randy pointed out. The first
issue is always relevant. It is a good design to consider where an object
exists. GC [and upward closures] is an attitude of making everything
potentially global. In fact it is worse than just global. It is "I don't
know where I need that damn thing."

This is A) mess, B) sloppy programming, C) impossible model in our
networking distributed relativist world.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 02 Feb 2007 01:37:26 GMT, Ray Blaak wrote:

>> The point is that the programmer is freed from the error prone tedium of
>> explicitly managing memory.
>
> This is a misconception. There are two fundamentally different issues:
>
> 1. Object scopes
> 2. Memory management
>
> The second issue is less and less relevant as Randy pointed out. The first
> issue is always relevant. It is a good design to consider where an object
> exists. GC [and upward closures] is an attitude of making everything
> potentially global. In fact it is worse than just global. It is "I don't
> know where I need that damn thing."

Closure don't "make things global". They do it as much as returning an
Integer, makes, GOD FORBID!, a value global (don't return Integers
people, that makes a value global and we all know, global is bad --
how nonsensical is that?). Closures provide exactly the opposite of
"making things global". They provide a way for a module (a capsule of
knowledge / implementation) to return a method (how to do things)
without disclosing the implementation (i.e. keeping up the abstraction
barrier). 

I can't believe I even have to spell it out. On the other side -- why
do I argue? You're even opposing generics.

> This is A) mess, B) sloppy programming, C) impossible model in our
> networking distributed relativist world.

There are BTW, even distributed garbage collection algorithms. This
probably will enrage you no end? :-).

Re: in defense of GC

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 02 Feb 2007 01:37:26 GMT, Ray Blaak wrote:
> 
>>> The point is that the programmer is freed from the error prone tedium of
>>> explicitly managing memory.
>>
>> This is a misconception. There are two fundamentally different issues:
>>
>> 1. Object scopes
>> 2. Memory management
>>
>> The second issue is less and less relevant as Randy pointed out. The first
>> issue is always relevant. It is a good design to consider where an object
>> exists. GC [and upward closures] is an attitude of making everything
>> potentially global. In fact it is worse than just global. It is "I don't
>> know where I need that damn thing."
> 
> Closure don't "make things global". They do it as much as returning an
> Integer, makes, GOD FORBID!, a value global (don't return Integers
> people, that makes a value global and we all know, global is bad --
> how nonsensical is that?).

You return a value of the type (Integer) which scope encloses the
subprogram returning that value.

> Closures provide exactly the opposite of
> "making things global". They provide a way for a module (a capsule of
> knowledge / implementation) to return a method (how to do things)
> without disclosing the implementation (i.e. keeping up the abstraction
> barrier).

I have no problem with that. But it is not yet an upward closure when the
type of the returned object is local.

I am a long proponent of procedural types for Ada. Now consider. A
procedure is a limited object. Limited objects can be returned in Ada 2005.
What else you need? [Note, this is still not an upward closure, I am
opposing.]

> I can't believe I even have to spell it out. On the other side -- why
> do I argue? You're even opposing generics.

Yes I do! (:-))

>> This is A) mess, B) sloppy programming, C) impossible model in our
>> networking distributed relativist world.
> 
> There are BTW, even distributed garbage collection algorithms. This
> probably will enrage you no end? :-).

Yes I know, they are usually called trojans...  (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 02 Feb 2007 01:37:26 GMT, Ray Blaak wrote:
>> 
>>>> The point is that the programmer is freed from the error prone tedium of
>>>> explicitly managing memory.
>>>
>>> This is a misconception. There are two fundamentally different issues:
>>>
>>> 1. Object scopes
>>> 2. Memory management
>>>
>>> The second issue is less and less relevant as Randy pointed out. The first
>>> issue is always relevant. It is a good design to consider where an object
>>> exists. GC [and upward closures] is an attitude of making everything
>>> potentially global. In fact it is worse than just global. It is "I don't
>>> know where I need that damn thing."
>> 
>> Closure don't "make things global". They do it as much as returning an
>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>> people, that makes a value global and we all know, global is bad --
>> how nonsensical is that?).
>
> You return a value of the type (Integer) which scope encloses the
> subprogram returning that value.

Same applies to closures when they are returned. Where is the problem?
Scope is defined as the visibility of identifiers. There is now
introduction of global scope in the cas eof returning closures. You
seem to confuse this with lifetime of memory....


>
>> Closures provide exactly the opposite of
>> "making things global". They provide a way for a module (a capsule of
>> knowledge / implementation) to return a method (how to do things)
>> without disclosing the implementation (i.e. keeping up the abstraction
>> barrier).
>
> I have no problem with that. But it is not yet an upward closure when the
> type of the returned object is local.

?. Do you confuse the type of the enclosed objects with the type of
the closure?


Forgive me Dmitry, but I'm on the verge of giving up on you. Your
terminology is, well, unusual. I suggest you read up on some FP and
especially do some and the we restart this argument (or not).


> I am a long proponent of procedural types for Ada. Now consider. A
> procedure is a limited object. Limited objects can be returned in Ada 2005.
> What else you need? [Note, this is still not an upward closure, I am
> opposing.]

I do need that

  function Make_a_Stepper (K:Integer) return ... is

      N : Integer := Complicated_Function(K);

      function Stepper(F:Foo) return Foo is
    
        begin
          
          return Foo + N;

        end;

    begin
      return Stepper;
    end;


would work. And no nitpicking, please, if I made syntax error here: The
intention should be clear.

If it works, we have closures. If it doesn't I fail to see what you
mean by 'returning procedures'. You seem to be long term proponent for
something you're arguing hard to be bad / not useful / whatever ... --
ahem, fighting yourself :-).


>> I can't believe I even have to spell it out. On the other side -- why
>> do I argue? You're even opposing generics.
>
> Yes I do! (:-))

Yes I notice. That does make you avantgarde, certainly. Even the Java
people learned that there is no live without generics / functors.


>>> This is A) mess, B) sloppy programming, C) impossible model in our
>>> networking distributed relativist world.
>> 
>> There are BTW, even distributed garbage collection algorithms. This
>> probably will enrage you no end? :-).
>
> Yes I know, they are usually called trojans...  (:-))

?.

Regards -- Markus

Re: in defense of GC

[Dmitry A. Kazakov]

On Sat, 03 Feb 2007 15:28:53 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:
>>
>>> Closure don't "make things global". They do it as much as returning an
>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>> people, that makes a value global and we all know, global is bad --
>>> how nonsensical is that?).
>>
>> You return a value of the type (Integer) which scope encloses the
>> subprogram returning that value.
> 
> Same applies to closures when they are returned. Where is the problem?

The problem is this:

function Foo return ?What? is
   type Bar is ...;
   X : Bar;
begin
   return X;
end Foo;

>> I am a long proponent of procedural types for Ada. Now consider. A
>> procedure is a limited object. Limited objects can be returned in Ada 2005.
>> What else you need? [Note, this is still not an upward closure, I am
>> opposing.]
> 
> I do need that
> 
>   function Make_a_Stepper (K:Integer) return ... is
> 
>       N : Integer := Complicated_Function(K);
> 
>       function Stepper(F:Foo) return Foo is
>     
>         begin
>           
>           return Foo + N;
> 
>         end;
> 
>     begin
>       return Stepper;
>     end;
> 
> 
> would work. And no nitpicking, please, if I made syntax error here: The
> intention should be clear.

I suppose it is. Here I propose a closure-free solution:

package Something_Very_Functional is
   type function Stepper (F : Foo) return Foo;
      -- The type of a function we want to pass somewhere
   procedure Step_It (Visitor : Stepper'Class);
   ...
end Something_Very_Functional;

package Stepper_Factory is
   function Create (K : Integer) return Stepper'Class;
      -- This is a constructor for the stepper provided here. We
      -- don't want to expose any details about it, so the
      -- Stepper type is made private.
private
   type Stepper_With_A_Parameter (N : Integer) is new Stepper;
      -- This is a derived type to have a discriminant, which could serve
      -- as a carrier for the locally computed value.
end Stepper_Factory;

package body Stepper_Factory is
   function Create (K : Integer) return Stepper'Class is
   begin
      return
         Stepper_With_A_Parameter'
         (  N => Complicated_Function (K),
         with
            begin
               return F + N;
            end;
         );
end Stepper_Factory;

Some notes. Within the "procedural record extension" the visibility rules
are such that local variables of Create are invisible. The package data are
visible and accessibility checks are made to ensure that the scope of
Stepper_With_A_Parameter is not statically deeper than one of Stepper.

-----------------
BTW, I prefer an OO design with Stepper being an abstract primitive
operation of some object:

type Data is abstract ...;
function Stepper (State : in out Data; F : Foo) return Foo is abstract;
procedure Step_It (Data : in out Data'Class);
-------------------

> If it works, we have closures. If it doesn't I fail to see what you
> mean by 'returning procedures'.

Hmm, it must be obvious. How could it be so that we have
access-to-procedure types, but no procedure types?

>>> I can't believe I even have to spell it out. On the other side -- why
>>> do I argue? You're even opposing generics.
>>
>> Yes I do! (:-))
> 
> Yes I notice. That does make you avantgarde, certainly. Even the Java
> people learned that there is no live without generics / functors.

As if Java weren't bad enough for them... (:-))

>>>> This is A) mess, B) sloppy programming, C) impossible model in our
>>>> networking distributed relativist world.
>>> 
>>> There are BTW, even distributed garbage collection algorithms. This
>>> probably will enrage you no end? :-).
>>
>> Yes I know, they are usually called trojans...  (:-))
> 
> ?.

They arrive at your computer and collect garbage while you don't notice
that... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 03 Feb 2007 15:28:53 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:
>>>
>>>> Closure don't "make things global". They do it as much as returning an
>>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>>> people, that makes a value global and we all know, global is bad --
>>>> how nonsensical is that?).
>>>
>>> You return a value of the type (Integer) which scope encloses the
>>> subprogram returning that value.
>> 
>> Same applies to closures when they are returned. Where is the problem?
>
> The problem is this:
>
> function Foo return ?What? is
>    type Bar is ...;
>    X : Bar;
> begin
>    return X;
> end Foo;
>
>>> I am a long proponent of procedural types for Ada. Now consider. A
>>> procedure is a limited object. Limited objects can be returned in Ada 2005.
>>> What else you need? [Note, this is still not an upward closure, I am
>>> opposing.]
>> 
>> I do need that
>> 
>>   function Make_a_Stepper (K:Integer) return ... is
>> 
>>       N : Integer := Complicated_Function(K);
>> 
>>       function Stepper(F:Foo) return Foo is
>>     
>>         begin
>>           
>>           return Foo + N;
>> 
>>         end;
>> 
>>     begin
>>       return Stepper;
>>     end;
>> 
>> 
>> would work. And no nitpicking, please, if I made syntax error here: The
>> intention should be clear.
>
> I suppose it is. Here I propose a closure-free solution:
>
> package Something_Very_Functional is
>    type function Stepper (F : Foo) return Foo;
>       -- The type of a function we want to pass somewhere
>    procedure Step_It (Visitor : Stepper'Class);
>    ...
> end Something_Very_Functional;
>
> package Stepper_Factory is
>    function Create (K : Integer) return Stepper'Class;
>       -- This is a constructor for the stepper provided here. We
>       -- don't want to expose any details about it, so the
>       -- Stepper type is made private.
> private
>    type Stepper_With_A_Parameter (N : Integer) is new Stepper;
>       -- This is a derived type to have a discriminant, which could serve
>       -- as a carrier for the locally computed value.
> end Stepper_Factory;
>
> package body Stepper_Factory is
>    function Create (K : Integer) return Stepper'Class is
>    begin
>       return
>          Stepper_With_A_Parameter'
>          (  N => Complicated_Function (K),
>          with
>             begin
>                return F + N;
>             end;
>          );
> end Stepper_Factory;
>
> Some notes. Within the "procedural record extension" the visibility rules
> are such that local variables of Create are invisible. The package data are
> visible and accessibility checks are made to ensure that the scope of
> Stepper_With_A_Parameter is not statically deeper than one of Stepper.
>
> -----------------
> BTW, I prefer an OO design with Stepper being an abstract primitive
> operation of some object:
>
> type Data is abstract ...;
> function Stepper (State : in out Data; F : Foo) return Foo is abstract;
> procedure Step_It (Data : in out Data'Class);
> -------------------

Yes. That is exactly what I referred to in earlier posts as clumsy --
to replace closure by this kind of dance.


>
>> If it works, we have closures. If it doesn't I fail to see what you
>> mean by 'returning procedures'.
>
> Hmm, it must be obvious. How could it be so that we have
> access-to-procedure types, but no procedure types?

?? I still do not understand. If memory serves me right, I cannot
return an access to a local procedure. So?


>>>> I can't believe I even have to spell it out. On the other side -- why
>>>> do I argue? You're even opposing generics.
>>>
>>> Yes I do! (:-))
>> 
>> Yes I notice. That does make you avantgarde, certainly. Even the Java
>> people learned that there is no live without generics / functors.
>
> As if Java weren't bad enough for them... (:-))

Well -- actually that was one of the things they did right for once,
and it wasn't even tacked on ad hoc, but carefully designed by people
who do know hwat they are talking about (i.e. Philip Wadler of FP
fame).

Regards -- Markus

Re: in defense of GC

[Dmitry A. Kazakov]

On Sun, 04 Feb 2007 21:24:01 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 03 Feb 2007 15:28:53 +0100, Markus E Leypold wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Fri, 02 Feb 2007 13:44:42 +0100, Markus E Leypold wrote:
>>>>
>>>>> Closure don't "make things global". They do it as much as returning an
>>>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>>>> people, that makes a value global and we all know, global is bad --
>>>>> how nonsensical is that?).
>>>>
>>>> You return a value of the type (Integer) which scope encloses the
>>>> subprogram returning that value.
>>> 
>>> Same applies to closures when they are returned. Where is the problem?
>>
>> The problem is this:
>>
>> function Foo return ?What? is
>>    type Bar is ...;
>>    X : Bar;
>> begin
>>    return X;
>> end Foo;
>>
>>>> I am a long proponent of procedural types for Ada. Now consider. A
>>>> procedure is a limited object. Limited objects can be returned in Ada 2005.
>>>> What else you need? [Note, this is still not an upward closure, I am
>>>> opposing.]
>>> 
>>> I do need that
>>> 
>>>   function Make_a_Stepper (K:Integer) return ... is
>>> 
>>>       N : Integer := Complicated_Function(K);
>>> 
>>>       function Stepper(F:Foo) return Foo is
>>>     
>>>         begin
>>>           
>>>           return Foo + N;
>>> 
>>>         end;
>>> 
>>>     begin
>>>       return Stepper;
>>>     end;
>>> 
>>> would work. And no nitpicking, please, if I made syntax error here: The
>>> intention should be clear.
>>
>> I suppose it is. Here I propose a closure-free solution:
>>
>> package Something_Very_Functional is
>>    type function Stepper (F : Foo) return Foo;
>>       -- The type of a function we want to pass somewhere
>>    procedure Step_It (Visitor : Stepper'Class);
>>    ...
>> end Something_Very_Functional;
>>
>> package Stepper_Factory is
>>    function Create (K : Integer) return Stepper'Class;
>>       -- This is a constructor for the stepper provided here. We
>>       -- don't want to expose any details about it, so the
>>       -- Stepper type is made private.
>> private
>>    type Stepper_With_A_Parameter (N : Integer) is new Stepper;
>>       -- This is a derived type to have a discriminant, which could serve
>>       -- as a carrier for the locally computed value.
>> end Stepper_Factory;
>>
>> package body Stepper_Factory is
>>    function Create (K : Integer) return Stepper'Class is
>>    begin
>>       return
>>          Stepper_With_A_Parameter'
>>          (  N => Complicated_Function (K),
>>          with
>>             begin
>>                return F + N;
>>             end;
>>          );
>> end Stepper_Factory;
>>
>> Some notes. Within the "procedural record extension" the visibility rules
>> are such that local variables of Create are invisible. The package data are
>> visible and accessibility checks are made to ensure that the scope of
>> Stepper_With_A_Parameter is not statically deeper than one of Stepper.
>>
>> -----------------
>> BTW, I prefer an OO design with Stepper being an abstract primitive
>> operation of some object:
>>
>> type Data is abstract ...;
>> function Stepper (State : in out Data; F : Foo) return Foo is abstract;
>> procedure Step_It (Data : in out Data'Class);
>> -------------------
> 
> Yes. That is exactly what I referred to in earlier posts as clumsy --
> to replace closure by this kind of dance.

Do you refer to the first variant or to the second?

Doesn't it solve the problem? Note that in your solution you were unable to
describe what function Make_a_Stepper actually returns. Consider also this:

protected type Bar is
   function Make_a_Mess return ...;
private
   Baz : Integer;
      -- To be put into the closure together with barriers of the entries!

how do you return a closure from a protected object or a task rendezvous?
Will it be able to assign Baz?

I certainly prefer OO solution because it explicitly maintains the context
of the operation. It is easier to understand for the reader and it easier
to maintain.

>>> If it works, we have closures. If it doesn't I fail to see what you
>>> mean by 'returning procedures'.
>>
>> Hmm, it must be obvious. How could it be so that we have
>> access-to-procedure types, but no procedure types?
> 
> ?? I still do not understand. If memory serves me right, I cannot
> return an access to a local procedure. So?

I merely explained why I consider procedural types necessary. Accessibility
checks are needed for both them and access to procedure. Though for
procedural values they will be much weaker. Downward closures would require
no checks at all.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> 
>> Yes. That is exactly what I referred to in earlier posts as clumsy --
>> to replace closure by this kind of dance.
>
> Do you refer to the first variant or to the second?

The "closure free solution" (I'm not quoting it again -- it's long
enough as it is).

> Doesn't it solve the problem? 

Perhaps. This (and some other stuff)

>>    type function Stepper (F : Foo) return Foo;
>>       -- The type of a function we want to pass somewhere
>>    procedure Step_It (Visitor : Stepper'Class);
>>    ...

doesn't look like Ada to me. So I assume, you're still proposing
language extensions. With unclear semantics to me. And perhaps they
alow you to do what you want: But so complicated, well ...

You can do that in FORTRAN and too: With even less comprehensibility.

> Note that in your solution you were unable to
> describe what function Make_a_Stepper actually returns. 

Since there is no closure type, presently. But if you like, add a language extension:

  type stepper_t is procedure ( I : Integer ) return Integer;

and the fill in this type.



> Consider also this:
>
> protected type Bar is
>    function Make_a_Mess return ...;
> private
>    Baz : Integer;
>       -- To be put into the closure together with barriers of the entries!
>
> how do you return a closure from a protected object or a task rendezvous?
> Will it be able to assign Baz?

Interesting thought. Either it must inherit the barriers, somehow, or
you simply can't.

> I certainly prefer OO solution because it explicitly maintains the context
> of the operation. It is easier to understand for the reader and it easier
> to maintain.

My mileage varies. 


>>>> If it works, we have closures. If it doesn't I fail to see what you
>>>> mean by 'returning procedures'.
>>>
>>> Hmm, it must be obvious. How could it be so that we have
>>> access-to-procedure types, but no procedure types?
>> 
>> ?? I still do not understand. If memory serves me right, I cannot
>> return an access to a local procedure. So?

> I merely explained why I consider procedural types necessary. 

Well -- I think your addition is not worth the effort, but YMMV. I
still do not see, how you would manage to pass procedure upwards which
us variables that are defined in their environment.

> Accessibility checks are needed for both them and access to
> procedure. Though for procedural values they will be much
> weaker. Downward closures would require no checks at all.

Just write an addendum to the ARM. Perhaps we'll find it in Ada
2020. But somehow I doubt it.

Regards -- Markus

Re: in defense of GC

[Markus E Leypold]

Hi Dmitry, 

I've just been reconsider this thread, which, in my news reader has
become quite unmanageable. I've written (or at list tried to hint at)
in another response that I somehow doubt the sense in continuing this
discussion. I'd like to reinforce that for a last time.

E.g. you write some hardly understandable statement that somehow mixes
up memory live times with visibility and scoping (which already made
me doubt you have any idea what "encapsulation" really means) ..., 


> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> > The second issue is less and less relevant as Randy pointed out. The first
> > issue is always relevant. It is a good design to consider where an object
> > exists. GC [and upward closures] is an attitude of making everything
> > potentially global. In fact it is worse than just global. It is "I don't
> > know where I need that damn thing."

but what is worse, you get refuted by Ray Blake, ...

> GC does not affect visibility or scoping. That is an orthogonal issue, and
> still quite properly under the control of the programmer. Upward closures do
> not make an object more global unless the closure explicitly exposes the
> object for external use.

.. and in more word, but not as well formulated, by me. But do we get
any feedback on that? No, instead we just continue the discussion with
some other quirky notion if yours which until then was a side issue.

>> I am a long proponent of procedural types for Ada. Now consider. A
>> procedure is a limited object. Limited objects can be returned in Ada 2005.
>> What else you need? [Note, this is still not an upward closure, I am
>> opposing.] 

>> I certainly prefer OO solution because it explicitly maintains the context
>> of the operation. It is easier to understand for the reader and it easier
>> to maintain.

And similar things happen in all sub-threads spawned by you or in
which you participate.

Does it make sense under the circumstances to continue the discussion?
I don't think so. 

And I fear to become a crank myself but just arguing OT (!!)  notions in c.l.a.
(and that includes my excursions into GC, FP and typesystems).

So I'm calling quits to this discussion (at least as far as my
participation goes).

Regards -- Markus

Re: in defense of GC

[Markus E Leypold]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Hi Dmitry, 
>
> I've just been reconsider this thread, which, in my news reader has
> become quite unmanageable. I've written (or at list tried to hint at)
> in another response that I somehow doubt the sense in continuing this
> discussion. I'd like to reinforce that for a last time.
>
> E.g. you write some hardly understandable statement that somehow mixes
> up memory live times with visibility and scoping (which already made
> me doubt you have any idea what "encapsulation" really means) ..., 
>
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> > The second issue is less and less relevant as Randy pointed out. The first
>> > issue is always relevant. It is a good design to consider where an object
>> > exists. GC [and upward closures] is an attitude of making everything
>> > potentially global. In fact it is worse than just global. It is "I don't
>> > know where I need that damn thing."
>
> but what is worse, you get refuted by Ray Blake, ...
>
>> GC does not affect visibility or scoping. That is an orthogonal issue, and
>> still quite properly under the control of the programmer. Upward closures do
>> not make an object more global unless the closure explicitly exposes the
>> object for external use.
>
> .. and in more word, but not as well formulated, by me. But do we get
> any feedback on that? No, instead we just continue the discussion with
> some other quirky notion if yours which until then was a side issue.

=> of yours.

Sorry.

>
>>> I am a long proponent of procedural types for Ada. Now consider. A
>>> procedure is a limited object. Limited objects can be returned in Ada 2005.
>>> What else you need? [Note, this is still not an upward closure, I am
>>> opposing.] 
>
>>> I certainly prefer OO solution because it explicitly maintains the context
>>> of the operation. It is easier to understand for the reader and it easier
>>> to maintain.
>
> And similar things happen in all sub-threads spawned by you or in
> which you participate.
>
> Does it make sense under the circumstances to continue the discussion?
> I don't think so. 
>
> And I fear to become a crank myself but just arguing OT (!!)  notions in c.l.a.
> (and that includes my excursions into GC, FP and typesystems).
>
> So I'm calling quits to this discussion (at least as far as my
> participation goes).
>
> Regards -- Markus

Re: in defense of GC

[Dmitry A. Kazakov]

On Sun, 04 Feb 2007 23:47:29 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Consider also this:
>>
>> protected type Bar is
>>    function Make_a_Mess return ...;
>> private
>>    Baz : Integer;
>>       -- To be put into the closure together with barriers of the entries!
>>
>> how do you return a closure from a protected object or a task rendezvous?
>> Will it be able to assign Baz?
> 
> Interesting thought. Either it must inherit the barriers, somehow, or
> you simply can't.

But proposing upward closures you have to be prepared to answer such
questions...
 
>  I
> still do not see, how you would manage to pass procedure upwards which
> us variables that are defined in their environment.

As I said before, I don't want this feature in Ada, it is your wish, not
mine. For all I don't know what is "environment." It is up to you to define
it, before it could be reasonably discussed. Further I don't see why
environment cannot be expressed as an object of manifested type (=OO
solution) and why it should be passed outwards.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 04 Feb 2007 23:47:29 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Consider also this:
>>>
>>> protected type Bar is
>>>    function Make_a_Mess return ...;
>>> private
>>>    Baz : Integer;
>>>       -- To be put into the closure together with barriers of the entries!
>>>
>>> how do you return a closure from a protected object or a task rendezvous?
>>> Will it be able to assign Baz?
>> 
>> Interesting thought. Either it must inherit the barriers, somehow, or
>> you simply can't.
>
> But proposing upward closures you have to be prepared to answer such
> questions...

Since I'm not on the standard commitee and neither get paid for it I
can afford such sloppiness. But just to set the record straight: I've
been talking about the general usefulness of closures (in languages)
in the context of general considerations of what other languages have
that might make the more popular than our beloved Ada, than about the
definition of closure (after your slip up concerning "but this makes
it global" this was necessary).

I've never tried to suggest that it would be easy to fit closures back
into Ada, nor did I suggest to do so in the short term. After all, the
next standard probably doesn't happen until 2020 or so ... :-).


>>  I
>> still do not see, how you would manage to pass procedure upwards which
>> us variables that are defined in their environment.
>
> As I said before, I don't want this feature in Ada, it is your wish, not

It was your suggestion that the code you proposed was some substitute
for closures.

> mine. 

> For all I don't know what is "environment." 

Exactly.

> It is up to you to define it, before it could be reasonably
> discussed. Further I don't see why environment cannot be expressed
> as an object of manifested type (=OO solution) and why it should be
> passed outwards.

Well, you see, we (that is: you, in this case :-) are missing some
groundwork on programming langauge design and implementation. So
necessarily we talk on cross purposes (closures cannot be grasped in
Ada terms). And I don't want to start a beginner's tutorial on FP here
on c.l.a. of all things.

So'll have to leave it at that, but -- as always I'm available to
targeted questions.

Regards -- Markus

Re: in defense of GC

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> I do need that
>
>   function Make_a_Stepper (K:Integer) return ... is
>
>       N : Integer := Complicated_Function(K);
>
>       function Stepper(F:Foo) return Foo is
>     
>         begin
>           
>           return Foo + N;
>
>         end;
>
>     begin
>       return Stepper;
>     end;
>
> would work. And no nitpicking, please, if I made syntax error here: The
> intention should be clear.

I don't think this is nitpicking:

I'm not sure what you mean by the above example.  Is N intended to be
constant or variable (in Ada terms -- that's immutable/immutable in FP
terms)?

Do you mean this:

  function Make_a_Stepper (K:Integer) return ... is
      N : constant Integer := Complicated_Function(K); -- I added "constant" here! ****************
      function Stepper(F:Foo) return Foo is
        begin
          return Foo + N;
        end;
    begin
      return Stepper;
    end;

Or this:

  function Make_a_Stepper (K:Integer) return ... is
      N : Integer := Complicated_Function(K);
      function Stepper(F:Foo) return Foo is
        begin
          N := N + 1; -- I added a modification of N here! ****************
          return Foo + N;
        end;
    begin
      return Stepper;
    end;

?

These two cases of so-called "upward closure" seem very different to me.
(Both are of course illegal in Ada, but we're discussing what "ought" to be.)

In the former case, we're returning a function that looks at some local
value (the value of N).  In this case, you comment about returning
integer values is quite correct:

>> Closure don't "make things global". They do it as much as returning an
>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>> people, that makes a value global and we all know, global is bad --
>> how nonsensical is that?).

Right.  What's the big deal?  Returning a function that looks at integer
values is no worse than returning integer values.  Integer values live
forever, and the value of N is certainly not tied to the lifetime of N.

But in the latter, case, the return of Stepper is causing the lifetime
of an integer VARIABLE (i.e. mutable) to be longer than one might
suspect for a local variable of Make_A_Stepper.  That seems like a
problem to me.

You (Markus) seem to be an advocate of (possibly-upward) closures.
And also an advocate of function programming.  So how would you like a
rule that says the former example is OK, but the latter is illegal?
(That is, upward closures are allowed only when you're doing functional
(no side-effects) programming).

Note that the latter is not functional -- a call to the function that
Make_A_Stepper returns modifies N, which is the key difference!

- Bob

Re: in defense of GC

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> I do need that
>>
>>   function Make_a_Stepper (K:Integer) return ... is
>>
>>       N : Integer := Complicated_Function(K);
>>
>>       function Stepper(F:Foo) return Foo is
>>     
>>         begin
>>           
>>           return Foo + N;
>>
>>         end;
>>
>>     begin
>>       return Stepper;
>>     end;
>>
>> would work. And no nitpicking, please, if I made syntax error here: The
>> intention should be clear.
>
> I don't think this is nitpicking:
>
> I'm not sure what you mean by the above example.  Is N intended to be
> constant or variable (in Ada terms -- that's immutable/immutable in FP
> terms)?

Ah, you see, that is the point with closures. If we were talking about
closures, N would be different for every invocation of Make_Stepper
but every Stepper returned would refer to a constant N during its
livetime. THis is why they are called closure (they enclose their
environment at the instance of their instantiation which in this case
would be (in a sense) between the invocation of Make_Stepper and
before the body of Make_Stepper is executed.


>
> Do you mean this:
>
>   function Make_a_Stepper (K:Integer) return ... is
>       N : constant Integer := Complicated_Function(K); -- I added "constant" here! ****************
>       function Stepper(F:Foo) return Foo is
>         begin
>           return Foo + N;
>         end;
>     begin
>       return Stepper;
>     end;
>
> Or this:
>
>   function Make_a_Stepper (K:Integer) return ... is
>       N : Integer := Complicated_Function(K);
>       function Stepper(F:Foo) return Foo is
>         begin
>           N := N + 1; -- I added a modification of N here! ****************
>           return Foo + N;
>         end;
>     begin
>       return Stepper;
>     end;
>
> ?
>
> These two cases of so-called "upward closure" seem very different to me.

Ah, yes, I see how that comes about, since we are not talking names
and their bindings to values here, but variables in Ada. Actually I'd
say both. The last case is no pure functional programming (just for
the record) and in OCaml would b expressed like this:

  let make_stepper k = 
      let n = ref (complicated k) 
      in
        (fun f -> n := !n + 1; f + !n)

and in the first case (just to show the difference)

  let make_stepper k = 
      let n = (complicated k) 
      in
        (fun f -> f + n)

So in (impure) FP both cases are possible and if we go back to Ada
syntax from that: Why not use the constant keyword to distinguish the
cases?

> (Both are of course illegal in Ada, but we're discussing what "ought" to be.)

Ehm. And I'm thankful for you rather insightful input :-).

> In the former case, we're returning a function that looks at some local
> value (the value of N).  In this case, you comment about returning
> integer values is quite correct:
>
>>> Closure don't "make things global". They do it as much as returning an
>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>> people, that makes a value global and we all know, global is bad --
>>> how nonsensical is that?).
>
> Right.  What's the big deal?  Returning a function that looks at integer
> values is no worse than returning integer values.  Integer values live
> forever, and the value of N is certainly not tied to the lifetime of N.


> But in the latter, case, the return of Stepper is causing the lifetime
> of an integer VARIABLE (i.e. mutable) to be longer than one might
> suspect for a local variable of Make_A_Stepper.  That seems like a
> problem to me.

It's still only encapsulated _state_, the visibility of indentifiers
(scope) is not extended by that. Outsiders can't look into the
closure. And we already have encapsulate state like this, in tagged
objects. Closure differ from objects only in 2 points: (1) they have
only one method (apply) and (2) they can take (implicitely) values
from their whole environment at the place of instantiation.

Indeed the more I think about it, a bit compiler support (which knows
which parts of the environment are actually used in the closures
body), a new keyword (closure to distinguis them from ordinary
procedures) and all the mechanisms already present in tagged types
should be quite enough implement closure in Ada. (Well, OK, there are
problems with sharing N in the non-constant case with other closures
and other procedure which can see N, but in the constant case (which
is perhaps in the presence of object the mor important one), 'constant
N' can be just copied into a implementation object of the type

   tagged record
     N : Integer;
   end record;



> You (Markus) seem to be an advocate of (possibly-upward) closures.

Certainly. As I said in another post of the recent article storm, I
_think_ (think, mind you, no hard data) that if too much thinks
(narrowing of type w/o RTTI during method invocation, scope of access
types and passing procedural parameters can only be "done downwards",
some desirable structures become impossible.

> And also an advocate of function programming.  

'functional'. :-).

> So how would you like a rule that says the former example is OK, but
> the latter is illegal?

I'd weep silently :-).

> (That is, upward closures are allowed only when you're doing functional
> (no side-effects) programming).


> Note that the latter is not functional -- a call to the function that
> Make_A_Stepper returns modifies N, which is the key difference!

Yes. That is so. But Ada is not functional any way and impure closures
have their value. Nonetheless: Since the encapsulation of mutable
state can be done in tagged types forbidding the latter would probably
not hurt as much as in languages w/o OO. Still, that requires further
analysis of the most frequent use cases. 

Regards -- Markus

Re: in defense of GC

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
>> Markus E Leypold
>> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>>
>>> I do need that
>>>
>>>   function Make_a_Stepper (K:Integer) return ... is
>>>
>>>       N : Integer := Complicated_Function(K);
>>>
>>>       function Stepper(F:Foo) return Foo is
>>>     
>>>         begin
>>>           
>>>           return Foo + N;
>>>
>>>         end;
>>>
>>>     begin
>>>       return Stepper;
>>>     end;
>>>
>>> would work. And no nitpicking, please, if I made syntax error here: The
>>> intention should be clear.
>>
>> I don't think this is nitpicking:
>>
>> I'm not sure what you mean by the above example.  Is N intended to be
>> constant or variable (in Ada terms -- that's immutable/immutable in FP
>> terms)?
>
> Ah, you see, that is the point with closures. If we were talking about
> closures, N would be different for every invocation of Make_Stepper
> but every Stepper returned would refer to a constant N during its
> livetime.

The VALUE of N is different for every....

>... THis is why they are called closure (they enclose their
> environment at the instance of their instantiation which in this case
> would be (in a sense) between the invocation of Make_Stepper and
> before the body of Make_Stepper is executed.

Agreed.

>> Do you mean this:
>>
>>   function Make_a_Stepper (K:Integer) return ... is
>>       N : constant Integer := Complicated_Function(K); -- I added "constant" here! ****************
>>       function Stepper(F:Foo) return Foo is
>>         begin
>>           return Foo + N;
>>         end;
>>     begin
>>       return Stepper;
>>     end;
>>
>> Or this:
>>
>>   function Make_a_Stepper (K:Integer) return ... is
>>       N : Integer := Complicated_Function(K);
>>       function Stepper(F:Foo) return Foo is
>>         begin
>>           N := N + 1; -- I added a modification of N here! ****************
>>           return Foo + N;
>>         end;
>>     begin
>>       return Stepper;
>>     end;
>>
>> ?
>>
>> These two cases of so-called "upward closure" seem very different to me.
>
> Ah, yes, I see how that comes about, since we are not talking names
> and their bindings to values here, but variables in Ada. Actually I'd
> say both. The last case is no pure functional programming (just for
> the record) and in OCaml would b expressed like this:
>
>   let make_stepper k = 
>       let n = ref (complicated k) 
>       in
>         (fun f -> n := !n + 1; f + !n)
>
> and in the first case (just to show the difference)
>
>   let make_stepper k = 
>       let n = (complicated k) 
>       in
>         (fun f -> f + n)
>
> So in (impure) FP both cases are possible and if we go back to Ada
> syntax from that: Why not use the constant keyword to distinguish the
> cases?

Because in Ada I want local variables (local in visibility and local and
lifetime).  I think the Ada equivalent of OCaml's non-functional
"let n = ref (complicated k)" would be:

    type Ref_Integer is access Integer;
    N: constant Ref_Integer := new Integer'(Complicated_Function(K));

That makes it clear that the integer variable we're talking about is an
object allocated on the heap and therefore has who-knows-what lifetime.
I have no problem with forming a closure that can see N (a constant)
and passing that closure outward.

My point is: I want to understand the lifetime of a variable (Ada term)
by looking at its declaration.  I don't care about the lifetimes of
constants/values -- they can be copied willy-nilly anyway.

>> (Both are of course illegal in Ada, but we're discussing what "ought" to be.)
>
> Ehm. And I'm thankful for you rather insightful input :-).

Thanks for saying so.  And I'm thankful to you for helping me understand
these conceptual issues.  :-)

>> In the former case, we're returning a function that looks at some local
>> value (the value of N).  In this case, you comment about returning
>> integer values is quite correct:
>>
>>>> Closure don't "make things global". They do it as much as returning an
>>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>>> people, that makes a value global and we all know, global is bad --
>>>> how nonsensical is that?).
>>
>> Right.  What's the big deal?  Returning a function that looks at integer
>> values is no worse than returning integer values.  Integer values live
>> forever, and the value of N is certainly not tied to the lifetime of N.
>
>
>> But in the latter, case, the return of Stepper is causing the lifetime
>> of an integer VARIABLE (i.e. mutable) to be longer than one might
>> suspect for a local variable of Make_A_Stepper.  That seems like a
>> problem to me.
>
> It's still only encapsulated _state_, the visibility of indentifiers
> (scope) is not extended by that.

Right.  We're talking about lifetimes.  Some folks in this thread may
have said "scope" when they meant "lifetime".

>...Outsiders can't look into the
> closure. And we already have encapsulate state like this, in tagged
> objects. Closure differ from objects only in 2 points: (1) they have
> only one method (apply) and (2) they can take (implicitely) values
> from their whole environment at the place of instantiation.
>
> Indeed the more I think about it, a bit compiler support (which knows
> which parts of the environment are actually used in the closures
> body), a new keyword (closure to distinguis them from ordinary
> procedures) and all the mechanisms already present in tagged types
> should be quite enough implement closure in Ada. (Well, OK, there are
> problems with sharing N in the non-constant case with other closures
> and other procedure which can see N, but in the constant case (which
> is perhaps in the presence of object the mor important one), 'constant
> N' can be just copied into a implementation object of the type
>
>    tagged record
>      N : Integer;
>    end record;
>
>
>
>> You (Markus) seem to be an advocate of (possibly-upward) closures.
>
> Certainly. As I said in another post of the recent article storm, I
> _think_ (think, mind you, no hard data) that if too much thinks
> (narrowing of type w/o RTTI during method invocation, scope of access
> types and passing procedural parameters can only be "done downwards",
> some desirable structures become impossible.
>
>> And also an advocate of function programming.  
>
> 'functional'. :-).

Sorry, that was a typo.  I meant "functional".

>> So how would you like a rule that says the former example is OK, but
>> the latter is illegal?
>
> I'd weep silently :-).
>
>> (That is, upward closures are allowed only when you're doing functional
>> (no side-effects) programming).
>
>
>> Note that the latter is not functional -- a call to the function that
>> Make_A_Stepper returns modifies N, which is the key difference!
>
> Yes. That is so. But Ada is not functional any way and impure closures
> have their value.

This is the key point I'm interested in: why do impure outward closures
have value?  We can emulate that via tagged types, as you say:

>...Nonetheless: Since the encapsulation of mutable
> state can be done in tagged types forbidding the latter would probably
> not hurt as much as in languages w/o OO. Still, that requires further
> analysis of the most frequent use cases. 

And it seems to me there's some value in knowing that a local variable
of a procedure has local lifetime.  And if it doesn't, the extra
syntactic baggage of tagged types or access types or whatever seems like
a benefit (i.e. warning: this thing lives longer).

- Bob

Re: in defense of GC

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>> So in (impure) FP both cases are possible and if we go back to Ada
>> syntax from that: Why not use the constant keyword to distinguish the
>> cases?
>
> Because in Ada I want local variables (local in visibility and local and
> lifetime).  I think the Ada equivalent of OCaml's non-functional
> "let n = ref (complicated k)" would be:
>
>     type Ref_Integer is access Integer;
>     N: constant Ref_Integer := new Integer'(Complicated_Function(K));
>
> That makes it clear that the integer variable we're talking about is an
> object allocated on the heap and therefore has who-knows-what lifetime.
> I have no problem with forming a closure that can see N (a constant)
> and passing that closure outward.
>
> My point is: I want to understand the lifetime of a variable (Ada term)
> by looking at its declaration.  I don't care about the lifetimes of
> constants/values -- they can be copied willy-nilly anyway.

I agree with the last part of the last sentence, but your handling of
mutable data strikes me as complicated: Variables are already namens
for mutable storage (that is different in ML and why we need an
explicti ref there). So N: Integer vs. N: constant Integer should be
quite enough.


>>> In the former case, we're returning a function that looks at some local
>>> value (the value of N).  In this case, you comment about returning
>>> integer values is quite correct:
>>>
>>>>> Closure don't "make things global". They do it as much as returning an
>>>>> Integer, makes, GOD FORBID!, a value global (don't return Integers
>>>>> people, that makes a value global and we all know, global is bad --
>>>>> how nonsensical is that?).
>>>
>>> Right.  What's the big deal?  Returning a function that looks at integer
>>> values is no worse than returning integer values.  Integer values live
>>> forever, and the value of N is certainly not tied to the lifetime of N.
>>
>>
>>> But in the latter, case, the return of Stepper is causing the lifetime
>>> of an integer VARIABLE (i.e. mutable) to be longer than one might
>>> suspect for a local variable of Make_A_Stepper.  That seems like a
>>> problem to me.
>>
>> It's still only encapsulated _state_, the visibility of indentifiers
>> (scope) is not extended by that.
>
> Right.  We're talking about lifetimes.  Some folks in this thread may
> have said "scope" when they meant "lifetime".

Yes, that was the underlying reason dfor sime mixups. But as I said:
We've already indefinitely long living storage by the fact that we
have 'new' and can return objects (which contain state).

>
>>...Outsiders can't look into the
>> closure. And we already have encapsulate state like this, in tagged
>> objects. Closure differ from objects only in 2 points: (1) they have
>> only one method (apply) and (2) they can take (implicitely) values
>> from their whole environment at the place of instantiation.
>>
>> Indeed the more I think about it, a bit compiler support (which knows
>> which parts of the environment are actually used in the closures
>> body), a new keyword (closure to distinguis them from ordinary
>> procedures) and all the mechanisms already present in tagged types
>> should be quite enough implement closure in Ada. (Well, OK, there are
>> problems with sharing N in the non-constant case with other closures
>> and other procedure which can see N, but in the constant case (which
>> is perhaps in the presence of object the mor important one), 'constant
>> N' can be just copied into a implementation object of the type
>>
>>    tagged record
>>      N : Integer;
>>    end record;


BTW. I take that back. It's not as easy as that to tack really useful
closures on top of a stack oriented language implementation.

>>
>>> You (Markus) seem to be an advocate of (possibly-upward) closures.
>>
>> Certainly. As I said in another post of the recent article storm, I
>> _think_ (think, mind you, no hard data) that if too much thinks
>> (narrowing of type w/o RTTI during method invocation, scope of access
>> types and passing procedural parameters can only be "done downwards",
>> some desirable structures become impossible.
>>
>>> And also an advocate of function programming.  
>>
>> 'functional'. :-).
>
> Sorry, that was a typo.  I meant "functional".

I know. Therefore the ":-)".

>
>>> So how would you like a rule that says the former example is OK, but
>>> the latter is illegal?
>>
>> I'd weep silently :-).
>>
>>> (That is, upward closures are allowed only when you're doing functional
>>> (no side-effects) programming).
>>
>>
>>> Note that the latter is not functional -- a call to the function that
>>> Make_A_Stepper returns modifies N, which is the key difference!
>>
>> Yes. That is so. But Ada is not functional any way and impure closures
>> have their value.
>
> This is the key point I'm interested in: why do impure outward closures
> have value?  

> We can emulate that via tagged types, as you say:

Because ideally they can capture their whole environment e.g. when
returning functions that return functions that return functions.

Of course for any specific case that can be cumbersomely emulated by
using tagged objects: But that requires very specialized solutions in
every single case. It feels -- wrong?

Why encaspualting mutable state? Well -- i.e. to produce time stampers
and similar functional objects.

I admit, perhaps, just copying to the heap all the "external values" a
"closure" refers to at instantiation time will have the desired effect
(mostly). This still leaves the possibility to encapsulate mutable
state by having a heap reference (as you did above), Perhaps that will
work. I do not remember any important cases where state sharing
between different closures really was an important
consideration. "closure" in the following code fragment will thus just
be syntactic sugar for deriving a class and instantiating some object
from it:


  type Stepper_T is closure ( I : Integer ) return Integer;    -- in reality a cloaked tagged type


  function Make_Stepper ( K : Integer ) return Stepper_T

    N : Integer := Step_Width(K);

    closure Stepper ( I : integer ) return Integer is begin     -- derive a new tagged type and body becomes method, 
                                                              instantiate once
      return I + N;
    end;

  is begin
     return Stepper;
  end;


I try to sketch what the underlying implementation would be:


  type Stepper_T is abstract tagged null record;

  procedure Apply( S : Stepper_T ) return Integer is abstract;

  function Make_Stepper ( K : Integer ) return Stepper_T

    N : Integer := Step_Width(K);

    type Concrete_Stepper is new Stepper_T with record

         N : Integer;   -- This identifier is produced by the compiler from N in Stepper body 
                           because it refers to a definition outside the body of Stepper

    end record;

    procedure Apply( S : Concrete_Stepper ) return Integer is 
      return I + S.N; -- N as reference outside stepper body is rewritten to S.N.
    end;

    Stepper : Concrete_Stepper'( N => N );
    
  is begin
     return Stepper;
  end;
   
 
Having a shortcut syntax as follows would be also nice:

  type Stepper_T is abstract tagged null record;

  function Make_Stepper ( K : Integer ) return Stepper_T
    N : Integer := Step_Width(K);
  is begin 
    return closure ( I : integer ) return Integer is return N+I;
  end;

(This looks a bit strange, but what I want to say is, that the closure
name is actually not important and perhaps the begin/end block is a
bit nois in some cases. But YMMV.)

Even shorter:

  type Stepper_T is abstract tagged null record;

  function Make_Stepper ( K : Integer ) return Stepper_T

    N : Integer := Step_Width(K);

  is return closure ( I : integer ) return Integer is return N+I;



>>...Nonetheless: Since the encapsulation of mutable
>> state can be done in tagged types forbidding the latter would probably
>> not hurt as much as in languages w/o OO. Still, that requires further
>> analysis of the most frequent use cases. 
>
> And it seems to me there's some value in knowing that a local variable
> of a procedure has local lifetime.  

It has a local lifetime: Next call into the procedure could create a
new one, which of course could be captured by another closure. It would not be
like "static" variables in C!

> And if it doesn't, the extra syntactic baggage of tagged types or
> access types or whatever seems like a benefit (i.e. warning: this
> thing lives longer).

I understand your approach. It would go well with a "copy all relevant
data to the closure" approach (as sketched above), so basically, yes
(I hope I really understood what I'm agreeing to).

Regards -- Markus

Re: in defense of GC

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> But in the latter, case, the return of Stepper is causing the lifetime
> of an integer VARIABLE (i.e. mutable) to be longer than one might
> suspect for a local variable of Make_A_Stepper.  That seems like a
> problem to me.

Yes, the lifetime is longer (as specified by the programmer) but the global
visibility is not affected -- N still cannot be directly manipulated in a
global sense.

> You (Markus) seem to be an advocate of (possibly-upward) closures.
> And also an advocate of function programming.  So how would you like a
> rule that says the former example is OK, but the latter is illegal?
> (That is, upward closures are allowed only when you're doing functional
> (no side-effects) programming).

I like general closures akin to the style of Lisp. It is interesting that
JavaScript, for all its faults, at least has fully general closures.

C# delegates are now essentially the same thing, and have full GC support.

Java's are busted due to implementation laziness.

So why not have general closures in Ada? They are a very powerful concept, and
one still gets the control if needed by simply not using them if appropriate.

But to do closures properly, one really does need GC.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> But to do closures properly, one really does need GC.

My words. Or to be truthful: They could have been. :-)

BTW, you've been discussing (with ... I don't remember) the possibilty
of switching GC off. My idea (even with ML-like languages) was always
to define a subset of the language which the compiler can implement
with a stack only. One could use this subset to embbed real time
capable procedures (as prioritized tasks or as interrupt handlers) in
a system with as a whole (user interface) does only provide "soft
realtime" (i.e. +/- garbage collection times). This should cover even
most cases with hard real time requirements.

Suitable subsets again could be compiled to pure C code which works
without GC (compile time garbage collections) or without heap. It's
the compilers job (maybe with help of the annotations) to
discover/prove that the code can be translated like that.

Seems to me a more useful approach than explicit pointer management.

One advantage of that would be that one could start out with code that
requires GC, but is "obviously" correct and then transform in
correctness preserving steps it into code that doesn't require
GC. Both implementations could be tested against each other, at least
as far as their computational function goes, not the real time
capabilities that are perhaps only possessed by the 2nd variant.

Regards -- Markus

Re: in defense of GC

[Ray Blaak]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> BTW, you've been discussing (with ... I don't remember) the possibilty
> of switching GC off. My idea (even with ML-like languages) was always
> to define a subset of the language which the compiler can implement
> with a stack only. 

Does that automatically preclude any access types, unbounded strings, etc.,
then? That would be quite a limited language.

That would simplify GC right off the bat. Maybe it wouldn't be needed at all,
right there.

> One advantage of that would be that one could start out with code that
> requires GC, but is "obviously" correct and then transform in
> correctness preserving steps it into code that doesn't require
> GC. Both implementations could be tested against each other, at least
> as far as their computational function goes, not the real time
> capabilities that are perhaps only possessed by the 2nd variant.

My reaction is to not trust testing only to gain the measure of confidence
needed. You must be able to prove the the equivalence well enough.

Also, if the non-GC version was realtime, why wouldn't the first one be? Where
is the difference in behaviour? If you have no heap, then wouldn't execution
should be equivalently predictable in either case?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>> BTW, you've been discussing (with ... I don't remember) the possibilty
>> of switching GC off. My idea (even with ML-like languages) was always
>> to define a subset of the language which the compiler can implement
>> with a stack only. 
>
> Does that automatically preclude any access types, unbounded strings, etc.,
> then? That would be quite a limited language.

Not necessarily. It precludes any _handling_ of stuff in a way that
doesn't allow the compiler to de-allocate memory when leaving the
scope. Basically the compiler would look at what happens and instead
of using heap allocated (GC'ed) memory it would use 'Controlled'
memory (in Ada parlance).


And BTW: AFAIK that has already been done once for some obscure subset of ML.

>
> That would simplify GC right off the bat. Maybe it wouldn't be needed at all,
> right there.

:-).


>> One advantage of that would be that one could start out with code that
>> requires GC, but is "obviously" correct and then transform in
>> correctness preserving steps it into code that doesn't require
>> GC. Both implementations could be tested against each other, at least
>> as far as their computational function goes, not the real time
>> capabilities that are perhaps only possessed by the 2nd variant.
>
> My reaction is to not trust testing only to gain the measure of confidence
> needed. You must be able to prove the the equivalence well enough.

Right. Therefore (in the case where more trust is needed) the proof of
euivalence by equivalence transformations (for a suitable definition
of equivalence).

> Also, if the non-GC version was realtime, why wouldn't the first one be? 

Because the interfaces change. Only the data processing provided is
equivalent, but the way data is passed and retrieved, changes.

> Where is the difference in behaviour? If you have no heap, then
> wouldn't execution should be equivalently predictable in either
> case?

I'll try to make up a simple, but not necessarily good example. This
is not about runtime GC but about going from GC to manual memory
management, but I hope it will serve. The programs concatenate 2
strings:

With GC (naive implementation)

   let concat1 (s1:string) (s1:string) = s1 ^ s2;;

With manual MM.

  let concat2  (s1:string) (s2:string) (result: string ref) = 

      result := Some (s1 ^ s2)

I realize this might not be the beste example, since I just made it
up. But the idea is, that (string ref) is (by the compiler) translated
into a char* and that result := ... actually becomes a malloc() plus a
copying of memory. some_var := None would compile to explicit
deallocation (pointer is overwritten with null).

Both functions are equivalent (they concatenate strings), but the
second would not be required to work in a GC'ed environment.

Similarily, I think, it might be possible to avoid malloc() if
everything is done in static or local buffers.

Regards -- Markus

Re: in defense of GC

[Ray Blaak]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> I realize this might not be the beste example, since I just made it
> up. But the idea is, that (string ref) is (by the compiler) translated
> into a char* and that result := ... actually becomes a malloc() plus a
> copying of memory. some_var := None would compile to explicit
> deallocation (pointer is overwritten with null).

I am not convinced you can avoid GC. Can the compiler insert the appropriate
deallocation calls? How would it know the string is not in use somewhere else?

So I see only that some sort of reference counting scheme can be implemented
in the restricted case, but that is just GC all over again, and a poor one at
that.

> Similarily, I think, it might be possible to avoid malloc() if
> everything is done in static or local buffers.

I don't think so. Many algorithms have unbounded and unpredictable memory
usage patterns. These could only be handled by viewing the (large?) static
buffers as preallocated memory, and then one has the equivalent of malloc
and/or GC all over again.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>> I realize this might not be the beste example, since I just made it
>> up. But the idea is, that (string ref) is (by the compiler) translated
>> into a char* and that result := ... actually becomes a malloc() plus a
>> copying of memory. some_var := None would compile to explicit
>> deallocation (pointer is overwritten with null).
>
> I am not convinced you can avoid GC. Can the compiler insert the appropriate
> deallocation calls? How would it know the string is not in use somewhere else?

As I said -- not the best example perhaps. GC cannot be avoided for
the whole language but for a subset. Not a syntactic subset, a
semantic one, if you like (it's in that respect similar to
eleminiating if branches and loops). 

I admit my example is not good or at least not complete. The whole
disciplin is, AFAIK, called "compile time garbage collection" and
usuallay seems to require some support from the type system or an
annotation language which embeds proofs or hints to proofs that the
values are used in a certain way.

I'm not pushing that as something to come tomorrow. But I believe it
might be the long term future just to specialize single program parts
of a program written in the full language (which has all, including
GC) instead of embedding low level languages or writing -- god forbid
-- the whole program in a low level language only because a tiny part
of it must be optimized or provide some guarantees.

> So I see only that some sort of reference counting scheme can be implemented
> in the restricted case, but that is just GC all over again, and a poor one at
> that.

In my example, yes. If I don't say about the string reference that it
is 'unique'. I hear, the Mercury type system provides such constraints
which help the compiler to do compile time GC.

>> Similarily, I think, it might be possible to avoid malloc() if
>> everything is done in static or local buffers.
>
> I don't think so. Many algorithms have unbounded and unpredictable memory
> usage patterns. 

No, no, no! Not in the general case. You'll have to write the
algorithm accordingly and then the compiler (nudged by a compile time
directive) will try hard to implement your source w/o using GC.

The point being: If (only if) you can do it in Ada / C w/o GC you can
always write a ML+1 (let's call it like this) program that the
compiler can translate into an object file that doesn't need the GC.

Have I know expressed my vision better? This is all S-F AFAIK, but
there was at least 1 experimental ML translation system that had
something like this and the whole disciplin is called compile time
GC. Don't hold me responsible for my vagueness -- this is not my
current work. Except if you have access to a research grant, then
we'll be forthcoming with more detailed plans :-)). (Joking, but only
half).

> These could only be handled by viewing the (large?) static
> buffers as preallocated memory, and then one has the equivalent of malloc
> and/or GC all over again.

Or simply reserving them during OS load time as is indeed done in a
lot of embedded software. My vision after all was to make FP possible
in embedded systems or better: To provide a seamless environment of FP
in which a embeddable sublanguage exists. Unified testing frameworks
and tools and all this would be the ROI.

Regards -- Markus

Re: in defense of GC

[Ray Blaak]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> > Similarily, I think, it might be possible to avoid malloc() if
> > everything is done in static or local buffers.
> 
> I don't think so. Many algorithms have unbounded and unpredictable memory
> usage patterns. These could only be handled by viewing the (large?) static
> buffers as preallocated memory, and then one has the equivalent of malloc
> and/or GC all over again.

To clarify: by viewing the static buffers as a preallocated memory *pool*.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> But in the latter, case, the return of Stepper is causing the lifetime
>> of an integer VARIABLE (i.e. mutable) to be longer than one might
>> suspect for a local variable of Make_A_Stepper.  That seems like a
>> problem to me.
>
> Yes, the lifetime is longer (as specified by the programmer) but the global
> visibility is not affected -- N still cannot be directly manipulated in a
> global sense.

My complaint is that it's not specified by the programmer on the
declaration of that variable (mutable object).  Some nested procedure
happens to mention N and that procedure gets returned to a more-global
place, dragging N along with it.  (Yes of course I understand that
"N still cannot be directly manipulated in a global sense.")

I've got no problem with passing functions (closures) outward in a
functional (no mutable variables) context.

- Bob

Re: in defense of GC

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> My complaint is that it's not specified by the programmer on the
> declaration of that variable (mutable object).  Some nested procedure
> happens to mention N and that procedure gets returned to a more-global
> place, dragging N along with it.

I am wondering if your complaint is caused by strangeness of it all, rather
than its actual detrimental effects.

Consider a local pointer variable. You cannot tell from the declaration that
the lifetime of the pointer will necessarily outlive its scope. Possibly it
can, but some return call might pass it out, some might not. Some nested
procedure might do so, some might not. 

You instead have to look to see the actual step of extension past its scope to
know.

I suppose that the pointer's declaration explicitly indicates heap allocation
makes the essential difference to you. As a programmer you simply feel more in
control of what is precisely happening.

In languages with full closures, *any* local variable can outlive it's
scope. That you cannot tell this from the variable itself does not bother me
at all. Why should it?

Local variables can only be captured by the lexical scoping of a nested
procedure/closure. "Some nested procedure" should be very much obviously
present and visible to the programmer. How big do methods on typical Ada
projects get anyway? I tend to assume that a method is always under the
control of a single programmer at a time.

I would think that any fears you have about a local variable having an
unexpected lifetime should also occur with the heap allocated values as
well. After all they must be more carefully managed. It is just that with heap
values you are naturally "on guard".

Well, the presence of closure declarations provides a similar indication.

Of course, without GC, things are quite a bit more dangerous, since it becomes
quite a bit more difficult to reason when something can be safely freed. That
might also explain the instinct to mistrust general closures.

My question in the context of this example is how can a mutating local integer
variable that outlives its scope be possibly dangerous? Only the closure is
operating on it and nothing else. There are no heap issues to worry
about. What is the possible harm?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>>> But in the latter, case, the return of Stepper is causing the lifetime
>>> of an integer VARIABLE (i.e. mutable) to be longer than one might
>>> suspect for a local variable of Make_A_Stepper.  That seems like a
>>> problem to me.
>>
>> Yes, the lifetime is longer (as specified by the programmer) but the global
>> visibility is not affected -- N still cannot be directly manipulated in a
>> global sense.
>
> My complaint is that it's not specified by the programmer on the
> declaration of that variable (mutable object).  Some nested procedure
> happens to mention N and that procedure gets returned to a more-global
> place, dragging N along with it.  (Yes of course I understand that
> "N still cannot be directly manipulated in a global sense.")

But exactly the same happens with record fields. They are also mutable
(when a record is returned). Why is it a problem here and not there?


Regards -- Markus

>
> I've got no problem with passing functions (closures) outward in a
> functional (no mutable variables) context.
>
> - Bob

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Fri, 02 Feb 2007 01:37:26 GMT, Ray Blaak wrote:
> > Modern GC systems simply do a better job at it them people do.
> 
> Maybe, but that does not explain why such GC should be hard-wired. Note you
> are talking about systems (plural), but wired could be only one. Why do you
> want to forbid me to use my GC?

Well, I am not forbidding anyone. Certainly there are times where it is
justified to disable GC, as I already pointed out. So, presumably a fully
general language environment would be able to run with it disabled if
necessary.

If nothing else, you are free choose the language you like. Currently that
means Ada. For me, that would be C#.

The original context of this thread is about the popularity of Ada. My
position is that Ada would be a better fit for general use if GC was the
default, not the exception.

> 
> [...]
> > The point is that the programmer is freed from the error prone tedium of
> > explicitly managing memory.
> 
> This is a misconception. There are two fundamentally different issues:
> 
> 1. Object scopes
> 2. Memory management
> 
> The second issue is less and less relevant as Randy pointed out. The first
> issue is always relevant. It is a good design to consider where an object
> exists. GC [and upward closures] is an attitude of making everything
> potentially global. In fact it is worse than just global. It is "I don't
> know where I need that damn thing."

GC does not affect visibility or scoping. That is an orthogonal issue, and
still quite properly under the control of the programmer. Upward closures do
not make an object more global unless the closure explicitly exposes the
object for external use.

All GC is really about is reclaiming objects that are no longer in use.

As to memory management being less relevant, I am clearly disagreeing with
Randy. As long as memory is finite, it matters. We have huge memories on our
computers today as compared to, say, the 80's. Memory management matters more
than ever.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Adam Beneschan]

On Feb 2, 10:15 am, Ray Blaak <rAYbl...@STRIPCAPStelus.net> wrote:

> As to memory management being less relevant, I am clearly disagreeing with
> Randy. As long as memory is finite, it matters. We have huge memories on our
> computers today as compared to, say, the 80's. Memory management matters more
> than ever.

Yep, sounds like Parkinson's Law is still in effect . . . .

                               -- Adam

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 18:15:05 GMT, Ray Blaak wrote:

> GC does not affect visibility or scoping.

But scoping does affect GC. If scope of each object is known, then there is
nothing to collect.

Further argumentation to what I have already made is that "object in use"
is a semantic concept which cannot be inferred (you wanted automatic
collection). "in use" /= "has references."

It is the programmer who expresses "in use" in language terms. It could be
scoped names or a bunch of controlled pointers distributed across the
program. There must be very strong reasons for choosing the latter.

(I don't think that gaining popularity for a programming language is a good
reason for spaghetti programming. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Fri, 02 Feb 2007 18:15:05 GMT, Ray Blaak wrote:
> > GC does not affect visibility or scoping.
> 
> But scoping does affect GC. If scope of each object is known, then there is
> nothing to collect.

If one is using explicit pointers at all, even within a single scope there is
still manual work to free them, unless you want to force the use of some sort
of smart pointer controlled types (which I find tedious compared to using
native pointers).

GC alleviates this work even within a single scope.

> It is the programmer who expresses "in use" in language terms. It could be
> scoped names or a bunch of controlled pointers distributed across the
> program. There must be very strong reasons for choosing the latter.

I am happy to relax the criteria to be just "practical". With GC, one no
longer needs to have such a strong concern precisely because the consequences
are not dire.

> (I don't think that gaining popularity for a programming language is a good
> reason for spaghetti programming. (:-))

I agree :-). I just strongly disagree that the use of shared objects in
conjunction with GC is spaghetti programming.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Dmitry A. Kazakov]

On Fri, 02 Feb 2007 22:40:51 GMT, Ray Blaak wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> On Fri, 02 Feb 2007 18:15:05 GMT, Ray Blaak wrote:
>>> GC does not affect visibility or scoping.
>> 
>> But scoping does affect GC. If scope of each object is known, then there is
>> nothing to collect.
> 
> If one is using explicit pointers at all, even within a single scope there is
> still manual work to free them, unless you want to force the use of some sort
> of smart pointer controlled types (which I find tedious compared to using
> native pointers).

Why? The language should make no difference between them! BTW, Ada 83 was
designed much in this spirit. It had pragma Controlled.

> GC alleviates this work even within a single scope.

But it is much simpler to hide original object and use controlled pointers
as proxies. Again Ada 83 design had that in mind by making access types
almost transparent. One should just have made them fully transparent.

>> It is the programmer who expresses "in use" in language terms. It could be
>> scoped names or a bunch of controlled pointers distributed across the
>> program. There must be very strong reasons for choosing the latter.
> 
> I am happy to relax the criteria to be just "practical". With GC, one no
> longer needs to have such a strong concern precisely because the consequences
> are not dire.

Premature or belated finalization can be extremely dire. One of the worst
problems I had in C++ was fighting elaboration/finalization order of static
library objects. I suppose you propose to express such things using hard
references scattered across all objects? BTW, if GC were answer why would
anybody require weak references?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: in defense of GC

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> references scattered across all objects? BTW, if GC were answer why would
> anybody require weak references?

For caching. Collect when necessary, reuse when possible.

Regards -- Markus

Re: in defense of GC

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

<a rather lucid defense of GC>

Standing ovations here! I could not agree more.

Regards -- Markus

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Gautier]

Ray Blaak:

> It is only sloppy programming in the context of manual clean up. With a valid
> GC you do not have to clean up at all. One simply stops using objects when
> they no longer need them, just "dropping them on the floor", leaving it up to
> the GC to eventually collect it.

Sorry for my ignorance in this field, but from a real household point of view, 
it seems to me that there is a big difference between
  (1) "stop using an object"
and
  (2) "drop an object on the floor".

In case of (1), I would hate that my object is taken from the table and thrown 
away by my garbage collecting robot GeeCee. Hey, does he know I really won't 
use my object anymore ?! In the case (2), it's OK that GeeCee takes it away, 
but then there is an action (Drop_on_the_floor) and I can do it in Ada 
(procedure Drop_on_the_floor_and_even_directly_throw_away is new 
Ada.Unchecked_Deallocation).

Thanks for an explanation...
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Ray Blaak]

Gautier <gautier@fakeaddress.nil> writes:
> Sorry for my ignorance in this field, but from a real household point of view,
> it seems to me that there is a big difference between
>   (1) "stop using an object"
> and
>   (2) "drop an object on the floor".
> 
> In case of (1), I would hate that my object is taken from the table and thrown
> away by my garbage collecting robot GeeCee. Hey, does he know I really won't
> use my object anymore ?! In the case (2), it's OK that GeeCee takes it away,
> but then there is an action (Drop_on_the_floor) and I can do it in Ada
> (procedure Drop_on_the_floor_and_even_directly_throw_away is new
> Ada.Unchecked_Deallocation).

I was not sure if this was serious or not, so if it was...

Regarding (1), if you are not sure you will use an object anymore, then the GC
will not collect it, *by definition*, since it must be still reachable in some
way in order for it to be even possible to use. GC only collects unreachable
memory.

Regarding (2), doing a matching "drop" for every "new" is the whole trouble,
of course. What if you miss one? Well, with GC, you don't (need to) do an
explicit "drop" at all. And that's the freedom.

Now nothing is completely perfect and free. You can still have memory leaks
with GC, of course, but they are of a different kind. Instead of a lost
pointer that still refers to allocated memory, one has live objects still
being referred to in some way, i.e., "not lost" pointers that one no longer
needs to refer to.

So, the most one needs to do is to clear a pointer/reference occasionally.
Note though, that this is far far simpler than, for example, carefully
deallocating each node of some long lived complex data structure, cycles and
all. Instead one simply clears the reference to the root of entire complex
structure, and it all just goes away.

In the case of stacked based references (which are the most common kind),
there is nothing do to. New objects are made, maybe returned out to the
caller, maybe not, without regard to destruction, copy construction, etc. It
just is no longer necessary.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Hyman Rosen]

Ray Blaak wrote:
> GC only collects unreachable memory.

The proper definition of (ideal) GC is that it collects
memory for reuse from objects that the program will never
access again. Reachability and such are implementation
details.

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Ray Blaak]

Hyman Rosen <hyrosen@mail.com> writes:
> Ray Blaak wrote:
> > GC only collects unreachable memory.
> 
> The proper definition of (ideal) GC is that it collects
> memory for reuse from objects that the program will never
> access again. Reachability and such are implementation
> details.

Fair enough. In practice, is any other measure besides reachability ever used?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> GC is one of the modern advances of computing science, period, akin to the use
                   ^^^^^^
> of high level languages vs assembly, lexical scoping vs dynamic scoping,
> strong typing vs no typing, etc.

Modern?  GC is many years old.

> It should be used by default and turned off only in unusual situations.

Agreed that it should be "on" by default.

> Of course, in this group, those circumstances are probably the usual
> case, what with the use of Ada for realtime and embedded programming.
>
> Still, given recent realtime GC algorithms, I would consider the use of GC for
> any system I was responsible for, and would give it up reluctantly, only if
> timing and space constraints were too tight for a given application.

I've read many papers about so-called real-time GC, but I remain
skeptical.

- Bob

Re: in defense of GC (was Re: How come Ada isn't more popular?)

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > GC is one of the modern advances of computing science, period, akin to the use
>                    ^^^^^^
> > of high level languages vs assembly, lexical scoping vs dynamic scoping,
> > strong typing vs no typing, etc.
> 
> Modern?  GC is many years old.

Well, sure. But you do realize that mainstream computing is slowly and
inexorably reimplementing good old fashioned Lisp, right? :-)

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> > GC is one of the modern advances of computing science, period, akin to the use
>>                    ^^^^^^
>> > of high level languages vs assembly, lexical scoping vs dynamic scoping,
>> > strong typing vs no typing, etc.
>> 
>> Modern?  GC is many years old.
>
> Well, sure. But you do realize that mainstream computing is slowly and
> inexorably reimplementing good old fashioned Lisp, right? :-)

Yeah.  ;-)

Did you mean "reimplementing... Lisp, right?"
or "reimplementing... Lisp right."?

;-)

- Bob

Re: in defense of GC

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Did you mean "reimplementing... Lisp, right?"
> or "reimplementing... Lisp right."?

Well, both I suppose, although I imagine I would do it differently from you.

I used to be a shiny eyed Ada true believer. These days I find myself seduced
by the dynamic side of things.

The main thing I would do with Lisp is make it have optional type declarations
(Common Lisp sort of has them; Dylan has them, but what's a Dylan? And if only
it could make up it's mind about looking like a lisp vs a pascal).

I really do like C# these days, actually. You can see the Ada influence on
it. It's a pity about the politics of Microsoft, though.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> Did you mean "reimplementing... Lisp, right?"
>> or "reimplementing... Lisp right."?
>
> Well, both I suppose, although I imagine I would do it differently from you.
>
> I used to be a shiny eyed Ada true believer. These days I find myself seduced
> by the dynamic side of things.
>
> The main thing I would do with Lisp is make it have optional type declarations

That's why you MUST use Ocaml :-). No, joke, I do not know what is the
important thing to you in Lisp. OCaml has no macros etc. But the
typing makes things vastly more manageable.

> (Common Lisp sort of has them; Dylan has them, but what's a Dylan? And if only
> it could make up it's mind about looking like a lisp vs a pascal).

:-)

>
> I really do like C# these days, actually. You can see the Ada influence on
> it. It's a pity about the politics of Microsoft, though.


Regards -- Markus

Re: in defense of GC

[Ray Blaak]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> That's why you MUST use Ocaml :-). No, joke, I do not know what is the
> important thing to you in Lisp. OCaml has no macros etc. But the
> typing makes things vastly more manageable.

I think what I prefer about Lisp (and Scheme) vs the ML style languages is
that Lisp is a little more laid back. The syntax is cleaner, and the whole FP
obsession thing is optional.

The whole obsession in the syntax with just how functions map from inputs to
outputs just seem a little too serious, but maybe I am confusing things with
ML. I prefer to relax with the currying in declarations and just show simple
function signatures instead. Of course in Lisp, one just passes the lambas
around and lets the runtime worry about the mismatches.

The funny thing is that the whole dynamic thing just doesn't seem to fail as
badly as the static typing purists would have us believe. Now I do want my
strong static typing, espcially for parameter mismatches on function calls,
but I find it interesting that significant software can get done just fine in
Lisp.

I have always had OCaml on my list to dig into more. Maybe I should actually
get around to it.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Georg Bauhaus]

On Wed, 2007-02-07 at 07:44 +0000, Ray Blaak wrote:

> The funny thing is that the whole dynamic thing just doesn't seem to fail as
> badly as the static typing purists would have us believe. Now I do want my
> strong static typing, espcially for parameter mismatches on function calls,
> but I find it interesting that significant software can get done just fine in
> Lisp.
> 
> I have always had OCaml on my list to dig into more. Maybe I should actually
> get around to it.

If you do this, perhaps you can find the time to use a, uh, stop-watch
to measure the time it takes to produce, read, and change the programs?
I.e., to technically manage significant software. The times will be
important input for deciding whether or not static typing does indeed
help in production.
The only thing that relates to economic efficiency, if you want it :-)


 -- Georg 

Re: in defense of GC

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Wed, 2007-02-07 at 07:44 +0000, Ray Blaak wrote:
>
>> The funny thing is that the whole dynamic thing just doesn't seem to fail as
>> badly as the static typing purists would have us believe. Now I do want my
>> strong static typing, espcially for parameter mismatches on function calls,
>> but I find it interesting that significant software can get done just fine in
>> Lisp.
>> 
>> I have always had OCaml on my list to dig into more. Maybe I should actually
>> get around to it.
>

> If you do this, perhaps you can find the time to use a, uh, stop-watch
> to measure the time it takes to produce, read, and change the programs?
> I.e., to technically manage significant software. The times will be
> important input for deciding whether or not static typing does indeed
> help in production.
> The only thing that relates to economic efficiency, if you want it :-)

So the how long a beginner in a specific language takes to do
something is "important input for deciding ..." if compared to what,
exactly?

Regards -- Markus

Re: in defense of GC

[Georg Bauhaus]

On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 

> > If you do this, perhaps you can find the time to use a, uh, stop-watch
> > to measure the time it takes to produce, read, and change the programs?
> > I.e., to technically manage significant software. The times will be
> > important input for deciding whether or not static typing does indeed
> > help in production.
> > The only thing that relates to economic efficiency, if you want it :-)
> 
> So the how long a beginner in a specific language takes to do
> something is "important input for deciding ..." if compared to what,
> exactly?

I don't think Ray is a beginner in functional programming.

Now before I try singing old wisdom from the neighbourhood of
The Mythical Man Month ...
How will a piece of source code, your own or someone else's, and
a language with tools fit these and the market as we might think
it is now?

project size,
project duration,
forced language,
availability of programmers (need to hire?),
job changes,
programmer skills,
multiple projects at the same time,
language switching e.g. between projects every other week,
time needed for education,
documentation needs,
future modification done by others,
future modification to be done by the author,
...


A rich set of opportunities for collecting some input, if only
in order to convince ourselves that some things might have changed
in software production (due to language changes?) while others
haven't changed --for example we might get carried away by a
subjective estimate of the usability of our preferred language.
In accord with the findings of Leon Festinger (1957).


 -- Georg 

Re: in defense of GC

[Markus E Leypold]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>
>> > If you do this, perhaps you can find the time to use a, uh, stop-watch
>> > to measure the time it takes to produce, read, and change the programs?
>> > I.e., to technically manage significant software. The times will be
>> > important input for deciding whether or not static typing does indeed
>> > help in production.
>> > The only thing that relates to economic efficiency, if you want it :-)
>> 
>> So the how long a beginner in a specific language takes to do
>> something is "important input for deciding ..." if compared to what,
>> exactly?
>
> I don't think Ray is a beginner in functional programming.

>> So the how long a beginner in a specific language takes to do
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I should think I have been quite clear on that. 

Regards -- Markus

Re: in defense of GC

[Georg Bauhaus]

On Thu, 2007-02-08 at 09:49 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@arcor.de> writes:
> 
> > On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
> >> Georg Bauhaus <bauhaus@futureapps.de> writes:
> >> 
> >
> >> > If you do this, perhaps you can find the time to use a, uh, stop-watch
> >> > to measure the time it takes to produce, read, and change the programs?
> >> > I.e., to technically manage significant software. The times will be
> >> > important input for deciding whether or not static typing does indeed
> >> > help in production.
> >> > The only thing that relates to economic efficiency, if you want it :-)
> >> 
> >> So the how long a beginner in a specific language takes to do
> >> something is "important input for deciding ..." if compared to what,
> >> exactly?
> >
> > I don't think Ray is a beginner in functional programming.
> 
> >> So the how long a beginner in a specific language takes to do
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I should think I have been quite clear on that. 

If your question is asking how much time a beginner will need
to start coding productively in either dynamically typed language
or statically typed language, then this is a somewhat related question.

As for an answer, we have been shown an interesting article about
experiences with Ada vs C in teaching model train control. 

* Equate the expressiveness of Ada base types in source code to explicit
and static typing of OCaml on the one hand.

* Equate the typical use of int or char* in C to the typical absence
of static type expression in Lisp.

Then the article shows that explicit static typing helps beginners
find a working solution faster.

(I know the above equations are not technically correct. But my
viewpoint here is on beginning programmers who are mostly guided
by what they see written, not by their knowledge of type system
effects etc.)

Re: in defense of GC

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Thu, 2007-02-08 at 09:49 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@arcor.de> writes:
>> 
>> > On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
>> >> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> >> 
>> >
>> >> > If you do this, perhaps you can find the time to use a, uh, stop-watch
>> >> > to measure the time it takes to produce, read, and change the programs?
>> >> > I.e., to technically manage significant software. The times will be
>> >> > important input for deciding whether or not static typing does indeed
>> >> > help in production.
>> >> > The only thing that relates to economic efficiency, if you want it :-)
>> >> 
>> >> So the how long a beginner in a specific language takes to do
>> >> something is "important input for deciding ..." if compared to what,
>> >> exactly?
>> >
>> > I don't think Ray is a beginner in functional programming.
>> 
>> >> So the how long a beginner in a specific language takes to do
>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> I should think I have been quite clear on that. 
>
> If your question is asking how much time a beginner will need

If that is you only question, fine. It wasn't mine.

> to start coding productively in either dynamically typed language
> or statically typed language, then this is a somewhat related question.

In just the same way that a GUI makes it easy for a beginner to start
using applications and "surfing" the internet. Does give us reason to
suspect that GUIs have a larger "power" in the sense that you can do
more with them? "Somewhat related" does not seem to be related enough
for the questions you had.

Regards -- Markus

Re: in defense of GC

[Georg Bauhaus]

On Fri, 2007-02-09 at 17:17 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Thu, 2007-02-08 at 09:49 +0100, Markus E Leypold wrote:
> >> Georg Bauhaus <bauhaus@arcor.de> writes:
> >> 
> >> > On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
> >> >> Georg Bauhaus <bauhaus@futureapps.de> writes:
> >> >> 
> >> >
> >> >> > If you do this, perhaps you can find the time to use a, uh, stop-watch
> >> >> > to measure the time it takes to produce, read, and change the programs?
> >> >> > I.e., to technically manage significant software. The times will be
> >> >> > important input for deciding whether or not static typing does indeed
> >> >> > help in production.
> >> >> > The only thing that relates to economic efficiency, if you want it :-)
> >> >> 
> >> >> So the how long a beginner in a specific language takes to do
> >> >> something is "important input for deciding ..." if compared to what,
> >> >> exactly?
> >> >
> >> > I don't think Ray is a beginner in functional programming.
> >> 
> >> >> So the how long a beginner in a specific language takes to do
> >                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> 
> >> I should think I have been quite clear on that. 
> >
> > If your question is asking how much time a beginner will need
> 
> If that is you only question, fine. It wasn't mine.

OK, I admit I have had some difficulty in parsing the beginner-sentence,
I tried my best which is never enough. Does your question have to do
with beginners at all?

Re: in defense of GC

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Fri, 2007-02-09 at 17:17 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>> > On Thu, 2007-02-08 at 09:49 +0100, Markus E Leypold wrote:
>> >> Georg Bauhaus <bauhaus@arcor.de> writes:
>> >> 
>> >> > On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
>> >> >> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> >> >> 
>> >> >
>> >> >> > If you do this, perhaps you can find the time to use a, uh, stop-watch
>> >> >> > to measure the time it takes to produce, read, and change the programs?
>> >> >> > I.e., to technically manage significant software. The times will be
>> >> >> > important input for deciding whether or not static typing does indeed
>> >> >> > help in production.
>> >> >> > The only thing that relates to economic efficiency, if you want it :-)
>> >> >> 
>> >> >> So the how long a beginner in a specific language takes to do
>> >> >> something is "important input for deciding ..." if compared to what,
>> >> >> exactly?
>> >> >
>> >> > I don't think Ray is a beginner in functional programming.
>> >> 
>> >> >> So the how long a beginner in a specific language takes to do
>> >                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> 
>> >> I should think I have been quite clear on that. 
>> >
>> > If your question is asking how much time a beginner will need
>> 
>> If that is you only question, fine. It wasn't mine.
>
> OK, I admit I have had some difficulty in parsing the beginner-sentence,
> I tried my best which is never enough. Does your question have to do
> with beginners at all?


In this subthread I didn't have a question: I just encouraged Ray to
have a look into OCaml. More like a recommendation between people that
are lokking for good restaurants: Tastes differ, but still one is
listening to other peoples advice and one is still giving references
where one liked it :-).

In the superthread the open question seemd to be yours: Typing - is it
good or bad, is type inference good or bad etc -- so I related your
request for measurements to your question(s) and was a bit surprised
that suddenly we're only talking about suitability for beginners.

But as I said in other posts (responses to your's and Dmitry's): I'm
not sure any more at all what we're talking about, except (rather
general) likes disklikes and feelings of good and bad vibrations ... 

I'm admittedly not sure I'd like to posit any thesis here now or
suggest that anyone else does: After all, we don't have the
instruments here to check / test "the truth" or find empirical data
that definitely doesn't exist. 

Regards -- Markus

Re: in defense of GC

[Markus E Leypold]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>
>> > If you do this, perhaps you can find the time to use a, uh, stop-watch
>> > to measure the time it takes to produce, read, and change the programs?
>> > I.e., to technically manage significant software. The times will be
>> > important input for deciding whether or not static typing does indeed
>> > help in production.
>> > The only thing that relates to economic efficiency, if you want it :-)
>> 
>> So the how long a beginner in a specific language takes to do
>> something is "important input for deciding ..." if compared to what,
>> exactly?

<snipped>

> Now before I try singing old wisdom from the neighbourhood of
> The Mythical Man Month ...
> How will a piece of source code, your own or someone else's, and
> a language with tools fit these and the market as we might think
> it is now?

I find myself a bit confused on what you're talking about now --
exactly against what do you propose that I defend myself? Since Ray
Blaak expressed past interest in OCaml I had the cheek to encourage
him to really go and have a deeper look into OCaml when he finds
time. 

That was it. I certainly miss, how all that here comes in:

> project size,
> project duration,
> forced language,
> availability of programmers (need to hire?),
> job changes,
> programmer skills,
> multiple projects at the same time,
> language switching e.g. between projects every other week,
> time needed for education,
> documentation needs,
> future modification done by others,
> future modification to be done by the author,
> ...

But let me give a real short answer to your request as it stands:

> How will a piece of source code, your own or someone else's, and
> a language with tools fit these and the market as we might think
> it is now?

It will depend on the ability of mine or someone else to code in this
unnamed language with arbitrary tools. Note that I doubt that "we
think" the same about the market and what counts -- finally -- is how
the market is, not how we think about it, which might be a different
thing altogether.

Does that answer satisfy you? No? I thought so. You have to ask better
questions then.

> A rich set of opportunities for collecting some input, if only

Questions as those rather wide ranging ones you just posed above are
not "opportunities for collecting some input". They just stay
questions. I fail to see the opportunity. Even if R.B. would use the
suggested "stop watch" (and we all know how little the time alone will
tell you), I hope you don't try to draw conclusion on all those topics:


> project size,
> project duration,
> forced language,
> availability of programmers (need to hire?),
> job changes,
> programmer skills,
> multiple projects at the same time,
> language switching e.g. between projects every other week,
> time needed for education,
> documentation needs,
> future modification done by others,
> future modification to be done by the author,
> ...

> in order to convince ourselves that some things might have changed
> in software production (due to language changes?) while others

Well, things have changed, but you're probably missing how.

> haven't changed --for example we might get carried away by a

Care not to use that all-inclusive sick-nurse style "we" here?  If you
get carried away: Your problem. If you insist I did, then say so.

And note that I didn't give a specific factor of improvement of
productivity. Brooks excludes "magical" improvements for large
projects in orders of magnitude, not

  (a) for small projects (in large projects it's not the
      implementation that dominates)

  (b) not for reasonable factors.

In small day-to-day development I don't think a factor of

> subjective estimate of the usability of our preferred language.

> In accord with the findings of Leon Festinger (1957).

Good. That might be. How's than that C is rumoured to be so much less
productive than Ada?

Bah!

George, you're not trying to find out things, but to win. At, I might
say, every price. 

As I already said: Just ignore what I say and we'll be fine. I'm not
conducting paid scientific research here on language usability and
I've no interest in making converts. Just say that what I say cannot
be proven, you refuse to believe anything of it and let it be
done. _I_ do not see any way to help you here, esp. since above you
just sketched a many man year research program as the things you need
to get answered. How to you propose I answer to 

> How will a piece of source code, your own or someone else's, and
> a language with tools fit these and the market as we might think
> it is now? (...)

Say "They fit well?". Would I be done then? Or would you call me
deluded (not with that word of course) and we'd argue over what I say
until I bring sworn affidavits? You know, I'm already convinced
(though I doubt you exactly grasped of what), so I don't need to
conduct any experiments or research in the directions _you_
require. You're not convinced and IMO unconvincable, but as I said:
YMMV and I'll let you you're point of view and practice of
programming. Since I don't work for or with you I don't have to find a
common style with you. And for the rest: Well -- I just don't have the
time. As I already said: I'm not even sure I know what you want.

I reserve the right, though, to give some, perhaps not well recieved
or well like answers to questions like "Why is Ada not more popular"
or oppose some views on GC or type inference. Oppose, mind you. That
means some statement of dissenting opinion and experience (which
anybody can ignore at their will), but that doesn't mean I've to slug
it out. That is what scientific studies are for and they usually take
a bit more time than 30 minutes on usenet. I know a number of people
who'd happily accept some research grants on these topics, so if you
just happen to have some spare money and the need to answer

> project size,
> project duration,
> forced language,
> availability of programmers (need to hire?),
> job changes,
> programmer skills,
> multiple projects at the same time,
> language switching e.g. between projects every other week,
> time needed for education,
> documentation needs,
> future modification done by others,
> future modification to be done by the author,
> ...

is just so urgent and important to you, you might consider sponsoring them.

Regards -- Markus

Re: in defense of GC

[Georg Bauhaus]

On Thu, 2007-02-08 at 10:24 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@arcor.de> writes:
> 

> > How will a piece of source code, your own or someone else's, and
> > a language with tools fit these and the market as we might think
> > it is now?
> 
> It will depend on the ability of mine or someone else to code in this
> unnamed language with arbitrary tools. Note that I doubt that "we
> think" the same about the market and what counts -- finally -- is how
> the market is, not how we think about it, which might be a different
> thing altogether.
> 
> Does that answer satisfy you? No? I thought so.

Yes, it does!
And more or less uncertainty about causes and effects of PLs
in production use is the only common base we have for making
decisions, right or wrong. Partial knowledge is all we
will ever have, still it is something to build on.

Nevertheless, this is where *Ada* started, AFAIKT:
Some of the effects of using more than 400 PLs in one large
organization were pretty well diagnosed. A catalogue of desirable
PL properties was drafted, and reviewed. Looking at
the outcome, my conclusion is that this large research effort
did suggest answers to some of the questions of this co-thread
about redundancy, explicit typing, or robust syntax (To see
highly sensitive syntax typical of the Bell labs tradition ;-),
try

struct s {
   int a;
}

int main()
{
   struct s x;
   return 0;
}



> Well, things have changed, but you're probably missing how.

> George, you're not trying to find out things, but to win. At, I might
> say, every price. 

I'm only trying to draw attention to some findings when
programming is observed as caused by programmers using programming
languages. This includes findings about old and new languages. [*]
 Any findings are important because they can affect decisions.
As a consequence of these, they will potentially affect the amount
of money spent, the technical qualities of solutions and the
time needed to produce. I'm trying to allude to data to again be
placed in a frame of reference for language design decisions.

But I understand you are convinced that OCaml, if you let me name
it as a representative of a few things, answers many of the
questions best. So do I, to some extent.

Yet, if conviction is all there is, then indeed we loose the
common ground for a discussion.


[*] Comparing, say, Ada and Haskell wrt understandability,
neither is intuitive enough for my taste, though not always
for the same reasons.
Some language properties are hidden away, even when they are useful,
or important to know for runtime behavior.

- Like Ada tagged types being aliased therefore you can
have 'Unchecked_Access to function parameters...

- Like the Haskell expressions
 sum [1 .. n] or foldr (+) 0 [1 .. n] should almost certainly
be rewritten. The programmer has to find out why and how. Yet,
the first expression is so nice and straight forward and reflects
almost exactly what Hughes has suggested in 1984...

Re: in defense of GC

[Ray Blaak]

Georg Bauhaus <bauhaus@futureapps.de> writes:
> If you do this, perhaps you can find the time to use a, uh, stop-watch
> to measure the time it takes to produce, read, and change the programs?
> I.e., to technically manage significant software. The times will be
> important input for deciding whether or not static typing does indeed
> help in production.

No, I am a strong believer in strong static typing and I have no interest in
abandoning it.

C/C++ failures are clear, pretty much because they can easily have "no typing"
and low level memory corruption.

No, my point was merely the observation that strong dynamically typed systems
like Lisp don't seem to fail that badly, due to the robustness of the VM, most
likely, and the flexibilities they are allow to bring to bear.

It was merely out loud pondering, which always seems to get me in trouble.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: in defense of GC

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>> That's why you MUST use Ocaml :-). No, joke, I do not know what is the
>> important thing to you in Lisp. OCaml has no macros etc. But the
>> typing makes things vastly more manageable.
>
> I think what I prefer about Lisp (and Scheme) vs the ML style languages is
> that Lisp is a little more laid back. The syntax is cleaner, and the whole FP
> obsession thing is optional.
>
> The whole obsession in the syntax with just how functions map from inputs to
> outputs just seem a little too serious, but maybe I am confusing things with
> ML. I prefer to relax with the currying in declarations and just show simple

Ah, I understand. In OCaml 'let f a b c = ...' defines a curried
function so the "function ... -> function ... -> function" is greatly
diminished even if you want curried functions.

> function signatures instead. Of course in Lisp, one just passes the lambas
> around and lets the runtime worry about the mismatches.

> The funny thing is that the whole dynamic thing just doesn't seem to fail as
> badly as the static typing purists would have us believe. Now I do want my

No certainly not. I've even been heard to say "Python is not such abd
language" sometimes. It's basically a testing thing and if you build
slowly enough (not too many new _library_ components) or do really
good code reviews and dcoumentation) it doesn't seem to make too much
difference for systems not too large (I don't know about really large
systems since I'm missing the opprotunity to compare -- one really
large system is written in Lisp: Emacs :-).

> strong static typing, espcially for parameter mismatches on function calls,
> but I find it interesting that significant software can get done just fine in
> Lisp.

Lisp is not such a bad language. And the List support is excellent :-).

> I have always had OCaml on my list to dig into more. Maybe I should actually
> get around to it.
 
Do it! The infrastructure around it (bytecode + native compilers,
abilitiy to build interactive top levels, good library bindings etc)
are also something not to be missed. It has dome downsides to the
purist or if you're looking for specific things: Strings are always
mutable (has been criticized but will not/never be changed) which is a
source for some errors and there are no subrange types.

But overall: Recommended.

Regards -- Markus

Re: How come Ada isn't more popular?

[Georg Bauhaus]

On Sun, 2007-01-28 at 16:06 +0100, Markus E Leypold wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>  Since a lot of programming these days is general list
> manipulation, everyday jobs become painful. 

That lots of programming these days is list manipulation is a
popular misunderstanding I think. Witness the popularity
of what is known as Okasaki's Book. "forall", "exists",
remove-member, map(filter'access, items), etc. do not require
lists. Some of these operations don't even need traversal
(iteration, recursion, whatever you call it).
On the contrary, old Lisp style sets and maps have
always known to be as inefficient as O(n) can be.

As you have said yourself,

"the presence of
> lists and hashtables/dictionaries in those languages together with the
> absence of memory management is a factor in this popularity. 

It's not lists you manipulate when using hashtables/dictionaries.

>     But what is absolutely annoying, is, that the compatibility of
>     objects is determined by inheritance instead by the type
>     signature.

Compatibility of objects or of references to objects? What about
assignment?

I think interface types are helpful here.

>  The Java generics
> tutorial in I my eyes documents 2 things: (a) what has been really
> sorely missing from Java for 10 years and (b) that you can complement
> a type safe pascalish type system usefully with subtyping and
> parameterized types.

Why isn't Eiffel popular? :-)

Re: How come Ada isn't more popular?

[Markus E Leypold]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Sun, 2007-01-28 at 16:06 +0100, Markus E Leypold wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>  Since a lot of programming these days is general list
>> manipulation, everyday jobs become painful. 

In this case it was really me that wrote this, not Dmitry. People,
what's with news readers? :-))

> That lots of programming these days is list manipulation is a
> popular misunderstanding I think. 

I disagree. It's not all there is, but certainly there is lot of lists
everywhere. People enter lists of item into systems, the retrieve
lists of items. Lists of items are shown in GUI windows. Many loops
are actually processing lists of thingies (even if the list never
turns up explicitly -- it perhaps would in a functional language.


> Witness the popularity of what is known as Okasaki's Book.

That notwithstanding. 

> "forall", "exists", remove-member, map(filter'access, items),
> etc. do not require lists. Some of these operations don't even need
> traversal (iteration, recursion, whatever you call it).

> On the contrary, old Lisp style sets and maps have
> always known to be as inefficient as O(n) can be.

I agree here to a certain extend. A list is not always the best
representation, which is the reason that "hashes" or "dictionaries"
(actually: maps) are so prevalent in most modern scripting
languages. But with lists (for sequential processing) and maps (and
some sets) we're almost done for everyday data processing and are
vastly more powerful than C, ..., Ada. 

Therefore my plea that a modern all purpose language should have lists
in the standard library (or in the language syntax), and of course I
should have added maps and sets.

I would like add, that I've been participating in teaching software
engineering for some time. There was one exercise to specify something
which should have been easy to do using sets. Unfortunately a number
of participants ended up trying to emulate list processing (in VDM-SL)
and writing loops instead of just writing x \in M. And this where
students almost the end of their studies. I still wonder what I can
learn from that ... -- perhaps that they unlearned during their
occupation with C++ and Java (their main background) to think in the
proper abstractions (none of those languages has a set primitive, just
clumsy containers).


>
> As you have said yourself,
>
> "the presence of
>> lists and hashtables/dictionaries in those languages together with the
>> absence of memory management is a factor in this popularity. 
>
> It's not lists you manipulate when using hashtables/dictionaries.

Ah, yes. I was a bit short with my original statement, as you have
noted. But since came somewhere from "what should a language have to
be useful /successful" my statement still stands: Should have lists,
but of course ALSO sets and maps.

>
>>     But what is absolutely annoying, is, that the compatibility of
>>     objects is determined by inheritance instead by the type
>>     signature.
>
> Compatibility of objects or of references to objects? What about
> assignment?

Subtype polymorphic compatibility. And there are only references to
objects in OCaml (if you're asking about this). 

In Ada there are certainly various compatibilities

 - Assignment of objects not possible if not the same type -- no
   compatibility there.

 - Passing a A for a B is only possible if A is derived from B (wether
   by reference or not).

 - The same goes for casting

I'm actually missing what it buy you to differentiate "Compatibility
of objects or of references to objects?". Where there is compatibility
(subtype polymorphism) at all, it's tied to inheritance (of
implementation!). Perhaps I'm missing your point.


> I think interface types are helpful here.

A clumsy workaround, which also doesn't fix the co/contravariance
problem with binary methods. :-). 

>
>>  The Java generics
>> tutorial in I my eyes documents 2 things: (a) what has been really
>> sorely missing from Java for 10 years and (b) that you can complement
>> a type safe pascalish type system usefully with subtyping and
>> parameterized types.

> Why isn't Eiffel popular? :-)

I don't know. I know, why it didn't pass my evaluation: No bindings to
GUI toolkits (which is another matter), the same problem with the type
system as far as I can see.

Regards -- Markus

Re: How come Ada isn't more popular?

[Randy Brukardt]

"Charles D Hixson" <charleshixsn@earthlink.net> wrote in message
news:WaBuh.15096$pQ3.10501@newsread4.news.pas.earthlink.net...
...
> Ada subsets couldn't
> use the name Ada.  Janus Ada couldn't call itself Ada for
> quite awhile.  And even Janus Ada couldn't run on most CP/M
> machines.  Too resource intensive.  I bought an Apple ][ to
> run UCSD Pascal, and was so disappointed that I saved up and
> installed a CP/M card so that I could run C.  Ada wasn't a
> possibility.  (I never seriously considered Basic.  It was too
> non-portable.  If I wanted non-portable, I'd go for assembler.)

This is somewhat confused. Janus/Ada started out as an Ada subset on CP/M.
Indeed, Apple II CP/M boards were our number 1 platform for several years in
the 1980s. We never actually owned an Apple machine ourselves (we used the
machine of a friend for testing and copying of literally hundreds of floppy
disks). Janus/Ada for CP/M ran on any machine with a 56K TPA area, which was
the vast majority of them that had a full 64K of memory. (Early versions
used even less memory. Nowdays, it's hard to imagine a time when 16K memory
boards cost several hundred dollars each; a modern machine has 16,000 times
as much memory for the same money!) So Ada *was* a possibility on CP/M.

Our early IBM PC versions only required 256K machines. But a complete
implementation of Ada 83 a few years later did take a full 640K machine.

                Randy.

AW: How come Ada isn't more popular?

[Grein, Christoph (Fa. ESG)]

This has been asked several times, and I think you'll get many opinions.
There are historical reasons, but by now, they are no longer relevant.

In effect, there is no real reason why she isn't more popular - I
personally cannot understand this. Most of the arguments you hear
against Ada are in fact made up - people just don't want to use her,
they're happy with whatever they're using.

Mind you, I do not argue that there are strong reasons why some project
does not use Ada - we're talking popularity here.

Re: AW: How come Ada isn't more popular?

[Talulah]

Grein, Christoph (Fa. ESG) wrote:

> Mind you, I do not argue that there are strong reasons why some project
> does not use Ada - we're talking popularity here.

Popularity is the key thing surely - the chicken and egg. As a software
manager in a commercial business, I employ C programmers because there
are so few Ada programmers around in the UK. There are so few Ada
programmers in the UK because I employ C programmers! How do you break
that chain?

There are many examples in marketing history of inferior products
becoming the more widespread, e.g. Betamax v VHS video recorders, MSDOS
v Concurrent CPM-86. I guess this is just another one of them.

Re: AW: How come Ada isn't more popular?

[Anders Wirzenius]

"Talulah" <paul.hills@uk.landisgyr.com> writes:

> Grein, Christoph (Fa. ESG) wrote:
> 
> > Mind you, I do not argue that there are strong reasons why some project
> > does not use Ada - we're talking popularity here.
> 
> Popularity is the key thing surely - the chicken and egg. As a software
> manager in a commercial business, I employ C programmers because there
> are so few Ada programmers around in the UK. There are so few Ada
> programmers in the UK because I employ C programmers! How do you break
> that chain?

Quality is not free - short term.
Quality costs are traditionally split in:
- preventive costs
- inspection costs
- error costs, which are split in:
  - external error costs
  - internal error costs

Investing in Ada people belongs to the preventive quality
costs which hopefully are paid back at a later stage.

So, breaking the chain is a long term process which in the very
beginning does not produce much more than costs.
But in the long term ...  

> 
> There are many examples in marketing history of inferior products
> becoming the more widespread, e.g. Betamax v VHS video recorders, MSDOS
> v Concurrent CPM-86. I guess this is just another one of them.

I don't know what "this" refers to. :(

-- 
Anders

Re: AW: How come Ada isn't more popular?

[Jeffrey R. Carter]

Talulah wrote:
> 
> Popularity is the key thing surely - the chicken and egg. As a software
> manager in a commercial business, I employ C programmers because there
> are so few Ada programmers around in the UK. There are so few Ada
> programmers in the UK because I employ C programmers! How do you break
> that chain?

No one should be hiring X programmers. For long term employees, you 
should be looking for SW engineers, whom you then train if necessary. 
Identifying SW engineers isn't easy, but one clue is that SW engineers 
generally like Ada once they've been exposed to it.

This approach has long term cost savings, as Ada results in SW that is 
ready for deployment sooner and has far fewer post-deployment errors 
than SW in C. Your SW is ready before your competitors, and is higher 
quality.

Plus, your employees, liking Ada, won't be leaving to do C for your 
competitors.

Re: AW: How come Ada isn't more popular?

[Pascal Obry]

Jeffrey R. Carter a �crit :

> No one should be hiring X programmers. For long term employees, you
> should be looking for SW engineers, whom you then train if necessary.
> Identifying SW engineers isn't easy, but one clue is that SW engineers
> generally like Ada once they've been exposed to it.

How true! But sadly far from the common practice :(

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: AW: How come Ada isn't more popular?

[Maciej Sobczak]

Jeffrey R. Carter wrote:

> For long term employees, you 
> should be looking for SW engineers, whom you then train if necessary.

Yes.

> Identifying SW engineers isn't easy

Especially when the management (the hiring guys) are not SWEs themselves.

> but one clue is that SW engineers 
> generally like Ada once they've been exposed to it.

Sorry, but this is made up of very thin air.
What about SWEs that were never exposed to Ada?
What about coders that were exposed to Ada but still have no clue?

The only thing that backs up your statement is that an average Ada 
programmer is probably more competent than an average C programmer, but 
even though this correlation is statically true, it is not necessarily 
related to the virtues of any language, but rather to the fact that it 
requires more self-determination (and therefore professional discipline) 
to learn Ada in the world where Ada just does not sell (see "How come 
Ada isn't more popular" thread). Learning C or Java comes for free and 
the rest is just statistics, not the rule. There *are* SWEs that use 
other languages.

> This approach has long term cost savings, as Ada results in SW that is 
> ready for deployment sooner and has far fewer post-deployment errors 
> than SW in C.

As if these were the only progamming languages in the world. There are 
~2500, according to some very conservative estimations, so there is no 
need to keep comparing just these two. "Ada is good, because it's better 
than C" - is this the only thing that Ada can offer? :-) With ~2500 
languages around just being better than C does not count as any 
advantage, so I don't understand why do you use this as an argument so 
often.
If you want to sell Ada, compare it to Java or C++ or C#, for example.

> Your SW is ready before your competitors, and is higher 
> quality.

Just to flame a bit, I can write a database client library in C++ faster 
than in Ada without compromising its quality (see my recent posts 
concerning how much fun I've had with [Limited_]Controlled). ;-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: AW: How come Ada isn't more popular?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> Sorry, but this is made up of very thin air.
> What about SWEs that were never exposed to Ada?

You're going to expose them to Ada. They will like it. You'll know 
you've got a keeper.

> What about coders that were exposed to Ada but still have no clue?

They don't like Ada.

> As if these were the only progamming languages in the world. There are 
> ~2500, according to some very conservative estimations, so there is no 
> need to keep comparing just these two. "Ada is good, because it's better 
> than C" - is this the only thing that Ada can offer? :-) With ~2500 
> languages around just being better than C does not count as any 
> advantage, so I don't understand why do you use this as an argument so 
> often.
> If you want to sell Ada, compare it to Java or C++ or C#, for example.

The OP said he hired C programmers because he couldn't find Ada 
programmers, and he couldn't Ada programmers because he hired C 
programmers. So my reply is in those terms.

-- 
Jeff Carter
"Strange women lying in ponds distributing swords
is no basis for a system of government."
Monty Python & the Holy Grail
66

Re: How come Ada isn't more popular?

[Stephen Leake]

artifact.one@googlemail.com writes:

> I am a long time C programmer (10 years plus), having a look
> at Ada for the first time. From my (inadequate) testing, it seems
> that performance of average Ada code is on par with average
> C code, and there's a clear advantage in runtime safety. The
> GNU ada compiler makes pretty sure that there are very few
> platforms without easy access to Ada, so portability should be
> on at least an equal footing too.
>
> My question is: how come Ada isn't more popular?

Because most people don't have the same attitude towards language
evaluation that you do.

Most that I've actually asked have the attitude "C was what I learned
in college, and it's good enough for me". 

Or, in managers, "everyone else is using C, so it must be the best
language". When I point out that far more programs are written in
Visual Basic, or Excel, they look very puzzled :).

Welcome to enlightenment :).

-- 
-- Stephe

Re: How come Ada isn't more popular?

[adaworks]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:uy7nucb8e.fsf@stephe-leake.org...
>
> Or, in managers, "everyone else is using C, so it must be the best
> language". When I point out that far more programs are written in
> Visual Basic, or Excel, they look very puzzled :).
>
One of the long-forgotten success stories in Ada was at Xerox, another
company that has a history of grabbing defeat from the jaws of victory.

A team of developers at Xerox decided to use Ada for the software on
a new Xerox copier.   The project was a resounding success and every
team member was enthusiastic about the potential for software on other
Xerox projects.   There were analyses showing how Ada was more
cost-effective than C or other alternatives.  It looked as if Ada might
have found its niche in commercial software development.

Not so.  In spite of all the evidence in support of Ada, some idiot
higher up in management decreed that all software must be written
in C.   He had no understanding of Ada.  All he knew was that it
was a DoD language and he wanted no part of it.

This story has repeated itself over and over.  As noted, a lot of people
are reluctant to use a language designed for "killing and maiming."  It
is silly, of course, but programming aptitude has never been a good
predictor for sensible decision-making.

There is a shortage of Ada programmers, so Lockheed-Martin made
the decision to use C++ on some of our major weapon systems. Not
a particularly wide decision.    They have discovered that, for the software
to be dependable, they must cripple C++ to the point where it is being
used as a "better C" and they have lost all the alleged benefits of C++
except one:  the larger population of university-trained C++ programmers.

Academia has been no better.  As long as the DoD funded projects related
to Ada, professors were happy to take the money.  Once the funding vanished,
those professors redirected their efforts to projects using newer whiz-bang
languages that looked good when they submitted papers for publication.

I recently had the opportunity to teach a beginning class in Java.  What I
discovered is that Java is not type safe, and includes a lot more opportunities
for programming errors than Ada.   It is not any better designed than Ada,
but it does have a lot of libraries.  Most important, it is easier to get a 
paper
published if it mentions Java than if it mentions Ada.  A few years ago I was
invited to submit a paper to a conference by the conference chairperson.  I
was told not to mention Ada.

For a variety of reasons, there is a lot of ignorance and bias regarding Ada and
it will not be easy to overcome.   One bright spot is that SPARK has achieved
a high level of respectability and SPARK is an Ada-based environment.

Richard Riehle

Re: How come Ada isn't more popular?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> I recently had the opportunity to teach a beginning class in Java.  What I
> discovered is that Java is not type safe, <...> 

How so? I'd be really intrested to know.

Regards -- Markus

Re: How come Ada isn't more popular?

[Peter Hermann]

Markus E Leypold wrote:
> <adaworks@sbcglobal.net> writes:
> > discovered is that Java is not type safe, <...> 
> 
> How so? I'd be really intrested to know.

Java adopted a type system (at least for its scalar types)
which was about 20 years outdated at the time of Java's creation.
There is a lack of an important layer of abstraction
resulting from a C and Assembler mindset.

-- 
--Peter.Hermann@ihr.uni-stuttgart.de        (+49)0711-685-872-44(Fax79)
--Nobelstr.19 Raum 0.030, D-70569 Stuttgart IHR Hoechstleistungsrechnen
--http://www.ihr.uni-stuttgart.de/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Peter Hermann <ica2ph@csv.ica.uni-stuttgart.de> writes:

> Markus E Leypold wrote:
>> <adaworks@sbcglobal.net> writes:
>> > discovered is that Java is not type safe, <...> 
>> 
>> How so? I'd be really intrested to know.
>
> Java adopted a type system (at least for its scalar types)
> which was about 20 years outdated at the time of Java's creation.
> There is a lack of an important layer of abstraction
> resulting from a C and Assembler mindset.

So the type system is not rich enough, at least if you come from the
Ada world with those interesting subtyping stuff.

But how is Jave not _type safe_? 

I believe Luca Cardelli gave a good definition of what type safe means in his paper

    http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf

But I fail to see, how "execution errors" in the sense give there can
occur in Java.  Shall I elaborate? 

Regards -- Markus

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Stephen Leake wrote:
> 
> Or, in managers, "everyone else is using C, so it must be the best
> language". When I point out that far more programs are written in
> Visual Basic, or Excel, they look very puzzled :).

More programming is done in COBOL than any other language.

Re: How come Ada isn't more popular?

[Frank J. Lhota]

"Jeffrey R. Carter" <jrcarter@acm.org> wrote in message 
news:WYtth.318145$FQ1.108931@attbi_s71...
> More programming is done in COBOL than any other language.

Several decades ago, that was definitely true, but is it /still/ true today? 
If one measures things by job openings, then COBOL appears to be outpaced by 
C++, Java, and C#.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Frank J. Lhota wrote:
> 
> Several decades ago, that was definitely true, but is it /still/ true today? 
> If one measures things by job openings, then COBOL appears to be outpaced by 
> C++, Java, and C#.

The most recent survey of actual projects that I've seen (in CACM, IIRC) 
still had COBOL in 1st place.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Jeffrey R. Carter wrote:

>> Several decades ago, that was definitely true, but is it /still/ true 
>> today? If one measures things by job openings, then COBOL appears to 
>> be outpaced by C++, Java, and C#.
> 
> The most recent survey of actual projects that I've seen (in CACM, IIRC) 
> still had COBOL in 1st place.

Did it cover open-source projects as well?
COBOL was popular at the time when development was centralized in big 
companies, so it was easier to count the number of lines. Today every 
kid is coding something and it's even hard to estimate how much code is 
written every day that is just unnoticed. Just having Windows as a major 
operating system (with milions of development shops shipping software 
for it) gives a hint that COBOL might not be a winner any longer.

--
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> Did it cover open-source projects as well?
> COBOL was popular at the time when development was centralized in big 
> companies, so it was easier to count the number of lines. Today every 
> kid is coding something and it's even hard to estimate how much code is 
> written every day that is just unnoticed. Just having Windows as a major 
> operating system (with milions of development shops shipping software 
> for it) gives a hint that COBOL might not be a winner any longer.

It covered projects for which people were paid to develop SW. When you 
include open-source and teenage kids creating buffer-overflow errors in 
their bedrooms, you may get a different result.

-- 
Jeff Carter
"Strange women lying in ponds distributing swords
is no basis for a system of government."
Monty Python & the Holy Grail
66

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Maciej Sobczak wrote:
>> Did it cover open-source projects as well?
>> COBOL was popular at the time when development was centralized in
>> big companies, so it was easier to count the number of lines. Today
>> every kid is coding something and it's even hard to estimate how
>> much code is written every day that is just unnoticed. Just having
>> Windows as a major operating system (with milions of development
>> shops shipping software for it) gives a hint that COBOL might not be
>> a winner any longer.
>
> It covered projects for which people were paid to develop SW. When you
> include open-source and teenage kids creating buffer-overflow errors
> in their bedrooms, you may get a different result.

Teanage kids these days write c001 PHP web applications. Now buffer
overflows there, but any amount of security holes.

BTW, what one can learn from that, is, that it is the absence of
correct models and absence encapsulation of state and representation
that makes software bad (insecure / unsafe / whatever), not only the
buffer overflows.

Regards -- Markus

Re: How come Ada isn't more popular?

[Markus E Leypold]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> "Jeffrey R. Carter" <jrcarter@acm.org> writes:
>
>> Maciej Sobczak wrote:
>>> Did it cover open-source projects as well?
>>> COBOL was popular at the time when development was centralized in
>>> big companies, so it was easier to count the number of lines. Today
>>> every kid is coding something and it's even hard to estimate how
>>> much code is written every day that is just unnoticed. Just having
>>> Windows as a major operating system (with milions of development
>>> shops shipping software for it) gives a hint that COBOL might not be
>>> a winner any longer.
>>
>> It covered projects for which people were paid to develop SW. When you
>> include open-source and teenage kids creating buffer-overflow errors
>> in their bedrooms, you may get a different result.
>
> Teanage kids these days write c001 PHP web applications. Now buffer
> overflows there, but any amount of security holes.

s/Teanage/Teenage/;s/Now/No/

Sorry.

>
> BTW, what one can learn from that, is, that it is the absence of
> correct models and absence encapsulation of state and representation
> that makes software bad (insecure / unsafe / whatever), not only the
> buffer overflows.
>
> Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

> Teanage kids these days write c001 PHP web applications. Now buffer
> overflows there, but any amount of security holes.
> 
> BTW, what one can learn from that, is, that it is the absence of
> correct models and absence encapsulation of state and representation
> that makes software bad (insecure / unsafe / whatever), not only the
> buffer overflows.

Exactly.

http://www.owasp.org/index.php/OWASP_Top_Ten_Project#Top_Ten_Overview

Just changing the implementation language from C to whatever else (Ada 
including) can rule out only one (buffer overflows) of the top 10 
security flaws - and even that not always (especially when binding to 
some C code is used, where the buffer overflow can happen on the 
language border).

Security holes are not about just language choices.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> Just changing the implementation language from C to whatever else (Ada 
> including) can rule out only one (buffer overflows) of the top 10 
> security flaws - and even that not always (especially when binding to 
> some C code is used, where the buffer overflow can happen on the 
> language border).

I recall reading that buffer overflows account for about 50% of actually 
exploited vulnerabilities in networking SW. I'm not sure if that's still 
true when one considers "web applications". Also, it documents 
exploitation, not existence.

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Maciej Sobczak wrote:
>> Just changing the implementation language from C to whatever else
>> (Ada including) can rule out only one (buffer overflows) of the top
>> 10 security flaws - and even that not always (especially when
>> binding to some C code is used, where the buffer overflow can happen
>> on the language border).
>
> I recall reading that buffer overflows account for about 50% of
> actually exploited vulnerabilities in networking SW. 

> I'm not sure if that's still true when one considers "web
> applications". Also, it documents exploitation, not existence.

I don't think it's true any more. Bugs that have to do with processing
unchecked user input (esp. quoting and unquoting to/from html and
SQL-statements) in "scripted" web applications seem to be the majority
now. Of course buffer overflow is still a concern (i.e. in gpg or mail
processing application) but it's not restricted to networking software
since user very often process foreign data/"documents". Se, in
example, the resent flurry of bugs in MS word and PDF viewers (and
even those are often a bit more complicated than simple overflow as
the WMF-bug demonstrates).

I haven't any quantitative data though, but one can try to count the
security alerts in the full disclosure list or relevant security
forums. My impression: Buffer overflow still happens, but is not the
main problem any more. The main problem IMHO are bad software
engineers / programmers that create monolithic applications (no
modules, no abstraction boundaries) without contracts.

Regards -- Markus

Re: How come Ada isn't more popular?

[Björn Persson]

Stephen Leake wrote:

> Because most people don't have the same attitude towards language
> evaluation that you do.
> 
> Most that I've actually asked have the attitude "C was what I learned
> in college, and it's good enough for me".

Lots of people also seem to pounce on the latest hype, thinking that latest
equals greatest. (I suppose that's what makes up a hype.) Those who realize
that C has serious problems typically hope for a new language to solve
those problems. It doesn't seem to occur to them that the problems might
have already been solved in some existing language. At least that's the
impression I get.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: How come Ada isn't more popular?

[Alex R. Mosteo]

artifact.one@googlemail.com wrote:

> Hello.
> 
> I am a long time C programmer (10 years plus), having a look
> at Ada for the first time. From my (inadequate) testing, it seems
> that performance of average Ada code is on par with average
> C code, and there's a clear advantage in runtime safety. The
> GNU ada compiler makes pretty sure that there are very few
> platforms without easy access to Ada, so portability should be
> on at least an equal footing too.
> 
> My question is: how come Ada isn't more popular?

Others have given longer scoped responses, and I will concentrate on the
hobbyist POV (I have felt an Ada hobbyist for a long time now): there is a
catch-22 problem with Ada and it is the lack of libraries. This is a
relative problem, consider these points.

1) The standard library is really standard, so this is an advantage if it
does all you need. Also some features (e.g. fixed point, bound checking,
tasking!) are in the language so you don't need extra wrappers around the
basic language or OS.

2) There's no good, easy, almost automatic C binding generator, although the
language has well defined mechanisms for C interfacing. Yes, there was some
generator. No, it is not trivial at present to get it running in my
experience. There's some effort to have Ada integrated into SWIG; this is
promising and IMHO an important selling point to newcomers.

3) There are bindings for quite some important things: Gtk+, Xml parser,
Unicode, CORBA, databases...

Summarizing, the Ada programmer feels a bit pariah when he sees his fellow
C/C++/java friends trying the latest and greatest version of some library.
Either it is unavailable for Ada, or is not up to date, or has to invest
some time in creating or tweaking a binding.

This is something that, as I said, may be important or not at some point,
depending on what you need to do. Also going against the majority of
colleagues is a burden. In my lab almost all development is done in matlab,
C or C++, and these are not all CS people but from other engineering
branches too. It's a shock when you have to use other's code and start to
see random pointers in function declarations, arcane syntax for complex
datatypes (because typedef seems a forbidden word) and so on. In my case,
Ada isn't event a obscure language: it is taught in my university and has
good backing among several high-profile teachers. Even so, I feel very
alone... :)

Re: How come Ada isn't more popular?

[gautier_niouzes]

[about bindings - and their lack of]

For libraries that are no more developped, like some compression or
image formats, an alternative is to get an Ada translation and not
needing a binding anymore (a problem with a binding is that you have to
provide it and keep it up-to date for each compiler/OS/CPU
architecture, and accept that the quality of the bound library
fluctuates with the time...).
If you are lucky, there is a Pascal translation around and you can go
further with P2Ada, it is much easier than translating from C which is
very different.
It is also a good occasion to seriously debug these libraries.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: How come Ada isn't more popular?

[Dr. Adrian Wrigley]

On Tue, 23 Jan 2007 11:38:28 +0100, Alex R. Mosteo wrote:

> artifact.one@googlemail.com wrote:
> 
>> Hello.
>> 
>> I am a long time C programmer (10 years plus), having a look
>> at Ada for the first time. From my (inadequate) testing, it seems
>> that performance of average Ada code is on par with average
>> C code, and there's a clear advantage in runtime safety. The
>> GNU ada compiler makes pretty sure that there are very few
>> platforms without easy access to Ada, so portability should be
>> on at least an equal footing too.
>> 
>> My question is: how come Ada isn't more popular?
> 
> Others have given longer scoped responses, and I will concentrate on the
> hobbyist POV (I have felt an Ada hobbyist for a long time now): there is a
> catch-22 problem with Ada and it is the lack of libraries. This is a
> relative problem, consider these points.
> 
> 1) The standard library is really standard, so this is an advantage if it
> does all you need. Also some features (e.g. fixed point, bound checking,
> tasking!) are in the language so you don't need extra wrappers around the
> basic language or OS.
> 
> 2) There's no good, easy, almost automatic C binding generator, although the
> language has well defined mechanisms for C interfacing. Yes, there was some
> generator. No, it is not trivial at present to get it running in my
> experience. There's some effort to have Ada integrated into SWIG; this is
> promising and IMHO an important selling point to newcomers.

I think this is critical.  Why can't we just say:

with stdio;

pragma import (C, stdio, "stdio.h");

and be able to get structs, functions, constants, variables from C in
an obvious and reasonably reliable way?

Much of what is in C has direct analogs in Ada.  Some of it is via
fiddly #defines, but even a useful subset of these would be e

And of course compilers should spit out header files on request
matching an ada package via the "obvious" rules, so you can
#include it from C.
--
Adrian

Re: How come Ada isn't more popular?

[Alex R. Mosteo]

Dr. Adrian Wrigley wrote:

>> 2) There's no good, easy, almost automatic C binding generator, although
>> the language has well defined mechanisms for C interfacing. Yes, there
>> was some generator. No, it is not trivial at present to get it running in
>> my experience. There's some effort to have Ada integrated into SWIG; this
>> is promising and IMHO an important selling point to newcomers.
> 
> I think this is critical.  Why can't we just say:
> 
> with stdio;
> 
> pragma import (C, stdio, "stdio.h");
> 
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?

Ah, that sounds even better... One can dream...

Re: How come Ada isn't more popular?

[tmoran]

> I think this is critical.  Why can't we just say:
>
> with stdio;
>
> pragma import (C, stdio, "stdio.h");
>
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?

  To some extent one can do this with APIs that come with typelibs.  But
having recently made an Ada binding to the Google Earth API, I observe
that the time spent finding out what the various calls *actually* do vs
what the documentation indicates they do, takes much more time than the
typing of a bunch of pragma imports etc.

Re: How come Ada isn't more popular?

[artifact.one]

On Jan 23, 9:56 pm, "Dr. Adrian Wrigley"
<a...@linuxchip.demon.co.uk.uk.uk> wrote:
>
>  Why can't we just say:
>
> with stdio;
>
> pragma import (C, stdio, "stdio.h");
>
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
>

That, would be one of the most beautiful things I'd seen in computing
if it existed!

MC

Re: How come Ada isn't more popular?

[Keith Thompson]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:
[...]
> I think this is critical.  Why can't we just say:
> 
> with stdio;
> 
> pragma import (C, stdio, "stdio.h");
> 
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
[...]

Probably because there is no "obvious and reasonably reliable way" to
do this.

Presumably the above is intended to import the contents of the C
standard header <stdio.h>.  The problem is that, assuming it works by
processing the actual file (typically "/usr/include/stdio.h" on
Unix-like systems), it's going to pick up a huge amount of irrelevant
cruft.

For example, files in C are handled via the type "FILE*", which is a
pointer to an object of type FILE.  The C standard doesn't say what's
in a FILE object (it only requires it to be an object type), and the
actual contents can vary from one implementation to another.  C
programs are expected to use only FILE* objects, and only via the
manipulation functions defined by the standard (fopen, fclose, etc.).
In effect, FILE is an opaque type (and C programmers actually tend to
avoid writing code that depends on the unspecified internal details).

But C has no good way to express this in the language, so you're
probably going to import the actual definition of type FILE for the
current system, translated into an Ada record declaration.  You really
want
    type FILE is private;
but I don't see how you can get it.

Ideally, I suppose you'd like to be able to automatically translate
the contents of <stdio.h> into an Ada interface that's about as clean
as the C interface *as defined in the C standard*.  I'm not convinced
that it's practical to do that automatically.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: How come Ada isn't more popular?

[Gautier]

Dr. Adrian Wrigley:

> I think this is critical.  Why can't we just say:
> 
> with stdio;
> 
> pragma import (C, stdio, "stdio.h");
> 
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
> 
> Much of what is in C has direct analogs in Ada.  Some of it is via
> fiddly #defines, but even a useful subset of these would be e

A problem is that you will want to import something else than "stdio.h", for 
instance "XYZ.h" which contains

#if defined(_MSC_VER) || defined(__CYGWIN__) || defined(__MINGW32__)
#   define WIN32_LEAN_AND_MEAN
#   define NO_MIN_MAX
#    include <windows.h>
#   undef min
#   undef max
...

or worse messes... You need the whole #include and #define preprocessing, 
admit that "with ABC, XYZ;" may well behave differently than "with XYZ, ABC;" 
and plenty of funny things! In addition, I guess that with this "feature" each 
Ada compiler and compiler version would still behave slightly differently in 
that respect, with big differences at the bottom line.
That way you quickly scale down most interesting aspects of Ada: non-flat 
modularity, strong typing (Keith's reply), portability and probably more.
It is a bit too much retro-computing for Ada, I'm afraid.

You'd better to write a preprocessor that takes XYZ.h plus the 
pre-defined-#define's as input, and spits XYZ.ads as output with the Import 
pragmata. You can take a look at the preprocessor I made for Borland Pascal / 
Delphi, BP2P, in newp2ada.zip there:

http://www.mysunrise.ch/users/gdm/gsoft.htm#p2ada

> And of course compilers should spit out header files on request
> matching an ada package via the "obvious" rules, so you can
> #include it from C.

For that, again, you don't need to wait an (IMHO) unlikely change in the 
standard; especially the because the "obvious" is maybe not so clear to define 
- or is it ?
You have all ingredients to make a nice tool: tons of Ada yacc grammars on the 
Internet, even an up to date ayacc/aflex if you want to do your tool in Ada 
(see again newp2ada.zip).

The "obvious and reasonably reliable way" of importing C stuff is certainly 
more something soft (just like C itself) that you can express better in doing 
import/export tools than something solid you can define in an Ada standard...
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: How come Ada isn't more popular?

[Charles D Hixson]

Dr. Adrian Wrigley wrote:
> On Tue, 23 Jan 2007 11:38:28 +0100, Alex R. Mosteo wrote:
> 
>> artifact.one@googlemail.com wrote:
>>
>>> ...
> I think this is critical.  Why can't we just say:
> 
> with stdio;
> 
> pragma import (C, stdio, "stdio.h");
> 
> and be able to get structs, functions, constants, variables from C in
> an obvious and reasonably reliable way?
> 
> Much of what is in C has direct analogs in Ada.  Some of it is via
> fiddly #defines, but even a useful subset of these would be e
> 
> And of course compilers should spit out header files on request
> matching an ada package via the "obvious" rules, so you can
> #include it from C.
> --
> Adrian
> 
> 
That would be very nice.  Notice that it's divided into two 
pieces:
1) import c header files, and
2) export header files for C
While both would be extremely useful, and 1, perhaps, more 
than 2, it seems to me that 2 would be much more readily 
accomplished.

Re: How come Ada isn't more popular?

[Tero Koskinen]

Hi,

On 22 Jan 2007 21:53:32 -0800 artifact.one@googlemail.com wrote:
> 
> My question is: how come Ada isn't more popular?
> 

I would like to throw in yet another possible reason(*) for Ada being
not popular (within the free software folks).

Currently, the only non-restricted free Ada compiler is FSF GCC/GNAT.
However, the GCC development team doesn't consider Ada to be
a release critical language, so it gets less love whenever a new GCC
is released and its quality is sometimes lower than C and C++ parts
of GCC. In addition, Ada part of GCC supports far less platforms than
C and C++ parts. (**)

So, lets imagine that you are a lead developer in an open source
project (***). One of your goals is to produce software, which will
run atleast on following systems:
 * Debian GNU/Linux 3.1: i386, IA-64, ARM, PowerPC, SPARC, MIPS
 * OpenSUSE 10.2: i386, x86-64
 * OpenBSD 4.0: i386, AMD64, ARM, PowerPC, SPARC
 * FreeBSD 6.2: i386, AMD64, Alpha

The question is: Which programming language do you choose?

Ada is ruled out, because of its limited support for non-mainstream
free operating systems.

-Tero

(*) Actually, only a guess
(**) For example, platforms like OpenBSD/{arm,sparc,ppc,amd64} are
totally unsupported.
(***) Like KDE, Subversion, GTK+, or Sendmail

Re: How come Ada isn't more popular?

[Ludovic Brenta]

Tero Koskinen writes:
> Ada part of GCC supports far less platforms than C and C++ parts.

Actually, I don't think that that's a result of Ada not being a
release-critical language for GCC.  I rather think that that's a
result of too few people contributing to the Ada part of GCC, which is
itself a result of too few people using Ada.  Chicken and egg,
catch-22.  But that also applies to other software; for example
OpenBSD's ports collection is much smaller than Debian's or FreeBSD's;
why is that?

As a counter-example, Aurélien Jarno single-handedly ported GNAT to
GNU/kFreeBSD, which is hardly a mainstream platform.  His patches,
initially available for several versions of GNAT, are now in the
Debian packages; you can review them if you like to get a feeling of
how hard it would be to support, say, OpenBSD.

I believe that it was Samuel Tardieu who contributed the sparc-linux
port back in the 3.13p or 3.14p days, but I may be wrong on this.

> So, lets imagine that you are a lead developer in an open source
> project (***). One of your goals is to produce software, which will
> run atleast on following systems:
>  * Debian GNU/Linux 3.1: i386, IA-64, ARM, PowerPC, SPARC, MIPS
>  * OpenSUSE 10.2: i386, x86-64
>  * OpenBSD 4.0: i386, AMD64, ARM, PowerPC, SPARC
>  * FreeBSD 6.2: i386, AMD64, Alpha
> 
> The question is: Which programming language do you choose?
> (***) Like KDE, Subversion, GTK+, or Sendmail

If your project consists of general-purpose libraries and you want
them available to as many developers as possible, then your best
choice is C; not only because of compiler availability because, more
importantly, because C makes it easy to call your libraries from other
languages.  It is a design goal of GNOME, for example, to support many
languages for application development, and that's why the GTK+ and
GNOME libraries are implemented in C, despite the fact that they are
object-oriented and so would have benefited from an object-oriented
language.

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Ludovic Brenta wrote:

> If your project consists of general-purpose libraries and you want
> them available to as many developers as possible, then your best
> choice is C

That's a misconception as well, quite common in an open-source world.

> not only because of compiler availability because, more
> importantly, because C makes it easy to call your libraries from other
> languages.

 > It is a design goal of GNOME, for example, to support many
> languages for application development, and that's why the GTK+ and
> GNOME libraries are implemented in C, despite the fact that they are
> object-oriented and so would have benefited from an object-oriented
> language.

Windows was implemented in C++, and it has C API.
Encapsulation is what separates a language choice for the interface and 
implementation - well, at least to some extent and provided that both 
languages are easily "bindable". You can even have C API for Ada 
implementation - pragma Export is just as useful as pragma Import!.
In other words, you don't need to use C for implementation part even if 
you want to have C API for reasons of useability. This is exacly what 
the open-source guys don't seem to get right.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Yves Bailly]

Maciej Sobczak wrote:
> [...]
> implementation - pragma Export is just as useful as pragma Import!.
> In other words, you don't need to use C for implementation part even if
> you want to have C API for reasons of useability. This is exacly what
> the open-source guys don't seem to get right.
  ^^^
Please, replace that "the" by "some", or even "many" if you like ;-)
I'm an open-source guy, currently creating an Ada binding to the
C++ library Qt through a C layer... pragma Export, Import and exern "C"
everywhere :-)

Regards,

-- 
(o< | Yves Bailly  : http://kafka-fr.net   | -o)
//\ | Linux Dijon  : http://www.coagul.org | //\
\_/ |                                      | \_/`

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> both languages are easily "bindable". You can even have C API for Ada
> implementation - pragma Export is just as useful as pragma Import!.
> In other words, you don't need to use C for implementation part even
> if you want to have C API for reasons of useability. This is exacly
> what the open-source guys don't seem to get right.

So Ada = Closed Source = Good and C = Open Source = Bad or something
like this? I don't understand it.

Apart from that, me seems it would be a bit difficult to have a C API
to some Ada library, since Ada requires quite a lot of runtime support
for tasking, so certainly doesn't interact to well C-code which also
use signals, longjmp etc.

Regards -- Markus

Re: How come Ada isn't more popular?

[Maciej Sobczak]

Markus E Leypold wrote:

>> both languages are easily "bindable". You can even have C API for Ada
>> implementation - pragma Export is just as useful as pragma Import!.
>> In other words, you don't need to use C for implementation part even
>> if you want to have C API for reasons of useability. This is exacly
>> what the open-source guys don't seem to get right.
> 
> So Ada = Closed Source = Good and C = Open Source = Bad or something
> like this? I don't understand it.

Of course not. There is a significant amount of extremely good open 
source software around, and I also suppose that some crappy Ada code 
exists as well (it's harder to find it, but for the sake of argument I 
can write some ;-) ).
My point is that the majority of open source world seems to get stuck 
with C as a main development language for reasons which I don't really 
understand. I understand the use of C on the interface level (everything 
can bind to C, so it's the "least common denominator" for interfacing), 
but internally many projects would greatly benefit from using just about 
anything else. Developers reject this idea on the grounds that C is 
*the* progamming language for open source, end of story. I think that 
GNU luminaries (Stallman in particular) add to this mindset by 
publishing web pages promoting C as the language of choice and the crowd 
follows.

> Apart from that, me seems it would be a bit difficult to have a C API
> to some Ada library, since Ada requires quite a lot of runtime support
> for tasking, so certainly doesn't interact to well C-code which also
> use signals, longjmp etc.

Your argument can be applied in the other direction as well. How about 
binding Ada to C libraries that use non-Ada runtime internally? It's 
enough if the C library uses POSIX threads and its interaction with 
tasking in Ada is already outside of what AARM specifies.
Binding (in any direction) requires some assuptions about the two 
environments. There is way to escape them.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Markus E Leypold wrote:
>
>>> both languages are easily "bindable". You can even have C API for Ada
>>> implementation - pragma Export is just as useful as pragma Import!.
>>> In other words, you don't need to use C for implementation part even
>>> if you want to have C API for reasons of useability. This is exacly
>>> what the open-source guys don't seem to get right.
>> So Ada = Closed Source = Good and C = Open Source = Bad or something
>> like this? I don't understand it.
>
> Of course not. There is a significant amount of extremely good open
> source software around, and I also suppose that some crappy Ada code
> exists as well (it's harder to find it, but for the sake of argument I
> can write some ;-) ).

Well. I remember having read some of it. :-). The language does not
guarantee good design.

> My point is that the majority of open source world seems to get stuck
> with C as a main development language for reasons which I don't really
> understand. I understand the use of C on the interface level

I share your not-understanding. My understanding of the reason for
this situation was always that it has something todo with (a)
premature optimization and (b) the lowest common denominator: A C
library can be bound to different language APIs, but a, say Python
library cannot. I doubt a Ada library could.

Apropos Python: There are a lot of languages that are rather popular
in OSS development apart from C. KDE is bound to Qt so cannot leave
C. GNOME AFAI understand will slowly shift to Mono as application run
time and thus will have more and mor C# code (that also shows what the
OSS guys percieve as their main problem: Pointers and memory
management, both of which have not been really solved in Ada to an
extent desirable for application programming (as opposed to
embedded)).

> (everything can bind to C, so it's the "least common denominator" for

Ooops. I didn't read so far. We agree :-).

> interfacing), but internally many projects would greatly benefit from
> using just about anything else. Developers reject this idea on the
> grounds that C is *the* progamming language for open source, end of

More likely, its "the available compiler".

> story. I think that GNU luminaries (Stallman in particular) add to
> this mindset by publishing web pages promoting C as the language of
> choice and the crowd follows.

I don't think so. Nobody really has a problem to contradict RMS :-).

>> Apart from that, me seems it would be a bit difficult to have a C API
>> to some Ada library, since Ada requires quite a lot of runtime support
>> for tasking, so certainly doesn't interact to well C-code which also
>> use signals, longjmp etc.
>
> Your argument can be applied in the other direction as well. How about
> binding Ada to C libraries that use non-Ada runtime internally? It's

Yes, this is a problem. Therefore the usual approach is, to avoid this
or at least to make the runtime separable and exchangeable.

> enough if the C library uses POSIX threads and its interaction with
> tasking in Ada is already outside of what AARM specifies.

Exactly. But you can writ Code in C which just does something with
things on the stack, doesn't fiddle with threads or signals and thus
interacts minimally with the host runtime. That's the reason why C is
so popular for libraries: You can.

> Binding (in any direction) requires some assuptions about the two
> environments. There is way to escape them.

Regards -- Markus

Re: How come Ada isn't more popular?

[Ludovic Brenta]

Markus E Leypold writes:
> Apropos Python: There are a lot of languages that are rather popular
> in OSS development apart from C. KDE is bound to Qt so cannot leave
> C.

C++, actually.  And there are bindings in Python and a few other
languages.  Yves Bailly is even busy writing an Ada binding for Qt,
using an intermediate C binding.  GNOME has more language bindings
because it is written directly in C.

> GNOME AFAI understand will slowly shift to Mono as application run
> time and thus will have more and mor C# code (that also shows what the
> OSS guys percieve as their main problem: Pointers and memory
> management, both of which have not been really solved in Ada to an
> extent desirable for application programming (as opposed to
> embedded)).

There seems to be disagreements between the GNOME developers.  Some
promote the shift towards C#, but others would rather stay with C in
order to avoid the need for the large C# library and interpreter
infrastructure.

>>> Apart from that, me seems it would be a bit difficult to have a C API
>>> to some Ada library, since Ada requires quite a lot of runtime support
>>> for tasking, so certainly doesn't interact to well C-code which also
>>> use signals, longjmp etc.
>>
>> Your argument can be applied in the other direction as well. How about
>> binding Ada to C libraries that use non-Ada runtime internally? It's
>
> Yes, this is a problem. Therefore the usual approach is, to avoid this
> or at least to make the runtime separable and exchangeable.

The usual approach is to either stick to C (see e.g. Evolution), or
accept the overhead of another language's runtime because the cost is
spread over a large code base (see the new GNOME applications written
in C#).  As I said, both approaches have their proponents within the
GNOME community.  The run-time is always separate (i.e. in shared
libraries), but not necessarily exchangeable, and exchangeability is
not a design goal.

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Markus E Leypold writes:
>> Apropos Python: There are a lot of languages that are rather popular
>> in OSS development apart from C. KDE is bound to Qt so cannot leave
>> C.
>
> C++, actually.  And there are bindings in Python and a few other

Ooops, yes :-).

Regards -- Markus

Re: How come Ada isn't more popular?

[Stephen Leake]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> But you can writ Code in C which just does something with
> things on the stack, doesn't fiddle with threads or signals and thus
> interacts minimally with the host runtime. That's the reason why C is
> so popular for libraries: You can.

You can do that in Ada as well. It is perhaps not as easy in Ada as in
C, because you must be more aware of what language constructs
require run-time support. 

For example, fixed-point types require run-time support. If you use
fixed-point types in C, it is obvious from the source code that the
run-time must include a fixed-point library, because all fixed-point
operations are function calls. In Ada, that's not so clear from the
source, because fixed-point operations are just operators.

GNAT provides 'pragma No_Run_Time' for this; it makes source code that
requires run-time support illegal. I've written code with this pragma
turned on (for export to a spacecraft executive that was mostly
written in C), and it does make Ada feel more like C. Still far
preferable to actually using C, though!

In GNAT GPL-2006, 'pragma No_Run_Time' is listed as 'obsolescent'; you
are supposed to use a "configurable run-time" instead. I'm not sure how
that impacts this issue.

-- 
-- Stephe

Re: How come Ada isn't more popular?

[Markus E Leypold]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> But you can writ Code in C which just does something with
>> things on the stack, doesn't fiddle with threads or signals and thus
>> interacts minimally with the host runtime. That's the reason why C is
>> so popular for libraries: You can.
>
> You can do that in Ada as well. It is perhaps not as easy in Ada as in
> C, because you must be more aware of what language constructs
> require run-time support. 

:-) good to know.

>
> For example, fixed-point types require run-time support. If you use
> fixed-point types in C, it is obvious from the source code that the
> run-time must include a fixed-point library, because all fixed-point
> operations are function calls. In Ada, that's not so clear from the
> source, because fixed-point operations are just operators.
>
> GNAT provides 'pragma No_Run_Time' for this; it makes source code that

Yes. I've been researching this some time ago and had the impression
that this is what No_Run_Time does, but for some reason I was not
completely convinced (the docs on that where very sparse) and since I
didn't need it at that time I just didn't look at it further. Of
course one would wish (sometimes) not to have tasking and perhaps not
even exceptions (I think that requires run time support also, doesn't
it), but have float point.

> requires run-time support illegal. I've written code with this pragma
> turned on (for export to a spacecraft executive that was mostly
> written in C), and it does make Ada feel more like C. Still far
> preferable to actually using C, though!

I completely agree with this, especially if the compiler works (which
is another can of worms).

> In GNAT GPL-2006, 'pragma No_Run_Time' is listed as 'obsolescent'; you
> are supposed to use a "configurable run-time" instead. I'm not sure how
> that impacts this issue.

Perhaps even better: Might that provide for the option to select
exception support w/o getting tasking etc.?


Regards -- Markus

Re: How come Ada isn't more popular?

[Ed Falis]

Markus E Leypold wrote:
..
> Perhaps even better: Might that provide for the option to select
> exception support w/o getting tasking etc.?

Check out pragma Restrictions in Annex H and in the GNAT RM.

- Ed

Re: How come Ada isn't more popular?

[Markus E Leypold]

Ed Falis <falis@verizon.net> writes:

> Markus E Leypold wrote:
> ..
>> Perhaps even better: Might that provide for the option to select
>> exception support w/o getting tasking etc.?
>
> Check out pragma Restrictions in Annex H and in the GNAT RM.

Yes. Thanks. That's cool. 

Regards -- Markus

Re: How come Ada isn't more popular?

[Harald Korneliussen]

On 25 Jan, 09:37, Maciej Sobczak <no.s...@no.spam.com> wrote:
> Markus E Leypold wrote:
> I think that
> GNU luminaries (Stallman in particular) add to this mindset by
> publishing web pages promoting C as the language of choice and the crowd
> follows.

I'm pretty sure Stallman has more love for Lisp and Scheme than C,
given his background. I don't think it's a coincidence that the lexer
amd parser, Bison/Flex, was something of the first they made for GNU,
and that gcc, pretty uniquely among C compilers, has support for
tail-call elimination and inner functions. Raymond is another case, and
quite explicitly anti-Ada. (I may be wrong, but it seems to me that
Larry Wall, the author of Perl, has something of a love/hate
relationship with Ada. Didn't he first publish the diff algorithm in
Ada way back when?)

Anyway, I think individuals are less important than culture. You could
read this straight out of the wikipedia page for C (until I changed it
slightly ...): "the safe, effective use of C requires more programmer
skill, experience, effort, and attention to detail than is required for
some other programming languages." So if you use C, that means you are
skilled, experienced and attentive, by some people's logic. It's a
macho thing, "If you can't handle the power, don't use it!".

Klingon programmers if there ever were any.

It's of course a symptom of lack of professionalism: construction
workers who are proud of what they do wear their helmets.

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Harald Korneliussen" <vintermann@gmail.com> writes:

> On 25 Jan, 09:37, Maciej Sobczak <no.s...@no.spam.com> wrote:
>> Markus E Leypold wrote:
>> I think that
>> GNU luminaries (Stallman in particular) add to this mindset by
>> publishing web pages promoting C as the language of choice and the crowd
>> follows.

It was not me, that wrote this, but Maciej. Looks a bit strange this
way to quote.

Regards -- Markus

Re: How come Ada isn't more popular?

[Harald Korneliussen]

On 25 Jan, 13:54, Markus E Leypold
<development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote:
> It was not me, that wrote this, but Maciej. Looks a bit strange this
> way to quote.
> 
> Regards -- Markus

Oops, sorry.

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Harald Korneliussen" <vintermann@gmail.com> writes:

> skill, experience, effort, and attention to detail than is required for
> some other programming languages." So if you use C, that means you are
> skilled, experienced and attentive, by some people's logic. It's a
> macho thing, "If you can't handle the power, don't use it!".
>
> Klingon programmers if there ever were any.

That, of course is a general problem in IT: Public
criticism/discussion of "popular" (read hyped) paradigms or tools is
hardly possible, because that seems to imply that the critic is just
not able to use it ("What you can't program safely in C -- I can!"). I
might go farther and note that in teams/projects criticism is often
disliked: What is called a 'can-do' attitude in cheap management
literature is considered to be important. ("According to my analysis,
we can not write this piece of software in 2 months, since ..." --
"What, are you so incompetent? Your colleague / competitor says he can
do it. So'll give it to him").

So in my opinion you only point out a sub-aspect of a quite larger
problem.

> It's of course a symptom of lack of professionalism: construction
> workers who are proud of what they do wear their helmets.

Quite right. But in computer science (esp. software engineering) the
hard data is often quite missing, so the participants in these
discussions replace it by belief. Whereas nobody expects a proud
construction worker to wear amulets and nobody seriously suggests it,
because the majority agrees that helmets protect and amulets probably
not, the situation is different for development paradigms, processes
and tools. And usually there is no hard data available. So even those
which act wrong from your point of view can continue believing that
they are doing the right thing. 

There is also the aspect of marketing which tends to further distort
reality (or whatever goes for it in IT).

Regards -- Markus

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Harald Korneliussen wrote:
> 
> Anyway, I think individuals are less important than culture. You could
> read this straight out of the wikipedia page for C (until I changed it
> slightly ...): "the safe, effective use of C requires more programmer
> skill, experience, effort, and attention to detail than is required for
> some other programming languages." So if you use C, that means you are
> skilled, experienced and attentive, by some people's logic. It's a
> macho thing, "If you can't handle the power, don't use it!".

The only safe use of C is as a target language for code generators (such 
as the SofCheck Ada -> C compiler). The continuing creation of 
buffer-overflow errors in C shows that, in practice, it is impossible 
for humans to create safe C.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Harald Korneliussen wrote:
>> Anyway, I think individuals are less important than culture. You
>> could
>> read this straight out of the wikipedia page for C (until I changed it
>> slightly ...): "the safe, effective use of C requires more programmer
>> skill, experience, effort, and attention to detail than is required for
>> some other programming languages." So if you use C, that means you are
>> skilled, experienced and attentive, by some people's logic. It's a
>> macho thing, "If you can't handle the power, don't use it!".
>
> The only safe use of C is as a target language for code generators
> (such as the SofCheck Ada -> C compiler). The continuing creation of
> buffer-overflow errors in C shows that, in practice, it is impossible
> for humans to create safe C.

Not to promote C, but purely from a logical perspective: The
"continuing creation of buffer-overflow errors in C" only shows that
there exist programmers/humans that don't always create safe programs
in C.

Since I assume that the same thing (unsafe programs) applies to Ada
(say with respect to unhandled exceptions (Ariane, for instance ...)
or with respect to memory leaks or priority inversions in tasking),
the only remaining line on which an argument of the usability of C
vs. that of Ada can develop is quantitatively, not qualitatively.

I'd like just to point out that the world even in this respect is
neither black and white (or at least you haven't demonstrated that
convincingly yet), but more shades of gray. I concede the gray might
be lighter in Ada sector and darker in the C sector, but I'd prefer
quantitative arguments / reasoning in this world and some effort to
estimate the difference between those shades over striking but
logically flawed reasoning. I want absolutes I'll turn to religion. :-).

Regards -- Markus

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Markus E Leypold wrote:
> 
> Not to promote C, but purely from a logical perspective: The
> "continuing creation of buffer-overflow errors in C" only shows that
> there exist programmers/humans that don't always create safe programs
> in C.

Don't you get logical on me here. I maintain that it is impossible for 
humans to write safe C. For proof by blatant assertion, see my previous 
post.

> I'd like just to point out that the world even in this respect is
> neither black and white (or at least you haven't demonstrated that
> convincingly yet), but more shades of gray. I concede the gray might
> be lighter in Ada sector and darker in the C sector, but I'd prefer
> quantitative arguments / reasoning in this world and some effort to
> estimate the difference between those shades over striking but
> logically flawed reasoning. I want absolutes I'll turn to religion. :-).

All together now: Put your hands on the monitor. Say, "I believe in Ada!"

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Markus E Leypold wrote:
>> Not to promote C, but purely from a logical perspective: The
>> "continuing creation of buffer-overflow errors in C" only shows that
>> there exist programmers/humans that don't always create safe programs
>> in C.
>
> Don't you get logical on me here. I maintain that it is impossible for
> humans to write safe C. For proof by blatant assertion, see my
> previous post.

:-)

>
>> I'd like just to point out that the world even in this respect is
>> neither black and white (or at least you haven't demonstrated that
>> convincingly yet), but more shades of gray. I concede the gray might
>> be lighter in Ada sector and darker in the C sector, but I'd prefer
>> quantitative arguments / reasoning in this world and some effort to
>> estimate the difference between those shades over striking but
>> logically flawed reasoning. I want absolutes I'll turn to religion. :-).
>
> All together now: Put your hands on the monitor. Say, "I believe in Ada!"

Yeees, that's more like it. If we all do this and are pure of spirit
(no C-thought!!) we'll overwhelm THEM with the pure power of our mind
fields.

I'm glad you take this with a bit of humor. But I would like to
emphasize once again that -- not only in the game Ada vs. C, but
most/every other programming language / development paradigm advocacy
-- I'm missing hard data. 

(I say this again here, since a number of my posts from yesterday
where I explained all that seem to have fallen into a black hole).

Regards -- Markus

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Markus E Leypold wrote:
> 
> I'm glad you take this with a bit of humor. But I would like to
> emphasize once again that -- not only in the game Ada vs. C, but
> most/every other programming language / development paradigm advocacy
> -- I'm missing hard data. 

Hard data are hard to come by. Few organizations have the resources or 
the inclination to do such studies. Where we do have hard data (that I 
know of) are 2 studies, 1 by Rational available at adaic.org, and the 
other by P&W, posted here some years ago by Condic; McCormick's results; 
results published by Praxis on the C-130J project; and a controlled 
study at the US Military Academy comparing Ada and Pascal as 1st-course 
languages published in /Ada Letters/.

The 1st 2 both showed that Ada, compared to C, offered a factor of 2 
improvement in cost of reaching deployment, a factor of 4 improvement in 
post-deployment errors, and a factor of 10 improvement in cost of 
correcting a post-deployment error.

The 3rd we've discussed adequately here, I think.

The 4th showed a factor of 10 improvement in post-deployment errors 
compared to C (and a further factor of 10 improvement of SPARK over Ada).

The 5th concluded that Ada was a better 1st-course language than Pascal.

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Markus E Leypold wrote:
>> I'm glad you take this with a bit of humor. But I would like to
>> emphasize once again that -- not only in the game Ada vs. C, but
>> most/every other programming language / development paradigm advocacy
>> -- I'm missing hard data.

> Hard data are hard to come by. 

Yes, but -- computer science and software engineering strife to be
_science_. So there should be a bit more proof and a bit less advocacy
(I've elaborated on this on one of the posts that went into a black
hole).

> Few organizations have the resources or the inclination to do such
> studies.

Simple: Science, esp. software engineering should. A whole discipline
of science (materials science)is dedicated to evaluate, test, and
describe the properties of new and old materials. Another science
disciplin (education science) is dedicated to research how to teach
things and how people learn things (not such a hard science but the
results are overall still better and more reliable than just having
Joe Sixpack say his part about how education should be done).

I think that there should be a discipline in computer science that
researches and quantitatively classifies the tools and methods which
are used to create new programs. Actually there is such a discipline
(software engineering) but there is also a lot of advocacy and
philosophy there and not so much hard data.

Presently I not, that new paradigms are put forward more in a
religious manner, and if they succeed just produce more opportunity for
research how to support the paradigm with give tools -- whereas the
first proof that the new paradigm / technique actually buys anything
is usually a bit thin.


> Where we do have hard data (that I know of) are 2 studies, 1 by
> Rational available at adaic.org, and the other by P&W, posted here
> some years ago by Condic; McCormick's results; results published by
> Praxis on the C-130J project; and a controlled study at the US
> Military Academy comparing Ada and Pascal as 1st-course languages
> published in /Ada Letters/.

Amazing. 2 Studies for 20 years of Ada :-).

> The 1st 2 both showed that Ada, compared to C, offered a factor of 2
> improvement in cost of reaching deployment, a factor of 4 improvement
> in post-deployment errors, and a factor of 10 improvement in cost of
> correcting a post-deployment error.

Actually I know the study by Rational.

> The 3rd we've discussed adequately here, I think.

Yes.

> The 4th showed a factor of 10 improvement in post-deployment errors
> compared to C (and a further factor of 10 improvement of SPARK over
> Ada).


Impressive :-).

> The 5th concluded that Ada was a better 1st-course language than Pascal.

I'm a bit surprised, actually. I would have thought Pascal simpler to
learn.

I'll have to try to find those studies some time in the future and
read up on them. 

Unfortunately, even agreeing Ada is the "better language" in most
aspects as a programming language (and I can imagine a number of
scenarios where some of the Ada stuff really get's in the way and that
is e.g. when I want to write something without the Ada runtime: I can
write a GNU Pascal procedure and link it into a C program, but can I
do that with something compiled by GNAT?), whatever -- even agreeing
Ada is the "better language", I've tried to point out in other posts
(hopefully not all of which went into the black whole) that -- coming
back to the topic of the thread -- real world decisions for tools are
not always influenced by technical merit alone. Availability of
libraries, costs of entering a market, existing code base, available
tools + compilers, flexibility after deciding on certain tools (read
alternative tools and second source vendors) are also important. Some
people here have argued along the line that "people simply don't know
better". I find that difficult to accept.

Regards -- Markus

Re: How come Ada isn't more popular?

[Frank J. Lhota]

"Markus E Leypold" 
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in 
message news:viveito0e5.fsf@hod.lan.m-e-leypold.de...
> Unfortunately, even agreeing Ada is the "better language" in most
> aspects as a programming language (and I can imagine a number of
> scenarios where some of the Ada stuff really get's in the way and that
> is e.g. when I want to write something without the Ada runtime: I can
> write a GNU Pascal procedure and link it into a C program, but can I
> do that with something compiled by GNAT?), whatever -- even agreeing
> Ada is the "better language",
\
Actually, the GCC people have done a really good job of supporting 
multi-language programming. Only the VMS people supported multiple 
high-level languages as well. 

Re: How come Ada isn't more popular?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message >
>
> I'm a bit surprised, actually. I would have thought Pascal simpler to
> learn.
>
It depends on what you want students to learn.   At an equivalent
level to Pascal, Ada is easier to learn primarily due to its improved
consistency of syntax.   At the more advanced level, it is more difficult
because of the difference in design issues.

Ease of learning should not an important factor when considering the
adoption of a programming language.   Python is amazingly easy to
learn.  So is Ruby.  Both are excellent languages. I like them both. Neither
is the right choice for safety-critical embedded systems.

C++ is not easy to learn.   To do C++ safely is really hard to learn. In
this case, it is easier to learn how to safe programming in Ada than in
C++.

Most of the time C++ and Ada are both taught badly.    That can make
them hard to learn.   The most frequently overlooked dimension of Ada
that is misunderstood by those who try to teach it is the scope and
visibility rules.    Yet that, not strong typing, is at the heart of the design
of the language.   It is sad that most instructors who try to teach Ada
don't understand those rules well enough to show how important they
are to being a good Ada programmer/designer.

With Ada, once a someone understands Chapter Eight of the ALRM, the
rest of the language issues fall into place quite easily.

Richard Riehle

Re: How come Ada isn't more popular?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> "Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message >
>>
>> I'm a bit surprised, actually. I would have thought Pascal simpler to
>> learn.
>>

> It depends on what you want students to learn.   At an equivalent
> level to Pascal, Ada is easier to learn primarily due to its improved
> consistency of syntax.   

OK. I never had much issues with the Pascal syntax, but than my memory
might be failing too.

> At the more advanced level, it is more difficult
> because of the difference in design issues.

>
> Ease of learning should not an important factor when considering the
> adoption of a programming language.   

It wasn't me that brought that topic into the discussion. I only
commented as an aside that this finding -- quoted by J R Carter --
surprises me.

> Python is amazingly easy to learn.  So is Ruby.  Both are excellent
> languages. I like them both. Neither is the right choice for
> safety-critical embedded systems.

No, certainly not. But my impression was not that we are discussing
"How come Ada isn't more popular for safety critical embedded system?"
which would be a really small scope indeed, but more "How come Ada
isn't more popular?". Add to that that Ada was originally
proposed/designed to be a general "systems programming language", so
restricting the discussion to "safety-critical embedded systems" would
seem, at least to me, to ditch the issue.

But never mind. If the community could please come forward and say:
Yes Ada is the best language ever (but we are talking ONLY about
safety critical systems), I'd be prepared to accept that statement
:-). 

But then understand 2 things:

 - We shouldn't teach general programming in a fringe language at
   University.

 - The guy asking for the Ada translation of a C algorithm wrote a
   book about "embedded programming". He didn't say "safety
   critical". So the mini-outrage that somebody daring to write about
   embedded programming doesn't know Ada was quite uncalled for, wasn't it.


:-). So what will it be ...?


> C++ is not easy to learn.   To do C++ safely is really hard to learn. In
> this case, it is easier to learn how to safe programming in Ada than in
> C++.

I fully agree with that sentiment (controlling memory is especially
difficult). But usually projects that use C++ for embedded programming
seem only to use a really limited subset, often down to just using
name spaces only because they make modularization a bit easier.

>> Most of the time C++ and Ada are both taught badly.    That can make

Bot. Indeed.

> them hard to learn.   The most frequently overlooked dimension of Ada
> that is misunderstood by those who try to teach it is the scope and
> visibility rules.    Yet that, not strong typing, is at the heart of the design
> of the language.   It is sad that most instructors who try to teach Ada
> don't understand those rules well enough to show how important they
> are to being a good Ada programmer/designer.
>
> With Ada, once a someone understands Chapter Eight of the ALRM, the
> rest of the language issues fall into place quite easily.

Right.

Regards -- Markus (who probably still has not understood everything about Ada :-)

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

adaworks@sbcglobal.net wrote:
>>
> It depends on what you want students to learn.   At an equivalent
> level to Pascal, Ada is easier to learn primarily due to its improved
> consistency of syntax.   At the more advanced level, it is more difficult
> because of the difference in design issues.

Right. When you get into ';' as statement separator, the need for 
begin-end blocks everywhere, the dangling-else problem, and probably a 
couple of others I don't remember right now, the "Pascal subset" of Ada 
is  cleaner and easier to use right than Pascal.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: How come Ada isn't more popular?

[adaworks]

"Jeffrey R. Carter" <jrcarter@acm.org> wrote in message 
news:Ymfuh.321356$FQ1.7034@attbi_s71...
>
> Don't you get logical on me here. I maintain that it is impossible for humans 
> to write safe C. For proof by blatant assertion, see my previous post.
>
I would take issue with your blanket statement even though I am in
general agreement with the foundation that motivates its expression.

Every programming language isbe error-prone at different levels, including
Ada.   The question is how error-prone a language might be.  On a continuum
of more error-prone to less, Ada is at the end of the scale for less error-prone
_____________________________________________________________
More 
Less
Error-prone            ------------------> 
Error-prone

Assembler       C                           C++           Java    C#         Ada 
SPARK
                    COBOL-68       COBOL-85   Objective-C        Eiffel
                                   Early PL/I                        Recent PL/I
______________________________________________________________

A more detailed continuum could be developed that covers more languages.  I only
show a small representation here.

I show Eiffel and Ada at the same place on the continuum.   Many would argue
with this.   I don't think that anyone who knows both Ada and C++ really well
would argue with their relative positioning.   Java is more error-prone than Ada
due some issues with its type model and the preservation of some dangerous
constructs.  C# design improves the dependability of some of those constructs.

As I have often noted in this forum and elsewhere, I often wonder why someone
who chooses to develop software in a language that is error-prone would expect
a software system that is error-free.   Although a language, by itself, cannot
guarantee a system that is error-free, one would expect an outcome that requires
less debugging time and would have fewer defects than with a language that is
error-prone.

While C++ may have some capabilities not found in other languages, it is still
a poor choice for software where dependability is important.   It is not a 
language
well-suited to safety-critical software.   On the other hand, I am impresed with
a lot of the design elements of C#.   It still fall short of being ideal for 
safety-critical
software, but it is an improvement over C++ and Java.

Richard Riehle






 

Re: How come Ada isn't more popular?

[Cesar Rabak]

adaworks@sbcglobal.net escreveu:
> "Jeffrey R. Carter" <jrcarter@acm.org> wrote in message 
> news:Ymfuh.321356$FQ1.7034@attbi_s71...
>> Don't you get logical on me here. I maintain that it is impossible for humans 
>> to write safe C. For proof by blatant assertion, see my previous post.
>>
> I would take issue with your blanket statement even though I am in
> general agreement with the foundation that motivates its expression.
> 
> Every programming language isbe error-prone at different levels, including
> Ada.  

Nice contribution, Richard, but the line wrapping mangled the diagram 
you propose to become almost unintelligible...

Would you mind posting it with the scale top to bottom?

>  The question is how error-prone a language might be.  On a continuum
> of more error-prone to less, Ada is at the end of the scale for less error-prone
> _____________________________________________________________
> More 
> Less
> Error-prone            ------------------> 
> Error-prone
> 
> Assembler       C                           C++           Java    C#         Ada 
> SPARK
>                     COBOL-68       COBOL-85   Objective-C        Eiffel
>                                    Early PL/I                        Recent PL/I
> ______________________________________________________________
> 
> A more detailed continuum could be developed that covers more languages.  I only
> show a small representation here.

I think is already a nice account of languages for this discussion.

> 
> I show Eiffel and Ada at the same place on the continuum.   Many would argue
> with this. 

I don't so I'll follow on.

>  I don't think that anyone who knows both Ada and C++ really well
> would argue with their relative positioning.   Java is more error-prone than Ada
> due some issues with its type model and the preservation of some dangerous
> constructs.  C# design improves the dependability of some of those constructs.

Yes, now if one dares to put this in a two axis space (like the 
'quadrants' certain consulting groups love to publish�) with error 
proneness (or its inverse 'safety'[?]) against 'market push', we'll 
arrive at something with Java and C# on the safer and 'market supported' 
space and then all remains the same in the market :-(

> 
> As I have often noted in this forum and elsewhere, I often wonder why someone
> who chooses to develop software in a language that is error-prone would expect
> a software system that is error-free. 

Because:

>  Although a language, by itself, cannot
> guarantee a system that is error-free, one would expect an outcome that requires
> less debugging time and would have fewer defects than with a language that is
> error-prone.

present beliefs in the SW industry are that the process (CMM sense) is 
what makes SW more reliable or not.

Upper management is used to navigate in the muddy waters of non perfect 
systems: unreliable OSs, virus/worm/trojan threats, so coping with a 
'popular' language is part of the (usual) business.

Another question we tend to forget about C is the formidable ecosystem 
that exists to help companies to get right with lint-like tools, memory 
checkers, etc.

> 
> While C++ may have some capabilities not found in other languages, it is still
> a poor choice for software where dependability is important.   It is not a 
> language
> well-suited to safety-critical software.   On the other hand, I am impresed with
> a lot of the design elements of C#.   It still fall short of being ideal for 
> safety-critical
> software, but it is an improvement over C++ and Java.

Food for thought:

Let's see, if we pick a recent project (Next-Generation James Webb Space 
Telescope) what would be the proposed language by IBM?

Re: How come Ada isn't more popular?

[Markus E Leypold]

Cesar Rabak <csrabak@yahoo.com.br> writes:

> present beliefs in the SW industry are that the process (CMM sense) is
> what makes SW more reliable or not.

Well, that is not completely wrong, you know. Though usually in
practice are code reviews are rarely done, despite the fact that they
are known to be the best instrument for creating code of high quality.


> Upper management is used to navigate in the muddy waters of non
> perfect systems: unreliable OSs, virus/worm/trojan threats, so coping
> with a 'popular' language is part of the (usual) business.

Which just means they recognize the value of the "things that already
exist" oas opposed to "the things that would have yet to be
written". A wise attidute indeed.

> Another question we tend to forget about C is the formidable ecosystem
> that exists to help companies to get right with lint-like tools,
> memory checkers, etc.

Exactly my point. This mitigates the "C is utter s***" judgment a bit.


>> While C++ may have some capabilities not found in other languages,
>> it is still a poor choice for software where dependability is
>> important.  It is not a language well-suited to safety-critical
>> software.  On the other hand, I am impresed with a lot of the
>> design elements of C#.  It still fall short of being ideal for
>> safety-critical software, but it is an improvement over C++ and
>> Java.


> Food for thought:
>
> Let's see, if we pick a recent project (Next-Generation James Webb
> Space Telescope) what would be the proposed language by IBM?

Perhaps mot C#. What do you suggest?

Regards -- Markus

Re: How come Ada isn't more popular?

[Cesar Rabak]

Markus E Leypold escreveu:
> Cesar Rabak <csrabak@yahoo.com.br> writes:
> 
>> present beliefs in the SW industry are that the process (CMM sense) is
>> what makes SW more reliable or not.
> 
> Well, that is not completely wrong, you know. 

Yes I know!

> Though usually in
> practice are code reviews are rarely done, despite the fact that they
> are known to be the best instrument for creating code of high quality.
> 
> 
>> Upper management is used to navigate in the muddy waters of non
>> perfect systems: unreliable OSs, virus/worm/trojan threats, so coping
>> with a 'popular' language is part of the (usual) business.
> 
> Which just means they recognize the value of the "things that already
> exist" oas opposed to "the things that would have yet to be
> written". A wise attidute indeed.

My only issue with this is the lack of a quality metric to ascertain the 
adequateness of the 'thints that already exist'.

> 
>> Another question we tend to forget about C is the formidable ecosystem
>> that exists to help companies to get right with lint-like tools,
>> memory checkers, etc.
> 
> Exactly my point. This mitigates the "C is utter s***" judgment a bit.
> 

I think so, too, and for the worse (at least for me when I try to use 
Ada technology) one can even hear that "...in C the use of these tools 
and their expenditure is at users will...whereas...".

[snipped]

>> Food for thought:
>>
>> Let's see, if we pick a recent project (Next-Generation James Webb
>> Space Telescope) what would be the proposed language by IBM?
> 
> Perhaps mot C#. What do you suggest?

I don't have a clue, but even in the site from Rational (where there is 
mention to other IBM products) there is not a word about Ada...

> 
> Regards -- Markus
> 

Re: How come Ada isn't more popular?

[Markus E Leypold]

Cesar Rabak <csrabak@yahoo.com.br> writes:

> Markus E Leypold escreveu:
>> Cesar Rabak <csrabak@yahoo.com.br> writes:
>>
>>> present beliefs in the SW industry are that the process (CMM sense) is
>>> what makes SW more reliable or not.
>> Well, that is not completely wrong, you know.
>
> Yes I know!
>
>> Though usually in
>> practice are code reviews are rarely done, despite the fact that they
>> are known to be the best instrument for creating code of high quality.
>>
>>> Upper management is used to navigate in the muddy waters of non
>>> perfect systems: unreliable OSs, virus/worm/trojan threats, so coping
>>> with a 'popular' language is part of the (usual) business.
>> Which just means they recognize the value of the "things that already
>> exist" oas opposed to "the things that would have yet to be
>> written". A wise attidute indeed.
>
> My only issue with this is the lack of a quality metric to ascertain
> the adequateness of the 'thints that already exist'.

This is not a question of "quality". It's only a question of "How much
money do I have top spent to recreate those already existing things?"
(Cost C1).

If I'm not going to do that the other question I have to answer (when
shifting to another language / tool set or process) is "How much money
do I have to spent integrate the existing things (process, tools,
code) with the new process / tools /code" (Cost C2)?

Quality only does come in here as C3: The _monetary_ costs (bugs,
maintenance, outright errors) avoided in future by creating better
"things" instead of the existing ones.

Either C1-C3 or C1-C2 is actually a suitable first measure of the
_value_ of the "existing things".

Quality, I insist, has only value as a factor in avoid expensive
failures of the system/programs in the future.  So the value of
quality does depend on context and it's this consideration that is too
often missing from those language advocacy discussions.


>>> Another question we tend to forget about C is the formidable ecosystem
>>> that exists to help companies to get right with lint-like tools,
>>> memory checkers, etc.
>> Exactly my point. This mitigates the "C is utter s***" judgment a
>> bit.
>>
>
> I think so, too, and for the worse (at least for me when I try to use
> Ada technology) one can even hear that "...in C the use of these tools
> and their expenditure is at users will...whereas...".


Yes. But the user's will is exactly what the development process
should be controlling. If we've gone as far as admitting that a proper
development process is necessary for a high quality of the final
product, we can as well go farther and compare not the languages per
se but the languages together with their tools and libraries. In my
opinion that will bring us much nearer to an answer to the question
"Why is Ada not more popular?".

>
> [snipped]
>
>>> Food for thought:
>>>
>>> Let's see, if we pick a recent project (Next-Generation James Webb
>>> Space Telescope) what would be the proposed language by IBM?
>> Perhaps mot C#. What do you suggest?
>
> I don't have a clue, but even in the site from Rational (where there
> is mention to other IBM products) there is not a word about Ada...

Well ...

Regards -- Markus

Re: How come Ada isn't more popular?

[adaworks]

"Cesar Rabak" <csrabak@yahoo.com.br> wrote in message 
news:eplsvd$1uu$1@aioe.org...
>
> I don't have a clue, but even in the site from Rational (where there is 
> mention to other IBM products) there is not a word about Ada...
>
It is really sad that Rational has decided to hide the fact that it was
once an Ada company.   This trend began over ten years ago
when they began to avoid any mention of Ada at trade shows,
in advertisements, and elsewhere.   They still make money from
Ada, but they act as if they are ashamed of having anything to
do with it.

IBM has never been good with Ada.  Rarely did anything they ever did that
involved Ada turned out well.   Their commitment to their own Ada
products was wishy-washy, and their Ada projects never seemed to
get very far.   That being said, even their own language, PL/I has been
allowed to spiral into decline.   It seems that IBM has not programming
language strategy, and Rational has adopted the IBM position with
regard to languages.

When I was active in Ada, up through 2000, there were a fair number
of Rational Ada users.   I wonder if there are any new projects using
Rational Ada.   My guess is, very few.   Rational just does not seem to
be interested in Ada anymore.   I would hope I am wrong about that,
but I suspect I'm not.

Richard Riehle 

Re: How come Ada isn't more popular?

[Jeffrey Creem]

adaworks@sbcglobal.net wrote:
> "Cesar Rabak" <csrabak@yahoo.com.br> wrote in message 
> news:eplsvd$1uu$1@aioe.org...
>> I don't have a clue, but even in the site from Rational (where there is 
>> mention to other IBM products) there is not a word about Ada...
>>
> It is really sad that Rational has decided to hide the fact that it was
> once an Ada company.   This trend began over ten years ago
> when they began to avoid any mention of Ada at trade shows,
> in advertisements, and elsewhere.   They still make money from
> Ada, but they act as if they are ashamed of having anything to
> do with it.
I agree the IBM site is not the easiest to navigate. But really it does 
not seem that hidden.
www.ibm.com, click products, software by category, Software Development, 
traditional programming languages & compilers.
Rational Ada Developer is then on the bottom of the page (In 
alphabetical order) and still above the XC compiler.


I do see what you mean about going down through the www.rational.com 
link. Tools like compilers don't even show up at that level though I 
think that is less about not liking Ada and more about the fact that a 
simple IDE/compiler is not at the same level as the high minded fairly 
useless 'craft you a solution' tools that IBM likes to sell.

AW: How come Ada isn't more popular?

[Grein, Christoph (Fa. ESG)]

>> Ada, but they act as if they are ashamed of having anything to
>> do with it.
> I agree the IBM site is not the easiest to navigate. But really it
does 
> not seem that hidden.
> www.ibm.com, click products, software by category, Software
Development, 
> traditional programming languages & compilers.
> Rational Ada Developer is then on the bottom of the page (In 
> alphabetical order) and still above the XC compiler.

But if you're looking for Ada, you wouldn't expect it under R, would
you?

Re: AW: How come Ada isn't more popular?

[Martin Krischik]

Grein, Christoph (Fa. ESG) wrote:

> 
>>> Ada, but they act as if they are ashamed of having anything to
>>> do with it.
>> I agree the IBM site is not the easiest to navigate. But really it
> does
>> not seem that hidden.
>> www.ibm.com, click products, software by category, Software
> Development,
>> traditional programming languages & compilers.
>> Rational Ada Developer is then on the bottom of the page (In
>> alphabetical order) and still above the XC compiler.
> 
> But if you're looking for Ada, you wouldn't expect it under R, would
> you?

More intersting: Click on "How to Buy"!

No price quoted
No online order
No selling to the general pubic

That is my impression. It might have missed something, I might be mistaken
but for answering "How come Ada isn't more popular" impression is all that
counts.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: How come Ada isn't more popular?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> As I have often noted in this forum and elsewhere, I often wonder why someone
> who chooses to develop software in a language that is error-prone would expect
> a software system that is error-free.   

But I think that "they" don't expect a software system that is error
free. Generally the probability of errors is just one factor
contributing to the overall cost of a project. Other factors are the
cost of having to re-implement already existing libraries or software,
the cost of having to maintain teams for more than one language,
support fees for tools, the cost of not having some tools for this
language, the cost of hiring for "unusual" languages, the cost of not
having a garbage collection etc.

I think that it is this point of view that makes decisions against Ada
for some other language at least understandable, even if you would
have decided differently. 

As I have said repeatedly (probably in in those posts lost to the
black hole) the decision against Ada is perhaps something you can
lament, but to call it irrational is, IMHO, irrational. One has to
understand the motives of other peoples decision to be able to
influence them. Of course calling them just ill-informed (as some post
in this thread do, not necessarily yours) helps to feel secure in ones
own position, but it doesn't help towards changing other peoples
position.

> Although a language, by itself, cannot guarantee a system that is
> error-free, one would expect an outcome that requires less debugging
> time and would have fewer defects than with a language that is
> error-prone.

Language is only one factor from many that influence the "bug" rate in
the final product. The bug rate on the other side is only one if many
factors that make up the overall cost.

I'm not surprised that "error proneness" doesn't prove to be the final
decisive argument in the favor of some language in all not even in the
majority of cases. 

It is just the economy of software development and the customers
priorities 

   (hello you people here using Word -- why don't you use TeX which
   _definitely_ has less bugs? -- see what I mean?)

which decide on
which kind of development is finally paid for. See the state of Ada as
a summary of the state of demand by the market for certain software
attributes.


> While C++ may have some capabilities not found in other languages, it is still
> a poor choice for software where dependability is important.   

Exactly: "Where dependability is important". Which is not in consumer
software, most embedded software (who cares if MP3 players or mobiles
crashes now and than) etc. 


> It is not a language well-suited to safety-critical software.  On
> the other hand, I am impressed with a lot of the design elements of
> C#.  It still fall short of being ideal for safety-critical
> software, but it is an improvement over C++ and Java.

Exactly. Which will make it (as much as I'm sorry to condone anything
Microsoft had their grubby hands in) probably one of the languages for
the future as far as consumer software, ticket vending machines, etc. 


Regards -- Markus


PS: You didn't, I think, answer my question, why you don't think Java is type safe ... ?

Re: How come Ada isn't more popular?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:ogy7nmsrog.fsf@hod.lan.m-e-leypold.de...
>
> PS: You didn't, I think, answer my question, why you don't think Java is type 
> safe ... ?
>
To start with, I don't like type promotion.

More later.

Richard 

Re: How come Ada isn't more popular?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> "Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:ogy7nmsrog.fsf@hod.lan.m-e-leypold.de...
>>
>> PS: You didn't, I think, answer my question, why you don't think Java is type 
>> safe ... ?
>>
> To start with, I don't like type promotion.
>
> More later.

Yes, please continue. 

Type promotion is annoying with regard to the readers ability to
easily see the semantic of the programm, but it's IMHO not type unsafe
in the sense of the definition given in Cardelli's paper, because it
doesn't break the abstraction of the represention of the program and
its values by the underlying "machine level stuff" (i.e. VM or CPU
instructions and machine words). Again I hope that sentence is
understandable, if not I'll be glad to elaborate :-).

Regards -- Markus

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

adaworks@sbcglobal.net wrote:
> 
> Every programming language isbe error-prone at different levels, including
> Ada.   The question is how error-prone a language might be.  On a continuum
> of more error-prone to less, Ada is at the end of the scale for less error-prone
> _____________________________________________________________
> More 
> Less
> Error-prone            ------------------> 
> Error-prone
> 
> Assembler       C                           C++           Java    C#         Ada 
> SPARK
>                     COBOL-68       COBOL-85   Objective-C        Eiffel
>                                    Early PL/I                        Recent PL/I
> ______________________________________________________________

Nice concept. Not a very good presentation on my newsreader. Maybe a 
vertical orientation would be better.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: How come Ada isn't more popular?

[Randy Brukardt]

"Jeffrey R. Carter" <jrcarter@acm.org> wrote in message
news:HIbvh.370756$1i1.249719@attbi_s72...
> adaworks@sbcglobal.net wrote:
> >
> > Every programming language isbe error-prone at different levels,
including
> > Ada.   The question is how error-prone a language might be.  On a
continuum
> > of more error-prone to less, Ada is at the end of the scale for less
error-prone
> > _____________________________________________________________
> > More
> > Less
> > Error-prone            ------------------>
> > Error-prone
> >
> > Assembler       C                           C++           Java    C#
Ada
> > SPARK
> >                     COBOL-68       COBOL-85   Objective-C        Eiffel
> >                                    Early PL/I
Recent PL/I
> > ______________________________________________________________
>
> Nice concept. Not a very good presentation on my newsreader. Maybe a
> vertical orientation would be better.

Richard needs a blog or other website for his pithy discussions of Ada and
programming. (Indeed, I tried to talk him into doing that some years ago.)
Plain text isn't the best format for his work.

                          Randy.

Re: How come Ada isn't more popular?

[Harald Korneliussen]

On 26 Jan, 00:26, Markus E Leypold
<development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote:
> "Jeffrey R. Carter" <jrcar...@acm.org> writes:

> Since I assume that the same thing (unsafe programs) applies to Ada
> (say with respect to unhandled exceptions (Ariane, for instance ...)
> or with respect to memory leaks or priority inversions in tasking),
> the only remaining line on which an argument of the usability of C
> vs. that of Ada can develop is quantitatively, not qualitatively.
>
A line is usually drawn at languages whose type systems (and possibly
inserted runtime checks) don't prevent invalid memory accesses. For
instance the paper linked to above, about type systems, draws this
line, and argues why it matters. Great paper, by the way.

Re: How come Ada isn't more popular?

[Harald Korneliussen]

On 25 Jan, 23:36, "Jeffrey R. Carter" <jrcar...@acm.org> wrote:
> The only safe use of C is as a target language for code generators (such
> as the SofCheck Ada -> C compiler). The continuing creation of
> buffer-overflow errors in C shows that, in practice, it is impossible
> for humans to create safe C.
>
Not to promote C myself, but there exist tools which may be useful.
Run-time checking such as can be achieved with profilers and
malloc-replacements don't cut it, IMO, since they only find errors in
the most trodden paths of the program. Static analysers, like the one
promoted by Coverity, now there's something valuable. Aslo,
annotation-based analyzers like splint can probably make programs as
safe as Ada if the developers actually take the time to use them.
Another interesting approach is that taken by CCured, of transforming C
programs by classifying pointers according to usage, and then inserting
run-time checks to guarantee no access violations of memory corruption.
These are interesting, practical approaches for those of us who have to
maintain C code. The downside is that the further your program strays
from ansi C (not to say into C++!), the less tools are available.

Re: How come Ada isn't more popular?

[Charles D Hixson]

Harald Korneliussen wrote:
> 
> On 25 Jan, 09:37, Maciej Sobczak <no.s...@no.spam.com> wrote:
>> Markus E Leypold wrote:
>> ...
> 
> ...
> Anyway, I think individuals are less important than culture. You could
> read this straight out of the wikipedia page for C (until I changed it
> slightly ...): "the safe, effective use of C requires more programmer
> skill, experience, effort, and attention to detail than is required for
> some other programming languages." So if you use C, that means you are
> skilled, experienced and attentive, by some people's logic. It's a
> macho thing, "If you can't handle the power, don't use it!".
> 
> Klingon programmers if there ever were any.
> 
> It's of course a symptom of lack of professionalism: construction
> workers who are proud of what they do wear their helmets.
> 
I think you picked up the right reason by the wrong handle.  C 
was the language of Dec computers, and of Kernighan and 
Ritchie, so everyone associated with Unix started using C.  So 
everyone associated with Unix and Linux uses C.  It's more 
historic than anything else.

Re: How come Ada isn't more popular?

[Cesar Rabak]

Tero Koskinen escreveu:
> Hi,
> 
> On 22 Jan 2007 21:53:32 -0800 artifact.one@googlemail.com wrote:
>> My question is: how come Ada isn't more popular?
>>
> 
> I would like to throw in yet another possible reason(*) for Ada being
> not popular (within the free software folks).

As a lot of interesting and complete info already has been posted here, 
my humble contribution on Tero's view:

> 
> Currently, the only non-restricted free Ada compiler is FSF GCC/GNAT.
> However, the GCC development team doesn't consider Ada to be
> a release critical language, so it gets less love whenever a new GCC
> is released and its quality is sometimes lower than C and C++ parts
> of GCC. In addition, Ada part of GCC supports far less platforms than
> C and C++ parts. (**)
[snipped]

FSF actually in their site 
http://www.gnu.org/prep/standards/standards.html#Design-Advice 
explicitly recommends use of C language as *the* language for FSF Open 
Source projects.

All other factors withstanding, they got clout in their realm.

--
Cesar Rabak

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

artifact.one@googlemail.com wrote:
> 
> My question is: how come Ada isn't more popular?

Much of what others have posted is good, but I also see:

Most developers (98% in my experience) are coders. Coders like languages 
like C that let them  code. Then then enjoy spending more time debugging 
then they did coding.

The other 2% are SW engineers. They like languages like Ada.

Obviously, C and its ilk are going to be more popular than Ada.

Re: How come Ada isn't more popular?

[adaworks]

"Jeffrey R. Carter" <jrcarter@acm.org> wrote in message 
news:fRtth.363405$1i1.178883@attbi_s72...
> artifact.one@googlemail.com wrote:
>
> Most developers (98% in my experience) are coders. Coders like languages like 
> C that let them  code. Then then enjoy spending more time debugging then they 
> did coding.
>
> The other 2% are SW engineers. They like languages like Ada.
>
> Obviously, C and its ilk are going to be more popular than Ada.
>
Fast-food joints are more popular than regular restaurants.   Ada is
the equivalent of a nourishing meal rather than a greasy burger.  C++
is the equivalent of peanut-brittle.  It tastes good at first, then it gets
stuck in your teeth, and then it causes your molars to decay.

Richard Riehle 

Re: How come Ada isn't more popular?

[Alex R. Mosteo]

Jeffrey R. Carter wrote:

> artifact.one@googlemail.com wrote:
>> 
>> My question is: how come Ada isn't more popular?
> 
> Much of what others have posted is good, but I also see:
> 
> Most developers (98% in my experience) are coders. Coders like languages
> like C that let them  code. Then then enjoy spending more time debugging
> then they did coding.
> 
> The other 2% are SW engineers. They like languages like Ada.
> 
> Obviously, C and its ilk are going to be more popular than Ada.

Perhaps we could run an informal poll to see the background of Ada people
here.

Re: Poll on background of Ada people (was: How come Ada isn't more po)

[Larry Kilgallen]

In article <51p863F1k9di7U2@mid.individual.net>, "Alex R. Mosteo" <devnull@mailinator.com> writes:

> Perhaps we could run an informal poll to see the background of Ada people
> here.

(in reverse order) Pascal, Bliss, various assembly languages.

Re: How come Ada isn't more popular?

[kevin cline]

artifact.one@googlemail.com wrote:
> Hello.
>
> I am a long time C programmer (10 years plus), having a look
> at Ada for the first time. From my (inadequate) testing, it seems
> that performance of average Ada code is on par with average
> C code, and there's a clear advantage in runtime safety. The
> GNU ada compiler makes pretty sure that there are very few
> platforms without easy access to Ada, so portability should be
> on at least an equal footing too.
>
> My question is: how come Ada isn't more popular?

1. Ada-83 simply sucked.  Expensive, inexpressive, with poor libraries
and no support for writing desktop applications.  Ada-83 was designed
for embedded development, and was OK for that purpose, but it was
hopeless for writing hosted applications.

2. For the same reason that Esperanto isn't more popular.  Ada was
designed by a committee to meet theroetical needs.  Most popular
languages have evolved to meet practical needs.  They grew from humble
beginnings to widespread acceptance.  Theoretically, they may be
abominations, but they get the job done.

3. For the same reason that Limburger cheese isn't more popular.  Most
programmers who have tried Ada didn't like it.  What makes a programmer
like a new language?  Usually, someone comes along and says something
like "Remember that program that we spent two weeks writing in C?
Here's a Perl implementation that I put together in three hours and
one-tenth the code."  That's never happened with Ada.



>
> This isn't intended to start a flame war, I'm genuinely interested.
> 
> thanks,
> MC

Re: How come Ada isn't more popular?

[Martin Dowie]

kevin cline wrote:
> 3. For the same reason that Limburger cheese isn't more popular.  Most
> programmers who have tried Ada didn't like it.  What makes a programmer
> like a new language?  Usually, someone comes along and says something
> like "Remember that program that we spent two weeks writing in C?
> Here's a Perl implementation that I put together in three hours and
> one-tenth the code."  That's never happened with Ada.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

FUD!!

http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html

Re: How come Ada isn't more popular?

[Alexander E. Kopilovich]

Martin Dowie wrote:

>>  What makes a programmer
>> like a new language?  Usually, someone comes along and says something
>> like "Remember that program that we spent two weeks writing in C?
>> Here's a Perl implementation that I put together in three hours and
>> one-tenth the code."  That's never happened with Ada.
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>FUD!!
>
>http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html

Is FUD a reserved word in Ada?

By the way, I think that the referenced (by above URL) article does not
contradict the apparently contested (under-marked) sentence, because
circumstances are far too different in several important aspects.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Alexander E. Kopilovich wrote:
> 
> By the way, I think that the referenced (by above URL) article does not
> contradict the apparently contested (under-marked) sentence, because
> circumstances are far too different in several important aspects.

Could you elaborate? It seemed pretty close to a controlled experiment 
to me. The students were not specially selected; the problem was the 
same; only the language and amount of solution made available to the 
students changed.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: How come Ada isn't more popular?

[Alexander E. Kopilovich]

Jeffrey R. Carter wrote:

>> By the way, I think that the referenced (by above URL) article does not
>> contradict the apparently contested (under-marked) sentence, because
>> circumstances are far too different in several important aspects.
>
>Could you elaborate? It seemed pretty close to a controlled experiment 
>to me. The students were not specially selected; the problem was the 
>same; only the language and amount of solution made available to the 
>students changed.

The original statement (from kevin cline) was:

>>>  What makes a programmer
>>> like a new language?  Usually, someone comes along and says something
>>> like "Remember that program that we spent two weeks writing in C?
>>> Here's a Perl implementation that I put together in three hours and
>>> one-tenth the code."  That's never happened with Ada.

The article http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
presents the case where use of Ada language in very specific circumstances
was much more effective than use of C language in the same circumstances.

Those circumstances include:

1) close support provided by teaching staff
2) full and precise spefications for the problem domain
3) stable general requirements for the task and at the same time relative
   freedom regarding details, and anyway, the absence of a stream of
   unexpected changes in requirements and/or scope and/or additional
   requirements

Compare these circumstances with those implied in the original statement
(quoted above). The latter certainly imply absence of condition 1 (permanent
close support), and also, the freedom of choice of a programming language
(or even an opportunity of discussion about that) very rarely comes to
programmers together with conditions 2 and 3.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Alexander E. Kopilovich wrote:
> 
> The original statement (from kevin cline) was:
> 
>>>>  What makes a programmer
>>>> like a new language?  Usually, someone comes along and says something
>>>> like "Remember that program that we spent two weeks writing in C?
>>>> Here's a Perl implementation that I put together in three hours and
>>>> one-tenth the code."  That's never happened with Ada.
> 
> The article http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
> presents the case where use of Ada language in very specific circumstances
> was much more effective than use of C language in the same circumstances.

The circumstances differed in this respect: The C students were given 
60% of the teacher's solution. Initially, the Ada students were given 
10% (or maybe less).

> Those circumstances include:
> 
> 1) close support provided by teaching staff
> 2) full and precise spefications for the problem domain
> 3) stable general requirements for the task and at the same time relative
>    freedom regarding details, and anyway, the absence of a stream of
>    unexpected changes in requirements and/or scope and/or additional
>    requirements

I agree that 1. doesn't apply to the OP's statement. However, I consider 
a running program to be a very precise and stable specification, so 2. 
and 3. appear to apply. And it's definitely a case of "Remember that 
program you couldn't get working in C in an entire semester even though 
you were given 60% of the code? Here's an Ada implementation that I got 
working in a semester when given 10% of the code."

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: How come Ada isn't more popular?

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Alexander E. Kopilovich wrote:
>> The original statement (from kevin cline) was:
>>
>>>>>  What makes a programmer
>>>>> like a new language?  Usually, someone comes along and says something
>>>>> like "Remember that program that we spent two weeks writing in C?
>>>>> Here's a Perl implementation that I put together in three hours and
>>>>> one-tenth the code."  That's never happened with Ada.
>> The article
>> http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
>> presents the case where use of Ada language in very specific circumstances
>> was much more effective than use of C language in the same circumstances.
>
> The circumstances differed in this respect: The C students were given
> 60% of the teacher's solution. Initially, the Ada students were given
> 10% (or maybe less).

So it was not really a comparable situation. One might argue that
already given partial solutions demotivate and that they have dangers
of its own (often draw people on a wrong path of thinking). I've
actually seen people given a partial solution perfoming worse than
those who had to do without.

Mind you, I do not suggest that really is the reason for the
differences found (I haven't even read the study yet), but I see a
problem with a study where the 2 groups compared are not really
starting from the same point. The only different factor should be the
programming language, not the rest of the setup.

Regards -- Markus

AW: How come Ada isn't more popular?

[Grein, Christoph (Fa. ESG)]

Von: comp.lang.ada-bounces@ada-france.org
[mailto:comp.lang.ada-bounces@ada-france.org] Im Auftrag von Markus E
Leypold

>> The circumstances differed in this respect: The C students were given
>> 60% of the teacher's solution. Initially, the Ada students were given
>> 10% (or maybe less).

> So it was not really a comparable situation. One might argue that
> already given partial solutions demotivate and that they have dangers
> of its own (often draw people on a wrong path of thinking). I've
> actually seen people given a partial solution perfoming worse than
> those who had to do without.

> ... (I haven't even read the study yet), but ...

You really should have looked before commenting... :-(

Fact is: The students were not able to finish the job, so they were
given more and more source. And even with 60%, they were still not able.

With Ada, the situation changed. Disaster was expected, but to the big
surprise the students finished the work with only 10% code given.

Re: AW: How come Ada isn't more popular?

[Markus E Leypold]

"Grein, Christoph (Fa. ESG)" <Christoph.Grein@eurocopter.com> writes:

> Von: comp.lang.ada-bounces@ada-france.org
> [mailto:comp.lang.ada-bounces@ada-france.org] Im Auftrag von Markus E
> Leypold
>
>>> The circumstances differed in this respect: The C students were given
>>> 60% of the teacher's solution. Initially, the Ada students were given
>>> 10% (or maybe less).
>
>> So it was not really a comparable situation. One might argue that
>> already given partial solutions demotivate and that they have dangers
>> of its own (often draw people on a wrong path of thinking). I've
>> actually seen people given a partial solution perfoming worse than
>> those who had to do without.
>
>> ... (I haven't even read the study yet), but ...
>
> You really should have looked before commenting... :-(

Yes, yes.

>
> Fact is: The students were not able to finish the job, so they were
> given more and more source. And even with 60%, they were still not able.

See my comment on the helpfullness of help in another articel. I've
only been trying to put forward a general point of view on the idea
that more help brings the students nearer to success in any case. 

Regards -- Markus

AW: AW: How come Ada isn't more popular?

[Grein, Christoph (Fa. ESG)]

Markus E Leypold wrote:
>> Fact is: The students were not able to finish the job, so they were
>> given more and more source. And even with 60%, they were still not able.

> See my comment on the helpfullness of help in another articel. I've
> only been trying to put forward a general point of view on the idea
> that more help brings the students nearer to success in any case. 

You're absolutely correct on this, no help and also more help up to 60% did not help the students finish their work in C.

On the other hand, using Ada they were able to finish. This is the very definite result of the study - contrary to what was expected by the instructor.

(Wannst 'as g'lesen hättst, dadst ned so daherredn :-)

Re: AW: AW: How come Ada isn't more popular?

[Markus E Leypold]

"Grein, Christoph (Fa. ESG)" <Christoph.Grein@eurocopter.com> writes:

> Markus E Leypold wrote:

>>> Fact is: The students were not able to finish the job, so they were
>>> given more and more source. And even with 60%, they were still not able.
>
>> See my comment on the helpfullness of help in another articel. I've

Wow, I hate to see the number of spelling errors NNTP introduces in my
articles every time. I swear they were word perfect when they left my
news reader. I swear!!!

(Note to self: Never forget to use flyspell-mode ...)


>> only been trying to put forward a general point of view on the idea
>> that more help brings the students nearer to success in any case. 

> You're absolutely correct on this, no help and also more help up to
> 60% did not help the students finish their work in C.
>
> On the other hand, using Ada they were able to finish. This is the
> very definite result of the study - contrary to what was expected by
> the instructor.


> (Wannst 'as g'lesen h�ttst, dadst ned so daherredn :-)

I definitely should read the study. As I said: Not now. I can't
continue to discuss on this branch any more for lack of having done my
homework :-). So please excuse this student here. 

My other arguments, that suitability of language is only a small
factor in the decision for a certain language / development system and
the final quality of the system delivered, still stands. Yes I'd wish
Linux was written in Ada, and yes I'd wish people would use Ada
instead of C. But I also would wish to be a bit more independent from
the vagaries of AdaCore and that there would be more incentive or will
to actually release a high quality free compiler (with a GMGPL
runtime, mind you). Etc. Never mind.

Regards -- Markus

Re: How come Ada isn't more popular?

[Ludovic Brenta]

Markus E Leypold writes:
> "Jeffrey R. Carter" writes:
>
>> Alexander E. Kopilovich wrote:
>>> The original statement (from kevin cline) was:
>>>
>>>>>>  What makes a programmer
>>>>>> like a new language?  Usually, someone comes along and says something
>>>>>> like "Remember that program that we spent two weeks writing in C?
>>>>>> Here's a Perl implementation that I put together in three hours and
>>>>>> one-tenth the code."  That's never happened with Ada.
>>> The article
>>> http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
>>> presents the case where use of Ada language in very specific circumstances
>>> was much more effective than use of C language in the same circumstances.
>>
>> The circumstances differed in this respect: The C students were given
>> 60% of the teacher's solution. Initially, the Ada students were given
>> 10% (or maybe less).
>
> So it was not really a comparable situation. One might argue that
> already given partial solutions demotivate and that they have dangers
> of its own (often draw people on a wrong path of thinking). I've
> actually seen people given a partial solution perfoming worse than
> those who had to do without.

In the first years of the course, students started with 0% of the code
given to them, and the instructor started giving them parts of the
solution, gradually increasing to 60% over the years, only because all
students failed to complete the assignment.  So, your argument about
motivation does not hold.

> Mind you, I do not suggest that really is the reason for the
> differences found (I haven't even read the study yet), but I see a
> problem with a study where the 2 groups compared are not really
> starting from the same point. The only different factor should be the
> programming language, not the rest of the setup.

After you read the report, you will find that that was indeed the
case.  It is premature to comment before you read the report.

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Markus E Leypold writes:
>> "Jeffrey R. Carter" writes:
>>
>>> Alexander E. Kopilovich wrote:
>>>> The original statement (from kevin cline) was:
>>>>
>>>>>>>  What makes a programmer
>>>>>>> like a new language?  Usually, someone comes along and says something
>>>>>>> like "Remember that program that we spent two weeks writing in C?
>>>>>>> Here's a Perl implementation that I put together in three hours and
>>>>>>> one-tenth the code."  That's never happened with Ada.
>>>> The article
>>>> http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
>>>> presents the case where use of Ada language in very specific circumstances
>>>> was much more effective than use of C language in the same circumstances.
>>>
>>> The circumstances differed in this respect: The C students were given
>>> 60% of the teacher's solution. Initially, the Ada students were given
>>> 10% (or maybe less).
>>
>> So it was not really a comparable situation. One might argue that
>> already given partial solutions demotivate and that they have dangers
>> of its own (often draw people on a wrong path of thinking). I've
>> actually seen people given a partial solution perfoming worse than
>> those who had to do without.
>
> In the first years of the course, students started with 0% of the code
> given to them, and the instructor started giving them parts of the
> solution, gradually increasing to 60% over the years, only because all
> students failed to complete the assignment.  So, your argument about
> motivation does not hold.

OK. This was not intended as an argument really (I didn't read the
paper) but rather as food for thought. I've seen beginners playing GO
(a board game) worse when they got more tokens head start (which is
supposes to help beginners and level the playing field with a more
advanced partner). My theory was that this is because they do not know
how to use the advance tokens properly and get side tracked into a
less than optimal game. Suggestion was, that the same might have
applied here to a ceratin degree: Given parts of the solution might
keep people from finding their own and tied up in efforts to fit their
probably different approach to the pieces they got.

Again: I do not seriously put that forward as an argument in the given
study, since I haven't read it. But my experiance is, that help is not
always helping, so that should be well controlled factor in a study
and arguments of the kind "they got helped more and did come less far"
are flawed as a general approach because the help could have been well
the factor hindering them.

>
>> Mind you, I do not suggest that really is the reason for the
>> differences found (I haven't even read the study yet), but I see a
>> problem with a study where the 2 groups compared are not really
>> starting from the same point. The only different factor should be the
>> programming language, not the rest of the setup.

> After you read the report, you will find that that was indeed the
> case.  It is premature to comment before you read the report.

OK. Some time soon I'll read it. I find the different amount of "help"
they got still irritating.

Regards -- Markus

Re: How come Ada isn't more popular?

[Alexander E. Kopilovich]

Jeffrey R. Carter wrote:
 
>> The original statement (from kevin cline) was:
>> 
>>>>>  What makes a programmer
>>>>> like a new language?  Usually, someone comes along and says something
>>>>> like "Remember that program that we spent two weeks writing in C?
>>>>> Here's a Perl implementation that I put together in three hours and
>>>>> one-tenth the code."  That's never happened with Ada.
>> 
>> The article http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
>> presents the case where use of Ada language in very specific circumstances
>> was much more effective than use of C language in the same circumstances.
>
>...
>
>> Those circumstances include:
>> 
>> 1) close support provided by teaching staff
>> 2) full and precise spefications for the problem domain
>> 3) stable general requirements for the task and at the same time relative
>>    freedom regarding details, and anyway, the absence of a stream of
>>    unexpected changes in requirements and/or scope and/or additional
>>    requirements
>
>I agree that 1. doesn't apply to the OP's statement. However, I consider 
>a running program to be a very precise and stable specification, so 2. 
>and 3. appear to apply.

Well, of course, after the program is completed and accepted then it 
represents a kind of precise specification. But in the case described in
the article those full specifications was known in advance, which, generally
(for common programmer) does not happen very often.

When, in the original statement, the teller points at particular program,
he certainly means that the information probably will be relevant not just
to that particular program, but to some wide class of programs, and it is
quite possible that many programs in this class have only partial and vague
specifications at the start of their development. 

> And it's definitely a case of "Remember that 
>program you couldn't get working in C in an entire semester even though 
>you were given 60% of the code? Here's an Ada implementation that I got 
>working in a semester when given 10% of the code."

Still note, that it was the teacher of the course making his comparative
conclusion to the readers of professional journal, and not one of his students
to another student. Actually that article does not mention any opportunity
for those students to make that comparison among themselves.

Therefore it is not exactly the case described in original statement, but
rather somehow similar case, no more than that. There is a teacher telling
another teachers (or project leaders or managers) how he, by switching to Ada,
enabled his students to do things which were too hard for them with C.
Consequently (and in full agreement with the original statement) this article
may contribute to Ada popularity among teachers, software development managers
or, perhaps, project leaders - but it is not the audience implied in the
original statement.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Martin Dowie wrote:
> 
> FUD!!

The whole post is FUD. It's an obvious troll, full of outright lies, and 
hardly worth the effort of a reply.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: How come Ada isn't more popular?

[kevin cline]

On Jan 23, 4:18 pm, Martin Dowie <martin.do...@btopenworld.remove.com>
wrote:
> kevin clinewrote:
> > 3. For the same reason that Limburger cheese isn't more popular.  Most
> > programmers who have tried Ada didn't like it.  What makes a programmer
> > like a new language?  Usually, someone comes along and says something
> > like "Remember that program that we spent two weeks writing in C?
> > Here's a Perl implementation that I put together in three hours and
> > one-tenth the code."  That's never happened with Ada.                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> FUD!!
>
> http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html

Yes, I've read that article.  It would really be sad if Ada were not
superior to C for a toy problem in embedded control system development,
since Ada was designed specifically for that purpose.  But the point
was that expressiveness drives programmers to new languages, and Ada
isn't particularly expressive.

Re: How come Ada isn't more popular?

[Ludovic Brenta]

kevin  cline writes:
> But the point was that expressiveness drives programmers to new
> languages, and Ada isn't particularly expressive.

On the contrary, I think that Ada is the most expressive language
around.  Consider:

procedure Set_Bit_In_Register (At_Address : in System.Address) is
   type Register is array (1 .. 32) of Boolean;
   pragma Pack (Register);
   for Register'Bit_Order use System.High_Order_First;
   pragma Volatile (Register);
   
   R : Register;
   for R'Address use At_Address;
begin
   Register (4) := True;
end;

versus

void set_bit_in_register (volatile unsigned long * at_address)
{
   *at_address |= 2 << 3;
}

The Ada version makes many more things explicit, that are assumed and
implicit in C; for example, the size of the register, the fact that
the parameter is an address and not a pointer (*), the endianness, and
which bit is being set.  As 64-bit architectures become prevalent, the
hidden assumption that C's "unsigned long" is 32 bits wide is more and
more likely to be incorrect.

(*) consider that when we increment the address by one, it then
references the next byte; whereas if we increment the pointer by one,
it points to the next "unsigned long", i.e. 2, 4 or 8 bytes and not 1
byte further.  C makes no distinction between addresses and pointers,
lacking expressiveness in a crucial area.

When calling the subprogram, we get:

Set_Bit_In_Register (At_Address => To_Address (16#DEADBEEF#));

versus

set_bit_in_register (0xDEADBEEF);

Again, at the call site, the Ada version gives more information to the
human programmer, i.e. is more expressive.

Expressiveness is not to be confused with conciseness.

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Hi Ludovic,

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> kevin  cline writes:
>> But the point was that expressiveness drives programmers to new
>> languages, and Ada isn't particularly expressive.
>
> On the contrary, I think that Ada is the most expressive language
> around.  

If I were in the business of language advocacy as some people in this
thread obviously are, I'd now cry: "FUD!!"

Anyway, I have to contradict. You'd have to restrict the scope
of your statement a bit (to a special application area or a specific
subset of all programming languages) for it to become true.

I stipulate that languages with a Hindley-Milner type system and/or
functional languages are, in many aspects, more expressive. Even more
so, if they have modules, functors and classes (like OCaml) does.

Or consider Haskell which is a VERY expressive language.

Of course it all depends a bit on how you define "expressiveness".

I do not want to denigrate Ada here. But I think judging the place of
Ada in the world right is more important (or useful to Ada or the
community) than claming ALL the superlatives for Ada.


> procedure Set_Bit_In_Register (At_Address : in System.Address) is
>    type Register is array (1 .. 32) of Boolean;
>    pragma Pack (Register);
>    for Register'Bit_Order use System.High_Order_First;
>    pragma Volatile (Register);
>    
>    R : Register;
>    for R'Address use At_Address;
> begin
>    Register (4) := True;
> end;
>
> versus
>
> void set_bit_in_register (volatile unsigned long * at_address)
> {
>    *at_address |= 2 << 3;
> }


<cynical mode>

You're sure you're not confusing verbosity with "expressiveness"? :-)

</cynical mode>


Regards -- Markus

Re: How come Ada isn't more popular?

[Ludovic Brenta]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Hi Ludovic,
>
> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
>> kevin  cline writes:
>>> But the point was that expressiveness drives programmers to new
>>> languages, and Ada isn't particularly expressive.
>>
>> On the contrary, I think that Ada is the most expressive language
>> around.  
>
> If I were in the business of language advocacy as some people in this
> thread obviously are, I'd now cry: "FUD!!"
[...]
> I do not want to denigrate Ada here. But I think judging the place of
> Ada in the world right is more important (or useful to Ada or the
> community) than claming ALL the superlatives for Ada.

OK, I'll take back what I said above, and replace with "Ada is the
most expressive language I know of."  I can't comment on Haskell or
OCaml because I don't know them well enough.

>> procedure Set_Bit_In_Register (At_Address : in System.Address) is
>>    type Register is array (1 .. 32) of Boolean;
>>    pragma Pack (Register);
>>    for Register'Bit_Order use System.High_Order_First;
>>    pragma Volatile (Register);
>>    
>>    R : Register;
>>    for R'Address use At_Address;
>> begin
>>    Register (4) := True;
>> end;
>>
>> versus
>>
>> void set_bit_in_register (volatile unsigned long * at_address)
>> {
>>    *at_address |= 2 << 3;
>> }
>
> <cynical mode>
> You're sure you're not confusing verbosity with "expressiveness"? :-)
> </cynical mode>

No, but there is bound to be some correlation.  Expressiveness is the
ability to carry a lot of information across to the human programmer
as well as to the compiler.  Verbosity, or its opposite conciseness,
is the density of that information, as in "information units per line
of code" or some such ill-defined measure.

Ada is more expressive than C because it allows programmes to express
more information.  In a way, it is also more concise in that Ada
compilers insert all sorts of implicit checks, and in that Ada has
built-in constructs like tasking, array slices and return of
dynamically-sized objects that require much more lines of code to
achieve in C.

But C more concise than Ada in other ways; for example "volatile
unsigned long *" does not require a separate type definition, and "{}"
takes only 11.765% of the space of "begin; null; end;"

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Markus E Leypold]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Hi Ludovic,
>>
>> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>>
>>> kevin  cline writes:
>>>> But the point was that expressiveness drives programmers to new
>>>> languages, and Ada isn't particularly expressive.
>>>
>>> On the contrary, I think that Ada is the most expressive language
>>> around.  
>>
>> If I were in the business of language advocacy as some people in this
>> thread obviously are, I'd now cry: "FUD!!"
> [...]
>> I do not want to denigrate Ada here. But I think judging the place of
>> Ada in the world right is more important (or useful to Ada or the
>> community) than claming ALL the superlatives for Ada.
>
> OK, I'll take back what I said above, and replace with "Ada is the
> most expressive language I know of."  I can't comment on Haskell or
> OCaml because I don't know them well enough.

Fine. I agree it's the most expressive one of the "classic" imperative
Familie, under which I count FORTRAN, C, C++, Modula, Pascal and so on
(forgive me, there is a similarity, so I think it makes sense for a
rough classification to put all those languages into a big
super-family, as opposed to in example the more or less functional
languages from LISP to Haskell).


>>
>> <cynical mode>
>> You're sure you're not confusing verbosity with "expressiveness"? :-)
>> </cynical mode>
>
> No, but there is bound to be some correlation.  Expressiveness is the
> ability to carry a lot of information across to the human programmer
> as well as to the compiler.  Verbosity, or its opposite conciseness,
> is the density of that information, as in "information units per line
> of code" or some such ill-defined measure.

Difficult. With time I've learnt to like the type inference and
annotations of Ocaml + Haskell and starting to get annoyed by the
Pascal style. Here verbosity buys me hardly anything and leaves me
with the necessity to state and restate the same thing everywhere. So
no: There is a correlation between verbosity and expressiveness, but
not a very strict one.

>
> Ada is more expressive than C because it allows programmes to express
> more information.  In a way, it is also more concise in that Ada

I admit it has a richer, type system which allows to express more details.

> compilers insert all sorts of implicit checks, and in that Ada has
> built-in constructs like tasking, array slices and return of

Those I wouldn't count towards expressiveness, only as more
functionality in the standard runtime.

> dynamically-sized objects that require much more lines of code to
> achieve in C.

More power.

Regards -- Markus

Re: How come Ada isn't more popular?

[Pascal Obry]

Markus E Leypold a �crit :
> <cynical mode>
> 
> You're sure you're not confusing verbosity with "expressiveness"? :-)
> 
> </cynical mode>

Let's try :

   pragma Remote_Call_Interface;

as an expressiveness example :)

I won't even try to give the equivalent C/C++ code!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: How come Ada isn't more popular?

[Markus E Leypold]

Pascal Obry <pascal@obry.net> writes:

> Markus E Leypold a �crit :
>> <cynical mode>
>> 
>> You're sure you're not confusing verbosity with "expressiveness"? :-)
>> 
>> </cynical mode>
>
> Let's try :
>
>    pragma Remote_Call_Interface;
>
> as an expressiveness example :)
>
> I won't even try to give the equivalent C/C++ code!


So what is expressiveness in your definition? :-)

Regards -- Markus

Re: How come Ada isn't more popular?

[Pascal Obry]

Markus E Leypold a �crit :

> So what is expressiveness in your definition? :-)

It is so expressive that I won't be able to comment here. See Annex-E in
the Ada reference manual :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: How come Ada isn't more popular?

[Markus E Leypold]

Pascal Obry <pascal@obry.net> writes:

> Markus E Leypold a �crit :
>
>> So what is expressiveness in your definition? :-)
>
> It is so expressive that I won't be able to comment here. See Annex-E in
> the Ada reference manual :)

No, I asked, how you define expressiveness (generally), not, what is
so expressive in this pragma. But never mind. It's not important.

Regards -- Markus

Re: How come Ada isn't more popular?

[Pascal Obry]

Markus E Leypold a �crit :

> No, I asked, how you define expressiveness (generally), not, what is
> so expressive in this pragma. But never mind. It's not important.

Sorry I did not understand that! For me, a high expressiveness in a
programming language is how easy/simple it is to declare something that
can be quite complex underneath.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: How come Ada isn't more popular?

[Markus E Leypold]

Hi Pascal,

Pascal Obry <pascal@obry.net> writes:

> Markus E Leypold a �crit :
>
>> No, I asked, how you define expressiveness (generally), not, what is
>> so expressive in this pragma. But never mind. It's not important.
>
> Sorry I did not understand that! For me, a high expressiveness in a
> programming language is how easy/simple it is to declare something that
> can be quite complex underneath.

Ludovics example was quite the opposite (verbose if precise). I think,
that expressiveness can not be defined or measured very well. Perhaps
as number of programming patterns that are supported and their
flexibility. So object orientation introduces more expressiveness when
compared with procedures, Hindley-Milner type systems when compared
with languages that have no parameterized types, templates (C++) would
also introduce more expressiveness (don't flame me, we are talking
"expressiveness" now, not safety), range sub-typing Ada style is also
added expressiveness (which on the other side is absent from the
Hindley-Milner type systems ...), functions as closures and 1st class
citizens allow to abstract over iteration patterns (fold, map, etc),
so this also introduces more expressiveness. And so on.

I do not agree with your definition that just measures the ratio
between "things happening underneath" and the construct you write in
your program. If I'd agree, I also had to concede that 

 #include <stdio.h> 

is terribly expressive, because it pulls in such a lot of
functionality with one line (actually I think Fortran programmer would
agree :-) -- since there is no preprocessor defined in Fortran (up to
77 at least), they abuse the C preprocessor to reuse data definitions
and this like).

Perhaps we should ask: Which programming patterns / paradigms does
the language support? I realize that is terribly vague.

To widen the scope of this discussion a bit: I've been using some
10-20 languages in the last 2 decades intensively and looked upon
perhaps double as many. I'm amazed about the narrowing of perspective
I perceive with a number of participants in this discussion and the
other one (where someone asked for an Ada example for his book). Ada
still has it's place in the world, I think, but it would be good to
admit that things have changed a bit during the last 25 years. There
is a lot to be learned from Ada. Exclusive focus on it and ignoring
that not every piece of software fits into the Ada niche (which I
perceive to be reliable embedded programming) won't help to promote
it. I sometimes even doubt it can be rescued in the long run.

(That isn't against you, I'm just adding this not here, because I
can't decide where else).


Regards -- Markus

Re: How come Ada isn't more popular?

[Pascal Obry]

Markus E Leypold a �crit :

>  #include <stdio.h> 
> 
> is terribly expressive, because it pulls in such a lot of

Certainly not. It does nothing at the semantic level. But I agree that
it is not easy to have a common view about expressiveness, let's drop
this then.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: How come Ada isn't more popular?

[Markus E Leypold]

Pascal Obry <pascal@obry.net> writes:

> Markus E Leypold a �crit :
>
>>  #include <stdio.h> 
>> 
>> is terribly expressive, because it pulls in such a lot of
>
> Certainly not. It does nothing at the semantic level. But I agree that

I can see your point here.

> it is not easy to have a common view about expressiveness, let's drop
> this then.


OK. :-)

Regards -- Markus

Re: How come Ada isn't more popular?

[adaworks]

I came across an article in a recent book by Joel Spolsky
with an article titled, "C++.  The Forgotten Trojan Horse,"
by Eric Johnson.   Spolsky's book is titled "The Best Software
Writing I," and it is published by Apress.

The article begins, "I find C++ interesting.  No, not because
my compiler can spit out an incoherent set of errors ... there's
a lesson to be learned about how it conquered an existing
community."

Johnson makes a good case for the insidious way that C++
found its way to dominance, not because of its superiority
as a programming language but for entirely different reasons.

A language achieves popularity or is ignored according to a
set of circumstances that are quite independent of what
any adopter of that language might consider as quality. It
would seem that quality is the last factor to be considered,
otherwise, C++ would never have become so dominant.

In more recent times, Java has campaigned for the role of
dominant language.   However, Java is even more bureaucratic
than Ada and even the simplest tasks are swollen into excessive
syntactic and structural absurdities.

More recently, I am seeing a trend away from C++ and Java
toward more "agile" languages such as Python and Ruby.  In
particular, Ruby seems to have captured the interest of anyone
who has looked carefully at it.  Python is wonderfully easy to
learn, and powerful in what can be done in a few lines of code.
I particularly like the fact that functions are first-class objects
since, for mathematical programming, I like to use functional
programming.    Ruby is the same in this respect.

What I have noticed, though, is that these easy-to-use languages
do not scale-up as well for really large software systems as C++,
Eiffel, and Ada.   Advocates of Python and Ruby disagree, of
course, but advocacy is not a good reason to believe them.  Also,
those who prefer Python and Ruby seem to have rejected the
importance of type-safety, at least in the literature.   As I read
their objections to type-safety, it is clear that they are framing
those objections in their experience with C/C++ (where type
safety is a hideous joke) or Java (where type-safety falls short
of what one would find in Ada).

So, the two languages that seem to best scale up for safety-critical
software are still Eiffel and Ada.

I have come to believe that C++ should always be the language
of last resort for any serious programming project.

Java has a place, but it is in a twilight zone that is often better filled
with Python or Ruby.   We could lose Java today and the world
would not be worse-off for it because Ruby would easily fill the
void.

What does a programmer choose as the language s/he uses at home
or for recreational programming?    Many in this forum choose Ada.
However, even those in this forum, as they discover Python and Ruby,
are probably enjoying the option of making small programs work
quickly and easily for everything from CGI to sockets.

This does not answer the question of why Ada is not more popular,
but one could pose an alternative question of why an error-prone
language should have ever become so popular.   Why would anyone
choose a language that is error-prone and expect an outcome that is
error-free.   Perhaps error-free software is not a goal.  Perhaps the
goal is to simply see how much code we can lay down in given period
of time.

Richard Riehle

Re: How come Ada isn't more popular?

[Harald Korneliussen]

On 24 Jan, 19:09, Pascal Obry <pas...@obry.net> wrote:
> For me, a high expressiveness in a
> programming language is how easy/simple it is to declare something that
> can be quite complex underneath.
>

But does that really matter all that much, as long as there are good
means of abstraction? I'd say that functional languages do perhaps have
an advantage there --- from the little I've tried, it seems that they
have some genuinely different ways of gluing things together.
Combinator-based parsing libraries would be an example. Amazing stuff,
which is not feasible in Ada or C++ (you could probably torture
templates into doing it in C++, but I don't count that as feasible).
But you can't easily do low-level stuff in them, which you can in Ada,
and although the type system in Ada is less extensible, it also has
some lovely features like the Positive numeric type, which can probably
be emulated in Haskell, but usually aren't.

Re: How come Ada isn't more popular?

[Adam Beneschan]

On Jan 24, 12:07 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> kevin  cline writes:
> > But the point was that expressiveness drives programmers to new
> > languages, and Ada isn't particularly expressive.On the contrary, I think that Ada is the most expressive language
> around.  Consider:
>
> procedure Set_Bit_In_Register (At_Address : in System.Address) is
>    type Register is array (1 .. 32) of Boolean;
>    pragma Pack (Register);
>    for Register'Bit_Order use System.High_Order_First;
>    pragma Volatile (Register);
>
>    R : Register;
>    for R'Address use At_Address;
> begin
>    Register (4) := True;
> end;
>
> versus
>
> void set_bit_in_register (volatile unsigned long * at_address)
> {
>    *at_address |= 2 << 3;
>
> }

I think maybe I understand how C might be considered "more expressive"
to some programmers.  If you want to set the third bit of this word,
you can just type in what you want, without going through a whole lot
of rigmarole like defining types and telling the compiler what you
intend to do and what order you think the bits are in and stuff like
that.  You can just say it.  Of course, if there's a misunderstanding
between you and the compiler about how your data is laid out, perhaps,
then your code doesn't work and it crashes your PC and introduces a
vulnerability that some clever hacker can take advantage of to turn
your computer into a subservient automaton whose sole purpose in life
is to send millions of "performance-enhancing drug" ads to *my* e-mail
address---but hey, at least you got to express yourself.   C lets you
do this without having to do as much thinking or actual work, which
mean old Ada makes you do.

Perhaps we should just concede that C is a "more expressive
language"---with about as much benefit as there is to teaching math
students to be "more expressive" as opposed to getting the right
answer.

                               -- Adam

Re: How come Ada isn't more popular?

[Niklas Holsti]

Without wishing anyone ill, I want to sound my whistle to point out some 
fouls in this battle...

Adam Beneschan wrote:
> 
> On Jan 24, 12:07 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> 
>>kevin  cline writes:
>>
>>>But the point was that expressiveness drives programmers to new
>>>languages, and Ada isn't particularly expressive.On the contrary, I think that Ada is the most expressive language
>>
>>around.  Consider:
>>
>>procedure Set_Bit_In_Register (At_Address : in System.Address) is
>>   type Register is array (1 .. 32) of Boolean;
>>   pragma Pack (Register);
>>   for Register'Bit_Order use System.High_Order_First;

According to RM 13.5.3, the Bit_Order attribute can be specified only 
for record types, not array types like Register, so this Bit_Order 
clause is nonstandard. But this is perhaps not central to the argument...

>>   pragma Volatile (Register);
>>
>>   R : Register;
>>   for R'Address use At_Address;
>>begin
>>   Register (4) := True;
>>end;

If the High_Order_First clause were allowed for type Record, this would 
set the 4th highest bit, that is the bit for 2**28. If the bit indices 
run the other way, this would set the 4th lowest bit, the bit for 2**8.

>>versus
>>
>>void set_bit_in_register (volatile unsigned long * at_address)
>>{
>>   *at_address |= 2 << 3;
>>
>>}

That sets the bit for the 5th lowest bit, the bit for 2**16. Note that 
the shifted thing is 2#10#, not 2#1#.

> I think maybe I understand how C might be considered "more expressive"
> to some programmers.  If you want to set the third bit of this word,
> you can just type in what you want, without going through a whole lot
> of rigmarole like defining types and telling the compiler what you
> intend to do and what order you think the bits are in and stuff like
> that.  You can just say it.  Of course, if there's a misunderstanding
> between you and the compiler...

There is a misunderstanding somewhere, because the oh-so-expressive C 
code is not doing the same thing as the Ada code (in either Bit_Order), 
nor the same thing as you say it does.

And of course the same formula can be written in Ada with modular types, 
Shift_Right, "or". More characters to type, but less line-noise style 
and no need to check the well-thumbed page of my C manual that shows the 
C operator precedence table. This page has had a yellow post-it tab on 
it for a long time... :-)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: How come Ada isn't more popular?

[Bob Spooner]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:1169655934.028861.51000@j27g2000cwj.googlegroups.com...
> ...
> Perhaps we should just concede that C is a "more expressive
> language"---with about as much benefit as there is to teaching math
> students to be "more expressive" as opposed to getting the right
> answer.
>
>                               -- Adam
>
My view of expressiveness in a computer language is that it is inversely 
proportional to the distance between the problem space and the solution 
space. In other words, it is a measure of how high a level of abstraction in 
which you can work when you use it.

Bob 

Re: How come Ada isn't more popular?

[Dave Thompson]

On Wed, 24 Jan 2007 09:07:15 +0100, Ludovic Brenta
<ludovic@ludovic-brenta.org> wrote:
<snip>
> On the contrary, I think that Ada is the most expressive language
> around.  Consider:
> 
> procedure Set_Bit_In_Register (At_Address : in System.Address) is
>    type Register is array (1 .. 32) of Boolean;
>    pragma Pack (Register);
>    for Register'Bit_Order use System.High_Order_First;
>    pragma Volatile (Register);
>    
>    R : Register;
>    for R'Address use At_Address;
> begin
>    Register (4) := True;
> end;
> 
Even if this combination is/was actually supported (and MSB means
highest-subscript, which I don't find all that obvious) ...

> versus
> 
> void set_bit_in_register (volatile unsigned long * at_address)
> {
>    *at_address |= 2 << 3;
> }
> 
You presumably meant 1 << 3 (zero-origin numbering) to match subscript
4 (one-origin).

But to be safe in the (more) general case you need 1UL << B, since
promotion in C is strictly bottom-up (no expected-type context) and
the literal defaults to type 'int' which _might_ be only 16 bits while
'long' must be at least 32 bits. And you might even want an
  assert( B < 32 /* or other M */ );
(or environment/project-specific equivalent).

> The Ada version makes many more things explicit, that are assumed and
> implicit in C; for example, the size of the register, the fact that

Right, although C99 -- so far not that much more widely adopted and
available than Ada05 -- adds explicitly-sized integers at least for
the common cases of 8, 16, 32, 64. (Other values of N are up to the
implementation's option, and will probably be rare on common hw.)

> the parameter is an address and not a pointer (*), the endianness, and

See below.

> which bit is being set.  As 64-bit architectures become prevalent, the
> hidden assumption that C's "unsigned long" is 32 bits wide is more and
> more likely to be incorrect.
> 
> (*) consider that when we increment the address by one, it then
> references the next byte; whereas if we increment the pointer by one,
> it points to the next "unsigned long", i.e. 2, 4 or 8 bytes and not 1
> byte further.  C makes no distinction between addresses and pointers,
> lacking expressiveness in a crucial area.
> 
Wrong. C, even before C89, does know about pointer targets (strides).
Only _very_ early, Bell-Labs-only, pre-K&R1 C that was still in
transition from B had pointer === integer. 

> When calling the subprogram, we get:
> 
> Set_Bit_In_Register (At_Address => To_Address (16#DEADBEEF#));
> 
(optionally)

> versus
> 
> set_bit_in_register (0xDEADBEEF);
> 
The type mismatch is a constraint violation (which must be diagnosed)
if the prototype declaration (or definition) is visible, and undefined
behavior (~ Ada erroneous, but occurring in many more places, hence
not necessarily diagnosed) if not. You _must_ cast:
  set_bit_in_register ( (/*volatile*/unsigned long *) 0xDEADBEEF );
or (better?) ... ( (my_reg_addr_typedef) 0xDEADBEEF );

(assuming ulong aligned 3 mod 4 even works on your platform <G>)

(You don't actually need the volatile, since the call silently adds
it, but it is clearer -- i.e. more expressive -- to have it.)

Lack of parameter labelling is a shortcoming, although you can (and
people do) smush some of it into the routine name. And tools and/or
conventions can be used to find the description or doc when needed.

> Again, at the call site, the Ada version gives more information to the
> human programmer, i.e. is more expressive.
> 
> Expressiveness is not to be confused with conciseness.

Agree there. C does have _some_ expressiveness, where it happened to
be necessary or convenient, but not because it was actively sought.

- David.Thompson1 at worldnet.att.net

Re: How come Ada isn't more popular?

[Ludovic Brenta]

On Feb 6, 10:54 am, Dave Thompson wrote:
> On Wed, 24 Jan 2007 09:07:15 +0100, Ludovic Brenta wrote:
[snip]
>> (*) consider that when we increment the address by one, it then
>> references the next byte; whereas if we increment the pointer by one,
>> it points to the next "unsigned long", i.e. 2, 4 or 8 bytes and not 1
>> byte further.  C makes no distinction between addresses and pointers,
>> lacking expressiveness in a crucial area.
>
> Wrong. C, even before C89, does know about pointer targets (strides).
> Only _very_ early, Bell-Labs-only, pre-K&R1 C that was still in
> transition from B had pointer === integer.

Wrong? I think we're in agreement here. I was explaining that a
pointer is not the same thing as an address, since incrementing a
pointer gives a different result (next object) than incrementing an
address (next byte).

In C, address arithmetic is implemented in terms of char* and size_t
only because sizeof(char) == 1; I think that's a hack. In contrast,
address arithmetic in Ada is in terms of System.Address and
Storage_Offset, which is much more explicit.

> > When calling the subprogram, we get:
>
> > Set_Bit_In_Register (At_Address => To_Address (16#DEADBEEF#));
>
> (optionally)
>
> > versus
>
> > set_bit_in_register (0xDEADBEEF);
>
> The type mismatch is a constraint violation (which must be diagnosed)
> if the prototype declaration (or definition) is visible, and undefined
> behavior (~ Ada erroneous, but occurring in many more places, hence
> not necessarily diagnosed) if not. You _must_ cast:
>   set_bit_in_register ( (/*volatile*/unsigned long *) 0xDEADBEEF );
> or (better?) ... ( (my_reg_addr_typedef) 0xDEADBEEF );

So 0xDEADBEEF is an int, and there is no implicit conversion to
unsigned long*. Is that what you're saying? OK, now I see my knowledge
of C is fading away...

> (assuming ulong aligned 3 mod 4 even works on your platform <G>)

yeah, let's ignore that :-)

Thanks for your comments.

--
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Dave Thompson]

On 6 Feb 2007 03:01:41 -0800, "Ludovic Brenta"
<ludovic@ludovic-brenta.org> wrote:

> On Feb 6, 10:54 am, Dave Thompson wrote:
> > On Wed, 24 Jan 2007 09:07:15 +0100, Ludovic Brenta wrote:
> [snip]
> >> (*) consider that when we increment the address by one, it then
> >> references the next byte; whereas if we increment the pointer by one,
> >> it points to the next "unsigned long", i.e. 2, 4 or 8 bytes and not 1
> >> byte further.  C makes no distinction between addresses and pointers,
> >> lacking expressiveness in a crucial area.
> >
> > Wrong. C, even before C89, does know about pointer targets (strides).
> > Only _very_ early, Bell-Labs-only, pre-K&R1 C that was still in
> > transition from B had pointer === integer.
> 
> Wrong? I think we're in agreement here. I was explaining that a
> pointer is not the same thing as an address, since incrementing a
> pointer gives a different result (next object) than incrementing an
> address (next byte).
> 
Okay, I agree with that. I read your "no distinction" to mean
"addresses and pointers are/appear the same [in C]" or as it is more
commonly phrased (and wrong) on c.l.c "pointers are just addresses".

> In C, address arithmetic is implemented in terms of char* and size_t

Quibble: cv-qual un/signed/plain char *, and any integer type but
preferring size_t and ptrdiff_t, or perhaps ssize_t in POSIX

> only because sizeof(char) == 1; I think that's a hack. In contrast,
> address arithmetic in Ada is in terms of System.Address and
> Storage_Offset, which is much more explicit.
> 
Ada is certainly more explicit, as usual. In 1970 there was still
current or at least recent extensive experience with word-addressed
machines where you in fact did not have consistent (flat) addresses of
all possible data elements, as the now-popular understanding expects
and the Ada model demands (though presumably it could be emulated).

I don't know if you mean 'hack' in its older-computer-specific meaning
of 'clever but arcane', or its more general and media-preferred
meaning of 'cheap', 'sloppy', and even 'criminal'. Given the
environment in which and the goals for which C was created, I think
this was a reasonable design choice at the time, and qualified for the
former meaning -- if we weren't still stuck with it (and other
infelicities) today.

FWLIW C99 adds standard names (typedefs) [u]intptr_t for integer types
able to hold without loss (but with explicit conversions) any data
pointer value, if the implementation has such (and all I know of do).
You still aren't officially guaranteed arithmetic on these values, but
on all known modern platforms it does work.

> > > set_bit_in_register (0xDEADBEEF);
> >
> > The type mismatch is a constraint violation (which must be diagnosed)
> > if the prototype declaration (or definition) is visible, and <snip>
> So 0xDEADBEEF is an int, and there is no implicit conversion to
> unsigned long*. Is that what you're saying? OK, now I see my knowledge
> of C is fading away...
> 
Right. Or rather, 0xDEADBEEF is some integer type, exactly which
depending on your platform -- on most common platforms today with
32-bit signed and unsigned int it will be unsigned int -- and there is
no implicit conversion from any integer type to any pointer, except as
a very hysterical raisin special case the constant (manifest) zero to
a null pointer (of any type). (And even that is better expressed with
the standard macro NULL instead.)

- formerly david.thompson1 || achar(64) || worldnet.att.net

Re: How come Ada isn't more popular?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message >
> Yes, I've read that article.  It would really be sad if Ada were not
> superior to C for a toy problem in embedded control system development,
> since Ada was designed specifically for that purpose.  But the point
> was that expressiveness drives programmers to new languages, and Ada
> isn't particularly expressive.
>
It depends on what you want to express.   Expressiveness, like beauty,
is often "in the eye of the beholder."  For many software professionals,
the absence of curly-braces makes a language less expressive.  For
others, their presence is a problem.   For some, brevity is a sign of
expressiveness.  For others, ease of understanding on the part of a
reader is important to expressiveness.

I do know a lot of languages, including many in the C family.  I have
programmed in COBOL, Fortran, PL/I, BASIC, Python, and many
others.   I teach a class in comparative programming languages.

An important distinction to be made is expressibility versus expressiveness.
The fact that I can express a solution in Fortran that is better suited to being
expressed in COBOL does not mean that Fortran is expressive.   When
a solution is possible, that makes it expressible.  When the language is
designed to express such solutions, that makes it expressive -- for that
kind of problem.

Languages evolve to become more expressive.  Fortran has evolved.  COBOL
has evolved.  Ada has evolved.  Even Java continues to evolve.  Some languages
seem not to evolve and remain stagnent.  PL/I comes to mind.   Some programmers
do not evolve, and they also become out-of-date.


As languages evolve some tend to get better at being more directly expressiveof
a larger range of solutions.  Not all languages evolve well.   In my view, C++
has not become better with its most recent "improvements."

Ada is expressive of a large number of solutions that are more difficult to
express in C or other languages.  However, the base language is not as
expressive as Perl for regular expressions.  That has required a separate
library unit.  It is not as directly expressive of mathematical solutions as
Fortran.  That too requires library units.    All the fundamental constructs
are in place to create powerful library units.  This capability allows the
language to be easily extended to accomodate a large number of kinds
of solutions.  Expressiveness is, for some kinds of solutions, through the
creation of such libraries, not by burdening the language.

The type model of Ada does enhance expressiveness since it allows a
lot of extensions.   There are certainly things I would do differently in
that type system, and future languages will come along that improve on
Ada.  At present, that has not happened -- certainly not with a type
model that I like.   The visibility rules of Ada allow some powerful
constructs for designing large-scale software systems.   None of the
C family, including C++, is as expressive in this regard.

Expressiveness needs to be considered beyond toy programs.  Real
software systems also evolve.  The fact that I can program myself
into a corner with some simple code that needs to be rewritten from
scratch each time the problem changes a little, can give me the
illusion of expressiveness.  Real expressiveness includes the ability to
easily adapt the software in-place to the changing realities of the
environment in which it is deployed.

With all its shortcomings, and it does have shortcomings, Ada seems to
be have the capacity for being expressive of most kinds of practical
software solutions.  For many of those solutions, without supporting
libraries, it is characterized by expressibility.  When one adds libraries
written in Ada, we see greater expressiveness.

Expressiveness is not always hampered by the language design but
by those who have not yet learned how to use that design as it was
intended to be used.

Richard riehle 

Re: How come Ada isn't more popular?

[kevin cline]

On Jan 24, 10:14 am, <adawo...@sbcglobal.net> wrote:
> "kevin cline" <kevin.cl...@gmail.com> wrote in message >
> > Yes, I've read that article.  It would really be sad if Ada were not
> > superior to C for a toy problem in embedded control system development,
> > since Ada was designed specifically for that purpose.  But the point
> > was that expressiveness drives programmers to new languages, and Ada
> > isn't particularly expressive.It depends on what you want to express.   Expressiveness, like beauty,
> is often "in the eye of the beholder."  For many software professionals,
> the absence of curly-braces makes a language less expressive.  For
> others, their presence is a problem.   For some, brevity is a sign of
> expressiveness.  For others, ease of understanding on the part of a
> reader is important to expressiveness.
>
> I do know a lot of languages, including many in the C family.  I have
> programmed in COBOL, Fortran, PL/I, BASIC, Python, and many
> others.   I teach a class in comparative programming languages.
>
> An important distinction to be made is expressibility versus expressiveness.
> The fact that I can express a solution in Fortran that is better suited to being
> expressed in COBOL does not mean that Fortran is expressive.   When
> a solution is possible, that makes it expressible.  When the language is
> designed to express such solutions, that makes it expressive -- for that
> kind of problem.
>
> Languages evolve to become more expressive.  Fortran has evolved.  COBOL
> has evolved.  Ada has evolved.  Even Java continues to evolve.  Some languages
> seem not to evolve and remain stagnent.  PL/I comes to mind.   Some programmers
> do not evolve, and they also become out-of-date.
>
> As languages evolve some tend to get better at being more directly expressiveof
> a larger range of solutions.  Not all languages evolve well.   In my view, C++
> has not become better with its most recent "improvements."
>
> Ada is expressive of a large number of solutions that are more difficult to
> express in C or other languages.  However, the base language is not as
> expressive as Perl for regular expressions.  That has required a separate
> library unit.  It is not as directly expressive of mathematical solutions as
> Fortran.  That too requires library units.    All the fundamental constructs
> are in place to create powerful library units.

Not as powerful as I would like, and definitely not as powerful as C++
templates.  Christopher Grein demonstrated this conclusively in his
paper on modeling scientific units in Ada.  C++ templates allow the
straightforward construction of a compile-time safe system of physical
units, allowing arbitrary computations, while Ada's explicit
instantiation model forced one to rely on run-time checking.

Re: How come Ada isn't more popular?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1169684558.876074.40530@s48g2000cws.googlegroups.com...
>
>
> On Jan 24, 10:14 am, <adawo...@sbcglobal.net> wrote:
>> "kevin cline" <kevin.cl...@gmail.com> wrote in message >
>> > Yes, I've read that article.  It would really be sad if Ada were not
>> > superior to C for a toy problem in embedded control system development,
>> > since Ada was designed specifically for that purpose.  But the point
>> > was that expressiveness drives programmers to new languages, and Ada
>> > isn't particularly expressive.It depends on what you want to express. 
>> > Expressiveness, like beauty,
>> is often "in the eye of the beholder."  For many software professionals,
>> the absence of curly-braces makes a language less expressive.  For
>> others, their presence is a problem.   For some, brevity is a sign of
>> expressiveness.  For others, ease of understanding on the part of a
>> reader is important to expressiveness.
>>
>> I do know a lot of languages, including many in the C family.  I have
>> programmed in COBOL, Fortran, PL/I, BASIC, Python, and many
>> others.   I teach a class in comparative programming languages.
>>
>> An important distinction to be made is expressibility versus expressiveness.
>> The fact that I can express a solution in Fortran that is better suited to 
>> being
>> expressed in COBOL does not mean that Fortran is expressive.   When
>> a solution is possible, that makes it expressible.  When the language is
>> designed to express such solutions, that makes it expressive -- for that
>> kind of problem.
>>
>> Languages evolve to become more expressive.  Fortran has evolved.  COBOL
>> has evolved.  Ada has evolved.  Even Java continues to evolve.  Some 
>> languages
>> seem not to evolve and remain stagnent.  PL/I comes to mind.   Some 
>> programmers
>> do not evolve, and they also become out-of-date.
>>
>> As languages evolve some tend to get better at being more directly 
>> expressiveof
>> a larger range of solutions.  Not all languages evolve well.   In my view, 
>> C++
>> has not become better with its most recent "improvements."
>>
>> Ada is expressive of a large number of solutions that are more difficult to
>> express in C or other languages.  However, the base language is not as
>> expressive as Perl for regular expressions.  That has required a separate
>> library unit.  It is not as directly expressive of mathematical solutions as
>> Fortran.  That too requires library units.    All the fundamental constructs
>> are in place to create powerful library units.
>
> Not as powerful as I would like, and definitely not as powerful as C++
> templates.

But safer than C++, overall.  And safer than C++ templates.

>Christopher Grein demonstrated this conclusively in his
> paper on modeling scientific units in Ada.  C++ templates allow the
> straightforward construction of a compile-time safe system of physical
> units, allowing arbitrary computations, while Ada's explicit
> instantiation model forced one to rely on run-time checking.
>
I have not read Christopher Grein's paper, and from what I know
of C++ and C++ templates, I am skeptical of the notion of it being
compile-time safe under any circumstances.   I suppose one could
write some very careful code to make that true, but the language
itself is not inherently safe.

I have not had the experience of having to rely on run-time checking
for templates.   In fact, my own experience of generics is that they
tend to enforce a great deal of checking at compile-time.  That being
said, C++ templates do allow more complex variations on genericity,
and that does not contribute to type-safe software.

The whole point of Ada is to allow the maximum amount of checking
at compile-time.   In fact, the point of the language design is to maximize
the amount of checking possible over the entire system as early in the
development as possible.   C++ does not support anything close to
that goal except in a few isolated places within the langauge design.
We would want to evaluate the language as a whole, not one or
two features.   We can compare C++ to Visual Basic and make
Visual Basic come out ahead.  We can compare Ada to COBOL
and make COBOL come out ahead.   In both cases, it will depend
on our criteria and what we decide to compare.

As to power.  With Ada you get more power, safely, than you do in
C++ or Java.   Empowering a language, while making it less safe
is not a good thing.   As for Grein's paper, which I will take the time
to read, it is my experience that one can make a case quite nicely
by stacking the evidence in a particular way.    I will try to find a
copy of the paper and make my own judgement about that.

Richard Riehle

Re: How come Ada isn't more popular?

[Maciej Sobczak]

adaworks@sbcglobal.net wrote:

> I have not read Christopher Grein's paper, and from what I know
> of C++ and C++ templates, I am skeptical of the notion of it being
> compile-time safe under any circumstances.

What is there in C++ templates that makes them unsafe?

> C++ templates do allow more complex variations on genericity,
> and that does not contribute to type-safe software.

Could you elaborate on this?
Do you mean that expressiveness and flexibility go against type-safety?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: How come Ada isn't more popular?

[Markus E Leypold]

Maciej Sobczak <no.spam@no.spam.com> writes:

> adaworks@sbcglobal.net wrote:
>
>> I have not read Christopher Grein's paper, and from what I know
>> of C++ and C++ templates, I am skeptical of the notion of it being
>> compile-time safe under any circumstances.
>
> What is there in C++ templates that makes them unsafe?

Yes, the "under any circumstance" makes me rather
suspicious. Overgeneralizing? There might be (indeed are) good reasons
for disliking C++ templates but that statement, I think, will not hold
under examanation as a sufficient one.

>
>> C++ templates do allow more complex variations on genericity,
>> and that does not contribute to type-safe software.
>
> Could you elaborate on this?
> Do you mean that expressiveness and flexibility go against type-safety?

'adaworks' has already suggested that Java is not type safe. I fear he
does not agree with my definition of type safe.

Regards -- Markus

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On 24 Jan 2007 16:22:38 -0800, kevin  cline wrote:

> Christopher Grein demonstrated this conclusively in his
> paper on modeling scientific units in Ada.  C++ templates allow the
> straightforward construction of a compile-time safe system of physical
> units, allowing arbitrary computations, while Ada's explicit
> instantiation model forced one to rely on run-time checking.

There exist numerous application where run-time unit checking is a
requirement. For instance in automation and control, data acquisition and
distribution, HMI. Templates fail there.

BTW, I am afraid that the solution you referred to, is unable to handle �C,
�F. Not much promising, I would say...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Harald Korneliussen]

Richard Riehle wrote:
> The type model of Ada does enhance expressiveness since it allows a
> lot of extensions.   There are certainly things I would do differently in
> that type system, and future languages will come along that improve on
> Ada.  At present, that has not happened -- certainly not with a type
> model that I like.
Just wondering, what do you think is the problem with H-M-type systems,
like ML and Haskell use? It seems to me they are a wonderful tool for
extending the type system to check properties at compile time that
would otherwise have to be checked at run time. I recently read about
an XML combinator library for Haskell that some researcher had written
that ensured that only valid XML could be generated - and it guaranteed
this at compile time!

Re: How come Ada isn't more popular?

[Alexander E. Kopilovich]

kevin cline wrote:

> the point 
>was that expressiveness drives programmers to new languages, and Ada
>isn't particularly expressive.

This is substantially inaccurate statement.

Ada is very expressive language, perhaps the most expressive language overall
among programming languages for which more than one commercially supported
compiler exists.

But there is indeed big issue with expressiveness in Ada, which hampers it
popularity: that big part of Ada expressiveness, which is really outstanding,
pertains to concrete information (both for data and for program structure),
which is likely to be proprietary in too many cases and thus not sharable. 

At the same time Ada has poor expressiveness for incomplete (in one sense
or another) programs and components - thus making random collective 
development almost impossible.

Re: How come Ada isn't more popular?

[Charles D Hixson]

kevin cline wrote:
> 
> On Jan 23, 4:18 pm, Martin Dowie <martin.do...@btopenworld.remove.com>
> wrote:
>> kevin clinewrote:
>>> 3. For the same reason that Limburger cheese isn't more popular.  Most
>>> programmers who have tried Ada didn't like it.  What makes a programmer
>>> like a new language?  Usually, someone comes along and says something
>>> like "Remember that program that we spent two weeks writing in C?
>>> Here's a Perl implementation that I put together in three hours and
>>> one-tenth the code."  That's never happened with Ada.                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> FUD!!
>>
>> http://www.stsc.hill.af.mil/crosstalk/2000/08/mccormick.html
> 
> Yes, I've read that article.  It would really be sad if Ada were not
> superior to C for a toy problem in embedded control system development,
> since Ada was designed specifically for that purpose.  But the point
> was that expressiveness drives programmers to new languages, and Ada
> isn't particularly expressive.
> 
Ada is quite expressive, but it can be very clumsy when you 
want to write a flexible routine.  You can do it, and you can 
do it with much greater safety, but it takes more work.

Just, for instance, look at the Ada version of:
#include  <stdio.h>
void main()  {  print ("Hello", " ", "World!");	exit(0);  }

(I may have gotten that wrong, my main language is Python. 
I'm intending to move to Ada for a particular project that 
I've got in mind, because I despise the way C uses pointers.)

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sat, 27 Jan 2007 05:43:28 GMT, Charles D Hixson wrote:

> Ada is quite expressive, but it can be very clumsy when you 
> want to write a flexible routine.  You can do it, and you can 
> do it with much greater safety, but it takes more work.
> 
> Just, for instance, look at the Ada version of:
> #include  <stdio.h>
> void main()  {  print ("Hello", " ", "World!");	exit(0);  }
> 
> (I may have gotten that wrong, my main language is Python. 
> I'm intending to move to Ada for a particular project that 
> I've got in mind, because I despise the way C uses pointers.)

The example is wrong C, but the point is that such examples show little if
anything. Who is designing console applications today? What about "Hello
World" in X11, Windows API, GTK+ or similar with a requirement of some
definite look-and-feel? If we looked at C, Ada, Python code of that, we
would find all them far from being expressive.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Michael Bode]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> The example is wrong C, but the point is that such examples show little if
> anything. Who is designing console applications today? What about "Hello
> World" in X11, Windows API, GTK+ or similar with a requirement of some
> definite look-and-feel? If we looked at C, Ada, Python code of that, we
> would find all them far from being expressive.

I'd say such micro examples don't show anything even if you make them
GUI examples. A graphical "hello world" in Tcl/Tk would be:

pack [label .l -text "Hello World!"]

So why isn't  Tcl/Tk the most popular language today?

One hint on why Ada isn't popular might be my own case. I'm an
autodidact in programming (I'd never dare to call me software
engineer). I learned programming at the age of 14 with BASIC, later I
discovered Turbo-Pascal and liked it much better (I had to unlearn
some quite bad BASIC habits).

When I switched from DOS to OS/2 I found out what's so bad about
vendor lock in: no Turbo-Pascal for OS/2. So I looked for a better
standardized language and changed to C/C++ but never liked it
much. I've found out about Ada only 3 years ago on Usenet. Finally
there was a (Turbo-)Pascal done right. Had there only been more
advertising for Ada95 10 years ago that could have saved me years of
C.

-- 
Michael Bode

Re: How come Ada isn't more popular?

[Markus E Leypold]

Michael Bode <m.g.bode@web.de> writes:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> The example is wrong C, but the point is that such examples show little if
>> anything. Who is designing console applications today? What about "Hello
>> World" in X11, Windows API, GTK+ or similar with a requirement of some
>> definite look-and-feel? If we looked at C, Ada, Python code of that, we
>> would find all them far from being expressive.
>
> I'd say such micro examples don't show anything even if you make them
> GUI examples. A graphical "hello world" in Tcl/Tk would be:
>
> pack [label .l -text "Hello World!"]
>
> So why isn't  Tcl/Tk the most popular language today?
>
> One hint on why Ada isn't popular might be my own case. I'm an
> autodidact in programming (I'd never dare to call me software
> engineer). I learned programming at the age of 14 with BASIC, later I
> discovered Turbo-Pascal and liked it much better (I had to unlearn
> some quite bad BASIC habits).
>
> When I switched from DOS to OS/2 I found out what's so bad about
> vendor lock in: no Turbo-Pascal for OS/2. So I looked for a better
> standardized language and changed to C/C++ but never liked it
> much. 

Almost sounds like my biography :-). I'd bet you're +/- 3 years my age
(which is not going to be disclosed here ...).

> I've found out about Ada only 3 years ago on Usenet. Finally
> there was a (Turbo-)Pascal done right. Had there only been more
> advertising for Ada95 10 years ago that could have saved me years of
> C.

On factor that hugely contributed to the success of Borland's Turbo
line of products (at least in Germany) were the excellently written
manuals which documented anything -- from the language itself,
library, the stack layout and the interfacing with C and assembler. If
documents like this would have been available as a boxed set for, say,
GNAT in, say, 1990 or even 1995, then the world would perhaps look
differently today. 

As it is, as a hobbyist, you still have to collect stuff from all over
the internet (libraries, documents and some stuff is really not
documented at all). And I still think that making it easy for
beginners (people who learn their first language and don't know much
about operating systems, linking and how all that fits together) is
absolutely necessary to achieve popularity.

In some other post somebody asked wether it was a factor contributing
toward C's popularity that C was the language in which major
operating systems were written in. I don't think so. I suggest that
the availability of Quick C and Turbo C for 8/16-Bit micros was
perhaps a large if not the major factor.

Regards -- Markus

Re: How come Ada isn't more popular?

[Martin Krischik]

Markus E Leypold schrieb:

> As it is, as a hobbyist, you still have to collect stuff from all over
> the internet (libraries, documents and some stuff is really not
> documented at all). And I still think that making it easy for
> beginners (people who learn their first language and don't know much
> about operating systems, linking and how all that fits together) is
> absolutely necessary to achieve popularity.

Exacly the problem The GNU Ada project [1] set out to solve.

Reminder: The project is not about providing a compiler! It is about 
providing compiler and librarys.

Only we are short of manpower.

Martin

[1] http://gnuada.sf.net

Re: How come Ada isn't more popular?

[Gautier]

Charles D Hixson:

> Ada is quite expressive, but it can be very clumsy when you want to 
> write a flexible routine.  You can do it, and you can do it with much 
> greater safety, but it takes more work.
> 
> Just, for instance, look at the Ada version of:
> #include  <stdio.h>
> void main()  {  print ("Hello", " ", "World!");    exit(0);  }

with Ada.Text_IO;
procedure pied is begin Ada.Text_IO.Put("Hello" & " " & "World!"); end;

Is it so clumsy ?
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: How come Ada isn't more popular?

[Ludovic Brenta]

Gautier writes:
>> #include  <stdio.h>
>> void main()  {  print ("Hello", " ", "World!");    exit(0);  }
>
> with Ada.Text_IO;
> procedure pied is begin Ada.Text_IO.Put("Hello" & " " & "World!"); end;

LOL!

For those who don't know French: "main" means "hand", "pied" means
"foot".

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Charles D Hixson]

Gautier wrote:
> Charles D Hixson:
> 
>> Ada is quite expressive, but it can be very clumsy when you want to 
>> write a flexible routine.  You can do it, and you can do it with much 
>> greater safety, but it takes more work.
>>
>> Just, for instance, look at the Ada version of:
>> #include  <stdio.h>
>> void main()  {  print ("Hello", " ", "World!");    exit(0);  }
> 
> with Ada.Text_IO;
> procedure pied is begin Ada.Text_IO.Put("Hello" & " " & "World!"); end;
> 
> Is it so clumsy ?
> ______________________________________________________________
> Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
> Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
> 
> NB: For a direct answer, e-mail address on the Web site!
Sorry, I knew I shouldn't have used that example.  (Of course, 
maybe it's the texts I'm looking at for Ada...).

But I was intentionally NOT concatenating the strings. 
Perhaps if the central string were a number?  or an unbounded 
string instead of a fixed string?  Or perhaps my concerns are 
those of a neophyte...but I've got around 8 texts, and they 
all use that verbose form...Thus:

with Ada.Text_IO;
use Ada.Text_IO;
procedure pied is
begin
   Put("Hello ");
   Put(3);
   put("World!");
   newline;
end pied;

I acknowledge that this vertical separation is optional ... 
but doesn't the put(3) need to be a separate print statement?
(And now that my C is coming back to me a bit the C print 
statement should have been:
printf("Hello, %d %s\n", 3, "World");

As shown by the silly mistake that I made in C, it's not my 
favorite language.  But when I compare a book on expert 
systems written in C and one written in Ada (well, Ada83), the 
book in Ada is both thicker and has more pages devoted to code 
than the book in C, and the expert systems are approximately 
of equivalent power (i.e., toy systems).   Well, the type size 
is a trifle larger, and the paper a bit thicker...so the 
comparison isn't quite as straightforward as I'm making it 
out, but basically Ada83 appears to take approx 1.5 times as 
many lines to do the same thing.  (I didn't count the lines. 
It's a rough estimate.  Say somewhere between 1.1 and 1.9 
times as many lines.)  Possibly this is a comment on the 
skills of the authors, but the number of extensive comparisons 
I've encountered is very limited.  (Or maybe it's a comment on 
Ada83, and doesn't apply to Ada95.)

Re: How come Ada isn't more popular?

[Ludovic Brenta]

Charles D Hixson writes:
> basically Ada83 appears to take approx 1.5 times as many lines to do
> the same thing.  (I didn't count the lines. It's a rough estimate.
> Say somewhere between 1.1 and 1.9 times as many lines.)  Possibly
> this is a comment on the skills of the authors, but the number of
> extensive comparisons I've encountered is very limited.  (Or maybe
> it's a comment on Ada83, and doesn't apply to Ada95.)

In my experience, the ratio is close to 1.0.  Ada's verbosity in some
areas (type declarations and explicit conversions, access types,
traditionally longer identifiers and keywords, etc.)  is compensated
for by more concise constructs in others like array slices, returning
objects of unconstrained types, generics, overloading, implicit rather
than explicit run-time checks, etc., so it all evens out.

Ada 95's main feature, object-oriented programming, does not have a
direct equivalent in C; so writing an object-oriented program in C,
complete with dynamic dispatching and run-time type identification,
would be much more verbose than in Ada.  For example, GTK+ and GNOME
are written in pure C but are object-oriented, and _quite_ verbose.
The same would apply to tasking and generics.

Maybe your observation is true for smaller programs.  It may be that
for very large programs, Ada is actually more concise than C...

-- 
Ludovic Brenta.

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Charles D Hixson wrote:
> 
> As shown by the silly mistake that I made in C, it's not my favorite 
> language.  But when I compare a book on expert systems written in C and 
> one written in Ada (well, Ada83), the book in Ada is both thicker and 
> has more pages devoted to code than the book in C, and the expert 
> systems are approximately of equivalent power (i.e., toy systems).   
> Well, the type size is a trifle larger, and the paper a bit thicker...so 
> the comparison isn't quite as straightforward as I'm making it out, but 
> basically Ada83 appears to take approx 1.5 times as many lines to do the 
> same thing.  (I didn't count the lines. It's a rough estimate.  Say 
> somewhere between 1.1 and 1.9 times as many lines.)  Possibly this is a 
> comment on the skills of the authors, but the number of extensive 
> comparisons I've encountered is very limited.  (Or maybe it's a comment 
> on Ada83, and doesn't apply to Ada95.)

That's a good thing. Ada emphasizes ease of reading over ease of 
writing, since code is read far more often than it is written. C's 
emphasis is the opposite.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: How come Ada isn't more popular?

[adaworks]

"Charles D Hixson" <charleshixsn@earthlink.net> wrote in message 
news:zwSuh.15379>


>  the book in Ada is both thicker and has more pages devoted to code than the 
> book in C, and the expert systems are approximately of equivalent power (i.e., 
> toy systems).

No an expert systems book, but a thin book on Ada that has
most of what a newbie needs

           Ada Distilled

Download it free from www.adaic.com

Richard Riehle

Re: How come Ada isn't more popular?

[Arthur Evans Jr]

In article <1169588206.234714.312650@k78g2000cwa.googlegroups.com>,
 "kevin  cline" <kevin.cline@gmail.com> wrote:

>                                                         Ada was
> designed by a committee to meet theroetical needs.

Not so. Before design of Ada started, about 1970, there was a lengthy 
period of gathering requirements. Input was solicited from all over, 
both inside DOD and out, about what should be in the language. DOD 
published in 1971 a Strawman proposal of language features, followed by 
a Tinman, an Ironman, and finally a Steelman. Each of these feature 
requirement documents was widely reviewed by anyone who chose to submit 
comments, and these comments were studied to produce the next document 
in the series. Comments came from language design theorists and 
practitioners, from folks who thought a big program was 5000 lines and 
from those who thought big was 5,000,000 lines, and from pretty much any 
one else who chose to participate. Many had extensive experience in 
large scale software development.

During all of this requirements development process, compiler 
implementation started. In response to an RFP four teams were chosen to 
implement the language. (I think Tinman was then the latest requirement 
document.) The designs were evaluated publicly and the two best were 
told to go on, and later the better of the two completed implementation 
of what became Ada-83. I may have mis-remembered some of the details; 
it's been a long time.

Was the result perfect? Far from it, but I thought then and still think 
that Ada-83 was better for large mission-critical applications than any 
other language then available.

BUT: Ada was not designed by a committee, and the needs it was intended 
to meet were not theoretical. They were very practical.

All of that said, much of what was fine in Ada-83 was due to Jean 
Ichbiah, who led the team that did that implementation. I disagreed with 
some of Jean's decisions, some times vocally, but I later came to 
realize that he was usually right. Participation in the Ada design 
process was one of the high points of my career.

Art Evans
Distinguished Reviewer for Ada-83 and Ada-95

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Dennis Lee Bieber wrote:
>>
> 	Well... as I recall, it ("Green") became DOD standard 1815 in
> December of 1980. It took another few years to become an ISO standard.

1980 Dec: MIL-STD-1815, Ada 80
1983 Feb: ANSI/MIL-STD-1815A, Ada 83 (adopted as an ISO standard 1987)
1995 Jan: ISO/IEC 8652:1995, Ada 95 (Technical Corrigendum 1 adopted in 
2000)

Hopefully 2007 will see Ada 0X become a standard. On the Ada-comment 
mailing list there's a discussion of revising the wording for 
"equivalence" for ordered containers (originally discussed on c.l.a), so 
it may be a while yet.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: How come Ada isn't more popular?

[Robert A Duff]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Dennis Lee Bieber wrote:
>>>
>> 	Well... as I recall, it ("Green") became DOD standard 1815 in
>> December of 1980. It took another few years to become an ISO standard.
>
> 1980 Dec: MIL-STD-1815, Ada 80

I don't think the so-called Ada 80 standard was used for much of
anything.  Was it?

> 1983 Feb: ANSI/MIL-STD-1815A, Ada 83 (adopted as an ISO standard 1987)

That was the first real standard.

> 1995 Jan: ISO/IEC 8652:1995, Ada 95 (Technical Corrigendum 1 adopted in
> 2000)

> Hopefully 2007 will see Ada 0X become a standard.

I think Ada 2005 will become an ISO standard in 2007.
Even if ISO red tape holds it up for another 50 years,
it's still Ada 2005, in common parlance, and just "Ada"
in official parlance.

>... On the Ada-comment
> mailing list there's a discussion of revising the wording for
> "equivalence" for ordered containers (originally discussed on c.l.a), so
> it may be a while yet.

No.  Such minor bugs in the Standard will not delay it.
If a fix is necessary, it will be a correction to Ada 2005.

- Bob

Re: How come Ada isn't more popular?

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> I don't think the so-called Ada 80 standard was used for much of
> anything.  Was it?

IIRC, the 1st delivered Ada system was a payroll system in Ada 80.

> I think Ada 2005 will become an ISO standard in 2007.
> Even if ISO red tape holds it up for another 50 years,
> it's still Ada 2005, in common parlance, and just "Ada"
> in official parlance.

I'll call it Ada 07 when I need to distinguish it.

> No.  Such minor bugs in the Standard will not delay it.
> If a fix is necessary, it will be a correction to Ada 2005.

That's good to hear.

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: How come Ada isn't more popular?

[Randy Brukardt]

"Jeffrey R. Carter" <jrcarter@acm.org> wrote in message
news:Jfauh.240347$aJ.979@attbi_s21...
...
> Hopefully 2007 will see Ada 0X become a standard. On the Ada-comment
> mailing list there's a discussion of revising the wording for
> "equivalence" for ordered containers (originally discussed on c.l.a), so
> it may be a while yet.

Those sorts of bugs will go in a corrigendum or amendment to come down the
road.

The Amendment completed its last approval stage (the JTC1 vote) this week.
(There is a press release in preparation.) The only remaining task is for
the Amendment to be officially published. Can't say how long that will take,
but we now know that there won't be any substantial changes to it.

                        Randy Brukardt.

Re: How come Ada isn't more popular?

[JPWoodruff]

On Jan 22, 9:53 pm, artifact....@googlemail.com wrote:

>
> My question is: how come Ada isn't more popular?
>
I have another hypothesis that involves the way many programmers got
started at a young age.  For some decades, classes of smart young
teenagers have had easy access to computers and amateur tools, and
have honed their skills at what most of them called "hacking".  They
learned to reason in low levels of abstraction.  They spent a lot of
time in thread-of-execution debugging.

I think that software engineers who started their understanding in
that paradigm are a hard sell for Ada.  They do have techniques that
work and there are plentiful examples of their success, but we Ada
guys prefer something different.

There are other ways to come to the software engineering mindset. One
way is to want to write interesting essays in the form of executable
programs.  Ada is one of the finest tools for this task - at least as
far as our kind of program is concerned.

I submit Richard as an example - he writes whereof he knows.  A few of
the other deponents on this conversation are no slouches either. 

John

Re: How come Ada isn't more popular?

[gautier_niouzes]

> > My question is: how come Ada isn't more popular?I have another hypothesis that involves the way many programmers got
> started at a young age.  For some decades, classes of smart young
> teenagers have had easy access to computers and amateur tools, and
> have honed their skills at what most of them called "hacking".  They
> learned to reason in low levels of abstraction.  They spent a lot of
> time in thread-of-execution debugging.
>
> I think that software engineers who started their understanding in
> that paradigm are a hard sell for Ada.  They do have techniques that
> work and there are plentiful examples of their success, but we Ada
> guys prefer something different.
[...]

Probably one hurdle for Ada is that the "Ada guys", self-called "we,
the true Software Engineers" want to keep "their" language for
themselves and discourage the "young hackers" even to take a look at it
when they mature... :-)
You are missing some aspects:
- a hacking teenager (I was one) is able to evolve and see that the
some previous "hacks" stop quicker working because there too much
intrication between I/O, GUI, system, libraries, or the code was too
cryptic
- it is possible to hack in Ada; no surprise, such programs are the
only that compile and run after 10 years sleep, on a new environment;
you are happy there was no conditional compilation in the source,
whereas other hacks in another language stop a compiler at line 2 or
3...
- not having hacked in the young age does not help to program better.
If you look at the code of whatever time you see that untalented people
program exactly as poorly whatever they did in their young age. You see
these same huge chunks of copy-paste style instruction blocks in old
Fortran code or recent code of whatever language, with a mix of
interactive/non-interactive, mix of abstraction levels; these people
find that a subprogram is a kind of magic, so they prefer to activate
the copy-paste machine, which they think is safer...
If you succeeded in your effort of generation split (drawing Ada on the
"old" side, then into the coffin), yes, there would be trouble for that
language...
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: How come Ada isn't more popular?

[Alexander E. Kopilovich]

JPWoodruff wrote:

> classes of smart young
>teenagers have had easy access to computers and amateur tools, and
>have honed their skills at what most of them called "hacking".  They
>learned to reason in low levels of abstraction.  They spent a lot of
>time in thread-of-execution debugging.

Well, thread-of-execution is an extremely powerful abstraction, which appears
both as high-level and as low-level one. And thread-of-execution debugging
richly furnishes this abstraction with emotionally colored and socially 
sharable practical cases. No wonder that it attracts some fraction of smart
young teenagers.

> One way is to want to write interesting essays in the form of executable
>programs.  Ada is one of the finest tools for this task - at least as
>far as our kind of program is concerned.

The problem with this way is that it is hard to find a publishable subject,
which has sufficient potential of interest for "smart young teenagers" and
at the same time clearly demonstrates the strengths of Ada language.

It is because Ada language isn't adapted well for vague outlining of
possibilities and opportunities. Its main strengths are in expression of
very real and actual things, which, if are interesting, unfortunately almost
always are parts (or contain elements of or somehow connected with)
military/commercial/trade secrets.

Re: How come Ada isn't more popular?

[JPWoodruff]

On Jan 24, 5:01 pm, "Alexander E. Kopilovich" <a...@VB1162.spb.edu>
wrote:
> JPWoodruff wrote:
> > classes of smart young
> >teenagers

> And thread-of-execution debugging
> richly furnishes this abstraction with emotionally colored and socially
> sharable practical cases. No wonder that it attracts some fraction of smart
> young teenagers.

I take your point.  For all I know that's a good thing.  But my remark
was a claim that Ada won't capture those guys' attention easily.  Ada -
the way I've practiced her - has small use for execution tracing.

Still, the popularity topic is an open issue.

After all these years - thanks Arthur, Richard, et al for laying out
the history so clearly.  I like to believe the influence of that early
politics is waning.  Technical and economic arguments can be heard
above the echo of those early decisions (right?).

Maybe it's time to engage a social dimension in programming
experience.  Not for the first time, but this time on behalf of the
technical benefits of Ada.

I suggest that my hypothesis points to a way to engage next-generation
programmers.

I'd like there to be an opportunity to influence young learners toward
the "story telling" aspect of programming.  It would be nice to have
starter exercises with *narrative*.  These would accentuate the
program's content nouns above its behavior verbs.  Sad to say I have
absolutely no idea - nor any aptitude - how to make this happen.  So
it's just another pipe dream unless an idea lights the way.

> It is because Ada language isn't adapted well for vague outlining of
> possibilities and opportunities. Its main strengths are in expression of
> very real and actual things <...>

>From my experience, Ada does well at outlining, but that's a different
topic - maybe take it up later.

John

Re: How come Ada isn't more popular?

[Brian May]

>>>>> "artifact" == artifact one <artifact.one@googlemail.com> writes:

    artifact> My question is: how come Ada isn't more popular?

Reason 1: You have to wade through 400+ messages on the topic on
comp.lang.ada to find out the answer!

(a summary would be good... but I don't have time)

    artifact> This isn't intended to start a flame war, I'm genuinely
    artifact> interested.

Too late ;-)

Actually, more a discussion then a flame war, but anyway.

I know somebody who was forced to program in Ada and hated it.

I guess this just shows different people think in different ways.

Ada is very strict, and this is one of the reasons why I like it.
-- 
Brian May <bam@snoopy.apana.org.au>

RE: How come Ada isn't more popular?

[Randy Brukardt]

Dmitry A. Kazakov writes:

...
> Because it does not compose upon inheritance and aggregation.
>
> When inherited the constructing function need to be overridden, even if
> null record was the only thing added.

That's not true in Ada 2007. (That's a change I strongly opposed, BTW,
because it makes prototyping much harder. I usually start an extension with
a null record, figure out what needs to be overridden (giving those null
bodies), and then implement the actual routines and data. This no longer
works, because as soon as you add an extension component you are back to
square one.)

> Further one can barely publicly
> derive anything from T, which breaks encapsulation.

Not sure what you mean by this. It's certainly possible for a deivation to
break encapsulation (by deriving in a child unit, for instance), but you
really have to work at it.

It is annoying that we couldn't find a way to get composition to work for
anything other than :=, =, and stream attributes. (The lack of it for
finalization routines is especially aggrevating and error prone.) But the
workarounds for constructors aren't particularly bad, especially as you can
use extension aggregates in your overridings.

      (F with <new components>);

means that all of the new components are given; and you can pass whatever
parameters down to F.

                  Randy.

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Fri, 9 Feb 2007 22:18:51 -0600, Randy Brukardt wrote:

> Dmitry A. Kazakov writes:
> ...
>> Because it does not compose upon inheritance and aggregation.
>>
>> When inherited the constructing function need to be overridden, even if
>> null record was the only thing added.
> 
> That's not true in Ada 2007. (That's a change I strongly opposed, BTW,
> because it makes prototyping much harder. I usually start an extension with
> a null record, figure out what needs to be overridden (giving those null
> bodies), and then implement the actual routines and data. This no longer
> works, because as soon as you add an extension component you are back to
> square one.)

Yuck. Do I understand correctly, primitive operations are no more covariant
in the result?

   type T is tagged ...;
   function Foo return T;

   type S is new T ...;
      -- I don't need to override Foo????

>> Further one can barely publicly
>> derive anything from T, which breaks encapsulation.
> 
> Not sure what you mean by this. It's certainly possible for a deivation to
> break encapsulation (by deriving in a child unit, for instance),

Which is not always desirable or even possible, as we don't have multiple
parents (alas!).

> It is annoying that we couldn't find a way to get composition to work for
> anything other than :=, =, and stream attributes.

I think that the problem is that we have no unified composition model for
primitive operations. Things composed per magic (like ":=" or dispatching
subprograms) use different rules. Why don't we try to expose this mechanics
in the language? There certainly exist a common denominator of how
operations are composed. It is either of:

    g := f o g  -- f extends g
    g := g o f  -- f prepends g
    g := f       -- f replaces g
    g := e o g o p -- prologue and epilogue (conversion)
                   -- (like in out Natural accepting actual Integer)

All primitive operations including assignment, attributes, constructors
(from raw memory to object's invariant), destructors (backwards),
aggregates, conversions fall under some combination of these patterns.

This could radically simplify the language (fully backward compatible of
course).

> (The lack of it for
> finalization routines is especially aggrevating and error prone.)

Yes, especially, because there is no name for parent's Initialize/Finalize.

> But the
> workarounds for constructors aren't particularly bad, especially as you can
> use extension aggregates in your overridings.
> 
>       (F with <new components>);

Yes, aggregates compose (which is good), but they aren't functions. There
is an underlying thing which IMO should be named and exposed.

BTW, the aggregate above is almost equivalent to C++'s constructor
definition

    Derived::Derived (...) : F(...), <new components> {}

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 9 Feb 2007 22:18:51 -0600, Randy Brukardt wrote:
>
>> Dmitry A. Kazakov writes:
>> ...
>>> Because it does not compose upon inheritance and aggregation.
>>>
>>> When inherited the constructing function need to be overridden, even if
>>> null record was the only thing added.
>> 
>> That's not true in Ada 2007. (That's a change I strongly opposed, BTW,
>> because it makes prototyping much harder. I usually start an extension with
>> a null record, figure out what needs to be overridden (giving those null
>> bodies), and then implement the actual routines and data. This no longer
>> works, because as soon as you add an extension component you are back to
>> square one.)
>
> Yuck. Do I understand correctly, primitive operations are no more covariant
> in the result?
>
>    type T is tagged ...;
>    function Foo return T;
>
>    type S is new T ...;
>       -- I don't need to override Foo????

It depends what the "..." is.  You don't need to override Foo if it's
"with null record", which is what you were wanting above ("even if ...").

- Bob

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Sat, 10 Feb 2007 08:22:59 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 9 Feb 2007 22:18:51 -0600, Randy Brukardt wrote:
>>
>>> Dmitry A. Kazakov writes:
>>> ...
>>>> Because it does not compose upon inheritance and aggregation.
>>>>
>>>> When inherited the constructing function need to be overridden, even if
>>>> null record was the only thing added.
>>> 
>>> That's not true in Ada 2007. (That's a change I strongly opposed, BTW,
>>> because it makes prototyping much harder. I usually start an extension with
>>> a null record, figure out what needs to be overridden (giving those null
>>> bodies), and then implement the actual routines and data. This no longer
>>> works, because as soon as you add an extension component you are back to
>>> square one.)
>>
>> Yuck. Do I understand correctly, primitive operations are no more covariant
>> in the result?
>>
>>    type T is tagged ...;
>>    function Foo return T;
>>
>>    type S is new T ...;
>>       -- I don't need to override Foo????
> 
> It depends what the "..." is.  You don't need to override Foo if it's
> "with null record", which is what you were wanting above ("even if ...").

No, I didn't mean that. "Even if" was related to the model where
constructors were functions. This model is sometimes unnatural and the
requirement to override constructing function is a consequence of this
unnaturalness to me.

As for covariant functions, IMO the initial Ada 95 design is absolutely
correct, because whether a record was physically extended or not looks much
like an implementation detail to me. [*]

Constructors need not to be overridden when there is a way to generate them
safely. Though, I must admit that the difference looks too subtle.

---------
* Ideally, when deriving the programmer should be able to specify his
intent: whether the new type is equivalent, a generalization (extension), a
specialization (constraining) or both/neither. 

For generalization all primitive operations with out, in out parameters and
results of the base type should be required to be overridden.

For specialization all primitive operations with in and in out parameters
should be overridden.

For both everything need to be overridden.

(for overriding with the same body one could provide some syntax sugar)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How come Ada isn't more popular?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> * Ideally, when deriving the programmer should be able to specify his
> intent: whether the new type is equivalent, a generalization (extension), a
> specialization (constraining) or both/neither. 

I've been thinking the same thing.  What language has that capability?

- Bob

Re: How come Ada isn't more popular?

[Dmitry A. Kazakov]

On Mon, 12 Feb 2007 09:23:18 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> * Ideally, when deriving the programmer should be able to specify his
>> intent: whether the new type is equivalent, a generalization (extension), a
>> specialization (constraining) or both/neither. 
> 
> I've been thinking the same thing.  What language has that capability?

Ada 2010? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de