ASCL a doomed idea?

ASCL a doomed idea?

[Michael Erdmann]

Hallo,

as i can remeber the idea of ASCL is at least 2 years
old. I have done some thing like this already some time
a go, maybe you like to refere to:

   http://ascl.sourceforge.net/

IThe whole thing is more or less doomed because every
body likes the idea to have support components for his application
development, but you are still discussing about basic low level
things  like containers etc.
In order to make this project more interesting for every body,
please focus on higher level components like configiration
manager packages, transaction management etc.
It would make application development  easier if
there would be a documented common frame work for
applications available (e.g. the frame work covers config. files,
tracing etc.)!

But as long i can remeber this there is a dicussion about
basic containers going on which is find quite useless and
which does not help to reach the project objective.

Anyhow i will change the name of my project on sourceforge
in order to avoid any interference if you like!


Regards
    Michael

Re: ASCL a doomed idea?

[Mark Lundquist]

"Michael Erdmann" <michael.erdmann@snafu.de> wrote in message
news:mailman.1007670662.18290.comp.lang.ada@ada.eu.org...
>
> But as long i can remeber this there is a dicussion about
> basic containers going on which is find quite useless and
> which does not help to reach the project objective.

The objective of which project, would that be? :-)

If yours, then it should not be suprising if some other project does not
help to advance your objective :-)

Not that there is necessarily anything wrong with your project/objective.

-- mark

Re: ASCL a doomed idea?

[Nick Roberts]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:7RQP7.4406$Yy.272014@rwcrnsc53...
>
> "Michael Erdmann" <michael.erdmann@snafu.de> wrote in message
> news:mailman.1007670662.18290.comp.lang.ada@ada.eu.org...
> >
> > But as long i can remeber this there is a dicussion about
> > basic containers going on which is find quite useless and
> > which does not help to reach the project objective.
>
> The objective of which project, would that be? :-)
>
> If yours, then it should not be suprising if some other project does not
> help to advance your objective :-)
>
> Not that there is necessarily anything wrong with your project/objective.

I see that Michael has been busy in (at least) the areas of Ada database
interfacing and a project called ACDE, which is about providing components
for building distributed software. Respect.

I see also references to 'ASCL', but I'm not sure whether this is an old
name for ACDE or not, or whether it is currently extant.

Regardless of this, I have thought of a possible alternative name for the
STL-like containers project (effectively) started by TED: "Tenet", from the
Latin "it holds". I think this has the requisite short-and-pithy-ness, and I
don't think it's been used in an Ada context before. It does contain the
word "net", however, so maybe it's not ideal. Does this name tickle anyone's
ticklish bits, at all?

I've been looking carefully at my proposal (NJR 5), Jeffrey Carter's (JC01)
and TED's (1.3), and -- to put it totally bluntly -- I still think mine is
the best so far (I just can't help being perfect ;-) for some fairly
specific reasons:

(1) all my nomenclature is derived directly from Ada.Strings.* wherever
possible, the exceptions being 'cursor', 'cursorage', 'facing', 'prepend',
'split', 'move_cursor', and 'restart' (about which nobody seems to have
argued anyway), and the generic parameter Element_Type, and the function
End_of_*, both of which I have derived from Ada.*_IO;

(2) there are certainly a lot of operations, but (and I have them reviewed
carefully) I believe every single one is justified (including the array
ones), either for reasons of implementational efficiency, or significant
user convenience, or both;

(3) the closed (passive?) iterator included in both JC01 and TED 1.3 is
inferior to the open, container-wide iterator (I have already outlined,
haven't I?) to be added to my proposal, in that it does not permit
restarting within the client procedure, and it does not permit writing at
all.

Having reviewed my design, I have decided not to axe any of the operations,
but to axe two of the parameters: Facing and Offset (except in Move_Cursor).
The complete functionality of the Facing parameter can be reproduced by
implementing a 'smart reverse' operation (so that's two further subprograms
to be added!) with the appropriate semantics. I feel the Offset parameter
(of the cursor-based operations) was overkill, given that you can always
move the cursor to the required position, and then move it back again. Yet
another procedure that needs to be added is a Copy_Cursor. I have rejected
the idea of a separate cursor type (as pointless).

I'm afraid I must say I've been a bit unimpressed about the recent arguments
about the names of the ends of lists. I feel just like Gulliver witnessing,
with incredulity, the arguments between the Lilliputians and the Blefuscuans
about which end of the egg to eat first. Get it together guys, or I'm afraid
Michael's prediction will come true, and I will indeed simply go off and do
it on my own.

--
Sternly,
Nick Roberts

Re: ASCL a doomed idea?

[Jeffrey Carter]

Nick Roberts wrote:
> 
> I've been looking carefully at my proposal (NJR 5), Jeffrey Carter's (JC01)
> and TED's (1.3), and -- to put it totally bluntly -- I still think mine is
> the best so far (I just can't help being perfect ;-) for some fairly
> specific reasons:
> 
> (1) all my nomenclature is derived directly from Ada.Strings.* wherever
> possible, the exceptions being 'cursor', 'cursorage', 'facing', 'prepend',
> 'split', 'move_cursor', and 'restart' (about which nobody seems to have
> argued anyway), and the generic parameter Element_Type, and the function
> End_of_*, both of which I have derived from Ada.*_IO;

This is a significant problem with NJR5. Lists are not strings and use
different nomenclature.

> (3) the closed (passive?) iterator included in both JC01 and TED 1.3 is
> inferior to the open, container-wide iterator (I have already outlined,
> haven't I?) to be added to my proposal, in that it does not permit
> restarting within the client procedure, and it does not permit writing at
> all.

An iterator procedure is the only thing that is an iterator; anything
else called an iterator is misnamed. I don't know what you mean by
"writing" in this context. The iterator in JC01 allows updating the
value stored at the current position being acted upon. Insertion and
deletion should take place outside an iterator.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: ASCL a doomed idea?

[Nick Roberts]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C13D980.748CCCDA@acm.org...

> This is a significant problem with NJR5.

I need another pantomime chorus, please:

>Lists are not strings

[all together] "Oh yes they are!"

> and use different nomenclature.

[all together] "Oh no they don't!"

Or, rather, a string is a kind of list (do you really have a problem with
that concept?), and what the heck is the problem with using the same
nomenclature for both (as far as possible) to help avoid confusing the poor
Ada programmer? This isn't an ivory tower academic exercise.

> > (3) the closed (passive?) iterator included in both JC01 and TED 1.3 is
> > inferior to the open, container-wide iterator (I have already outlined,
> > haven't I?) to be added to my proposal, in that it does not permit
> > restarting within the client procedure, and it does not permit writing
at
> > all.
>
> An iterator procedure is the only thing that is an iterator; anything
> else called an iterator is misnamed.

According to which science? On which planet, Jeff? Are you serious?

> I don't know what you mean by
> "writing" in this context. The iterator in JC01 allows updating the
> value stored at the current position being acted upon. Insertion and
> deletion should take place outside an iterator.

Like a file Jeff, the architypal 'container'. You read from it, you write
into it.

I'd like to hear what TED says, but I am seriously thinking of just going it
alone now. I don't have time for sillyness. In fact, I have some fairly
specific needs of my own as regards a container suite (for AdaOS), so maybe
that colours my judgement; if so, however, that's just tough.

I have really appreciated the input from this lengthy (meta?)thread, but I
feel the need for action. I need sets! Contars! The wide open spaces!

I have not at this moment thought of any names better (hah ;-) than "Tenet"
and "Dastar". Dastar is what I have used internally in writing code for
AdaOS. It stands for DAta STorage And Retrieval (but is also a Sikh turban,
which seems oddly appropriate). Can I pinch one of these for my own
containers project, please?

--
Best wishes,
Nick Roberts

Re: ASCL a doomed idea?

[Jeffrey Carter]

Nick Roberts wrote:
> 
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3C13D980.748CCCDA@acm.org...
> 
> Or, rather, a string is a kind of list (do you really have a problem with
> that concept?), and what the heck is the problem with using the same
> nomenclature for both (as far as possible) to help avoid confusing the poor
> Ada programmer? This isn't an ivory tower academic exercise.

That's a different meaning of "list". You could use a list data
structure to implement a string, just as you can for a queue or stack.
And just like a queue or stack, the result has different nomenclature
than a list.

> > An iterator procedure is the only thing that is an iterator; anything
> > else called an iterator is misnamed.
> 
> According to which science? On which planet, Jeff? Are you serious?

By definition: An iterator is something that iterates. Executable code
can iterate. Types and objects cannot.

> Like a file Jeff, the architypal 'container'. You read from it, you write
> into it.

Then in list terminology, by "writing" you mean insertion. Insertion is
not advisable from an iterator.

-- 
Jeffrey Carter

Re: ASCL a doomed idea?

[Chad R. Meiners]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3C153926.102B17B1@boeing.com...

> By definition: An iterator is something that iterates. Executable code
> can iterate. Types and objects cannot.

Think back to your computation theory.  Executable code is an object.

-CRM

Re: ASCL a doomed idea?

[Jeffrey Carter]

"Chad R. Meiners" wrote:
> 
> "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
> news:3C153926.102B17B1@boeing.com...
> 
> > By definition: An iterator is something that iterates. Executable code
> > can iterate. Types and objects cannot.
> 
> Think back to your computation theory.  Executable code is an object.

Think back to the name of this newsgroup. In Ada, an object is something
with a subtype attached, such as a variable or constant.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: ASCL a doomed idea?

[Chad R. Meiners]

Which makes absolutely no difference.  Executable code and states can be
represented with variables.  A passive iterator is a storable iterator state
machine.  These machines do iterate, and so, your assertion is false.

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C156471.A32FC79C@acm.org...
> "Chad R. Meiners" wrote:
> >
> > "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
> > news:3C153926.102B17B1@boeing.com...
> >
> > > By definition: An iterator is something that iterates. Executable code
> > > can iterate. Types and objects cannot.
> >
> > Think back to your computation theory.  Executable code is an object.
>
> Think back to the name of this newsgroup. In Ada, an object is something
> with a subtype attached, such as a variable or constant.
>
> --
> Jeff Carter
> "Hello! Smelly English K...niggets."
> Monty Python & the Holy Grail

Re: ASCL a doomed idea?

[Mark Lundquist]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3C153926.102B17B1@boeing.com...
>
> > > An iterator procedure is the only thing that is an iterator; anything
> > > else called an iterator is misnamed.
> >

I have a tool in my garden shed.  It's basically a trencher, but with a
double head -- you reverse it and it's like a three-tined hoe.  This tool is
called a "cultivator" -- that's what the hardware store calls it, anyway (I
used to call it a "hoedag", and still do, just to irritate my wife :-).

Anyhow... the thing is, Jeff, even after many hours of watching it from my
lawn chair, this thing will not actually *cultivate*.  It just sits there,
propped up against whatever I have propped it up against.

I suppose I should take it back to the hardware store for a refund...?

Alexader Stepanov came up with this idea for how to write a suite of
collection classes, where the collection operations were *not* primitives of
the collections.  That way, the implementations of the collection operations
can be reused, i.e. shared across many collection types, instead of having
to be written custom-like for each one, and it allows the functionality of
the collection classes to be extended without the limitations of using
inheritance for the extension.  The collections he calls "containers" and
the operations he calls "algorithms".  The coupling mechanism between the
two is an abstraction he calls an "iterator".  Now, this idea is embodied in
the Standard Template Library for a language called "C++", which many, many
programmers in this quadrant know (or at least are able to claim to know
enough to get hired).  As a result, most sentient beings in the galaxy are
familiar with the concept of an "iterator" as the coupler between containers
and algorithms.

I'm not saying that the term "iterator" at all follows from Stepanov's usage
of it.  And I'm not saying he was the first to use the term "iterator" to
refer to a handle for traversing a collection.  What I am saying is that
since he was the one who consolidated and promulgated the concept of
"generic programming", he kind of gets to choose the terminology, for better
or worse, just because it's a powerful concept and so whatever nomenclature
he picked was bound to stick.  If he had called them "enumerators" instead,
everyone would have accepted that and we'd be stuck with "enumerators"
instead.  If "iterators" gave anyone heartburn, it wasn't enough to get the
name changed.

I feel very strongly that a collection library for Ada must have a "generic
programming" architecture, i.e. algorithms abstracted away from the
collections.  If that is to be the case, I think we should stay with the
universally understood and accepted nomenclature.  Here we are, trying to
bring Ada out of the stone age as regards having a decent standard library,
and the last thing I want to have to do is explain to the rest of the world,
"Well, this here is what is commonly called an 'iterator', but we call ours
a Dookus because strictly speaking, it does not iterate, being as it's just
an object and cannot actually do anything on its own."

I don't think you're gonna be able to get many people to go along with you
on this one.  You're rowing against the tide, and you're gonna end up being
the only one in your boat :-).

And I can't say much for your choice of name for the itera... I mean, the
uh... the dookus.  "Position" is what you call it, right?  Well, the term
"position" connotes like an index or something -- you know, "first",
"third", "last" or whatever, right?  "Position" does not carry the meaning
of something that denotes an element.  Like with an index, the value '7'
doesn't denote an object -- you have to combine the index with a container
(an array) to get a name for an object:

        An_Array (7);

It's like a house number as opposed to a full street address.

A Dookus is not like an index.  A Dookus is an abstract pointer.  A Dookus
really does denote an object, and to get the object you do not need to know
what collection it came from.  You don't need the collection, you only need
the Dookus.  We provide some operation like "Value" or whatever, for
"dereferencing" the Dookus.

Suppose you have a Dookus denoting an element that happens to be the first
element in a linked list.  Then suppose you insert a new element at the
"first" position of the list.  Your Dookus still denotes the same element,
even though its notional "position" has changed -- it is no longer the first
element in the the collection, it is now the second.  It seems really
strange to say that it still has the same Position!

Best wishes,
Mark

Re: ASCL a doomed idea?

[Ted Dennison]

In article <MZoR7.30524$wL4.108797@rwcrnsc51>, Mark Lundquist says...
>And I can't say much for your choice of name for the itera... I mean, the
>uh... the dookus.  "Position" is what you call it, right?  Well, the term
>"position" connotes like an index or something -- you know, "first",

It was called "Position" in the Strawman back when I wasn't presenting a safe
iterator, with an interal pointer back to its list. In that mode it really did
act like an array index, except that you didn't have random access. Now that the
Strawman is presenting a safe iterator object, the name "Iterator" seemed more
appropriate. That's why it is that way in 1.3.

Anyway, JC01 presents an unsafe style iterator. His comments say it could go
either way, but if its safe, there's no sense in supplying the list with it like
all JC01's routines do, so I think his presentation only makes sense for an
unsafe iterator. For an unsafe iterator, I think "Position" is reasonable, as it
at least underlines that you can't expect the compiler to do all your checking
for you like you would with a true iterator.

Which one we use is something that still needs to be decided. Perhaps there
hasn't been much discussion about this because everyone is happy with the way
the latest Strawman does it (safe)?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ASCL a doomed idea?

[Jean-Marc Bourguet]

Ted Dennison<dennison@telepath.com> writes:

> Which one we use is something that still needs to be decided. Perhaps there
> hasn't been much discussion about this because everyone is happy with the
> way the latest Strawman does it (safe)?

I'm happy with it.

-- 
Jean-Marc

Re: ASCL a doomed idea?

[Stephen Leake]

Ted Dennison<dennison@telepath.com> writes:

> Which one we use is something that still needs to be decided. Perhaps there
> hasn't been much discussion about this because everyone is happy with the way
> the latest Strawman does it (safe)?

I vote for the name "Iterator" (or "Iterator_Type" :), basically
because of the C++ STL usage.

I'd like to see an implementation of the safe iterator, so I can judge
how much overhead I'm signing up for. From the discussion I've seen so
far, it doesn't sound bad, so I'm provisionally voting for safe
iterators. 

-- 
-- Stephe

Re: ASCL a doomed idea?

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Anyway, JC01 presents an unsafe style iterator. His comments say it could go
> either way, but if its safe, there's no sense in supplying the list with it like
> all JC01's routines do, so I think his presentation only makes sense for an
> unsafe iterator. For an unsafe iterator, I think "Position" is reasonable, as it
> at least underlines that you can't expect the compiler to do all your checking
> for you like you would with a true iterator.

It presents a specification that doesn't bias the implementation. If you
leave the list parameters off, you can't have an unsafe implementation,
but putting them in doesn't prevent a safe implementation.

> Which one we use is something that still needs to be decided. Perhaps there
> hasn't been much discussion about this because everyone is happy with the way
> the latest Strawman does it (safe)?

I'm not too concerned either way. Complete safety means insertion and
deletion are O(M) in time, where M is the number of Locations in
existence. The additional protection this gets you over mostly safe
Locations seems to be against pathological cases, misuse of a list of a
kind that I've never actually seen in practice (and I've seen some
pretty poor code using lists with completely unsafe Locations). So, I'm
not sure complete safety is worth the effort, but I won't be bothered if
it's deemed essential for the standard list.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus

Re: ASCL a doomed idea?

[Ted Dennison]

In article <3C16DD1F.E768B33@acm.org>, Jeffrey Carter says...
>existence. The additional protection this gets you over mostly safe
>Locations seems to be against pathological cases, misuse of a list of a
>kind that I've never actually seen in practice (and I've seen some
>pretty poor code using lists with completely unsafe Locations). So, I'm
>not sure complete safety is worth the effort, but I won't be bothered if
>it's deemed essential for the standard list.

That's pretty much my feelings on it too. But it does seem to be the case that
the current (safe) version of the Strawman is the only one that has not drawn
any complaints about the iterator implementation. I have to admit that students,
one of the target audiences of this facility, are quite likely to generate those
pathalogical cases of misuse. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ASCL a doomed idea?

[Larry Hazel]

Mark Lundquist wrote:
> 
> And I can't say much for your choice of name for the itera... I mean, the
> uh... the dookus.  

Ah Yes, a Dookus. I like it. LOL

Larry

Re: ASCL a doomed idea?

[Jeffrey Carter]

Mark Lundquist wrote:
> 
> I have a tool in my garden shed.  It's basically a trencher, but with a
> double head -- you reverse it and it's like a three-tined hoe.  This tool is
> called a "cultivator" -- that's what the hardware store calls it, anyway (I
> used to call it a "hoedag", and still do, just to irritate my wife :-).

So you have a combination trenching tool and hoe that someone misnamed a
"cultivator". And your point is?

> Alexader Stepanov came up with this idea for how to write a suite of
> collection classes, where the collection operations were *not* primitives of
> the collections.  That way, the implementations of the collection operations
> can be reused, i.e. shared across many collection types, instead of having
> to be written custom-like for each one, and it allows the functionality of
> the collection classes to be extended without the limitations of using
> inheritance for the extension.  The collections he calls "containers" and
> the operations he calls "algorithms".  The coupling mechanism between the
> two is an abstraction he calls an "iterator".  Now, this idea is embodied in
> the Standard Template Library for a language called "C++", which many, many
> programmers in this quadrant know (or at least are able to claim to know
> enough to get hired).  As a result, most sentient beings in the galaxy are
> familiar with the concept of an "iterator" as the coupler between containers
> and algorithms.

Oh, I get it now. Since C++ got it wrong, Ada should get it wrong to be
compatible with C++. An excellent idea. Along the same lines, I suggest
removing type checking from Ada, and replacing "begin" and "end" with
{}. We'd better introduce the reserved words "class" and "friend" while
we're at it.

> And I can't say much for your choice of name for the itera... I mean, the
> uh... the dookus.  "Position" is what you call it, right?

"Position" is what it's usually called in the data structures literature
in describing the abstraction called a list.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus

Re: ASCL a doomed idea?

[Stephen Leake]

Jeffrey Carter <jrcarter@acm.org> writes:

> Oh, I get it now. Since C++ got it wrong, Ada should get it wrong to be
> compatible with C++. An excellent idea. Along the same lines, I suggest
> removing type checking from Ada, and replacing "begin" and "end" with
> {}. We'd better introduce the reserved words "class" and "friend" while
> we're at it.

I can be pedantic with the best of them, but there are times when it
pays to bow to practicality.

I doubt we will ever get agreement on the "right" definition of "list"
and related terms; even the people here who are quoting college texts
disagree. So I'll go with popularity on this one.

> "Position" is what it's usually called in the data structures literature
> in describing the abstraction called a list.

Can we get rid of these absolutist statements, and provide some
concrete references? I have no idea how to go about accessing "the"
data structures literature, so this statement is of no help to me. I
also find it hard to believe there is a monolithic set of such
literature, but I'm willing to be proven wrong. On the other hand, I
do have access to a good library, so a reference to a real book or
journal would be useful.

-- 
-- Stephe

Re: ASCL a doomed idea?

[Mark Lundquist]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C16DB37.A0F02702@acm.org...
> Mark Lundquist wrote:
> >
> > I have a tool in my garden shed.  It's basically a trencher, but with a
> > double head -- you reverse it and it's like a three-tined hoe.  This
tool is
> > called a "cultivator" -- that's what the hardware store calls it, anyway
(I
> > used to call it a "hoedag", and still do, just to irritate my wife :-).
>
> So you have a combination trenching tool and hoe that someone misnamed a
> "cultivator". And your point is?

Look, if you can't see the obvious connection between gardening tools and
collection libraries, then I'm afraid I can't help you :-) :-) :-)

Anyway, since you'll be away for a while... Merry Christmas / Hannukah /
Santa Day / Bah-Humbug Day (whatever the case may be) and Happy New Year...

-- Mark

Re: ASCL a doomed idea?

[Georg Bauhaus]

Jeffrey Carter <jrcarter@acm.org> wrote:
 
:> The coupling mechanism between the
:> two is an abstraction he calls an "iterator".  Now, this idea is embodied in
:> the Standard Template Library for a language called "C++", ...
:> As a result, most sentient beings in the galaxy are
:> familiar with the concept of an "iterator" as the coupler between containers
:> and algorithms.
: 
: Oh, I get it now. Since C++ got it wrong, Ada should get it wrong to be
: compatible with C++.

Why not use the opportunity and come up with an appropriate name
since people have to grow accustomed to the dfferent flavour of
programming lanuage that Ada is, anyway? Perhaps call
one of the things a Hopper?

Georg

Re: ASCL a doomed idea?

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9v37s0$cdmva$3@ID-25716.news.dfncis.de...
>
> According to which science? On which planet, Jeff? Are you serious?
>
> [snip]
>
> I have really appreciated the input from this lengthy (meta?)thread, but I
> feel the need for action. I need sets! Contars! The wide open spaces!
>
> I have not at this moment thought of any names better (hah ;-) than
"Tenet"
> and "Dastar".

Contars?  Dastars?  Tenet?

I think you are the one who must be from another planet, Nick!  That's it...
you're an acid-dropping dope fiend from the planet Contar!  That would also
explain why you need the "wide open spaces"... the wide open *interstellar*
spaces, am I right, eh?  How many more of you are there among us, that's
what I want to know!

Jeff's a little misguided about this "iterator" business, but it's a
personal hangup -- please do not think that is representative of planet
Earth.  Tell your people that they are "iterators" here as well, just like
everywhere else in the galaxy.

Best wishes from Earth,
- Marktar

Re: ASCL a doomed idea?

[Ted Dennison]

In article <MZoR7.32760$ER5.370062@rwcrnsc52>, Mark Lundquist says...
>
>I think you are the one who must be from another planet, Nick!  That's it...
>you're an acid-dropping dope fiend from the planet Contar!  That would also
>explain why you need the "wide open spaces"... the wide open *interstellar*
>spaces, am I right, eh?  How many more of you are there among us, that's
>what I want to know!

Nick, I take back everything bad I ever said about you. We are nice friendly
folk down here on Earth, really. Please tell your masters back on Contar to find
their leibenstraum on some other planet..unless they like it really cold with no
ozone layer. In that case, they can have Antartica if they'll just promise not
to slaughter the rest of us.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ASCL a doomed idea?

[Nick Roberts]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:wmpR7.57437$xS6.92885@www.newsranger.com...
> In article <MZoR7.32760$ER5.370062@rwcrnsc52>, Mark Lundquist says...
> >
> >I think you are the one who must be from another planet, Nick!  That's
it...
> >you're an acid-dropping dope fiend from the planet Contar!  That would
also
> >explain why you need the "wide open spaces"... the wide open
*interstellar*
> >spaces, am I right, eh?  How many more of you are there among us, that's
> >what I want to know!
>
> Nick, I take back everything bad I ever said about you. We are nice
friendly
> folk down here on Earth, really. Please tell your masters back on Contar
to find
> their leibenstraum on some other planet..unless they like it really cold
with no
> ozone layer. In that case, they can have Antartica if they'll just promise
not
> to slaughter the rest of us.

[Made me laugh loudly. Excellent.]

... Message coming in {sound of Morse code} ...

WE ARE THE CONTARI
YOU WILL BE ASSIMILATED
RESISTANCE IS FUTILE

... the skies are getting dark ...

What I really love is the fact that, despite the Borg having successfully
conquered half the galaxy, any Borg drone can be disabled by simply pulling
some plug out of the back of its neck! Shame. Daleks? Just run up a flight
of steps.

... Oh no! Not content just to conquor Earth, the evil Contari have brought
along their dreaded allies the TALIBANI {duh duh DUH} ...

... But wait! Who is this coming to rescue? Is it the saviour of mankind?
Yes! It's ...

Colin Powell Man! See him fly! And here come his friends, the mighty Delta
Forces ;-)

... Don't miss next week's exciting episode {music} ...

Well, I hope my little moment of petulance is forgiven. Never one to give up
(when any sensible person would ;-) I'm going to give it one more shot. Do
have a little scream, if it might make you feel any better.

I believe that the majority of Ada programmers would prefer that the names
of the subprograms and types for containers favoured practicality over
terminological exactitude. And it seems to me that re-using names and
concepts from Ada.Strings.* (and other existing standard Ada library units)
would be welcomed by most Ada programmers as having consistency and mnemonic
value, even if they don't actually correspond to the 'classic' list
operations and terminology from the textbooks. That is my argument as
regards names; take it or leave it.

Again, on the theme of practicality, I don't care whether they're called
iterators, enumerators, cultivators, dooki, or unidirectifiscanators, but I
believe my scheme has the following benefits:

(1) My iterators are container-wide. This means that an algorithm (a
subprogam) can be based on iterators, and then any kinds of containers
(list, set, contar, file, array) can be used in conjunction with it. Thus my
iterators form a key link between algorithms and data (containers), just as
Mark was talking about.

(2) My iterators distinguish between data streams: which do not terminate;
which do terminate; which can be restarted. This allows algorithms that
require termination or restarting to demand these qualities (usually)
statically, but it allows terminating and restarting data streams to be used
without any difficulty with algorithms that do not require these qualities.

(3) My iterators provide 'write' forms as well as 'read' forms. This may not
conform to classic doctrine, but it is nevertheless useful: it means that
algorithms can write data into containers, as well as reading data from
them, without having to be container-specific. Writing into containers such
as lists, sets, and contars works just like inserting (or appending);
writing into a file or pipe needs no explanation (surely!).

My theme, as I hope is obvious by now, is practicality, practicality,
practicality.

Is that snoring I can hear at the back there? All right then, this is Mork
signing off for another episode. Nanu Nanu.

--
Greetings to all Earthlings
Peace and Goodwill unto you all
Klaatu Beringa Nicto

Nick Roberts (aka 'Kraatis')





PS: I hope my attempt at humour is not considered in poor taste. It is meant
in the lightest of ways.

Re: ASCL a doomed idea?

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9v5gjn$d9cth$2@ID-25716.news.dfncis.de...

>
> PS: I hope my attempt at humour is not considered in poor taste. It is
meant
> in the lightest of ways.
>

Listen, if I can go around claiming to have exposed you for an acid-crazed
extraterrestrial, I think you've got plenty of time before the bad taste
police come knocking on your door...

:-) :-) :-)

Best wishes,
Mark

Re: ASCL a doomed idea?

[Jeffrey Carter]

Mark Lundquist wrote:
> 
> I think you are the one who must be from another planet, Nick!  That's it...
> you're an acid-dropping dope fiend from the planet Contar!  That would also
> explain why you need the "wide open spaces"... the wide open *interstellar*
> spaces, am I right, eh?  How many more of you are there among us, that's
> what I want to know!

Nick's posts make much more sense in light of this information.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus

Re: ASCL a doomed idea?

[Mark Lundquist]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9v37s0$cdmva$3@ID-25716.news.dfncis.de...
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3C13D980.748CCCDA@acm.org...
>
> >Lists are not strings
>
> [all together] "Oh yes they are!"
>
> > and use different nomenclature.
>
> [all together] "Oh no they don't!"
>
> Or, rather, a string is a kind of list (do you really have a problem with
> that concept?),

He's not the only one...

Look, you have said that you conceive of a list as a "store" into which
things are written and out of which things are read.  Are you truly saying
that if I write

    Put_Line ("Hello, world");

that you think of the thing I am passing as an instance of a kind such a
store?

> and what the heck is the problem with using the same
> nomenclature for both (as far as possible) to help avoid confusing the
poor
> Ada programmer?

The problem is, as Jeff says, that they are not the same thing, and in
fact have little to do with each other.  So if anything, you're going to
confuse people *more* if your nomenclature is at variance with standard
terminology for lists (assuming that there is such a thing...).

MHO,
-- mark

Re: ASCL a doomed idea?

[Nick Roberts]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:30wR7.37506$Yy.395982@rwcrnsc53...

> Look, you have said that you conceive of a list as a "store" into which
> things are written and out of which things are read.  Are you truly saying
> that if I write
>
>     Put_Line ("Hello, world");
>
> that you think of the thing I am passing as an instance of a kind such a
> store?

Yes indeedy! There are several programming languages in which a string is
explicitly a list. Think about LISP. It seems utterly bizarre and beyond all
reason to me to suggest that a string is not, in general, a kind of list.
It's a list of characters. Isn't that something a four-year-old would
understand? Talk about people coming from different planets!

I'm not talking about somebody's esoteric academic definition of a list, I'm
talking about ordinary everyday people's idea of a list. Most Ada
programmers are ordinary everyday people, and it is those programmers whom I
am considering when choosing names for the types and subprograms.

> > and what the heck is the problem with using the same
> > nomenclature for both (as far as possible) to help avoid confusing the
> > poor Ada programmer?
>
> The problem is, as Jeff says, that they are not the same thing, and in
> fact have little to do with each other.  So if anything, you're going to
> confuse people *more* if your nomenclature is at variance with standard
> terminology for lists (assuming that there is such a thing...).

I think my previous remark kills this one stone dead. A string is a kind of
list, ergo any string operation (that is not character-specific) is also a
list operation (this is to say nothing about the efficiency of such
operations, or the representation of strings and lists).

If you have an operation which does something (specifically) for a string
and an operation which does the same (analogous) thing for a list, does it
not make sense to give them the same name?

Let us take as an example a string "ABCDE" and a list (Bob, Tom, Jim, Fred,
Pete). If we have an operation called 'Head' that returns the first element
of a string ('A' in the example), do you think Ada programmers are going to
thank you for calling the same list operation (which would return Bob in the
example) something else ('First', 'Front', even 'Cat' or 'Dog')? I don't.

I can assure you that, in the big scheme of things, there is no standard
terminology for lists. There are a few terms that seem to be used
consistently, but only a few. Let us use the terminology already provided by
existing Ada standard library packages. That is, I am certain, the best way
for a container library to avoid confusion and gain acceptance.

Phew! I hope I'm 'getting my message across' as they say.

--
Best wishes,
Nick Roberts

Re: ASCL a doomed idea?

[Ian Wild]

Nick Roberts wrote:
> 
> ... There are several programming languages in which a string is
> explicitly a list. Think about LISP.

There may indeed be several such languages, but Lisp isn't
one of them  A Lisp string is an array of characters.

  (subtypep 'string 'array)  ==> T 


> It seems utterly bizarre and beyond all
> reason to me to suggest that a string is not, in general, a kind of list.

  (subtypep 'string 'list)  ==> NIL


> It's a list of characters. 

Apparently not.

> Isn't that something a four-year-old would
> understand?

Maybe.  But your typical 4yo doesn't care about O(n) v O(1)
access times.

Re: ASCL a doomed idea?

[Nick Roberts]

Does anyone have a good formula for removing large quantities of egg from
the face?

--
Best,
Nick Roberts

"Ian Wild" <ian.wild@eurocontrol.int> wrote in message
news:3C172DBE.3B7DB9E9@eurocontrol.int...
> Nick Roberts wrote:
> >
> > ... There are several programming languages in which a string is
> > explicitly a list. Think about LISP.
>
> There may indeed be several such languages, but Lisp isn't
> one of them  A Lisp string is an array of characters.
>
>   (subtypep 'string 'array)  ==> T

Re: ASCL a doomed idea?

[Brian Rogoff]

On Wed, 12 Dec 2001, Nick Roberts wrote:
> Does anyone have a good formula for removing large quantities of egg from
> the face?

Take one Remington 870, rack one 00 shell in, disengage safety, point at
egg stain, and pull trigger. Boom, egg and face all gone. :-)

More seriously, Haskell is such a language. Strings in Haskell are lists
of characters. One of the boneheaded mistakes of Haskell if you ask me.
That's what happens when all of the language designers come from academia.

-- Brian

>
> --
> Best,
> Nick Roberts
>
> "Ian Wild" <ian.wild@eurocontrol.int> wrote in message
> news:3C172DBE.3B7DB9E9@eurocontrol.int...
> > Nick Roberts wrote:
> > >
> > > ... There are several programming languages in which a string is
> > > explicitly a list. Think about LISP.
> >
> > There may indeed be several such languages, but Lisp isn't
> > one of them  A Lisp string is an array of characters.
> >
> >   (subtypep 'string 'array)  ==> T
>
>
>
>

Re: ASCL a doomed idea?

[Marin David Condic]

The important thing won't be some specific phraseology or word-science - it
will be if there is some reasonable level of functionality available. While
it is interesting that strings have some similarity to lists, what is
probably more important is that there be similar operations and nomenclature
with Ada.Strings.* because this will help the programmer transition from one
to the other. The rest is window dressing.

I'm glad that we seem to have made some really good progress on agreeing on
a lot of what needs to be in a list package. If we stay focused on getting a
solution together, I think this could be done in some reasonably short time.
We're better off leaving the nit-picking to academic critics who can tell us
later how badly we botched up the Grand Linked List Theory. :-) In the mean
time, there will be a functioning library in use by thousands (we hope!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9v6cn5$dcfkh$1@ID-25716.news.dfncis.de...
>
> I'm not talking about somebody's esoteric academic definition of a list,
I'm
> talking about ordinary everyday people's idea of a list. Most Ada
> programmers are ordinary everyday people, and it is those programmers whom
I
> am considering when choosing names for the types and subprograms.
>

Re: ASCL a doomed idea?

[Mark Lundquist]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C13D980.748CCCDA@acm.org...
> Nick Roberts wrote:
> >
> > (1) all my nomenclature is derived directly from Ada.Strings.* wherever
> > possible, the exceptions being 'cursor', 'cursorage', 'facing',
'prepend',
> > 'split', 'move_cursor', and 'restart' (about which nobody seems to have
> > argued anyway), and the generic parameter Element_Type, and the function
> > End_of_*, both of which I have derived from Ada.*_IO;
>
> This is a significant problem with NJR5. Lists are not strings and use
> different nomenclature.

I agree!

-- mark

Re: ASCL a doomed idea?

[Jeffrey Carter]

I know you'll all be heart broken, but I'll be mostly incommunicado for
a few weeks.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus

Re: ASCL a doomed idea?

[Ted Dennison]

In article <3C16DDFB.B3EF7A2A@acm.org>, Jeffrey Carter says...
>
>I know you'll all be heart broken, but I'll be mostly incommunicado for
>a few weeks.

I for one think your contribution has been quite helpful, if for no other reason
than in pointing out some inconsistencies in the Strawman. 

Stop by when you become "communicado" once again. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ASCL a doomed idea?

[Nick Roberts]

That is unfortunate, because, for all my ranting (about various subjects), I
don't underestimate the value of someone telling me I'm wrong. There's no
other way of becoming genuinely more knowledgeable. I hope you will be back
soon.

--
Beat wishes,
Nick Roberts

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C16DDFB.B3EF7A2A@acm.org...
> I know you'll all be heart broken, but I'll be mostly incommunicado for
> a few weeks.