Future features of Euphoria?
Thursday, 21/11/96, you wrote:
>Poster: Carlos Jose Gonzalia <gonzalia at CRIBA.EDU.AR>
>Subject: Future features of Euphoria?
>--------------------------------------------------------------------------
-----
>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
I don't see your point. This kind of type definition is quite possible in
Euphoria.
Try this:
global type weekday(sequence s)
return find(s, {"Monday","Tuesday","Wednesday","Thursday"
"Friday","Saturday","Sunday"})
end type -- weekday
>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.
You can have an include file with global type definitions type.e, like
this:
global constant TRUE = 1, FALSE = 0
global type boolean(integer i)
return i = TRUE or i = FALSE
end type -- boolean
In the body of a program you can define your weekdays, booleans, or
whatever
type you like. The number of statements in between (global) type and end
type is totally free, so you can type-check almost everything you want, I
think.
> 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.
It is possible to have:
boolean condition
condition = TRUE
...
...
if condition = FALSE then
do_something()
else -- condition is TRUE
do_something_else()
end if
> 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.
I'm very sorry, but I don't understand this. To me it seems you always have
to define constants and types before using them. In a header or include
file it's not much difference to define your constants and types like for
instance in the database example in Euphoria or an enumerated type or
structure as in Pascal or C. Maybe I'm to euphoric about Euphoria, but the
advantages it offers me compared to other computer languages I know, have
made me decide to stick to it for the time being.
But since I'm comparatively a novice and amateur programmer, I'm also
interested to see what others are saying about this subject.
Best regards,
Ad Rienks
> 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.
|
Not Categorized, Please Help
|
|
