1. 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
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.
2. Re: Future features of Euphoria?
Hello Carlos,
Nice thought. It was the first enhancement I had in mind but after
a while I loved it's simplicity how RDS handled this. Now after
working several months with this way of referencing I find this method
as standard as the way pascal uses enumerated types, so I don't miss
them anymore. I think this is Euphoria's strength. KISS (Keep It
Simple and Stupid).
Greetings,
Marcel Kollenaar
M.Kollenaar at slo.nl
The Netherlands
3. 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.
4. Re: Future features of Euphoria?
Adriann wrote about enumerated type:
>Try this:
>
>global type weekday(sequence s)
> return find(s, {"Monday","Tuesday","Wednesday","Thursday"
> "Friday","Saturday","Sunday"})
>end type -- weekday
>
Well Adriann the point is that you can't index a sequence with it.
As a pascal programmer I understand what Carlos meant by enumerated type.
In euphoria it could be something like this:
enum <identifier>
<tags list>
end enum
where identifier name this particular set
tags list enumerate the members of the set.
example:
enum week_days
Sunday,Monday,Thuesday,Wednesday,Thursday, Friday,Saterday
end enum
the system would type check enum as it does for other types
Then we could use those enum to index a sequence, for example
sequence ToDo -- a to do list.
Todo[Monday] = {"by a new car","kill the cat"," any thing else"}
You can't do that with your type weekday
as Todo["Monday"] would be a syntax error
Jacques Deschenes
Baie-Comeau, Quebec
Canada
desja at quebectel.com
5. Re: Future features of Euphoria?
- Posted by Robert Craig <72614.1667 at COMPUSERVE.COM>
Nov 21, 1996
-
Last edited Nov 22, 1996
Carlos Jose Gonzalia writes:
> I'm interested in knowing about the future plans for nexts versions of
> Euphoria.
I am working full-time on a new version. Eventually I will post more
information on exactly what features are planned. I am always interested
in getting suggestions.
This week I've been investigating support for hardware interrupt handling.
By supplying its own clock interrupt handler, Euphoria can now let you
select the clock-tick interrupt rate and boost it up much higher
than the normal 18.2 ticks per second that is standard with PC's. You can
set it to over 1000 ticks/sec on a Pentium before performance starts to degrade
a little. This has two benefits:
1. You can measure time with much more precision. Some people
have found 18.2 ticks per second (time() resolution of .05 seconds) to
be inadequate when measuring things that happen at (say) 20/sec
such as displaying frames of graphics on the screen.
2. Euphoria can use the interrupt handler to sample where your program
is executing, and generate a time profile.
Euphoria already has a statement-count profiler,
"with profile", but obviously one Euphoria statement could
take hundreds of times longer to execute
than another. Now you can get an accurate profile
showing what percentage of the total time was spent executing
each Euphoria statement. I've measured a few of the demo programs and
found one surprise so far. The mset program running on a 150Mz Pentium
spends almost 60% of its time in pixel(), plotting a pixel. I had thought
that it spent over 95% of its time doing floating-point calculations
to determine the color to make each pixel. Actually, I later found on
a 486 it *does* spend 94% on f.p. calculations and only 6% in pixel().
The Pentium is obviously much faster on f.p. but not much (if any) faster
on video output. When I altered the code to save each horizontal
line of pixels into a sequence, and then call pixel() with the whole
sequence, it more than doubled the speed on the Pentium, but made only
a small increase on the 486.
There are many other features on the wish list. There should be a beta
release of v1.5 for everyone to play with in a few months. Maybe I can
give out an "alpha" release to specific people that want to test it.
> 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 kin
d
> of datatype (known as enumerated data) is usual in normal programming. It
Yes, this concerned me a few years ago and I was tempted to do
something in the area of enumerations, however the overriding philosophy
of Euphoria is to keep things simple and avoid introducing new concepts
unless they are really necessary or really powerful and orthogonal.
By "orthogonal" I mean it can be applied broadly across the language, not
just to some special area, and also it must not partially duplicate
something that can already be achieved with an existing feature.
We used to send out questionnaires to registered users and what struck
me was that "simplicity" was often rated
the highest, out of several features (speed, flexibility etc.)
that people could choose from on a multiple-choice question.
The core language has been stable for quite a while. We've mainly been
adding library routines etc. If someone suggests a brilliant idea we'll
go for it, but for the next release we aren't planning anything.
We also hope to release a very simple Windows 95/NT version, but we will
keep improving the DOS version. The WATCOM C source code will be
largely shared between the two versions.
> algebraic types. One way would be to include a complex macro expansion mechani
sm
> similar to the ones found in some C systems.
I believe that even Bjarne Stroustrup (C++) hates the C #define facility.
He thinks it is too flexible and undisciplined.
Rob Craig
Rapid Deployment Software
6. Re: Future features of Euphoria?
- Posted by Jacques Deschenes <desja at QUEBECTEL.COM>
Nov 22, 1996
-
Last edited Nov 23, 1996
At 22:00 21-11-96 EST, you wrote:
>We also hope to release a very simple Windows 95/NT version, but we will
>keep improving the DOS version. The WATCOM C source code will be
>largely shared between the two versions.
>
> Rob Craig
> Rapid Deployment Software
>
Programming for windows 95 with the same simplecity as euphoria for dos
would be wounderfull. I would certainly buy it. Hope to see it soon.
Jacques Deschenes
Baie-Comeau, Quebec
Canada
desja at quebectel.com
