Reading a line of arbitrary length

Reading a line of arbitrary length

[Thomas Koenig]

What's the best way of reading a line of arbitrary length in Ada?

Get_Line only works on Strings, not Unbounded_Strings.  Would I need
to read in chunks of fixed length, then paste them together?
-- 
74 a3 53 cc 0b 19

Re: Reading a line of arbitrary length

[Robert Dewar]

Thomas asks

<<Get_Line only works on Strings, not Unbounded_Strings.  Would I need
to read in chunks of fixed length, then paste them together?>>

That's right. In GNAT 3.10, there is a child package 
Ada.Strings.Unbounded.Text_IO that provides Get and Put procedures
for unbounded strings.

Re: Reading a line of arbitrary length

[David C. Hoos, Sr.]

What you do is read into a temporary String of length larger than any you
will encounter.  Then you use the value of the actual parameter supplied
for the formal parameter "Last" to take the appropriate slice from the
temporary string.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Thomas Koenig <ig25@fg70.rz.uni-karlsruhe.de> wrote in article
<5ds40o$rpo@fg70.rz.uni-karlsruhe.de>...
> What's the best way of reading a line of arbitrary length in Ada?
> 
> Get_Line only works on Strings, not Unbounded_Strings.  Would I need
> to read in chunks of fixed length, then paste them together?
> -- 
> 74 a3 53 cc 0b 19
> 

Re: Reading a line of arbitrary length

[Jeff Carter]

David C. Hoos, Sr. wrote:
> 
> What you do is read into a temporary String of length larger than any you
> will encounter.  Then you use the value of the actual parameter supplied
> for the formal parameter "Last" to take the appropriate slice from the
> temporary string.

This assumes, of course, that you can define a "length larger than any
you will encounter." In some cases, you cannot. This is still not a
problem; see "Variable-Length String Input in Ada," _Ada Letters_, 1989
May/Jun, which presents a function

function Get_Line (File : Text_Io.File_Type := Text_Io.Current_Input)
return String;

which can then be used to initialize a String object:

declare
   S : String := Get_Line;
begin
   -- use S
end;

Get_Line returns all characters between the current position in File and
the next line terminator, and skips the line terminator. The String
returned has a lower bound of 1 and a length equal to the number of
characters read.
-- 
Jeff Carter
Innovative Concepts, Inc.

Now go away, or I shall taunt you a second time.

Re: Reading a line of arbitrary length

[Ted Dennison]

In article <330319F1.41C67EA6@innocon.com>,
Jeff Carter  <carter@innocon.com> wrote:
>David C. Hoos, Sr. wrote:
>> 
>> What you do is read into a temporary String of length larger than any you
>> will encounter.  Then you use the value of the actual parameter supplied
>> for the formal parameter "Last" to take the appropriate slice from the
>> temporary string.
>
>This assumes, of course, that you can define a "length larger than any
>you will encounter." In some cases, you cannot. This is still not a
>problem; see "Variable-Length String Input in Ada," _Ada Letters_, 1989
>May/Jun, which presents a function

Hmmm. I thought all unix (and VMS) shells had a command-line limit of 256
characters (or less). Is that not the case?

T.E.D.

Re: Reading a line of arbitrary length

[Geert Bosch]

Ted Dennison (dennison@zippy.cc.ukans.edu) wrote:
: Hmmm. I thought all unix (and VMS) shells had a command-line limit of 256
: characters (or less). Is that not the case?

That is not the case for many shells. The shell I use (bash on SunOS 4.1.1)
has a command-line limit of 1 MB. I can hardly believe that many shells have
a command-line limit of 256 characters, since it is very common to enter
long command-lines in Unix. 

Also wildcards are expanded by the shellbefore passing the 
command-line to the external command. So the shell will need to
be able to process long command-lines anyway.

Regards,
   Geert

Re: Reading a line of arbitrary length

[Larry Kilgallen]

In article <5dv7ea$epi$1@news.iag.net>, dennison@zippy.cc.ukans.edu (Ted Dennison) writes:
> In article <330319F1.41C67EA6@innocon.com>,
> Jeff Carter  <carter@innocon.com> wrote:
>>David C. Hoos, Sr. wrote:
>>> 
>>> What you do is read into a temporary String of length larger than any you
>>> will encounter.  Then you use the value of the actual parameter supplied
>>> for the formal parameter "Last" to take the appropriate slice from the
>>> temporary string.
>>
>>This assumes, of course, that you can define a "length larger than any
>>you will encounter." In some cases, you cannot. This is still not a
>>problem; see "Variable-Length String Input in Ada," _Ada Letters_, 1989
>>May/Jun, which presents a function
> 
> Hmmm. I thought all unix (and VMS) shells had a command-line limit of 256
> characters (or less). Is that not the case?

I cannot find the post which started this thread, but at least the
excerpts which have survived do not seem to indicate this is a
command line.  For the VMS case, there are three command line limits,
one of which may be 256 for some version of VMS:

	Maximum characters in a DCL symbol (not our problem)
	Maximum characters in a command to be parsed by VMS
	Maximum characters in a "foreign" command

But then there is:

	Maximum characters from reading SYS$INPUT

which is limited by how the system manager has set the typeahead buffer
and also by MAXBUF.  Those could probably extend to 65535 (or to 32767
with less chance of finding a new bug).  So that is about 32K bytes
(+/- 80 bytes) difference between a "length larger than any you will
encounter." and "what you will typically need".

Larry Kilgallen

Re: Reading a line of arbitrary length

[Rex Reges]

Ted Dennison wrote:
> 
> Hmmm. I thought all unix (and VMS) shells had a command-line limit of 256
> characters (or less). Is that not the case?
> 

Your observation is interesting for reasons other than the Get_Line 
problem.  Get_Line can apply to either a file or keyboard input.  The 
file input is where most problems occur. Files can have very
long lines (they end when the end-of-line character is 
encountered which is not necessary an end-of-record).

The problem with command line input on Unix is that it does 
require arbitrarily long string inputs.  For example, when
the command "grep -i find_me *" is issued, the asterisk 
must be replaced by the names of all of the files in the current
directory before the command is passed to grep.  

It happens frequently that you may want to search some source
code reference directory for with's or whatever.  For a medium
size job of 100,000 lines of code, this may involve 1000 file
names (package specs, package bodies, separates, etc.).  The 
file names tend to get long due to separates, maybe 30 characters
average length.  The string passed to grep ends up being over
30,000 characters long!  

Many Unix implementations cannot handle this problem and the 
grep fails.  Obviously with big jobs the problems get even worse.

Note that VMS does have a limit of 255 or so as you stated, but
you can tack on quite a few continuation lines.  Maybe the 
overall limit is 4095?

-- 
Rex Reges                      or you can call me The Fixer 
Systems Analyst                or you can call me The Lawyer
Lockheed Martin, M&DS          or you can call me The Doctor
(610)354-5047                  or you can call me Rexasaurus

Re: Reading a line of arbitrary length

[Matthew Heaney]

In article <33033173.6EC9@mds.lmco.com>, rex.r.reges@lmco.com wrote:


>The problem with command line input on Unix is that it does 
>require arbitrarily long string inputs.  For example, when
>the command "grep -i find_me *" is issued, the asterisk 
>must be replaced by the names of all of the files in the current
>directory before the command is passed to grep.  

But isn't that what the command xargs is used for?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Reading a line of arbitrary length

[Jean-Etienne Doucet]

About reading arbitrarily long strings, I've found (in a french book
about Ada(83)) something like the following:


with Ada.Text_IO; use Ada.Text_IO;

function Get_Long_String return String is

   type Ref_String is access String;
   
   Buffer : Ref_String := new String'("");
   Input  : Character;

begin -- Get_Long_String

   while not End_Of_Line loop
      Get (Input);
      Buffer := new String'(Buffer.all & Input);
   end loop;
   Skip_Line;
   
   return Buffer.all;

end Get_Long_String;


The question about storage usage was resolved by the fact that leaving the
scope of the Ref_String type would free the storage used by the successive values
of Buffer.all.

I can't fully test it, because my installation can't support input lines longer
than 255 characters :-(

If you've got comments about this construct, I'd be happy to hear them.

_______________________________________________________________________________
Jean-Etienne Doucet / LAAS-CNRS / Toulouse, France       E-mail: doucet@laas.fr

Re: Reading a line of arbitrary length

[Mats Weber]

> The question about storage usage was resolved by the fact that leaving the
> scope of the Ref_String type would free the storage used by the successive values
> of Buffer.all.

In Ada 83, this is not guaranteed to be portable (i.e. it may leak
memory on some implementations). I don't know if reclaiming that memory
is required in Ada 95.

> I can't fully test it, because my installation can't support input lines longer
> than 255 characters :-(

One level of recursion per character will not be very efficient.

Re: Reading a line of arbitrary length

[Robert Dewar]

Mats said

<<In Ada 83, this is not guaranteed to be portable (i.e. it may leak
memory on some implementations). I don't know if reclaiming that memory
is required in Ada 95.>>

certainly it is NOT required in either Ada 83 or Ada 95. In fact, given
the ability to specify storaghe pools, it is even less likely that the
default bejhavior meets this expectation.

Re: Reading a line of arbitrary length

[Robert Dewar]

David said (answering concerns about the above subject)

<<What you do is read into a temporary String of length larger than any you
will encounter.  Then you use the value of the actual parameter supplied
for the formal parameter "Last" to take the appropriate slice from the
temporary string.>>

By definition, this approach does *not* meet the spec, which says
arbitrary. No fixed finite value qualifies as arbitrary!

Re: Reading a line of arbitrary length

[Rex Reges]

Thomas Koenig wrote:
> 
> What's the best way of reading a line of arbitrary length in Ada?
> 
> Get_Line only works on Strings, not Unbounded_Strings.  Would I need
> to read in chunks of fixed length, then paste them together?
> --
> 74 a3 53 cc 0b 19

Inevitably, you will get various unexpected problems using 
the Get_Line function.  Let's assume that you create a 
very large string buffer to handle most situations:

   Input_Buffer : String( 1..10_000_000 ) ;

You may run into one of the following problems:

   1) The IO buffer allocated by the operating system for
      file IO is too small to handle large strings and you
      will get an exception (happens on the Vax for strings
      on the order of a million characters).

   2) You will get a storage_error exception because the 
      variable Input_Buffer will exceed the operating system
      limits on your program size (or more commonly that you 
      don't have stack space to instantiate it).

   3) An exception will occur during the processing and all the
      data for that line will be lost.  The most common exception
      is when an end-of-file is found before the end-of-line 
      (a favorite of xedit users).

Unfortunately, it turns out that getting one character at a time
is the best solution to avoid losing data and to handle unlimited
length strings.  Actully, this is not as bad as it seems since
the machines I have used buffer I/O in chunks anyway so that a
get does not involve a disk access most of the time.


-- 
Rex Reges                      or you can call me The Fixer 
Systems Analyst                or you can call me The Lawyer
Lockheed Martin, M&DS          or you can call me The Doctor
(610)354-5047                  or you can call me Rexasaurus

Re: Reading a line of arbitrary length

[Gene Ouye]

Robert Dewar wrote:

> By the way, I don't know if I mentioned this before, but version 3.10 of
> GNAT will include a complete implementation of SNOBOL-4 pattern matching,
> and other useful items from SPITBOL, including associative arrays.

Whoopee!!  Every time I worked on a project that had any need for string
handling,
it seemed that the first thing I did was come up with a library of
routines that 
simulated SNOBOL-4.  Once you've used SNOBOL, you can't help but miss
its string 
processing capabilities when you move to other languages!

I'll be excited to see these things included in GNAT!!!

(have I used enough exclamation points? can you tell I'm happy?  :-)

Re: Reading a line of arbitrary length

[Robert Dewar]

Gene said

<<Whoopee!!  Every time I worked on a project that had any need for string
handling,
it seemed that the first thing I did was come up with a library of
routines that
simulated SNOBOL-4.  Once you've used SNOBOL, you can't help but miss
its string
processing capabilities when you move to other languages!
>>

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.

Re: Reading a line of arbitrary length

[Brian Rogoff]

On 15 Feb 1997, Robert Dewar wrote:
> <... referring to the planned SNOBOL string library for GNAT v3.10  ...> 
>
> 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.

	Will this library be written in portable Ada-95, or will it be 
GNAT specific? The former would of course be preferable, and save many 
people from writing and using crude approximations.

-- Brian

Re: Reading a line of arbitrary length

[Robert Dewar]

Brian asked

<<        Will this library be written in portable Ada-95, or will it be
GNAT specific? The former would of course be preferable, and save many
people from writing and using crude approximations.>>

it uses (in a critical manner) the GNAT attribute Unrestricted_Attribute.
This is needed both in the implementation, and in the use of the package
(unless you want to force all referenced functions to be at the library
level). It may well have other specific GNAT dependencies. The design
objective is to be usable with GNAT, not with arbitrary Ada 95 compilers.
Oh yes, it also depends (a critical dependency for efficiency purposes)
on the child unit Ada.Strings.Unbounded.Aux, a new unit in GNAT 3.10w,
especially designed to let specialized external packages efficiencyly
access Unbounded internals.

(this is concerning the implementation of SPITBOL support in GNAT 3.10)

Re: Reading a line of arbitrary length

[Brian Rogoff]

On 15 Feb 1997, Robert Dewar wrote:
<... about the SNOBOL-like string library for GNAT ...>
> Brian asked
> 
> <<        Will this library be written in portable Ada-95, or will it be
> GNAT specific? The former would of course be preferable, and save many
> people from writing and using crude approximations.>>
> 
> it uses (in a critical manner) the GNAT attribute Unrestricted_Attribute.
> This is needed both in the implementation, and in the use of the package
> (unless you want to force all referenced functions to be at the library
> level). It may well have other specific GNAT dependencies. The design
> objective is to be usable with GNAT, not with arbitrary Ada 95 compilers.

	This is unfortunate, IMO. Do you think that it would be
prohibitively difficult to implement the library in standard Ada 95? I've 
started working on my Ada pattern matching library, which is based on a
Perl style regexp matcher, but I'd drop it if I knew that something better 
was on the way. Here "better" also means "portable". 

-- Brian

Re: Reading a line of arbitrary length

[Robert Dewar]

Brian said

<<        This is unfortunate, IMO. Do you think that it would be
prohibitively difficult to implement the library in standard Ada 95? I've
started working on my Ada pattern matching library, which is based on a
Perl style regexp matcher, but I'd drop it if I knew that something better
was on the way. Here "better" also means "portable".>>

Since we are only interested in it working with GNAT, as efficiently
as possible, this is not unfortunate from our point of view. Yes it
would be possible to do a portable version, but it would be annoyingly
limited (by not allowing the use of nested functions), and the syntax
would not be nearly so neat.

This implementation will of course be portable between all implementations
of GNAT! It will be GPL'ed code, so you can certainly use it as a starting
point for a more standard version (it's about 10,000 lines of code in all
including comments).

Re: Reading a line of arbitrary length

[Rex Reges]

Robert Dewar wrote:

> If your point is that it is non-trivial to ensure efficient execution of
> programs that use variable length strings that are millions of characters
> long, then yes, that is true, it is non-trivial, and also non-important!
> 

What you say about very large variable length strings
is true. I did not clearly express what I was talking about:
one very long string and that string is of fixed length.

The case I was thinking of is a distributed real-time simulator.  It was
distributed in that it consisted of several Ada mains which may or may 
not run on the same CPUs within the same computer.  It was real-time
in that some of the processes had to repeatedly complete a specific 
amount of work within set frames of 120 Hz, 60Hz and 30Hz.  

The problem was how to pass string information quickly.  This 
string information consisted of error messages, symbol names, and 
commands.  The solution used was to create a string heap that 
was similar to the regular heap except that persistent strings
were compressed and that each process could add to its string heap 
from entries in another processes string heap.  

Integer IDs for strings were provided at string creation time and
were gauranteed to be unique among all the processes.  The code
which used the string heap was unaware of the compression and 
communication mechanisms.  This allowed strings to be passed 
around as if using access types, but provided global distributed
strings.

The large string issue arose in the string heap itself.
A single large fixed-length string was used as the heap.
Start index and size were used to keep track of each string
heap entry.  

It was possible to save the string heap to a file and then 
restore it later.  This was useful for the symbol table data
which doesn't change from one execution to another.  This
caused a problem on the Vax: not being able to read in a 
5 million character string in one chunk.  

I've left out a lot of details which are hopefully 
irrelevant to this discussion, but I would like to 
mention the compression needs.  The symbol information
consisted of 70,000 symbols which were fully qualified
Ada names.  It also included the enumeration values 
for those symbols which were enumeration types.  This
information alone was over 5 megabytes.  The compression
mechanism was simple: a vocabulary of frequently
occuring substrings was created, then each symbol was 
saved as an array of vocabulary entries.  

The constraints of the real-time response
precluded the usual fixes like storing strings in a file.
It was necessary to keep the memory usage to a minimum
so that the programs could be locked in memory to prevent
page swapping.
 
It's good news to hear about the pattern matching!  Up to
now I've been satisfied writing string tools as needed, but 
the general feeling I got from other Ada programmers is that 
Ada doesn't do strings.  


-- 
Rex Reges                      or you can call me The Fixer 
Systems Analyst                or you can call me The Lawyer
Lockheed Martin, M&DS          or you can call me The Doctor
(610)354-5047                  or you can call me Rexasaurus

Re: Reading a line of arbitrary length

[Mats Weber]

> Probably first will be stack space, tasks tend to be limited in
> stack by about 100_000 bytes (I realize this can be adjusted).
> A problem will occur when the catenation result is stored temporarily
> on the stack because there won't be enough stack space to save it.

OK.

> Assuming this is fixed, the next problem will occur when heap space
> is exhausted, probably around 1_000_000 bytes.  This is because both
> Str1.all and Str2.all must exist for a short period together meaning
> that 2 megabytes of heap will be in use at one time.  Since tasks
> tend to have their own heap allocations, I'm predicting a
> Storage_Error exception will occur.

Wrong, the heap is generally global with respect to tasks, and it has to
be that way in this case because the type String_Access is a global
access type, potentially visible from any task.

Re: Reading a line of arbitrary length

[Robert Dewar]

Mats said

<<Wrong, the heap is generally global with respect to tasks, and it has to
be that way in this case because the type String_Access is a global
access type, potentially visible from any task.>>

There is no issue of visibility here, just because an access type is
visible to more than one task does not mean that it has to be allocated
in a global heap. Indeed, a very reasonable approach for *all* allocation
activity is to allocate from task local sub-storage pools to avoid the
expense of global task locking for allocation. This approach is quite
general, and applies to general and pool-specific access types.

You do have to be careful about unchecked_deallocation, but there are
completely safe algorithms that handle this case without locking as
well.

We have quite carefully considered approaches of this kind, especially
in the context of unbounded strings handling.

Re: Reading a line of arbitrary length

[Mats Weber]

> <<Wrong, the heap is generally global with respect to tasks, and it has to
> be that way in this case because the type String_Access is a global
> access type, potentially visible from any task.>>
> 
> There is no issue of visibility here, just because an access type is
> visible to more than one task does not mean that it has to be allocated
> in a global heap. Indeed, a very reasonable approach for *all* allocation
> activity is to allocate from task local sub-storage pools to avoid the
> expense of global task locking for allocation. This approach is quite
> general, and applies to general and pool-specific access types.

Interesting. But what happens to the task-local sub-storage when the
task terminates ? 

Is there a paper or other documentation where I can find information
about how memory allocation problems are solved in GNAT ?

Re: Reading a line of arbitrary length

[Robert Dewar]

Mats asks

<<Interesting. But what happens to the task-local sub-storage when the
task terminates ?

Is there a paper or other documentation where I can find information
about how memory allocation problems are solved in GNAT ?>>


To the first question: nothing special, you certainly cannot free it
in general, since the values may be referenced from other tasks.

To the second, memory management in GNAT is pretty straightforwardly
understood from the sources. You may also find the use of -gnatdg
helpful in studying the generated code, as well as styding the coding
of the standard storage pools.

Re: Reading a line of arbitrary length

[Robert Dewar]

Rex said

<<What is surprising is the GNAT routine's performance.  Obviously,
my assumption that a stack-to-heap transfer was occurring is
"erroneous".  Generally, there are several stacks:>>

I can't see any stack-to-heap transfers going on in the GNAT code ...

Re: Reading a line of arbitrary length

[Mats Weber]

>   Longest_Guess : Natural := 40;

You can't do this ! This global variable makes your code unusable with
tasks.

>   function Get_Line return String is
>     Buffer : String (1 .. Longest_Guess);
>     Last   : Natural;
>   begin
>     Ada.Text_IO.Get_Line (Buffer, Last);
> 
>     if Last = Buffer'Last then
>       Longest_Guess := Longest_Guess + Longest_Guess/2; -- 1.5x
>       return Buffer & Get_Line;
>     else
>       return Buffer(1..Last);
>     end if;
>   end Get_Line;

I would change it to:

  function Get_Line (Longest_Guess : Positive) return String is 
    Buffer : String (1 .. Longest_Guess);
    Last   : Natural;
  begin
    Ada.Text_IO.Get_Line (Buffer, Last);

    if Last = Buffer'Last then
      return Buffer & 
             Get_Line
               (Longuest_Guess => Longest_Guess + Longest_Guess/2);
    else
      return Buffer(1..Last);
    end if;
  end Get_Line;

  function Get_Line return String is
  begin
    return Get_Line(Longuest_Guess => 40);
  end;

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Brian Rogoff]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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

Re: Reading a line of arbitrary length

[Brian Rogoff]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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!

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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!

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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!

Re: Reading a line of arbitrary length

[Robert Dewar]

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 :-)

Re: Reading a line of arbitrary length

[Fergus Henderson]

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.

Re: Reading a line of arbitrary length

[Larry Kilgallen]

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

Re: Reading a line of arbitrary length

[Fergus Henderson]

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.

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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.

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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.

Re: Reading a line of arbitrary length

[Thomas Koenig]

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

Re: Reading a line of arbitrary length

[Larry Kilgallen]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

Larry said

<<Currently all known implementations support your goal>>

(speaking of lack of garbage collection)

Not quite fair, the Intermetrics Applet Magic compiler provides full GC
(I trust that is the right commercial designation, if not sorry!)

Re: Reading a line of arbitrary length

[Robert Dewar]

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.

Re: Reading a line of arbitrary length

[Robert A Duff]

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

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert A Duff]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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!

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Robert Dewar]

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
it is certainly not what I mean!

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Larry Kilgallen]

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

Re: Reading a line of arbitrary length

[Fergus Henderson]

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.

Really more GC talk (was: Reading a line of arbitrary length)

[Larry Kilgallen]

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

Re: Really more GC talk (was: Reading a line of arbitrary length)

[Fergus Henderson]

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.

Re: Really more GC talk (was: Reading a line of arbitrary length)

[Robert Dewar]

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.

Re: Really more GC talk (was: Reading a line of arbitrary length)

[Fergus Henderson]

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.

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Jon S Anthony]

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

Re: Reading a line of arbitrary length

[Matthew Heaney]

In article <5ds40o$rpo@fg70.rz.uni-karlsruhe.de>,
Thomas.Koenig@ciw.uni-karlsruhe.de wrote:

>What's the best way of reading a line of arbitrary length in Ada?
>
>Get_Line only works on Strings, not Unbounded_Strings.  Would I need
>to read in chunks of fixed length, then paste them together?

Yes.

There is a very simple way to do this that does not require explicit heap
allocation nor GNAT-specific extensions to the language.

When you call Get_Line,  e.g.

declare
   The_Buffer (1 .. 80);
   Last : Natural;
begin
   Ada.Text_IO.Get_Line (The_Buffer, Last);
end;

then Last will be in the range [0, The_Buffer'Last].

The key is realizing that if Last = The_Buffer'Last after the call, then
there's more data on the same line (even if it's just the end of line
marker).  You just have to keep reading until Last < The_Buffer'Last.

Here's the code to do it:


with Ada.Strings.Unbounded;

procedure Get_Line (
   Item          : in out Ada.Strings.Unbounded.Unbounded_String;
   Buffer_Length : in     Positive := 80);



with Ada.Text_IO;

procedure Get_Line (
   Item          : in out Ada.Strings.Unbounded.Unbounded_String;
   Buffer_Length : in     Positive := 80) is

   The_Buffer : String (1 .. Buffer_Length);
   Last       : Natural;

   use Ada.Strings.Unbounded;

begin -- Get_Line

   Item := Null_Unbounded_String;

   loop
      Ada.Text_IO.Get_Line (The_Buffer, Last);
      Append (Item, New_Item => The_Buffer (1 .. Last));
      exit when Last < The_Buffer'Last;
   end loop;

end Get_Line;

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Reading a line of arbitrary length

[Robert Dewar]

Matthew said

<<There is a very simple way to do this that does not require explicit heap
allocation nor GNAT-specific extensions to the language.>>

I don't know why one should worry about explicit heap allocation as opposed
to implicit heap allocation being done behind the scenes in 
Ada.Strings.Unbounded (almost certainly Append is likely to do some
heap allocation ...)

Re: Reading a line of arbitrary length

[Matthew Heaney]

In article <dewar.856123955@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

><<There is a very simple way to do this that does not require explicit heap
>allocation nor GNAT-specific extensions to the language.>>
>
>I don't know why one should worry about explicit heap allocation as opposed
>to implicit heap allocation being done behind the scenes in 
>Ada.Strings.Unbounded (almost certainly Append is likely to do some
>heap allocation ...)

Yes, it's true the heap is being implicitly allocated behind the scenes,
and that is exactly where I prefer to keep it.  In general, messing with
heap is dangerous business.  If it's a toss-up between a solution that
requires explicit heap allocation and a solution that hides that
allocation, then the latter solution wins.  

Also, I'm assuming that implementations of Unbounded_String are going to
make heap-space allocation optimizations that won't necessarily apply to
using the new operator directly.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Reading a line of arbitrary length

[Robert Dewar]

Matthew said

<<Yes, it's true the heap is being implicitly allocated behind the scenes,
and that is exactly where I prefer to keep it.  In general, messing with
heap is dangerous business.  If it's a toss-up between a solution that
requires explicit heap allocation and a solution that hides that
allocation, then the latter solution wins.

Also, I'm assuming that implementations of Unbounded_String are going to
make heap-space allocation optimizations that won't necessarily apply to
using the new operator directly.>>

Of course in GNAT, the *entire* operation of reading a variable length
string is behind the scenes. A programmer using GNAT version 3.10 merely
writes:

with Ada.Strings.Unbounded.Text_IO; use Ada.Strings.Unbounded.Text_IO;

...

    S : Unbounded_String := Get_Line (file);

and that's the end of it.

Re: Reading a line of arbitrary length

[Jon S Anthony]

In article <dewar.856619522@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 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).

Hold on - I thought that you no longer support this one (after seeing
some particularly bad examples of where some people wanted to use it)??!?

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Reading a line of arbitrary length

[Fergus Henderson]

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.

Well, if you require that GC be completely transparent even with
multi-language programming, you are effectively requiring conservative GC;
I don't think a standard should prohibit other approaches to GC.

>GC in SNOBOL4 is indeed transparent, and that is the way things should
>be in my opinion.

Does SNOBOL4 have a C interface?

--
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.

Re: Reading a line of arbitrary length

[Richard A. O'Keefe]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

>dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>>GC in SNOBOL4 is indeed transparent, and that is the way things should
>>be in my opinion.

>Does SNOBOL4 have a C interface?

The (free) DOS/UNIX/VMS port of the SIL implementation of SNOBOL4, by Budne,
does indeed have a C interface.  The current release supports dynamic loading
only on BSD+a.out systems, but static linking with C code is supported on all
systems.

SNOBOL4 of course considerably predates C. The SNOBOL4 "green book"
does, however, describe how to load and call Fortran.


-- 
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Reading a line of arbitrary length

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>>>GC in SNOBOL4 is indeed transparent, and that is the way things should
>>>be in my opinion.
>
>>Does SNOBOL4 have a C interface?
>
>The (free) DOS/UNIX/VMS port of the SIL implementation of SNOBOL4, by Budne,
>does indeed have a C interface.

So how transparent is the GC when used with the foreign language
interface?  Can one pass a pointer to a dynamically allocated SNOBOL4
data structure to the C code?  What happens if the last pointer to such
a data structure exists only in a C global variable?

--
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.

Re: Reading a line of arbitrary length

[Robert Dewar]

iFergus says

<<So how transparent is the GC when used with the foreign language
interface?  Can one pass a pointer to a dynamically allocated SNOBOL4
data structure to the C code?  What happens if the last pointer to such
a data structure exists only in a C global variable?
>>

Given that typical SNOBOL4 compilers have compacting collectors, they
are WAY out of range of this kind of consideration. A conservative
collector cannot conservatively modify things that it is not sure are
pointers! So the answer is that C can reference structures, but cannot
hold onto pointers AT ALL, let alone be the only one to hold on to them!

Re: Reading a line of arbitrary length

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Fergus says
>
><<So how transparent is the GC when used with the foreign language
>interface?  Can one pass a pointer to a dynamically allocated SNOBOL4
>data structure to the C code?  What happens if the last pointer to such
>a data structure exists only in a C global variable?
>>>
>
>Given that typical SNOBOL4 compilers have compacting collectors, they
>are WAY out of range of this kind of consideration. A conservative
>collector cannot conservatively modify things that it is not sure are
>pointers! So the answer is that C can reference structures, but cannot
>hold onto pointers AT ALL, let alone be the only one to hold on to them!

OK, so I guess you have to use some sort of handles instead of pointers.
Hmmm, it's not sounding quite so transparent anymore...
But my question still stands: what happens if the last reference
(handle, pointer, whatever) to a dynamically allocated SNOBOL4 data
structure is stored in a C global variable?

--
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.