1. Structures
- Posted by bensler at mail.com
Feb 20, 2002
Hi all,
Are there any libs for structure handling? I found only record.e in
the archive and it seems like a hack to me.
Anyways, I developed a system, that I think works very well.
It's basically just one routine, and a few constants.
You define your structure using a sequence, and validate your object in
comparison to the structure definition.
You can do stuff like this:
-- SAMPLE --
function char(object c)
if not integer(c) then return 0 end if
return c >= 0 and c <= 255
end function
-- THE STRUCTURE DEFINITION
constant MY_STRUCT_NULL ={
VS_INT, -- integer
VS_OBJ, -- object (anything can go in this element)
{ -- specifically defined sequence
VS_SEQ, -- undefined sequence
VS_INT -- integer
},
VS_ATOM, -- atom
{routine_id("char"),-255} -- custom type defininition (STRING,
MaxLen = 255)
}
type my_struct(object x)
if not valid_structure(x,MY_STRUCT_NULL) then structure_failed() end
if
return 1
end type
my_struct test
test = MY_STRUCT_NULL
-- END SAMPLE --
When a structure fails, and you call structure_failed(), you will get an
error message, something like this:
"Structure Validation Failed in element [1][2][3]"
"Atom Expected"
"Structure Definition is {0.1,0,{}}"
"Structure is {"WRONG",5,{'R','I','G','H','T'}}"
Your structure can be as complex as you like, and there are only 3
routines:
valid_structure() -- compare object to structure definition
structure_failed() -- force fatal error, with automatic error message
get_structure_error() -- handle the error yourself
I'd like to hear your opinions, and get some test drives before I give
it to Rob for the archives.
Thx
Chris
2. Structures
Hello all,
It's been a while since I've been active on the list
here, work projects have left me little time to pursue
programming for fun. I've still followed the list
passively when time has permitted because I still find
Euphoria a fascinating topic.
The subject of structures has been of particular
interest to me. It's one of those topics that manages
to resurrect itself every couple of months or so and
stir up heated discussions on both sides of the fence.
I'm admittedly biased, but until recently I didn't
feel that the "anti-structure" camp had made many
compelling arguments towards how the addition of
structures would "damage" Euphoria. Arguments centered
around the idea that if the programmer could emulate
something then there was no need to add a new feature,
regardless of the problems that the emulation incurred.
I'm glad this idea was never a dominant theory in
computer science or we'd all still be coding entirely
in assembly;)
For me, a couple of the recent posts are the first to
really show that the ideas put forth so far concerning
structures haven't addressed all the issues they needed
to. Type checking has been one of the leading arguments
*for* adding structures to Euphoria, but not all of the
aspects concerning how the typing of structures should
be handled have been investigated.
When I first became interested in the idea of adding
structures to Euphoria some time ago, I posted to the
list a bit of "conceptual" code to try to work out how
structures could be handled. It delves into a few more
details about type checking than many of the other
examples posted about structures, including the use of
structures as parameters, etc. You can find it in the
mail archives here:
Gabriel Boehme's post made me aware that I had neglected
to think through an important area: sequences containing
structures (even though I had gone as far as pointing out
that they would be possible). Specifically I had missed
the question of how they could be accessed given that
the containing sequence might have mixed data within it.
-------------------------------------------------------------------------
-- here's the problem:
structure my_struct1 begin
sequence a_member
end structure
structure my_struct2 begin
integer a_member
end structure
sequence a_sequence
atom an_atom
my_struct1 a_struct1
my_struct2 a_struct2
integer some_var
.
.
.
a_sequence = {a_struct1, a_struct2, an_atom}
.
.
.
a_sequence[some_var].a_member = "foo" -- Bad idea!
-------------------------------------------------------------------------
Jacques Guy's idea that the structure's declaration
should implicitly generate a type-checking function as well
would alleviate this problem, making the following possible:
if my_struct1(a_sequence[some_var]) then
a_sequence[some_var].a_member = "foo"
end if
Such an assignment would be quite slow though because
the interpretor can't just assume you were thoughtful enough
to perform all the necessary type-checking. On every pass
it would have to:
1. obtain the type of a_sequence[some_var], and verify that
it is a structure.
2. verify that a_sequence[some_var] has a member named a_member
(this will be very slow. It can't hard-code an index number
because it has no idea which structure is being used,
so it must look up the index number every time)
3. Perform the normal type-check to verify that the member
can hold what's being assigned to it.
The alternatives (that I've thought of) to this are
not very attractive...
One is to disallow access to the members of a structure
burried within a sequence, forcing the programmer to
shuffle the structure out to a temporary variable defined
of that type in order to read or modify it's members.
The other is to treat the structure like a sequence and
access it's members through the [] operator...
although I'll explain later why this should be allowed,
it's not the ideal solution to this particular problem
because it defeats the usefulness of having structures
to begin with... it re-instates the need for either
"magic-number" indicies, or constants that are liable
to suffer from namespace conflicts.
The automatic formation of the type check function for
the structure also addresses another of Mr. Boehme's
concerns: "What is the type of a structure?" Every
structure definition is it's own new type...
Using the declarations from the example above, an
assignment such as this would be illegal because they
have different types:
a_struct1 = a_struct2
Even if the two structures contained identical member
types in the same order, it would not be safe to allow
this. The problem is that if the author later comes in
and adds something to my_struct1 without doing the same
to my_struct2, the code will break all over the place.
It's better to have the assignments take place explicitly
on a member-by-member basis.
Structures should be abled to be *converted* to
sequences thru a simple assignment:
a_sequence = a_struct1
But the reverse shouldn't hold true for the same reason
that assigning structures of different types is a bad idea.
Also Mr. Boehme wrote that "functions like prepend(),
reverse(), and upper()" would cause some problems if
structures were treated as sequences, but this one-way
conversion policy prevents that.
some_sequence = append(some_struct, 12) -- perfectly ok.
some_struct = append(some_struct, 12) -- illegal, the data returned
-- by append() is a sequence
-- and cannot be assigned to
-- the structure.
Remember earlier I said that structures should allow
you to access it's members with the [] operator... This
is so that structures can be treated like a sequence when
the situation calls for it. This solves Mr. Boehme's
concern over what would happen if a structure were for
some reason shuffled through old code like this:
if sequence(x) then
sum = 0
for i = 1 to length(x) do
sum = sum + x[i]
end for
else
-- x must be an atom
sum = x
end if
At first, you might bawk at the idea of having a
structure act like a sequence in a situation like this,
but I'd argue that passing a structure through it
unintentionally is more of a logic error (read as
programmer stupidity;) than a type violation. In fact
there may be a few situations where it's beneficial...
Suppose x was a structure holding a list of golf
scores for several days.
Treating a structure like a sequence also solves a
much bigger problem that would arise from old code...
updating old libraries. Allowing a structure to be
accessed in this manner allows authors of libraries
to redo/update their old libraries to use structures
independant of the old code that uses them. All that
would be required is that the library retain the myriad
of constants that were used to index the old emulated
structures...
-- old indicies, must to maintained to support old code
constant BAR = 1
constant BAZ = 2
-- old foo structure
-- sequence foo
-- new foo structure
structure foo begin
integer bar
atom baz
end structure
-- Allows both old and new syntax for accessing the structure
foo[BAR] = 17 -- works, although type checking isn't there
foo.baz = 12.3 -- new code benefits from reduced potential
-- of namespace conflicts, and automatic type-checking
With this allowance the user of the library can update their
old code at their leisure when updating to a new library instead
of having to redo it all at once.
Lastly, Jacques Guy posted the following:
> Nothing prevents a sequence from containing routine id's. For instance:
> [Euphoria with records]
>
> record point
> integer x,y
> procedure draw()
> -- your code here
> end procedure
> end record
>
> point a
>
> a.x=1 a.y=1
> a.draw()
This goes a little beyond just including the routine_id
into a structure. To do that you'd simply use an integer
to hold the id and use call_proc() or call_func() to
invoke the "method". This is really a simplistic beginning
to a class implementation. I'd actually love to see
Euphoria implement a class construct, with the features
that make classes very powerful... maybe along the lines
of something based on the way Python handles them, (with
improvements... Python still has a few quirks in this area)
but certainly friendlier than the way C++ handles them.
There would then be no need to have structures because
classes could handle what structures are intended to do.
I really can't foresee this coming to pass though; to
implement classes well would more than likely require a
complete re-write of Euphoria's core, and would probably
yield a slower overall execution speed than Euphoria
currently enjoys.
Regards,
Christopher D. Hickman
3. Structures
I have to agree about the value of structures. I know that I can emulate
them using constants and sequences, but this kind of gets confusing in a
larger project, where the interpreter should enforce the record definition
anyway. It would be nice to define a static structure layout (as opposed to
the wonderfully versatile sequence) that understands fieldnames:
<begin code>
record phonebook
sequence name
sequence address
integer zipcode
end record
phonebook pbAmy, pbMark, pbTom
sequence AllPhoneBooks
pbAmy[name] = "Marc Anthony"
pbAmy[address] = "Alexandria, Egypt"
pbAmy[zip] = 11111
AllPhoneBooks = {pbAmy, pbMark, pbTom}
AllPhoneBooks[1][zip] = 22222
<end code>
Since a sequence of records is the same as any sequence anyway, why
complicate the issue with additional syntax for arrays of records? Any
sequence should be able to contain a static record. The only reason I want
these static records is so I can't accidentally change the individual
definition of the record. I still want to be able to slice arrays of
records, and append and prepend them.
<begin code>
phonebook pbAmy, pbMark, pbTom
sequence AllPhoneBooks, SomePhoneBooks
AllPhoneBooks = {}
AllPhoneBooks = append(AllPhoneBooks, pbAmy)
AllPhoneBooks = append(AllPhoneBooks, pbMark)
AllPhoneBooks = append(AllPhoneBooks, pbTom)
SomePhoneBooks = AllPhoneBooks[2..3]
<end code>
Use of records helps keep the code cleaner, removes fieldname confusion when
several types use the same fieldname, and simplify datafile i/o.
Notice that this would not specify the length of any contained sequences.
Do we really want to do this? I'm not convinced.
<begin code>
record phonebook
sequence name * 50
sequence address * 50
integer zipcode
end record
phonebook pbAmy
pbAmy = {"Bob Marley", "Kingston, Jamaica", 00000}
puts(outfile, pbAmy)
<end code>
PS: My two cents (centavos, pesetas...)
I don't see the need to clutter the EU spec with cryptic syntax. Like the C
+= class of operators, which always got me into trouble. Or
short-circuiting logic evaluation (if length(s)>10 and compare(s,
"Rumplestilskin") then ...). I see its convenience but I also see the
potential for bugs arising out of our forgetting how the short-cicuit works.
The pre-2.1 convention of multiple IF statements is more trouble but has the
definite advantage of being explicit.
if length(s)>10 then
if compare(s, "Rumplestilskin") then
...
end if
end if
Where the syntax is explicit, there is reduced possibility for confusion. I
see the obstacle in programming as dealing with the complexity and tacit
assumptions (which we often fail to see) of our programming languages and
conventions. By removing these "conveniences", we may make our jobs a
little mode tedious, but we lose a level of ambiguity and hidden
assumptions, allowing our code to be more readable and more trustworthy.
PPS:
Rob, now that 2.1 EXW can have multiple call-backs, does this mean we can
use threads??
Thanks,
nonlerer
4. Structures
- Posted by MAP <ddhinc at ALA.NET>
Mar 04, 1998
-
Last edited Mar 05, 1998
I have no doubt this has been covered in previous discussions
here, but I'm fairly new to Euphoria and wonder if someone
might labor over it again with me. Why doesn't Euphoria explicitly
provide a C-like structure? Granted, structures aren't as
flexible as sequences, they can't be reshaped at will, but
in many cases they don't need to be (and would be safer by
now being allowed to). I like Euphoria for it's easy readability,
and it's clean form that allows you to accomplish much more,
much more quickly, than programming an equivilant in C.
I think though that where structures are concerned Euphoria
falls down a bit. Implementing them as sequences puts the
burden on the programmer to design design it well and access
it in a readable form, which can often be more of a bother than
C's approach.
Also, with the new Win32 platform, porting the interfaces to
the DLL's is rather complex as well. A special type of struct
dedicated to C-style linkages would be of great benifit.
i.e. something like this:
C_STRUCT My_Structure{
C_INT value1
C_INT value2
some_other_struct structure2
}
Allowing you to create a varaible that would automatically
allocate memory for, and point to, this structure that's in
a form readily passable to your external functions.
I think this, as well structures dedicated to euphorias
native types, would improve Euphoria alot; Making programs
more readable and easier to implement.
Christopher D. Hickman
5. Re: Structures
> C_STRUCT My_Structure
> {
> C_INT value1
> C_INT value2
> some_other_struct structure2
> }
If I need a structure in Euphoria, here is what I do:
constant VALUE1 = 1, VALUE2 = 2,
MY_STRUCTURE = 2
procedure something()
sequence this
this = repeat({}, MY_STRUCTURE)
this[VALUE1] = 5
this[VALUE2] = 9
-- Code.....
end procedure
It works for me....
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
6. Re: Structures
At 09:59 AM 3/5/98 -0500, you wrote:
>> C_STRUCT My_Structure
>> {
>> C_INT value1
>> C_INT value2
>> some_other_struct structure2
>> }
>
>
>If I need a structure in Euphoria, here is what I do:
>
>constant VALUE1 = 1, VALUE2 = 2,
> MY_STRUCTURE = 2
>
>procedure something()
> sequence this
> this = repeat({}, MY_STRUCTURE)
>
> this[VALUE1] = 5
> this[VALUE2] = 9
> -- Code.....
>end procedure
>
>It works for me....
True, but a structure as implemented in, say, Pascal, does some
type checking, as well as making member references easier and
clearer. For example:
PayRec = record
name : string;
rate : real;
dependents : integer;
end;
employee = PayRec;
then you can reference these fields as:
employee.name = "Joe Smith"
or pay_amount = hours * employee.rate
and you won't be able to make assignment errors such as
dependents = 3.14 or rate = "Fred"
Plus there's no need to enumerate the fields before you can reference
them, i.e.: NAME = 1, RATE = 2, DEP = 3...etc.
Awful handy, IMO. Reduces errors and makes the code shorter and clearer
(isn't that the whole idea behind Euphoria?)
Irv
----------------------------------------------------------------------------
-----------
Visit my Euphoria programming web site:
http://www.mindspring.com/~mountains
----------------------------------------------------------------------------
-----------
7. Re: Structures
At 11:35 AM 3/5/98 -0500, you wrote:
>True, but a structure as implemented in, say, Pascal, does some
>type checking, as well as making member references easier and
>clearer. For example:
>
Okay, I'll enter this debate. True, type checking would be tighter, but
that's one of the major advantages to Euphoria. The ability to have
sequences of multiple, dynamic "types"
However, I would love to see the encapsulation available with a
"structure". (The dot syntax) But, I would not want to limit, for example,
the ability to add components to the "structure" on the fly. That is why I
like Euphoria!!!
By the way, I am a new kid on the block. A Visual Basic nut. I still really
only use Euphoria for a smart (advanced) DOS scripting language. But, I am
excited about it's advancements.
"A man is not a liar because he lies. He lies because he is a liar."
-* Adrian Rogers
Joe Phillips, Sytems Analyst
Texas Wesleyan University 817-531-4444
8. Re: Structures
- Posted by MAP <ddhinc at ALA.NET>
Mar 05, 1998
A little more elaboration on what my idea of what structures
would be like in Euphoria...
Native structures:
These would be structures composed of Euphoria's native types.
structure my_struct_type
integer member1,
atom member2,
sequence member3,
object member4
end structure
function do_stuff (my_struct_type this_struct)
integer int1
sequence seq1
my_struct temp_struct
.
.
.
this_struct.member1 = int1 -- fine, as long as int1 is
-- initialized
int1 = this_struct.member1 -- fine too, same condition
this_struct.member1 = seq1 -- gives exception only with
-- type checking on
this_struct = temp_struct -- always ensures temp_struct
-- is of same type, with or
-- without type check (otherwise
-- the <.whatever> syntax could
-- get you into trouble)
-- member initializations are
-- never checked
return this_struct -- can be returned, just like
-- any other type
-- member initializations are
-- checked.
end function
-----------------------------
my_struct_type a_struct
sequence a_sequence
.
.
.
a_struct = do_stuff(a_struct) -- since do_stuff has it's
-- parameter typed as a
-- structure, the variable
-- passed will always be
-- type-checked.
-- had it specified a parameter
-- as sequence or object,
-- no checking would be
-- done with type check off
a_sequence = do_stuff(a_sequence) -- illegal, because of
-- parameter type
a_sequence = a_struct -- fine, sequences can be
-- assigned the value of an
-- entire structure, so can
-- objects, but never the
-- other way around!
a_sequence.member1 = 1 -- illegal! sequences do NOT
-- inheret the <.whatever>
-- syntax, nor do objects
As Mr. Phillips suggested, having structs be flexible can be
of advantage, but that come's implicitly thru Euphoria's
flexible types. member3 or member4 could contain virtually
anything. Also by virtue of this being treated as basically
another type, you could have sequences containing structures,
giving quite a bit of flexibility there as well.
C Structures:
The example I used in my previous post was just for a special
type of structure, one for C's types that would be immediately
passable to external functions. These would by necessity be
very rigid, and could only be used for assignment and passing
to external functions, not to be generally used within the
rest of your program. (Also, the example I used in the other
post was fairly ugly, it was just what I was suggesting it do
logically, not how it should appear stylistically).
Thanks,
Christopher D. Hickman
9. Re: Structures
Christopher D. Hickman writes:
<lots of ideas about adding structures to Euphoria>
Thanks for the ideas.
Others on the list know that I am pretty reluctant to
add anything to the core language. I realize that
interfacing with C from a language that is quite
different from C can be awkward. I'll review this
sometime after the 2.0 official release.
Regards,
Rob Craig
Rapid Deployment Software
10. Structures
On a different subject from the namespace stuff... What about structures?
I know they were mentioned a few weeks ago, but I feel that structures
will make a lot of my code more readable and faster.
-- I don't usually use 'type' so if this doesn't work right... Ignore it.
type file(integer x)
return file >= -1
end type
structure coord
integer x
integer y
end structure
structure foobar
integer foo
file bar -- Supports other stuff, of course!
coord pos -- Other structures can be used, of course also!
end structure
foobar qwerty
qwerty.foo = 5
qwerty.bar = -5 -- Won't work! type file must be -1 or more!
printf(1, "%d\n", {qwerty.foo})
Currently, I am doing this:
-- Structure foobar
constant FOO = 1, BAR = 2,
FOOBAR_FIELDS = 2
sequence qwerty
qwerty = repeat({}, FOOBAR_FIELDS)
qwerty[FOO] = 5
qwerty[BAR] = -5 -- This shouldn't be able to work, but nothing can be
done
-- done about that . . .
printf(1, "%d\n", {qwerty[FOO]})
This isn't so bad, but I find myself needing a whole bunch of structures,
and then I start to get naming conflicts...
-- Structure coord
constant X = 1, Y = 2
-- Structure player
constant NAME = 1, HP = 2, X = 3, Y = 4 -- Oops! X and Y are already
defined!
-- Do this instead:
constant NAME = 3, HP = 4 -- X = 1, Y = 2
-- But what about this? Structure inventory:
-- NAME = 1, VALUE = 2 -- NAME is already defined, but it doesn't need
the
-- other stuff, just these two!
But I have already had instances where there are too many conflicts to
easily resolve by simply renumbering everything.
I don't know how hard this will be to actually impliment into Euphoria,
but I know it will be easy to code in, and won't break existing code, and
still is simple and easy to understand...
Any reason this couldn't be done eventually?
(Else is there some easy way to fix the problems I'm having?)
Sometime (A few months from now) I want to convert Descent into Euphoria,
seeing as the source code has been released..... All I need is to hope
the Euphoria Assembly language translator holds through it's ASM
code..... Me not knowing how to use Assembly and all....... :) Anyway,
since as I can use the code for non commercial purposees (can't charge
any money for it, and shouldn't ask for donations), and it has been
released, I thought a Euphoria version would be nice, but it uses
structures also and converting them into the constants will just be more
trouble . . . (There, isn't that a good reason to have structures? :)
Just my 1 cent. I dropped the other one and can't find it.... :)
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
11. Re: Structures
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Apr 21, 1998
-
Last edited Apr 22, 1998
At 05:36 PM 4/21/98 -0400, Robert B Pilkington wrote:
>On a different subject from the namespace stuff... What about structures?
>I know they were mentioned a few weeks ago, but I feel that structures
>will make a lot of my code more readable and faster.
><snip some code>
All good points. We don't spend time with type conversions and
casting with Euphoria. Instead, we spend our time debugging
functions that get an atom when they're expecting a sequence,
or vice-versa. User defined type checking doesn't work on elements of a
sequence, and sequence indexing leaves
something to be desired. Enum (preprocessor) offers a
partial solution to the indexing problem, but is far from ideal.
The structure seems to be the most suitable solution to all
these problems. I know, we all hate to complicate things,
but there are pretty good reasons for some of the features
provided by other languages.
Irv
----------------------------------------------------------
--Visit my Euphoria programming web site:--
--http://www.mindspring.com/~mountains --
----------------------------------------------------------
12. Re: Structures
On Tue, 21 Apr 1998, Robert B Pilkington wrote:
> On a different subject from the namespace stuff... What about structures?
> I know they were mentioned a few weeks ago, but I feel that structures
> will make a lot of my code more readable and faster.
>
> -- I don't usually use 'type' so if this doesn't work right... Ignore it.
> type file(integer x)
> return file >= -1
> end type
>
> structure coord
> integer x
> integer y
> end structure
>
> structure foobar
> integer foo
> file bar -- Supports other stuff, of course!
> coord pos -- Other structures can be used, of course also!
> end structure
Hmm. You can do something similar (ironically) with all as types, but it's
not as friendly as your suggestion...
type file(integer x)
return x >= -1
end type
constant coord_x = 1,
coord_y = 2
type structcoord(object x)
if not sequence(x) then
return 0
end if
if length(x) != 2 then
return 0
end if
return integer(x[1]) and integer(x[2])
end type
constant foobar_foo = 1,
foobar_bar = 2,
foobar_pos = 3
type structfoobar(object x)
-- IMHO, although I don't always do it, type definitions should always
-- have an object as the parameter, so that any errors are programmer
-- generated from within the type def.
-- for example:
if not sequence(x)
return 0
end if
if not length(x) != 3 then
return 0
end if
return integer(x[1]) and file(x[2]) and structcoord(x[3])
end type
structfoobar qwerty
qwerty = {0,0,{0,0}}
qwerty[foobar_pos][coord_y] = 17
-- etc. etc...
Actually, examining this, I reckon an advanced PP might be able to do this
kind of translation...
--
Carl R White - "FBIbait: The President will be castrated in his sleep."
E-mail...: cyrek- at -bigfoot.com / Remove the hyphens before
Finger...: crwhite- at -dcsun1.comp.brad.ac.uk \ mailing or fingering...
Url......: http://www.bigfoot.com/~cyrek/
13. Structures
Wash your mouths out with soap people.
Let us be honest, the thought of changing Euphoria probablely brings ROB out, at
least, in a cold sweat, after all it was his thesis.
So...
Rob doesn't want to hange Euphoria.
The sequence and lack of a million and one data types is what makes Euphoria sim
ple.
Type is what makes Euphoria more powerful.
Thus an extention of type would increases Euphorias power, and possiblely it's e
ffiency,
and wouldn't send Rob into fits.
It should be simple.
I have two suggestions:
length is/of i
elements are (atoms/integers/objects/sequences)
length would cause a type check failure if you wanted to exceded it and elements
would cause a type check failure if you tried to set a different type to the seq
uence.
That above option could then be used in the following, hardered to implemement s
uggestion...
_The complex Data Type_
It would basically be a C structure of your design, but maybe with the possibili
ty
to use sequences. See the previous ideas have suggested that you define a struct
ure,
but a structure doesn't fit within the context of the atom being the base data t
ype
and the sequence being a thing to put lots of them in.
type description( sequence s )
elements are integers
length is 256
return 1
end type
type menu_str( sequence s )
elements are integeres
length is 16
return 1
end type
-- because menu str is always 16 ints mem can be
-- pre-assigned
complex menu_item ( sequence s)
format { menu_str, integer, string, integer }
return 1
end complex
I suggested implementing a length keyword rather than using :
type six_elmnt_seq( sequence s)
return length(s) = 6
end type
as it could pre-allocate memory for the type if it had a fixed element type. The
re
is one suggestion of a data type iplemented only in complex and that is byte to
save
space, when all we want is a string.
It would save error detection coding. ( My Aborted HTML help system got bogged d
own
in that.
-----
Sincerely,
Mathew Hounsell
Mat.Hounsell at mailexcite.com
"Death to the semi-colon"
Compiler Errors:
Line 1 : End of line reached without semi-colon (;)
Line 2 : End of line reached without semi-colon (;) etc
Free web-based email, Forever, From anywhere!
http://www.mailexcite.com
14. Re: Structures
At 03:17 AM 4/24/98 -0700, Mathew Hounsel wrote:
>Wash your mouths out with soap people.
>
>Let us be honest, the thought of changing Euphoria probablely >brings ROB
out, at least, in a cold sweat, after all it was his >thesis.
You're right. He's probably sweating frequently from all the
suggested changes.
>So...
>Rob doesn't want to hange Euphoria.
>The sequence and lack of a million and one data types is what >makes
Euphoria simple.
>
>Type is what makes Euphoria more powerful.
>
Exactly. That's why we want to be able to use type, not just
in a few cases, but wherever it would be helpful in doing what
Euphoria is famous for: preventing "unexpected results".
I know "crash proofing" Euphoria is high on Rob's list.
You are also right, all the data types we need are already
there.
Irv
Spam Haiku:-------------------
Silent, former pig
One communal awareness
Myriad pink bricks
-------------------------------------
15. Re: Structures
- Posted by MAP <ddhinc at ALA.NET>
Apr 24, 1998
Mathew Hounsell wrote:
>
> Wash your mouths out with soap people.
>
> Let us be honest, the thought of changing Euphoria probablely brings ROB out,
at
> least, in a cold sweat, after all it was his thesis.
<snip>
> ... See the previous ideas have suggested that you define a structure,
> but a structure doesn't fit within the context of the atom being the base data
type
> and the sequence being a thing to put lots of them in.
I disagree. I started a discussion on this early last month. After
batting a few
ideas around I posted a conceptualization of structures in Euphoria
using native
data types, as follows:
MAP wrote:
>
> A little more elaboration on what my idea of what structures
> would be like in Euphoria...
>
> Native structures:
> These would be structures composed of Euphoria's native types.
>
> structure my_struct_type
> integer member1,
> atom member2,
> sequence member3,
> object member4
> end structure
>
> function do_stuff (my_struct_type this_struct)
> integer int1
> sequence seq1
> my_struct temp_struct
> .
> .
> .
> this_struct.member1 = int1 -- fine, as long as int1 is
> -- initialized
> int1 = this_struct.member1 -- fine too, same condition
>
> this_struct.member1 = seq1 -- gives exception only with
> -- type checking on
>
> this_struct = temp_struct -- always ensures temp_struct
> -- is of same type, with or
> -- without type check (otherwise
> -- the <.whatever> syntax could
> -- get you into trouble)
> -- member initializations are
> -- never checked
>
> return this_struct -- can be returned, just like
> -- any other type
> -- member initializations are
> -- checked.
> end function
> -----------------------------
> my_struct_type a_struct
> sequence a_sequence
> .
> .
> .
> a_struct = do_stuff(a_struct) -- since do_stuff has it's
> -- parameter typed as a
> -- structure, the variable
> -- passed will always be
> -- type-checked.
> -- had it specified a parameter
> -- as sequence or object,
> -- no checking would be
> -- done with type check off
>
> a_sequence = do_stuff(a_sequence) -- illegal, because of
> -- parameter type
>
> a_sequence = a_struct -- fine, sequences can be
> -- assigned the value of an
> -- entire structure, so can
> -- objects, but never the
> -- other way around!
>
> a_sequence.member1 = 1 -- illegal! sequences do NOT
> -- inheret the <.whatever>
> -- syntax, nor do objects
>
> As Mr. Phillips suggested, having structs be flexible can be
> of advantage, but that come's implicitly thru Euphoria's
> flexible types. member3 or member4 could contain virtually
> anything. Also by virtue of this being treated as basically
> another type, you could have sequences containing structures,
> giving quite a bit of flexibility there as well.
>
> C Structures:
> The example I used in my previous post was just for a special
> type of structure, one for C's types that would be immediately
> passable to external functions. These would by necessity be
> very rigid, and could only be used for assignment and passing
> to external functions, not to be generally used within the
> rest of your program. (Also, the example I used in the other
> post was fairly ugly, it was just what I was suggesting it do
> logically, not how it should appear stylistically).
>
> Thanks,
> Christopher D. Hickman
As far as Rob's opinion on implementing these, here's what he had to
say:
Robert Craig wrote:
>
> Christopher D. Hickman writes:
> <lots of ideas about adding structures to Euphoria>
>
> Thanks for the ideas.
> Others on the list know that I am pretty reluctant to
> add anything to the core language. I realize that
> interfacing with C from a language that is quite
> different from C can be awkward. I'll review this
> sometime after the 2.0 official release.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
Yes, it's evident even from this post that he's not keen on throwing
in features left and right just to suit the whim of the day, and that's
really a good thing, Euphoria owes it great features and speed to that.
He said he'd look into it though, I am sure he wouldn't even consider
it if he thought it was a *bad* idea.
The method you posted doesn't address any of the problems that brought
this discussion about in the first place.
> type description( sequence s )
> elements are integers
> length is 256
>
> return 1
> end type
What does this solve? It doesn't make handling complex sequences any
easier, it simply makes them rigid by fixing them to a single type and
fixed length, just like arrays in most other languages...
pecisely contrary to what sequences are all about.
Structures in Euphoria aren't (or shouldn't be, I should say) about
limiting anything, but giving the programmer a tool to work with
sequences at a more abstract level... improving readability to allow
faster implementation, better control, and less time debugging.
Thanks,
Christopher D. Hickman
