1. A tiny bit more about structures and arrays
Some time ago, Ralph Nieuwenhuijsen requested (in one of his
many interesting letters to the list) that structures and arrays be
implemented in euphoria (I assume, as integrated parts of the
interpreter, not only as official include files).
I'm personally not very exited about this,
though I'm no expert on programming languages,
and I'm open for good arguments (of which I'm
sure Ralf has plenty :)
It's just that when I read the refman.doc for
the first time,one of the things that really
struck me was the following lines:
"2.1.1 Atoms and Sequences
All data objects in Euphoria are either atoms or sequences. An atom is a
single numeric value. A sequence is a collection of numeric values."
Period.
It made me feel incredibly smart ;-> after a few seconds of reading, I had
managed to grasp the essence of this new programming langugage.
And I liked that essence. The dualist relationship between the infinitely
simple and the infinitely complex really appealed to me.
Ralph, are you sure you want those lines in the
refman to change into:
"2.1.1 Atoms, sequences, structures, arrays and other stuff.
All data objects in Euphoria are USUALLY either atoms or
sequences. An atom is a single numeric value. A sequence
is a collection of numeric values. Well, and then of course
there are structures which are somewhat different from
sequences, and arrays, which are like square
multidimentional sequences without dynamic memory
allocation, and ..."
Get my point?
I have still not understood why a special structure type is needed
in euphoria. The reason is probably that I'm still missing some
vital information on the subject. I guess I should have paid more
attention when the thread on structures flourished last year...
What I know is that, in contradiction to what I earlier believed, type
checking can presently be performed on sequences and
subsequences of any size or shape, since the algorithm inside the
type function can be of any complexity.
I also know that a series of elements in a sequence can not be directly
accessed in more than one dimension, which is perhaps one of the
'drawbacks' of sequences.
I mean; in s={{a1, a2},{b1,b2}} you can access all the "a" elements in
one go, but you cant access all the "1" elements (however, in Qbasic,
you can not even access all the "a" elements without using a loop...).
Would structures improve on this problem?
I also heard mentioned a so-called "name spacing" problem when using
sequences instead of structures. What is this all about?
Best regards,
Tor Bernhard Gausen.
2. Re: A tiny bit more about structures and arrays
Would someone who understands both Euphoria & Pascal please convert the
following to Euphoria 2.0 syntax. I suspect it will be quite a bit of code
so its a big favor I know. Also, I apologize for the compressed Pascal
syntax in advance...
type
t_sex = (m,f); t_digit = ("0".."9"); t_ssn = packed array [1..9] of
t_digit; t_name = string[30];
t_date = record year : 1900..2100; month : 1..12; day : 1..31; end;
t_person = record who , title : t_name; ident : t_ssn; gender : t_sex;
born , hired : t_date; end;
I work with records / structures a **lot** in other languages and I think
that I can explain Tor's questions if I have a good example of how the code
might be simplified from 2.0 to a fictional/proposed Euphoria with
structures (Euphoria 3.0 ?).
3. Re: A tiny bit more about structures and arrays
At 06:46 p.m. 28-01-99 -0800, you wrote:
>Would someone who understands both Euphoria & Pascal please convert the
>following to Euphoria 2.0 syntax. I suspect it will be quite a bit of code
>so its a big favor I know. Also, I apologize for the compressed Pascal
>syntax in advance...
Uncompressed pascal:
type
t_sex = (m,f);
t_digit = ("0".."9");
t_ssn = packed array [1..9] of t_digit;
t_name = string[30];
t_date = record
year : 1900..2100;
month : 1..12;
day : 1..31;
end;
t_person = record
who , title : t_name;
ident : t_ssn;
gender : t_sex;
born , hired : t_date;
end;
Euphoria "equivalent":
type t_sex (integer sex)
return (sex = 'm') or (sex = 'f')
end type
type t_digit (integer digit)
return (digit >= "0") and (digit <= "9")
end type
type t_ssn (sequence ssn)
if length(ssn) > 9 then
return 0
else if length(ssn) = 0 then
return 1
else
for i = 1 to length(ssn) do
if not t_digit(ssn[i]) then
return 0
end if
end for
end if
return 1
end type
type t_name (sequence name)
if length(name) > 30 then
return 0
else if length(name) = 0 then
return 1
else
for i = 1 to length(ssn) do
if (name[i] < 0) or (name[i] > 254) then
return 0
end if
end for
end if
end type
type t_date (sequence date)
if length(date) = 0 then
return 1
else if length(date) != 3 then
return 0
else
if (date[1] < 1900) or (date[i] > 2100) then
return 0
end if
if (date[2] < 1) or (date[2] > 12) then
return 0
end if
if (date[3] < 1) or (date[3] > 31) then
return 0
end if
end if
return 1
end type
type t_person (sequence person)
return t_name(person[1]) and t_name(person[2]) and t_ssn(person[3]) and
t_sex(person[4]) and t_date(person[5]) and t_date(person[6])
end type
>I work with records / structures a **lot** in other languages and I think
>that I can explain Tor's questions if I have a good example of how the code
>might be simplified from 2.0 to a fictional/proposed Euphoria with
>structures (Euphoria 3.0 ?).
As you can see it's very dificult to "strucutrize" Euphoria. Euphoria, on
it's language definition, it very struturized (and I love that), but data
types aren't designed that way :(
If you want to create a t_person "array" you'll need another type declaration:
type t_person_list (sequence person_list)
if length(person_list) = 0 then
return 1
end if
for i = 1 to length(person_list)
if not t_person(person_list[i]) then
return 0
end if
end for
return 1
end type
Regards,
Daniel Berstein
daber at pair.com
4. Re: A tiny bit more about structures and arrays
From: Tor Bernhard Gausen
>It made me feel incredibly smart ;-> after a few seconds of
>reading, I had managed to grasp the essence of this new programming
>langugage.
>And I liked that essence. The dualist relationship between the
>infinitely simple and the infinitely complex really appealed to me.
True, that is a Good Thing. But, Euphoria allows you to create your own
types of any complexity, or use allocate() and free() to manipulate memory
directly, etc, etc. So why not structures as well? Just like the other
complex stuff, the beginner doesn't have to mess with 'em until they're
needed, and then they'd be there.
>I also heard mentioned a so-called "name spacing" problem when using
>sequences instead of structures. What is this all about?
Therein lies the big problem. Namely, the accepted way to address items
in a
sequence is to declare constants for every index. Quite often, they'll need
to be global. Thus you must come up with different constants for each type
that you want to use, to avoid conflicts and accidentally attempting to
redefine a constant.
Structures create their own little namespace, avoiding that problem. It also
helps to prevent accidentally using an addressing constant on the wrong type,
which could be a tough logical error to find, as your data would be wrong, but
the program may or may not crash. Ex:
global constant NAME = 1, ADDRESS = 2, PHONE = 3
global constant MAKE = 1, MODEL = 2, WHEELS = 3
sequence c = repeat( 0, 3 )
--[...lots and lots of code doing mysterious things...]
c[WHEELS] = 4
Is that setting some vehicle's number of wheels to 4 or some person's phone
number to 4?
With structures, you would know it was right, because the person structure
doesn't have a WHEELS attribute.
struct Person
NAME
ADDRESS
PHONE
end struct
struct Vehicle
MAKE
MODEL
WHEELS
end struct
Person c
c[WHEELS] = 4 (or in the common syntax: c.WHEELS = 4 )
would produce "Attribute WHEELS not defined for struct Person" or some similar
error message.
Also, you could have another structure with the attributes
struct Employee
NAME
WORK_ADDRESS
WORK_PHONE
ADDRESS
PHONE
end struct
and NAME and PHONE wouldn't produce an "Attempt to redefine" crash, or
conflicts. You wouldn't have to worry about the structures someone else
defined in another include, or their scope, as long as they didn't have
another structure by the same name.
Thus, if the Person structure was buried somewhere in a shrouded include file
that was included in a file included by your main program... Well, the way it
is now, you'd have a crash. With structures, it'd work, even if you didn't
know the Person structure existed.
Of course, there's also the issue of making structured types. (Or typed
structures). Much easier and cleaner to say:
struct Person
string Name
integer Age
atom Salary
end struct
than the current method:
global constant NAME = 1, AGE = 2, SALARY = 3
global type Person( object v )
if sequence( v ) then
if length( v ) = 3 then
if string( v[NAME] ) and
integer( v[AGE] ) and
atom( v[SALARY] ) then
return TRUE
end if
end if
end if
return FALSE
end type
Thus, it would be easier for beginners too. Both by helping to avoid sneaky
logic errors and by making declarations easier, in addition to helping ease
the namespace-hacking burden.
Arrays would also be a useful thing to have in the Euphoria toolbox, but I
haven't yet got frustrated from lack of them.
I like using Ralf's oop.e, even just for structures. Makes it easy to build
structured types. Not as easy as it would be if it were built-in, but it also
provides oop functionality.
Of course, some of that is just style and opinion, you can code without 'em.
But why? Euphoria's dynamic typeless sequences are it's best asset at times,
but it's lack of structured types is the worst drawback at other times. Why
not have both?
Okay, that's enough rambling for me for one night. 
Falkon
