1. One last shot at Namespace and Structure
I have spent the last several days reading everything that I could find on
namespace and structure since January 1, 1998. There is a huge amount of
quite thoughtful information in that span, and I am sure that Rob has taken
note of it, but I think that some of it has become so theoretical that it
would be difficult to decide what is important.
My basic wish is for this:
A. Some means(can't use method here...might confuse) that will allow me to
read one of the thousands of files in this world with fixed length records
and fields, make changes and write it back out to a new file.
1. I don't care if it takes objects or classes or structures, but I want
to be able to use the same basic template(read here include) for the input
and output files( because I probably will do it over and over again and the
files are structurally identical).
2. I want to be able to refer to the fields in the input and output
records by name without using screwy numbered constants and without having
to play strange games to separate the input fields from the output fields.
3. I would really like to be able to dynamically attach a name to any
element in a sequence and have it usable from that point. But I will live
without this one.
B. I want to be able to use as many different libraries as I need without
having to look at anything but their documentation(knowing that in some
cases, I may not be able to look inside them anyway).
1. Whatever rules for precluding colliding includes are necessary, let us
enforce them in the interpreter...not depend on the good will and skills of
programmers at various levels of experience, however well intentioned.
2. If they are to be allowed to overlap intentionally, then give us
precedence rules(I think we have most of these, already).
3. If we don't want them to overlap, then we should be able to prevent
that at the include level, without acting or editing inside the include.
4. Dynamic includes would be really nice to allow programs to flexibly
adjust themselves to platform or environment or user selection without
contorted methods or including unneeded code to occupy the interpreter.
C. The means to exclude some items from bind so that initialization files
and other such items may be more easily implemented in bound code.
All these items share a logical set of functions except for the last and
that one comes from the same needs. Those needs are to be able to handle
data from external sources quickly and easily and to program arbitrarily
complex and large code sequences in as modular a manner as possible.
However these items are accomplished, I will be happy. Of course, timely
fulfilment wouldn't hurt my feelings :)
Everett L.(Rett) Williams
rett at gvtc.com
2. Re: One last shot at Namespace and Structure
This first desire of fixed length fields is easily obtainable.
I will see about creating some code to do just that in the near future.
If you know that all fields are fixed length then you can easily,
randomly read and/or edit any record without having to read the entire
file. Thus is the nature of fixed length fields and records.
Sincerely,
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow | ICQ: 9638898 | AIM: LLHIII | Computer |
| Horse +--------------+--------------+ Cafe' |
| Software | http://www.cdc.net/~lhilley | USA |
+----------+-------+---------------------+----------+
| http://www.ComputerCafeUSA.com |
+--------------------------------+
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, October 18, 1999 1:51 AM
Subject: One last shot at Namespace and Structure
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Everett Williams <rett at GVTC.COM>
> Subject: One last shot at Namespace and Structure
> --------------------------------------------------------------------------
-----
>
> I have spent the last several days reading everything that I could find on
> namespace and structure since January 1, 1998. There is a huge amount of
> quite thoughtful information in that span, and I am sure that Rob has
taken
> note of it, but I think that some of it has become so theoretical that it
> would be difficult to decide what is important.
>
> My basic wish is for this:
>
> A. Some means(can't use method here...might confuse) that will allow me to
> read one of the thousands of files in this world with fixed length records
> and fields, make changes and write it back out to a new file.
>
> 1. I don't care if it takes objects or classes or structures, but I
want
> to be able to use the same basic template(read here include) for the input
> and output files( because I probably will do it over and over again and
the
> files are structurally identical).
>
> 2. I want to be able to refer to the fields in the input and output
> records by name without using screwy numbered constants and without having
> to play strange games to separate the input fields from the output fields.
>
> 3. I would really like to be able to dynamically attach a name to any
> element in a sequence and have it usable from that point. But I will live
> without this one.
>
> B. I want to be able to use as many different libraries as I need without
> having to look at anything but their documentation(knowing that in some
> cases, I may not be able to look inside them anyway).
>
> 1. Whatever rules for precluding colliding includes are necessary, let
us
> enforce them in the interpreter...not depend on the good will and skills
of
> programmers at various levels of experience, however well intentioned.
>
> 2. If they are to be allowed to overlap intentionally, then give us
> precedence rules(I think we have most of these, already).
>
> 3. If we don't want them to overlap, then we should be able to prevent
> that at the include level, without acting or editing inside the include.
>
> 4. Dynamic includes would be really nice to allow programs to flexibly
> adjust themselves to platform or environment or user selection without
> contorted methods or including unneeded code to occupy the interpreter.
>
> C. The means to exclude some items from bind so that initialization files
> and other such items may be more easily implemented in bound code.
>
> All these items share a logical set of functions except for the last and
> that one comes from the same needs. Those needs are to be able to handle
> data from external sources quickly and easily and to program arbitrarily
> complex and large code sequences in as modular a manner as possible.
>
> However these items are accomplished, I will be happy. Of course, timely
> fulfilment wouldn't hurt my feelings :)
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
3. Re: One last shot at Namespace and Structure
On Mon, 18 Oct 1999 11:00:33 -0400, Lucius L. Hilley III <lhilley at CDC.NET>
wrote:
> This first desire of fixed length fields is easily obtainable.
>I will see about creating some code to do just that in the near future.
>If you know that all fields are fixed length then you can easily,
>randomly read and/or edit any record without having to read the entire
>file. Thus is the nature of fixed length fields and records.
>
I have been programming such things since 1966. I was using the simplest
case to demonstrate what, at minimum, should be accomplished by the changes
I am requesting. A byproduct of solving that issue at the interpreter level
will be the ability to do many other things. I would, however, welcome the
IO routines to access random fixed records. The post was really aimed at Mr.
Craig, with the secondary purpose of clarifying to many of the other posters
what IMO are the minimum goals to be accomplished by all the various
specific and theoretical discussions that have occurred on namespaces and
structures.
In the process of reading all that material, I stumbled on one post from Rob
that basically promised that "something" would be done in namespaces as a
very high priority...only with a Linux Alpha coming first. By the timing of
that post, I hope that namespaces will be dealt with in the next release(2.2
or 3.0 depending on how important he regards it as). I am hoping that
release will occur before the New Year. I have some things that I would like
to do in this language, but am unwilling to attempt until I see the type of
facilities that I have requested.
Your contributions to the discussion have been most thoughtful, and I have
enjoyed them. However good your routines for naming fixed fields might be,
it is most likely that they will conflict with whatever final solution is
implemented. I would be most interested in seeing and even playing with such
a set of routines for small utility programs, but I would be unwilling to
use them in any large undertaking. I thing that such a set of routines might
act as a model to Rob for whatever solution that he is contemplating. Proofs
of concept are always useful testbeds for ideas. Please inform me if or when
you do your routines.
Just as an aside, the first language that I ever used for fixed file repair
and reporting is still probably the easiest that I have ever seen. It was
one of the first "3rd generation" languages called EasyTreve by Pansophic.
One used offset and length with a name to describe only the fields that one
was interested in. All IO was basically automatic unless something other
than simple in and out was being done. Files were specified at execution
time in the JCL(Job Control Language for those too young to know).
Initially, the language had no branching or looping capability. Each record
was handled by the logic of the routine. When the end of the code was
reached, another record was read and the code re-executed. Later, some other
facilities were added, but it was very simple and quite powerful, especially
for it's time(1974). With that tool, I could produce reports and make
changes in less than one hour that required as much as two to three months
for the COBOL programmers to accomplish.
Everett L.(Rett) Williams
rett at gvtc.com
