Re: Euphoria vs. structures -- a view

new topic     » goto parent     » topic index » view thread      » older message » newer message

I SNIPPED it so don't be worried about size.
I also interject my Short comments throughout his SNIPPED message.

On Mon, 1 Feb 1999 20:20:00 -0600, Boehme, Gabriel <gboehme at MUSICLAND.COM>
wrote:

>Hello. I am new to the Euphoria mailing list, but I have been using
>Euphoria
>for quite some time now. I immediately noticed that 90% of my new Euphoria
>mail had to do with adding structures to Euphoria. I had also noticed the
>large number of posts on structures when I'd browsed the website earlier.
>Having read through the varying opinions and ideas, I'd like to share some
>of my thoughts on the whole structure debate.

  Most of the mail has been about Structures.
    [Hot Topic]
  He is new to the Euphoria mailing list.
   [Nice to know] but [irrelevant]

  <SNIP>

>Any way you look at it, structures would have an enormous impact on
>Euphoria's fundamental attitude towards data and memory access.

  I have to agree. Structures will impact Euphoria much more than
  originally thought.

> The simple
>combination of atoms and sequences is part of what makes Euphoria such a
>revolutionary programming language in the first place.

  Euphoria, simple, atoms & sequences.  [GOOD]

> Introducing
>structures into Euphoria is not going to "simplify" anything, not by a long
>shot. Sure, *some* things will be simpler to do, but many other things are
>going to be a lot more complicated. Structures -- as they have currently
>been suggested -- would seriously compromise Euphoria's current elegance
>and ease-of-use. There is no way around it.

  Again, I have to agree. Structure versus Sequence.
  A Structure IS NOT a Sequence.
  Embedded structures defy dynamic sequences instantly.

>Now, before I get flamed to death, I would like to say that I started out
>IN FAVOR of adding structures to Euphoria.

  NO Flame here.

  <SNIP>

>  However, the more I thought about it, the more I realized how
>difficult it would really be. The variable-length, recursive sequence is
>FUNDAMENTALLY at odds with the fixed-length, field-named structure, IMO.

  As above.
  A Structure IS NOT a Sequence.
  Embedded structures defy dynamic sequences instantly.

>I think the main problem we face with Euphoria is that the *idea* of
>sequences is so different from data storage in other languages. This is why
>the pro-structure camp is constantly accused of trying to convert Euphoria
>into "C++ with sequences" -- we're trying to take structure ideas from C++,
>Visual Basic, Pascal, etc., and shoehorn them into Euphoria. It won't work.
>The shoe doesn't fit.

  sequences are unique to Euphoria. They are dynamic.
  structures are fixed.  We can easily have fixed sequences BUT.
  embeded fixed sequences become difficult if not impossible to
  handle.

>We need something different. Something that carries out the same task as
>structures, but does it in a much more elegant fashion. I believe *that*
>should be the focus of our efforts here -- not to come up with clever ways
>of writing structure definitions, but coming up with a way to incorporate
>the *essential* features of structures into the Euphoria way of
>programming.
>That, I believe, is what Robert Craig means when he says he wants
>"something elegant and powerful."
>
>Now, if only we knew what that "something" was!

   Oh great Lord, Give us a vision.
   Seriously.  I have to agree yet again.

We can't have Structures.  They literally defy sequences.
We must have "something" that is a middle ground for sequences &
structures.

    Lucius L. Hilley III

--Good luck to all.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu