OpenEuphoria

Future features of Euphoria?

• Posted by Carlos Jose Gonzalia <gonzalia at CRIBA.EDU.AR> Nov 21, 1996
• 1617 views

Hi all

  This is a public thought of mine but surely the guys at RDS have a lot to say
about it, so it could be nice for all of us suscribers to know ;).

  I'm interested in knowing about the future plans for nexts versions of
Euphoria.
I'm actively involved in programming language design research, and that was the
main reason I'm following all that's happening regarding this language. I
find it
a very interesting concept and I'm very curious about what i will become
with time.

  After playing a bit with the language I noticed you always end defining
constants
for your significative data, since you only can represent them as numbers. For
example, defining constants MONDAY, ..., SUNDAY for the integers from 1 to 7. I
believe this has to be automated some way, since the pervasiveness of this kind
of datatype (known as enumerated data) is usual in normal programming. It
seems to
me there could be only 2 gentle ways to extend the language to support
enumerated
algebraic types. One way would be to include a complex macro expansion mechanism
similar to the ones found in some C systems. This is obviously in conflict with
the main goal of the language: simplicity. The other way would be to extend the
syntactic structures of the "type" construction. This would require also a
syntax
extension to support these special constants. Maybe the easiest way would be
requiring them to be atoms of the form #<identifier>, and allowing the user
to include
in the "type" constructions tests for belonging to the correct set of constants.
So we would have two kinds of atoms, in a way similar to Lisp or Prolog: numeric
atoms and symbolic atoms. Example, days of the week:

type weekday (atom d)
return member(d,{#Monday, #Tuesday, #Wednesday, #Thursday, #Friday, #Saturday,
  #Sunday})
end type

Obviously, booleans would be one of such enumerated types, and one that
should be
provided by the system. That would have to include a boolean() type testing
function.

  Probably the language would have to provide automatic printing of these
symbolic
atoms, and the most simple way to do it seems to be showing them in their same
syntactic form, #<identifier>, or better yet, just <identifier> so the #
doesn't get
in the way of a clean print.

  I still hadn't the time to sit thinking about the uses enumerated types
have in
other languages, like indexing a sequence(array) as in Pascal. Probably this
would
be a nice thing to have around if the language keeps its simplicity. What's
better,
allowing indexing by enumerated types would provide significative names to
record
fields, another thing for which you usually end defining a lot of constants.

  Well, this is just an informal reflexion about the subject, so I expect
this to
help me see where's the language evolving towards... :) Feel free to have your
saying. If nothing else, this could prove a fun and interesting debate! ;)

  Thanks for your attention all.

        Carlos Gonzalia, Universidad Nacional del Sur, Argentina, South America.