[parent not found: <dewar.855848896@merv>]
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
[not found] ` <dewar.855848896@merv>
@ 1997-02-16 0:00 ` Jon S Anthony
1997-02-18 0:00 ` Robert Dewar
1997-02-22 0:00 ` Jon S Anthony
` (9 subsequent siblings)
11 siblings, 1 reply; 77+ messages in thread
From: Jon S Anthony @ 1997-02-16 0:00 UTC (permalink / raw)
In article <dewar.855983270@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> The GNAT capability is not just a simulation but an exact and complete
> copy, with even a reasonable approximation of the SNOBOL-4 syntax. The
> code for the pattern matching (about 6000 lines of code with comments)
> is a complete pattern matching implementation including recursive
> patterns, and dynamic pattern assignment. The code uses the same
> algorithm as the pattern matcher I wrote for Macro SPITBOL.
That's impressive. Too bad it won't be portable. :-(
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-16 0:00 ` Jon S Anthony
@ 1997-02-18 0:00 ` Robert Dewar
0 siblings, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-02-18 0:00 UTC (permalink / raw)
Jon said
<<That's impressive. Too bad it won't be portable. :>>
As I mentioned before, our goal here is maximum functionality for GNAT
users. The unfortunate thing is the restrictions on the use of Access
being applied to nested procedures. These restrictions were considered
necessary during the design phase of Ada 95, to make it more practical
for compilers using displays (notably Alsys and RR) to implement access
to procedure.
For a compiler that uses static links, there is really no need to have
these restrictions, and that is why GNAT provides the attribute
Unrestricted_Access, which *can* be freely applied to procedures.
The SPITBOL pattern matching stuff relies significantly on this
attribute, both at the implementation level and at the usage level.
The other important aspect of the implementation is some intimate
knowledge of the way Unbounded_String's are implemented in GNAT. This
is an efficiency issue, but a pretty important one!
Robert Dewar
Ada Core Technologies
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
[not found] ` <dewar.855848896@merv>
1997-02-16 0:00 ` Jon S Anthony
@ 1997-02-22 0:00 ` Jon S Anthony
1997-02-21 0:00 ` Brian Rogoff
1997-02-23 0:00 ` Robert Dewar
1997-02-25 0:00 ` Jon S Anthony
` (8 subsequent siblings)
11 siblings, 2 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-02-22 0:00 UTC (permalink / raw)
In article <dewar.856305993@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jon said
>
> <<That's impressive. Too bad it won't be portable. :>>
>
> As I mentioned before, our goal here is maximum functionality for GNAT
> users.
Oh, I realize and readily accept that position. It may have been cool
to have defined some version of this as an Annex or part of some
appropriate Annex, but...
> The unfortunate thing is the restrictions on the use of Access
> being applied to nested procedures. These restrictions were considered
> necessary during the design phase of Ada 95, to make it more practical
> for compilers using displays (notably Alsys and RR) to implement access
> to procedure.
You don't _really_ want to open up _that_ discussion again, do you?
:-) :-)
We all know about the closure stuff...
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-22 0:00 ` Jon S Anthony
@ 1997-02-21 0:00 ` Brian Rogoff
1997-02-22 0:00 ` Robert Dewar
1997-02-23 0:00 ` Robert Dewar
1 sibling, 1 reply; 77+ messages in thread
From: Brian Rogoff @ 1997-02-21 0:00 UTC (permalink / raw)
To: Jon S Anthony
On 22 Feb 1997, Jon S Anthony wrote:
> In article <dewar.856305993@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
> > Jon said
> >
> > <<That's impressive. Too bad it won't be portable. :>>
> >
> > The unfortunate thing is the restrictions on the use of Access
> > being applied to nested procedures. These restrictions were considered
> > necessary during the design phase of Ada 95, to make it more practical
> > for compilers using displays (notably Alsys and RR) to implement access
> > to procedure.
>
> You don't _really_ want to open up _that_ discussion again, do you?
> :-) :-)
That was actually a good discussion, much better than all of this
OO and C++ stuff ;-).
Seriously, I was convinced at the end of that discussion that the
restriction was necessary for "political" reasons. But stuff like this
library makes me more sore about it. Ada could have been a better language.
Oh well.
> We all know about the closure stuff...
And the iterator stuff...
It would be an interesting experimental addition to GNAT to support
Pascalish function arguments, or even (as R. O'Keefe suggested) anonymous
"downward closures" in function arguments.
-- Brian
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-21 0:00 ` Brian Rogoff
@ 1997-02-22 0:00 ` Robert Dewar
1997-02-22 0:00 ` Brian Rogoff
0 siblings, 1 reply; 77+ messages in thread
From: Robert Dewar @ 1997-02-22 0:00 UTC (permalink / raw)
iBrian said
<< Seriously, I was convinced at the end of that discussion that the
restriction was necessary for "political" reasons. But stuff like this
library makes me more sore about it. Ada could have been a better language.
Oh well.>>
Yes, but best is the enemy of good :-)
Actually I think it is remarkable how few compromises were needed to get
rapid unanimous approval of the Ada 95 standard.
Sure everyone has a few pet peeves. Tuck will never forgive Robert for
helping to keep 'Class for untagged types out (neither will Bob Duff),
and Robert will never forgive Tuck for refusing to fight for in out
parameters for functions (but can't blame Bob, he agrees with me on
that one).
P.S. a giant :-) applies to the last paragraph :-)
Note that the particular case at hand (restricting 'Access on subprograms
because of dificulties with display implementations) did not turn out to
be a theoretical concern. Two of the currently validated Ada 95 compilers
(Aonix and RR), both use displays. Now who can say if this one thing would
have been enough to seriously discombobulate those two implementations (at
the time, both vendors thought it was significant).
Sure, this particular decision did not affect GNAT, but we think it is a good
thing that there are multiple Ada 95 compilers around. Nothing like
competition to sharpen technical products. We think that GNAT is the best
Ada 95 compiler, but we also think we have to run hard to keep it that way,
given the competition, and everyone benefits from this.
Robert Dewar
Ada Core Technologies
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-22 0:00 ` Robert Dewar
@ 1997-02-22 0:00 ` Brian Rogoff
0 siblings, 0 replies; 77+ messages in thread
From: Brian Rogoff @ 1997-02-22 0:00 UTC (permalink / raw)
On 22 Feb 1997, Robert Dewar wrote:
> iBrian said
>
> << Seriously, I was convinced at the end of that discussion that the
> restriction was necessary for "political" reasons. But stuff like this
> library makes me more sore about it. Ada could have been a better language.
> Oh well.>>
>
> Yes, but best is the enemy of good :-)
Of course. I am still convinced that the compromise was correct.
If the issue is ever revisited in the design of a future "Ada-like"
language, all of the GNAT code that uses Unrestricted_Access will
provide support to those who argue for removing the restriction.
> Sure everyone has a few pet peeves. Tuck will never forgive Robert for
> helping to keep 'Class for untagged types out (neither will Bob Duff),
> and Robert will never forgive Tuck for refusing to fight for in out
> parameters for functions (but can't blame Bob, he agrees with me on
> that one).
>
> P.S. a giant :-) applies to the last paragraph :-)
It would be great if all of the minutes of those design discussions
were HTMLified. (So, why *didn't* you want 'Class for untagged types?)
>
> Note that the particular case at hand (restricting 'Access on subprograms
> because of dificulties with display implementations) did not turn out to
> be a theoretical concern. Two of the currently validated Ada 95 compilers
> (Aonix and RR), both use displays. Now who can say if this one thing would
> have been enough to seriously discombobulate those two implementations (at
> the time, both vendors thought it was significant).
I think not delaying these compilers was a good enough reason,
and was much more compelling than the technical arguments. But I can
still be sore, can't I? ;-)
-- Brian
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-22 0:00 ` Jon S Anthony
1997-02-21 0:00 ` Brian Rogoff
@ 1997-02-23 0:00 ` Robert Dewar
1 sibling, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-02-23 0:00 UTC (permalink / raw)
Jon Anthony said
(of the SPITBOL pattern matching package)
<<Oh, I realize and readily accept that position. It may have been cool
to have defined some version of this as an Annex or part of some
appropriate Annex, but...>>
Oh no! That misunderstands the purposes of the annexes which is to codify
a small subset of standard functionality that everyone could agree on as
essential. Simulating SNOBOL4 pattern matching is *way* outside that mandate!
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (2 preceding siblings ...)
1997-02-22 0:00 ` Jon S Anthony
@ 1997-02-25 0:00 ` Jon S Anthony
1997-02-26 0:00 ` Robert Dewar
1997-02-27 0:00 ` Jon S Anthony
` (7 subsequent siblings)
11 siblings, 1 reply; 77+ messages in thread
From: Jon S Anthony @ 1997-02-25 0:00 UTC (permalink / raw)
In article <dewar.856737108@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Oh no! That misunderstands the purposes of the annexes which is to codify
> a small subset of standard functionality that everyone could agree on as
> essential. Simulating SNOBOL4 pattern matching is *way* outside that mandate!
I suppose so. But the annexes could be so much more useful. They
could even act as a kind of inter standard place for certain things
like this string stuff (assuming some sort of "formalization"
process) or more interesting GC stuff.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-25 0:00 ` Jon S Anthony
@ 1997-02-26 0:00 ` Robert Dewar
0 siblings, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-02-26 0:00 UTC (permalink / raw)
Jon said
<<I suppose so. But the annexes could be so much more useful. They
could even act as a kind of inter standard place for certain things
like this string stuff (assuming some sort of "formalization"
process) or more interesting GC stuff.>>
One person's "so much more useful" stuff is another person's
gratuitious rubbish. The point was to go as far as there was consensus
support, and not further. I would certainly have been very opposed
to even considering elaborate pattern matching stuff, there are too
many ways to approach this problem to decree one as standard. Similarly
for GC, it is clear that there would be no consensus on this addition.
Sure Jon, you have a pet list of stuff you would like to have avalailable,
but the annexes are not about pet stuff!
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (3 preceding siblings ...)
1997-02-25 0:00 ` Jon S Anthony
@ 1997-02-27 0:00 ` Jon S Anthony
1997-03-02 0:00 ` Robert Dewar
1997-03-02 0:00 ` Robert Dewar
1997-03-03 0:00 ` Jon S Anthony
` (6 subsequent siblings)
11 siblings, 2 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-02-27 0:00 UTC (permalink / raw)
In article <dewar.857004623@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
Robert goes off half cocked,
> Jon said
>
> <<I suppose so. But the annexes could be so much more useful. They
> could even act as a kind of inter standard place for certain things
> like this string stuff (assuming some sort of "formalization"
> process) or more interesting GC stuff.>>
>
> One person's "so much more useful" stuff is another person's
> gratuitious rubbish.
Wow.
> to even considering elaborate pattern matching stuff, there are too
> many ways to approach this problem to decree one as standard. Similarly
> for GC, it is clear that there would be no consensus on this addition.
There are "too many" ways to approach a language design to decree any
as standard. Sounds pretty silly, eh?
As for the GC example, you yourself suggested this as a possibility.
I believe I still have the post saved where you stated so.
> Sure Jon, you have a pet list of stuff you would like to have avalailable,
> but the annexes are not about pet stuff!
Well, that is your interpretation of what I said. A pretty odd one at
that. Shrug.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-27 0:00 ` Jon S Anthony
@ 1997-03-02 0:00 ` Robert Dewar
1997-03-02 0:00 ` Robert Dewar
1 sibling, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-03-02 0:00 UTC (permalink / raw)
Jon said
<<As for the GC example, you yourself suggested this as a possibility.
I believe I still have the post saved where you stated so.>>
Indeed, but read more carefully what I said, I said "the more interesting
GC stuff", and that is what I meant!
I think something could have been done in the GC area if there had been
any consensus (there was not, there was ZERO support for including anything
in the GC area).
When it comes to the pattern matching stuff I certainly disagree, but
then I don't know if Jon really knows SNOBOL4, and realizes the kind of
level of capability that I am talking about (remember that Jon is guessing
that the implementation of GNAT.Spitbol.Patterns, sight unseen, might be
suitable for an annex. For all kinds of reasons it is not!
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-27 0:00 ` Jon S Anthony
1997-03-02 0:00 ` Robert Dewar
@ 1997-03-02 0:00 ` Robert Dewar
1997-03-03 0:00 ` Fergus Henderson
1 sibling, 1 reply; 77+ messages in thread
From: Robert Dewar @ 1997-03-02 0:00 UTC (permalink / raw)
Jon said
<<> One person's "so much more useful" stuff is another person's
> gratuitious rubbish.
Wow.
> to even considering elaborate pattern matching stuff, there are too
> many ways to approach this problem to decree one as standard. Similarly
> for GC, it is clear that there would be no consensus on this addition.
There are "too many" ways to approach a language design to decree any
as standard. Sounds pretty silly, eh?>>
Not to anyone with any experience in language standardization. You only
want to standardize something if there is reasonable consensus gathered
around one particular approach. If there are many ways of doing something,
and no agreement as to what the best approach is, and substantial argument
about which is the best way, then you really have no basis for a standard.
Sometimes, there can be multiple ways of doing things (e.g. drive on the
right, or drive on the left), but it really does not matter which you choose,
so long as you choose one of the possibilities, since what is important is
that there *is* a standard.
But on anything where there is real disagreement, you can't make progress
often, and you just have to agree that you cannot agree on a standard
in that area.
Jon, I think you would have been *quite* frustrated with the Ada 95
effort (or any other language standardization effort for that matter).
It is not good enough in such an effort to be technically correct, you
have to be able to convince other people to gather behind one particular
approach (hint: resorting to name calling as in "going off half cocked" is
unlikely to succeed as a tactic -- sometimes good technical arguments
succeed, but even there you can find yourself frustrated :-)
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-02 0:00 ` Robert Dewar
@ 1997-03-03 0:00 ` Fergus Henderson
1997-03-03 0:00 ` Robert Dewar
1997-03-03 0:00 ` Larry Kilgallen
0 siblings, 2 replies; 77+ messages in thread
From: Fergus Henderson @ 1997-03-03 0:00 UTC (permalink / raw)
dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> ... to even considering elaborate pattern matching stuff, there are too
> many ways to approach this problem to decree one as standard. Similarly
> for GC, it is clear that there would be no consensus on this addition.
Certainly there is plenty of disagreement about whether or not GC
should be provided. But it's not clear to me that you couldn't achieve
concensus about a minimal portable API for GC, for those
implementations that do provide it. What makes you think this would be
so hard?
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Fergus Henderson
@ 1997-03-03 0:00 ` Robert Dewar
1997-03-03 0:00 ` Larry Kilgallen
1 sibling, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-03-03 0:00 UTC (permalink / raw)
Fergus said
<<Certainly there is plenty of disagreement about whether or not GC
should be provided. But it's not clear to me that you couldn't achieve
concensus about a minimal portable API for GC, for those
implementations that do provide it. What makes you think this would be
so hard?>>
Because I tried to explore this possibility during the design, and there
was a clear consensus that this was a bad idea, and lots of disagreement
on how one might approach the problem, and lots of agreement that no one
knew enough to be sure that one particular approach was the best, or even
good enough to be standardized.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Fergus Henderson
1997-03-03 0:00 ` Robert Dewar
@ 1997-03-03 0:00 ` Larry Kilgallen
1997-03-04 0:00 ` Fergus Henderson
1997-03-05 0:00 ` Jon S Anthony
1 sibling, 2 replies; 77+ messages in thread
From: Larry Kilgallen @ 1997-03-03 0:00 UTC (permalink / raw)
In article <5fdu5d$hn5@mulga.cs.mu.OZ.AU>, fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
> Certainly there is plenty of disagreement about whether or not GC
> should be provided. But it's not clear to me that you couldn't achieve
> concensus about a minimal portable API for GC, for those
> implementations that do provide it. What makes you think this would be
> so hard?
I thought the Ada design allowed Garbage Collection to "just work"
without any changes to the source code. Why would one need an API ?
Larry Kilgallen
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Larry Kilgallen
@ 1997-03-04 0:00 ` Fergus Henderson
1997-03-05 0:00 ` Jon S Anthony
1 sibling, 0 replies; 77+ messages in thread
From: Fergus Henderson @ 1997-03-04 0:00 UTC (permalink / raw)
kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>> Certainly there is plenty of disagreement about whether or not GC
>> should be provided. But it's not clear to me that you couldn't achieve
>> concensus about a minimal portable API for GC, for those
>> implementations that do provide it. What makes you think this would be
>> so hard?
>
>I thought the Ada design allowed Garbage Collection to "just work"
>without any changes to the source code. Why would one need an API ?
There's a couple of reasons. The main one is that since Ada supports
interfacing to C and other languages, you need to know how GC interacts
with multi-language programming. The API needs to specify that.
(A minimal portable API wouldn't give a programmer many guarantees here,
but as always, implementations would be free to guarantee more than the
standard.)
For some applications it is important to be able to exercise some
fine-grained control of garbage collection, and so it may be desirable
for the API to provide ways to explicitly request a full or partial
garbage collection, or to temporarily disable collection. It may also
be desirable for a program to be able to specify that it requires
garbage collection, or to request incremental collection, perhaps via a
configuration pragma. Other potentially desirable functionality
includes weak pointers and finalizers, although such features would be
harder to standardize.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Larry Kilgallen
1997-03-04 0:00 ` Fergus Henderson
@ 1997-03-05 0:00 ` Jon S Anthony
1 sibling, 0 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-03-05 0:00 UTC (permalink / raw)
In article <1997Mar5.081213.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> In article <5fh5g0$80h@fg70.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
> > In comp.lang.ada, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> >
> >>I strongly disagree that GC
> >>should not be simply transparent, and I do not like the idea of
> >>standardizing explicit programmer control, whatever that might be.
> >
> > In a realtime application, I do not want to have time-critical parts
> > interrupted by GC.
>
> That can be specified when instantiating the compiler purchase order.
>
> Currently all known implementations support your goal!
Is there a version of AdaMagic without GC? Seems unlikely. Doesn't
seem to make any sense either.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (4 preceding siblings ...)
1997-02-27 0:00 ` Jon S Anthony
@ 1997-03-03 0:00 ` Jon S Anthony
1997-03-03 0:00 ` Jon S Anthony
` (5 subsequent siblings)
11 siblings, 0 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-03-03 0:00 UTC (permalink / raw)
In article <5fdu5d$hn5@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
> > ... to even considering elaborate pattern matching stuff, there are too
> > many ways to approach this problem to decree one as standard. Similarly
> > for GC, it is clear that there would be no consensus on this addition.
>
> Certainly there is plenty of disagreement about whether or not GC
> should be provided. But it's not clear to me that you couldn't achieve
> concensus about a minimal portable API for GC, for those
> implementations that do provide it. What makes you think this would be
> so hard?
I could not agree more with this position and the apparent sentiment
behind it. Whether or not it is achievable, I don't know, but it is
anything but a silly or "gratuitous rubbish".
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (5 preceding siblings ...)
1997-03-03 0:00 ` Jon S Anthony
@ 1997-03-03 0:00 ` Jon S Anthony
1997-03-03 0:00 ` Jon S Anthony
` (4 subsequent siblings)
11 siblings, 0 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-03-03 0:00 UTC (permalink / raw)
In article <dewar.857349976@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jon said
>
> <<As for the GC example, you yourself suggested this as a possibility.
> I believe I still have the post saved where you stated so.>>
>
> Indeed, but read more carefully what I said, I said "the more interesting
> GC stuff", and that is what I meant!
Shrug.
> When it comes to the pattern matching stuff I certainly disagree, but
> then I don't know if Jon really knows SNOBOL4, and realizes the kind of
> level of capability that I am talking about (remember that Jon is guessing
> that the implementation of GNAT.Spitbol.Patterns, sight unseen, might be
> suitable for an annex. For all kinds of reasons it is not!
First, I kinda sorta know SNOBOL4, i.e, I've looked over various
descriptions of it. I even modeled my own set of generic pattern
matching packages after some of the stuff available there and have
used them for some years. They are extremely handy in many diverse
settings.
Second, I never said, and you incorrectly presume, that I think the
GNAT stuff here should be in annex. I have no idea. For all I know
it may indeed be "gratuitous rubbish". I merely said that some
_definition_ or _specification_ of a pattern matching capability
_might_ be a nice thing to have in an annex. It may well be that this
would not be agreed to by reason that it was somehow too specific or
something.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (6 preceding siblings ...)
1997-03-03 0:00 ` Jon S Anthony
@ 1997-03-03 0:00 ` Jon S Anthony
1997-03-03 0:00 ` Robert Dewar
1997-03-03 0:00 ` Jon S Anthony
` (3 subsequent siblings)
11 siblings, 1 reply; 77+ messages in thread
From: Jon S Anthony @ 1997-03-03 0:00 UTC (permalink / raw)
In article <dewar.857350120@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jon said
>
> There are "too many" ways to approach a language design to decree any
> as standard. Sounds pretty silly, eh?>>
>
> Not to anyone with any experience in language standardization. You only
Does this mean that you believe that there should not be any language
standards? Probably not. But that is what you are saying, even
thought that is almost certainly not what you mean. There are indeed
a boatload of ways of doing this, but that does not mean that some
should not be selected and then refined into a "standard". Now, your
comments here and in the previous post would seem to suggest that you
do not think this is a good idea or correct approach.
> But on anything where there is real disagreement, you can't make progress
> often, and you just have to agree that you cannot agree on a standard
> in that area.
Sure. Absolutely agree.
> Jon, I think you would have been *quite* frustrated with the Ada 95
> effort (or any other language standardization effort for that matter).
Maybe, but I'm not so sure. What I get frustrated about are people
who _presume_ to know everything up front about what the other party
is saying and then proceed to give all sorts of odd or strawman
interpretations of the other view as though they were fact.
> It is not good enough in such an effort to be technically correct, you
> have to be able to convince other people to gather behind one particular
> approach (hint: resorting to name calling as in "going off half cocked" is
> unlikely to succeed as a tactic -- sometimes good technical arguments
> succeed, but even there you can find yourself frustrated :-)
Oh you mean like "gratuitous rubbish" and "pet list of stuff". Well,
of course I agree with you on this. And yes, this sort of thing is
true in any environment where you have multiple stakeholders with
different ideas about what the "model" should be. This is not
restricted to PL design/standards efforts. The most typical problem
here is that the parties involved do not even know what each _means_
by the things being said. But they _presume_ they know. Typically
this is because the two (or more) involved have a significant overlap
of understanding, but then make the mistake of thinking their view
must surely extend to everything the other party understands. And
thus, if that party seems to be saying something not in accord with
your internal model, then of course they are mistaken and speaking
nonsense.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (7 preceding siblings ...)
1997-03-03 0:00 ` Jon S Anthony
@ 1997-03-03 0:00 ` Jon S Anthony
1997-03-03 0:00 ` Robert Dewar
` (2 more replies)
1997-03-04 0:00 ` Jon S Anthony
` (2 subsequent siblings)
11 siblings, 3 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-03-03 0:00 UTC (permalink / raw)
In article <1997Mar3.082830.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> In article <5fdu5d$hn5@mulga.cs.mu.OZ.AU>, fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>
> > Certainly there is plenty of disagreement about whether or not GC
> > should be provided. But it's not clear to me that you couldn't achieve
> > concensus about a minimal portable API for GC, for those
> > implementations that do provide it. What makes you think this would be
> > so hard?
>
> I thought the Ada design allowed Garbage Collection to "just work"
> without any changes to the source code. Why would one need an API ?
Because there are areas and cases where the GC should not be simply
"transparent". That it should have some explicit programmer control
available. It should also be defined how it interacts with manual
memory management - at least at the program model level. There may be
some other interesting aspects such as selectable GC style based on
the types of objects to be controlled. In the case of Ada this might
be defined in terms of certain storage pools and such. There are
probably others.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Jon S Anthony
@ 1997-03-03 0:00 ` Robert Dewar
1997-03-04 0:00 ` Thomas Koenig
[not found] ` <dewar.857447653@m <JSA.97Mar4154951@alexandria>
1997-03-05 0:00 ` Jon S Anthony
2 siblings, 1 reply; 77+ messages in thread
From: Robert Dewar @ 1997-03-03 0:00 UTC (permalink / raw)
Jon said
<<Because there are areas and cases where the GC should not be simply
"transparent". That it should have some explicit programmer control
available.>>
Well there is a contentions statement. I strongly disagree that GC
should not be simply transparent, and I do not like the idea of
standardizing explicit programmer control, whatever that might be.
Certainly if you take the position that GC should only be standardized
with suchj explicit programmer control, you would lose my support at
the standardization (which is too bad, since I seemed to be the only
one around the Ada 95 design effort with any sympathy for GC!)
GC in SNOBOL4 is indeed transparent, and that is the way things should
be in my opinion.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Robert Dewar
@ 1997-03-04 0:00 ` Thomas Koenig
1997-03-05 0:00 ` Larry Kilgallen
1997-03-06 0:00 ` Robert Dewar
0 siblings, 2 replies; 77+ messages in thread
From: Thomas Koenig @ 1997-03-04 0:00 UTC (permalink / raw)
In comp.lang.ada, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>I strongly disagree that GC
>should not be simply transparent, and I do not like the idea of
>standardizing explicit programmer control, whatever that might be.
In a realtime application, I do not want to have time-critical parts
interrupted by GC.
--
74 a3 53 cc 0b 19
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-04 0:00 ` Thomas Koenig
@ 1997-03-05 0:00 ` Larry Kilgallen
1997-03-06 0:00 ` Robert Dewar
1997-03-06 0:00 ` Robert Dewar
1 sibling, 1 reply; 77+ messages in thread
From: Larry Kilgallen @ 1997-03-05 0:00 UTC (permalink / raw)
In article <5fh5g0$80h@fg70.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
> In comp.lang.ada, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
>>I strongly disagree that GC
>>should not be simply transparent, and I do not like the idea of
>>standardizing explicit programmer control, whatever that might be.
>
> In a realtime application, I do not want to have time-critical parts
> interrupted by GC.
That can be specified when instantiating the compiler purchase order.
Currently all known implementations support your goal!
Larry Kilgallen
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-04 0:00 ` Thomas Koenig
1997-03-05 0:00 ` Larry Kilgallen
@ 1997-03-06 0:00 ` Robert Dewar
1 sibling, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-03-06 0:00 UTC (permalink / raw)
Thomas said
<<In a realtime application, I do not want to have time-critical parts
interrupted by GC.>>
Well certainly not, but obviously garbage collectoin needs to be under
programmer control at least to the extent of turning it on or off, presumably
by using the storage pool mechanism, or options having the same effect.
I do not think that is what we are talking about here in discussing
GC API's.
^ permalink raw reply [flat|nested] 77+ messages in thread
[parent not found: <dewar.857447653@m <JSA.97Mar4154951@alexandria>]
* Re: Reading a line of arbitrary length
[not found] ` <dewar.857447653@m <JSA.97Mar4154951@alexandria>
@ 1997-03-05 0:00 ` Robert A Duff
0 siblings, 0 replies; 77+ messages in thread
From: Robert A Duff @ 1997-03-05 0:00 UTC (permalink / raw)
In article <JSA.97Mar4154951@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>In article <dewar.857447653@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>> Jon said
>>
>> <<Because there are areas and cases where the GC should not be simply
>> "transparent". That it should have some explicit programmer control
>> available.>>
>>
>> Well there is a contentions statement. I strongly disagree that GC
>> should not be simply transparent, and I do not like the idea of
>> standardizing explicit programmer control, whatever that might be.
>
>Yes, it is. These are merely points that have been made in GC
>circles. I'm not _advocating_ them, just trying to point out various
>reason why a "defined standard minimal interface" may be needed.
Well, there are lots of useful performance-tuning hooks that are
supported by many existing garbage collectors. If one were
standardizing the existence of GC, it's not clear whether (some) such
hooks should be standardized as well. Probably performance-tuning hooks
are "transparent" in Robert's view, and I would agree, but the
programmer would still like to know how to spell the "Please GC now"
command, for example.
There are some interesting interactions between finalization and GC.
The simplest answer is that any object with controlled parts is "live",
so the GC can't collect it. But that's not what people want, I think.
At least not all the time. (Maybe only for non-limited controlled
things?) People probably want the GC to finalize things just before
reclaiming their storage. But this opens up various issues: What if the
Finalize routine takes an otherwise-dead object, and resurrects it by
planting a pointer to it somewhere? What if the Finalize routine calls
a non-reentrant procedure, and the GC decides to call Finalize at an
embarrassing time? Are there any constraints on the order in which
Finalize routines get called in a case where several heap objects become
dead at the same time? A standard for a GC'ed Ada would certainly need
to address these issues.
Somebody else mentioned the other area in which GC is not transparent:
interfacing to other languages. Garbage collection is a global problem,
so if just one small part of your program is written in, say, C, then
the programmer needs to know whose responsibility it is to deal with
pointers from the C side to the Ada side. Is the GC conservative? Or
does the user have to ensure that any such pointer is duplicated on the
Ada side?
The above is talking about an imaginary universe in which Ada 95
requires garbage collection. There's also the issue of what it means to
"require" GC -- one would need a much more specific (and complicated)
model of storage usage. Or else one would need to rely on untestable
"requirements", which has worked fine for Lisp and Eiffel and lots of
others.
- Bob
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-03 0:00 ` Jon S Anthony
1997-03-03 0:00 ` Robert Dewar
[not found] ` <dewar.857447653@m <JSA.97Mar4154951@alexandria>
@ 1997-03-05 0:00 ` Jon S Anthony
1997-03-06 0:00 ` Robert A Duff
2 siblings, 1 reply; 77+ messages in thread
From: Jon S Anthony @ 1997-03-05 0:00 UTC (permalink / raw)
In article <E6KxGL.B35@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
> hooks should be standardized as well. Probably performance-tuning hooks
> are "transparent" in Robert's view, and I would agree, but the
> programmer would still like to know how to spell the "Please GC now"
> command, for example.
Right. This is certainly one such example.
> There are some interesting interactions between finalization and GC.
> The simplest answer is that any object with controlled parts is "live",
> so the GC can't collect it. But that's not what people want, I think.
> At least not all the time. (Maybe only for non-limited controlled
> things?) People probably want the GC to finalize things just before
> reclaiming their storage. But this opens up various issues: What if the
> Finalize routine takes an otherwise-dead object, and resurrects it by
> planting a pointer to it somewhere? What if the Finalize routine calls
> a non-reentrant procedure, and the GC decides to call Finalize at an
> embarrassing time? Are there any constraints on the order in which
> Finalize routines get called in a case where several heap objects become
> dead at the same time? A standard for a GC'ed Ada would certainly need
> to address these issues.
Agree. These are again good example issues. Another area would seem
to be task interaction.
> Somebody else mentioned the other area in which GC is not transparent:
> interfacing to other languages. Garbage collection is a global problem,
> so if just one small part of your program is written in, say, C, then
> the programmer needs to know whose responsibility it is to deal with
> pointers from the C side to the Ada side. Is the GC conservative? Or
> does the user have to ensure that any such pointer is duplicated on the
> Ada side?
That would be Fergus, and certainly for Ada (Interfaces.* and all)
this is another area.
> model of storage usage. Or else one would need to rely on untestable
> "requirements", which has worked fine for Lisp and Eiffel and lots of
> others.
Agree.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-05 0:00 ` Jon S Anthony
@ 1997-03-06 0:00 ` Robert A Duff
1997-03-06 0:00 ` Robert Dewar
0 siblings, 1 reply; 77+ messages in thread
From: Robert A Duff @ 1997-03-06 0:00 UTC (permalink / raw)
In article <JSA.97Mar5182055@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>Agree. These are again good example issues. Another area would seem
>to be task interaction.
Yes, there are lots of "interesting" issues wrt tasks vs GC. Much of
the GC research (certainly not all) assumes a single sequential
program. E.g. in a sequential program, it makes sense for the "new"
operation to check available memory and whatnot, and then perhaps invoke
the GC to do some work. But that becomes rather more complicated when
there might be other tasks doing who-knows-what at the same time.
Many GC algorithms require all tasks to be in some "safe" place before
the GC can do its thing. This requires some sort of synchronization,
and making that efficient is not easy. I'm not sure if that requires
user-accessible hooks, though.
- Bob
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-06 0:00 ` Robert A Duff
@ 1997-03-06 0:00 ` Robert Dewar
0 siblings, 0 replies; 77+ messages in thread
From: Robert Dewar @ 1997-03-06 0:00 UTC (permalink / raw)
Bob Duff saide
<<Yes, there are lots of "interesting" issues wrt tasks vs GC. Much of
the GC research (certainly not all) assumes a single sequential
program. E.g. in a sequential program, it makes sense for the "new"
operation to check available memory and whatnot, and then perhaps invoke
the GC to do some work. But that becomes rather more complicated when
there might be other tasks doing who-knows-what at the same time.>>
*certainly* not all. There is an extensive literature on garbage collection
in Algol-68, a language with full tasking capabilities, and full transparent
garbage collection. These problems were solved a long time ago!
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (8 preceding siblings ...)
1997-03-03 0:00 ` Jon S Anthony
@ 1997-03-04 0:00 ` Jon S Anthony
1997-03-05 0:00 ` Larry Kilgallen
1997-03-04 0:00 ` Reading a line of arbitrary length Jon S Anthony
1997-03-05 0:00 ` Jon S Anthony
11 siblings, 1 reply; 77+ messages in thread
From: Jon S Anthony @ 1997-03-04 0:00 UTC (permalink / raw)
In article <dewar.857447653@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jon said
>
> <<Because there are areas and cases where the GC should not be simply
> "transparent". That it should have some explicit programmer control
> available.>>
>
> Well there is a contentions statement. I strongly disagree that GC
> should not be simply transparent, and I do not like the idea of
> standardizing explicit programmer control, whatever that might be.
Yes, it is. These are merely points that have been made in GC
circles. I'm not _advocating_ them, just trying to point out various
reason why a "defined standard minimal interface" may be needed.
> GC in SNOBOL4 is indeed transparent, and that is the way things should
> be in my opinion.
Well, as Rick said upon first meeting Maj.Strasser, "Let's just say I
understand the point of view of the fox as well as the hound's"
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-04 0:00 ` Jon S Anthony
@ 1997-03-05 0:00 ` Larry Kilgallen
1997-03-06 0:00 ` Fergus Henderson
0 siblings, 1 reply; 77+ messages in thread
From: Larry Kilgallen @ 1997-03-05 0:00 UTC (permalink / raw)
In article <JSA.97Mar4154951@alexandria>, jsa@alexandria (Jon S Anthony) writes:
> In article <dewar.857447653@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>> Jon said
>>
>> <<Because there are areas and cases where the GC should not be simply
>> "transparent". That it should have some explicit programmer control
>> available.>>
>>
>> Well there is a contentions statement. I strongly disagree that GC
>> should not be simply transparent, and I do not like the idea of
>> standardizing explicit programmer control, whatever that might be.
>
> Yes, it is. These are merely points that have been made in GC
> circles. I'm not _advocating_ them, just trying to point out various
> reason why a "defined standard minimal interface" may be needed.
It seems to me that by omission the Ada 95 (or 83, for that matter)
reference manual establishes that the "defined standard minimal interface"
is one without programmer control or API. Anything on top of that is
implementation-specific.
To specify anything further with no confirmed sightings of potential
implementors would give the impression that standards committees are
paid by the word.
Larry Kilgallen
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-03-05 0:00 ` Larry Kilgallen
@ 1997-03-06 0:00 ` Fergus Henderson
1997-03-06 0:00 ` Really more GC talk (was: Reading a line of arbitrary length) Larry Kilgallen
0 siblings, 1 reply; 77+ messages in thread
From: Fergus Henderson @ 1997-03-06 0:00 UTC (permalink / raw)
kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>It seems to me that by omission the Ada 95 (or 83, for that matter)
>reference manual establishes that the "defined standard minimal interface"
>is one without programmer control or API. Anything on top of that is
>implementation-specific.
Well, by omission it also implies that only conservative garbage
collection can be used -- or at least that memory areas used by the
foreign language interface must be conservatively scanned. This is a
potentially undesirable constaint to place on implementations.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Really more GC talk (was: Reading a line of arbitrary length)
1997-03-06 0:00 ` Fergus Henderson
@ 1997-03-06 0:00 ` Larry Kilgallen
1997-03-11 0:00 ` Fergus Henderson
0 siblings, 1 reply; 77+ messages in thread
From: Larry Kilgallen @ 1997-03-06 0:00 UTC (permalink / raw)
In article <5flm4e$ngl@mulga.cs.mu.OZ.AU>, fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>
>>It seems to me that by omission the Ada 95 (or 83, for that matter)
>>reference manual establishes that the "defined standard minimal interface"
>>is one without programmer control or API. Anything on top of that is
>>implementation-specific.
>
> Well, by omission it also implies that only conservative garbage
> collection can be used -- or at least that memory areas used by the
> foreign language interface must be conservatively scanned. This is a
> potentially undesirable constaint to place on implementations.
No, it implies that only conservative garbage collection is standardized.
Someone else talked about ongoing garbage collection "research", making
me think that it is not ready for inclusion in an Ada standard.
If someone wanted to have Ada non-conservative garbage collection
implementations confirm to some Posix (or other) standard API for
garbage collection, that would be fine, but it seems foolish for
Ada folk to be leading the way for such standards given that the
experience is all in other languages.
Larry Kilgallen
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Really more GC talk (was: Reading a line of arbitrary length)
1997-03-06 0:00 ` Really more GC talk (was: Reading a line of arbitrary length) Larry Kilgallen
@ 1997-03-11 0:00 ` Fergus Henderson
1997-03-11 0:00 ` Robert Dewar
0 siblings, 1 reply; 77+ messages in thread
From: Fergus Henderson @ 1997-03-11 0:00 UTC (permalink / raw)
kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>>
>>>It seems to me that by omission the Ada 95 (or 83, for that matter)
>>>reference manual establishes that the "defined standard minimal interface"
>>>is one without programmer control or API. Anything on top of that is
>>>implementation-specific.
>>
>> Well, by omission it also implies that only conservative garbage
>> collection can be used -- or at least that memory areas used by the
>> foreign language interface must be conservatively scanned. This is a
>> potentially undesirable constraint to place on implementations.
>
>No, it implies that only conservative garbage collection is standardized.
OK, if you want to be pedantic... yes, I left out the word
"standard-conforming" before "implementations".
The standard implies that standard-conforming implementations can use
only conservative garbage collection, and that implementations that use
non-conservative GC techniques cannot be standard-conforming.
That still seems to me to be a potentially undesirable constraint to
place on standard-conforming implementations.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Really more GC talk (was: Reading a line of arbitrary length)
1997-03-11 0:00 ` Fergus Henderson
@ 1997-03-11 0:00 ` Robert Dewar
1997-03-12 0:00 ` Fergus Henderson
0 siblings, 1 reply; 77+ messages in thread
From: Robert Dewar @ 1997-03-11 0:00 UTC (permalink / raw)
Fergus said
<<The standard implies that standard-conforming implementations can use
only conservative garbage collection, and that implementations that use
non-conservative GC techniques cannot be standard-conforming.
That still seems to me to be a potentially undesirable constraint to
place on standard-conforming implementations.
>>
I can't figure out the strange misreading of the RM that leads to this
incorrect conclusion, but it is certainly an incorrect conclusion.
There is no such constraint in the RM.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Really more GC talk (was: Reading a line of arbitrary length)
1997-03-11 0:00 ` Robert Dewar
@ 1997-03-12 0:00 ` Fergus Henderson
0 siblings, 0 replies; 77+ messages in thread
From: Fergus Henderson @ 1997-03-12 0:00 UTC (permalink / raw)
dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>Fergus said
>
><<The standard implies that standard-conforming implementations can use
>only conservative garbage collection, and that implementations that use
>non-conservative GC techniques cannot be standard-conforming.
>
>That still seems to me to be a potentially undesirable constraint to
>place on standard-conforming implementations.
>>>
>
>I can't figure out the strange misreading of the RM that leads to this
>incorrect conclusion, but it is certainly an incorrect conclusion.
>There is no such constraint in the RM.
Suppose I pass an Ada access type to a C function and store the pointer
in a C global variable, and suppose that the data pointed to is
reachable only via that pointer. Can my combined C/Ada program be
standard-conforming? If not, then I guess I'll just have to give
up mixed-language programming. If so, then does the Ada standard allow
the implementation to reclaim the memory? If so, please cite chapter
and verse. If not, then this would place potentially undesirable
constraints on implementations. In particular, it would prohibit
non-conservative GC techniques -- or require them to non-conservatively
collect the C code too, which is not feasible, due to the presence of
undiscriminated unions.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (9 preceding siblings ...)
1997-03-04 0:00 ` Jon S Anthony
@ 1997-03-04 0:00 ` Jon S Anthony
1997-03-05 0:00 ` Jon S Anthony
11 siblings, 0 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-03-04 0:00 UTC (permalink / raw)
In article <dewar.857447580@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jon said
>
> <<Does this mean that you believe that there should not be any language
> standards? Probably not. But that is what you are saying, even
> thought that is almost certainly not what you mean.>>
>
> nope, it is not what I am saying (by any stretch of misinterpretation) and
Actually, on the face of it - it's precisely what you were saying.
> it is certainly not what I mean!
Yes, I realize that.
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread
* Re: Reading a line of arbitrary length
1997-02-13 0:00 ` Rex Reges
` (10 preceding siblings ...)
1997-03-04 0:00 ` Reading a line of arbitrary length Jon S Anthony
@ 1997-03-05 0:00 ` Jon S Anthony
11 siblings, 0 replies; 77+ messages in thread
From: Jon S Anthony @ 1997-03-05 0:00 UTC (permalink / raw)
In article <1997Mar5.102140.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> In article <JSA.97Mar4154951@alexandria>, jsa@alexandria (Jon S Anthony) writes:
> > In article <dewar.857447653@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> >
> >> Jon said
> >>
> >> <<Because there are areas and cases where the GC should not be simply
> >> "transparent". That it should have some explicit programmer control
> >> available.>>
> >>
> >> Well there is a contentions statement. I strongly disagree that GC
> >> should not be simply transparent, and I do not like the idea of
> >> standardizing explicit programmer control, whatever that might be.
> >
> > Yes, it is. These are merely points that have been made in GC
> > circles. I'm not _advocating_ them, just trying to point out various
> > reason why a "defined standard minimal interface" may be needed.
>
> It seems to me that by omission the Ada 95 (or 83, for that matter)
> reference manual establishes that the "defined standard minimal interface"
> is one without programmer control or API. Anything on top of that is
> implementation-specific.
>
> To specify anything further with no confirmed sightings of potential
> implementors would give the impression that standards committees are
> paid by the word.
Ah. I see. The old "let's not learn anything from those who've done
it in similar languages and certainly let's not pay any attention to
GC folk". Hasn't this sort of thing already been done a few times?
Hmmm, maybe this is why Robert thinks Ada GC is doomed...
/Jon
--
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 77+ messages in thread