OpenEuphoria

Re: Structures

• Posted by MAP <ddhinc at ALA.NET> Apr 24, 1998
• 445 views

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