1. Version 2.4 and beyond
Hi Everyone,
Firstly, thank you Robert for the 2.3 release.
Now for the future.
I think that when we submit requests for changes to the Euphoria language, we
need to have answers
for,at least, these questions :
1) What problems is the new feature trying to solve?
2) What impact will it have on existing source code?
3) What impact will it have on RDS's Euphoria Interpreter?
4) How does it align with the Euphoria's primary requirements?
5) How costly will it be to implement?
Once when can answer these, then I think we can have informed debate on a new
feature's
justification. However, finding answers to all these questions will probably be
difficult. In
particular, #3, 4, and 5, depend on information that comes from RDS. I, for one,
am not 100% sure of
what are Euphoria's primary requirements. I suspect that minimulism, speed,
size, and platform
choice have a part, but what I'd really like, Robert, is to see them clearly
stated and published
under the RDS banner.
Does any of this make sense to anyone else?
I have a whole suite of suggestions for the language, but after having
considered the above
questions, I need to re-evaluate my list.
---------
cheers,
Derek.
2. Re: Version 2.4 and beyond
Derek Parnell writes:
> I, for one, am not 100% sure of what are Euphoria's primary requirements.
> I suspect that minimulism, speed, size, and platform choice have a part,
> but what I'd really like, Robert, is to see them clearly stated and published
> under the RDS banner.
I don't have any hard and fast requirements or goals for Euphoria.
I'm an opportunist. All I can do is tell you what I like about Euphoria,
and what I feel about the current situation.
1. The core language.
I'm content with the size of the core language. I reject the
notion that it is "incomplete", or must be extended every year
with new features. Sure, there could be some dotting of i's
and crossing of t's, but any major new extension would have
to match the power to weight ratio of the current core.
Structures, classes, etc. are tempting, but I've studied them
carefully over the years, and decided not to include them.
When I look at grandiose languages, with 1000-page
manuals describing only the *core* language, I'm appalled.
People seem to be building all sorts of exotic, trendy
features, just so they can one-up the others. I suspect these
features are probably buggy, interact with each other in
unpredictable ways, are rarely used and poorly
understood by the masses. Python may have a lot of
"features", but if it's 34x slower than the Euphoria *interpreter*,
do you really care? I'm still waiting to see a fast action game
written in Python or Perl.
2. Libraries
One of the great strengths of Euphoria, compared to
Python, Perl, or other interpreted languages, is that
that the standard libraries, and most other
important add-on libraries, Win32Lib etc.,
are all (heaven forbid!) written in Euphoria.
In Python they have some kludgy API that lets
people write extensions in C, since it's obvious
to everyone that Python itself would be far too slow.
This means that *all* Euphoria users can potentially write
important libraries and tools, where performance matters,
whereas in Python, you need to be a C expert and
a Python expert, as well as learning the strange API.
This bodes well for the future expansion of cool things
that you can do in Euphoria.
While I think the core should remain small,
I'll be very happy to see lots of libraries developed.
3. Interpreter Source Code
Releasing the source code was a bit of a two-edged sword.
Although I'm giving away a few secrets, and there will be
several different versions of Euphoria created, I think this
is a powerful way to inject a blast of creativity into the
Euphoria world, and some source holders have
said that they will port to some interesting platforms.
(nothing to announce yet).
Ray Smith writes:
> I also think RDS should have an official documented plan for the
> future of Euphoria.
"planning" stifles creativity.
People should not focus so much on what I'm going to do.
My job is to stimulate, and harness the creativity of the
Euphoria community. I can't predict what's going to happen.
Think of a big pot of boiling, bubbling chemicals and DNA.
Things will either explode, or else some creature from
the "X Files" is going to crawl out. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Version 2.4 and beyond
On Wednesday 13 February 2002 04:32 pm, Robert Craig wrote:
> I don't have any hard and fast requirements or goals for Euphoria.
> I'm an opportunist. All I can do is tell you what I like about Euphoria,
> and what I feel about the current situation.
Then you should read the Dr. Dobb's Feb. article found here:
http://www.ddj.com/documents/s=2287/ddj0202a/0202a.htm
<I'll quote a bit>
Is Worse Better?
In many ways, Richard Gabriel's notion of "Worse Is Better" versus "The Right
Thing" was the dominant theme of the workshop. In 1990, Gabriel wrote an
essay (http://www.dreamsongs.com/WorseIsBetter.html) that described two
approaches to software development. His thesis was that software should start
small and evolve according to the needs of its users. Although the result
might not be necessarily pretty, it has greater odds of surviving and even
flourishing.
<end quote>
Regards
Irv
4. Re: Version 2.4 and beyond
- Posted by euman at bellsouth.net
Feb 13, 2002
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
>
<snip......some>
> 2. Libraries
>
> One of the great strengths of Euphoria, compared to
> Python, Perl, or other interpreted languages, is that
> that the standard libraries, and most other
> important add-on libraries, Win32Lib etc.,
> are all (heaven forbid!) written in Euphoria.
> In Python they have some kludgy API that lets
> people write extensions in C, since it's obvious
> to everyone that Python itself would be far too slow.
>
> This means that *all* Euphoria users can potentially write
> important libraries and tools, where performance matters,
> whereas in Python, you need to be a C expert and
> a Python expert, as well as learning the strange API.
> This bodes well for the future expansion of cool things
> that you can do in Euphoria.
I always wondered why a better or faster way of doing something
is still not part of the interpreter. If
>This means that *all* Euphoria users can potentially write
>important libraries and tools, where performance matters
this has been accomplished already shouldnt it (after extensive test)
become part of our/your language? Freeing up some time spent
making Euphorians include them...
Here are some function that make Euphoria faster
why are they not put into the interpreter?
(small list)
global function alloc_string(sequence s) -- diff but faster
atom mem
mem = allocate(length(s) + 1)
poke(mem, s)
return mem
end function
-- these are used functions that would make our code
-- shorter. I have many larger examples.
--You know things that seem to be in almost every program
--but could possibly benefit from faster inlined C Code.
global function LOWORD(atom long)
return remainder(long,65536)
end function
global function HIWORD(atom long)
return floor(long/65536)
end function
--using API for most things are MUCH-MUCH faster
--than Euphoria's built-ins C Runtime counterparts
global function peek_zstring(atom lpzString)
return mypeek({lpzString,c_func(xlstrlen,{lpzString})})
end function
I guess Im on a soapbox here about this but it is a fact Rob
that API is faster in most case than your C Runtime.
Are you planning on making Windows programmers happier?
Euman
euman at bellsouth.net
5. Re: Version 2.4 and beyond
On Wednesday 13 February 2002 04:49 pm, C. K. Lester wrote:
> > I'm still waiting to see a fast action game
> > written in Python or Perl.
>
> That's what I'm lookin' for... you got any links for me?
>
Here's what I found while eating my breakfast cereal:
http://pygame.org/
http://shredwheat.zopesite.com/solarwolf
http://www.onlamp.com/pub/a/python/2001/10/04/pythonnews.html
http://py-universe.sourceforge.net/
http://www3.bc.sympatico.ca/futility/twitch/
http://www.serc.rmit.edu.au/~rob/openciv.html
http://www.oberhumer.com/opensource/pysol/
http://www.vex.net/parnassus/apyllo.py/238168060
http://yanoid.sourceforge.net
http://www.strout.net/python/bus/
http://www.interstelen.com/faq.html
Regards,
Irv
6. Re: Version 2.4 and beyond
C. K. Lester wrote:
<snip>
<quote Rob Craig>
> > Structures, classes, etc. are tempting, but I've studied them
> > carefully over the years, and decided not to include them.
</quote>
>
> What detriments outweighed what benefits?
>
</snip>
I've been studying the source code with a view to adding classes--it is
doable in priciple but the resulting interpreter will be significantly
bigger and slower. I may do this sometime as a custom interpreter, but for
for Rob to build in classes, etc. as a feature would be to impose OOP's
speed penalties on those who don't use OOP. While an OOP library is slower
than built in OOP would be, it imposes no speed penalty on non-users.
-- Mike Nelson
7. Re: Version 2.4 and beyond
-------Phoenix-Boundary-07081998-
Hi Mike Nelson, you wrote on 2/14/02 8:54:40 AM:
>I've been studying the source code with a view to adding classes--it is
>doable in priciple but the resulting interpreter will be significantly
>bigger and slower. I may do this sometime as a custom interpreter, but for
>for Rob to build in classes, etc. as a feature would be to impose OOP's
>speed penalties on those who don't use OOP. While an OOP library is slower
>than built in OOP would be, it imposes no speed penalty on non-users.
>
>-- Mike Nelson
>
I disagree. There is certainly no reason for the presence of
classes to slow down programs that don't use them. All that
happens is the addition of a few cases to a switch statement,
which adds zero time.
When using classes:
The declaration of a class just adds symbol table entries
which takes the same time as an equivalent number of
'normal' declarations.
The instantiation of a class is the same as the declaration
of a sequence.
Dot-notation need be no slower than selecting elements
of a sequence with '[]'.
Polymorphic dispatch should be slightly slower than simple
calls, involving a '[]' operation and a call_proc().
Classes might be slower to the extent that they led the
programmer to use more complicated structures than he
otherwise would.
The interpreter would be a bit larger of course. I
have implemented some convenience features and 3/4
of the code for classes. My LCC-ported interpreter
has grown from 104,480 to 108,576 bytes. (4%)
Karl Bochert
-------Phoenix-Boundary-07081998---
8. Re: Version 2.4 and beyond
- Posted by euman at bellsouth.net
Feb 14, 2002
While we're on the subject, didnt you write 2X threaded code for
LCC? Mind sharing what/how you did this?
Euman
euman at bellsouth.net
Q: Are we monetarily insane?
A: YES
----- Original Message -----
From: <kbochert at ix.netcom.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Version 2.4 and beyond
Hi Mike Nelson, you wrote on 2/14/02 8:54:40 AM:
>I've been studying the source code with a view to adding classes--it is
>doable in priciple but the resulting interpreter will be significantly
>bigger and slower. I may do this sometime as a custom interpreter, but for
>for Rob to build in classes, etc. as a feature would be to impose OOP's
>speed penalties on those who don't use OOP. While an OOP library is slower
>than built in OOP would be, it imposes no speed penalty on non-users.
>
>-- Mike Nelson
>
I disagree. There is certainly no reason for the presence of
classes to slow down programs that don't use them. All that
happens is the addition of a few cases to a switch statement,
which adds zero time.
When using classes:
The declaration of a class just adds symbol table entries
which takes the same time as an equivalent number of
'normal' declarations.
The instantiation of a class is the same as the declaration
of a sequence.
Dot-notation need be no slower than selecting elements
of a sequence with '[]'.
Polymorphic dispatch should be slightly slower than simple
calls, involving a '[]' operation and a call_proc().
Classes might be slower to the extent that they led the
programmer to use more complicated structures than he
otherwise would.
The interpreter would be a bit larger of course. I
have implemented some convenience features and 3/4
of the code for classes. My LCC-ported interpreter
has grown from 104,480 to 108,576 bytes. (4%)
Karl Bochert
9. Re: Version 2.4 and beyond
On Thursday 14 February 2002 02:37 pm, C. K. Lester wrote:
> Irv, as I sit here working on other things, do any of the links below
> point to files I can simply download and run?
>
> I did come across pygame the other day on my own and could not find any
> screen shots or anything else to demonstrate it's prowess. They must be
> hiding something!!! hehe
Two can play this game:
No. All the sites are bogus, and the links to Downloads and Screenshots and
Projects don't lead anywere. People are just putting those pages up because
they are trying to use up all the available webspace. Once the internet is
full, we'll all be able to go do something useful - if we haven't forgotten
how.
Regards,
Irv
10. Re: Version 2.4 and beyond
Karl,
If you have proved me wrong about OOP with your new interpreter,
congratulations!
Bernie,
I really love your idea about external additions to the interpreter (wish
I'd thought of it!)
11. Re: Version 2.4 and beyond
Kat wrote:
> And exec(sequence) would
> allow scripted database entries, as would defining the item as a class while
> the program is still running. Which would be easier for you Rob,
> exec(sequence) or build_class(sequence)) ?
It is possible to have exec() in the current Euphoria.
procedure setVarsForExec()
-- the inconvient part
-- tells exec() what are values of variables
setExecVar("foo", foo)
setExecVar("bar", bar)
...
end procedure
procedure setVarsFromExec()
-- the inconvient part
-- after exec() variales are updated if they was changed
-- by code in exec()
foo = getExecVar("foo")
bar = getExecVar("bar")
...
end procedure
procedure execCode(sequence t)
routine => call via routine_id()
emulate entire euphoria
has its own table of variables
end procedure
procedure exec(sequence s)
t = tokenize(s)
setVarsForExec()
for i=1 to length(t)
execCode(t)
end for
setVarsFromExec()
end procedure
It isn't as fast as exec() built-in into interpreter,
but allows the code to be translated to C.
So the only thing that would make exec() easier, is
the ability to reference variables via their name
like routine_id() does. But this would introduce
pointers...
-- Martin
12. Re: Version 2.4 and beyond
On 14 Feb 2002, at 19:27, Martin Stachon wrote:
>
> Kat wrote:
> > And exec(sequence) would
> > allow scripted database entries, as would defining the item as a class while
> > the program is still running. Which would be easier for you Rob,
> > exec(sequence) or build_class(sequence)) ?
>
> It is possible to have exec() in the current Euphoria.
>
> procedure setVarsForExec()
> -- the inconvient part
> -- tells exec() what are values of variables
> setExecVar("foo", foo)
> setExecVar("bar", bar)
> ...
> end procedure
Yeas, i had considered a preprocessor that built var tables, added includes
to handle passing vars back and forth between a second instance of the
interpreter, or sharing the permitted part of the var table with the subordinate
"threads", but it got overly wierd real fast. I didn't see it working.
> procedure setVarsFromExec()
> -- the inconvient part
> -- after exec() variales are updated if they was changed
> -- by code in exec()
> foo = getExecVar("foo")
> bar = getExecVar("bar")
> ...
> end procedure
>
> procedure execCode(sequence t)
> routine => call via routine_id()
> emulate entire euphoria
Well, we can now, with one of several interpreters in the RDS archives. But
routine_id()s are not valid outside the program that they are in. You can't
make a routine_id and pass it to a second program, unless it points to
locked memory, which Rob says to *never* do.
> has its own table of variables
And cannot pass them back. See, you'd need an include in both programs
that knows what vars exist, and their types. You cannot do this in an Eu
script:
set $1 $2
or
//$1
or
if atom(var1) then var1 = $2 end if -- who knows var1 exists?
> end procedure
>
> procedure exec(sequence s)
> t = tokenize(s)
> setVarsForExec()
> for i=1 to length(t)
> execCode(t)
> end for
> setVarsFromExec()
How will you setVarsFromExec() without knowing what vars were already
predefined in the calling code? And their types?
> end procedure
>
> It isn't as fast as exec() built-in into interpreter,
> but allows the code to be translated to C.
Using Eu only as glue language? Cusswords, i wanted a language to write
the whole program in!
> So the only thing that would make exec() easier, is
> the ability to reference variables via their name
> like routine_id() does. But this would introduce
> pointers...
Well, pointers can be hidden from the Eu users, like the items in sequences
are pointers.....
I think we are at the empasse where Rob wants to keep the language as the
ideal he held 12 years ago, rather than make it more broadly attractive and
infinitely useable. It's a given that interpreters are going to be slower than
compiled languages, i accept that. But interpreters can also be smarter. I
draw the line at the language semantically parsing the language syntax like
Rebol, but some new commands, like goto and eval(), and better integration
into the OSs that Eu runs on, such as exw supporting kernal32 disk file calls
transparently to the programmer, are overdue. I once thought Rob might take
a cue from MS integrating things that had been addons (remember
Stacker?), and usurping the original code authors, but now i see the opposite
is happening, Rob isn't adding anything that people are finding universally
useful, it's mostly all in win32lib! I mean !really!, i used seek() in pascal
for
years, in every program, even writing machine code to expand what pascal
provided, and now i can't use it in Eu??
Kat
13. Re: Version 2.4 and beyond
Kat wrote :
> >
> > It is possible to have exec() in the current Euphoria.
>
> Yeas, i had considered a preprocessor that built var tables, added includes
> to handle passing vars back and forth between a second instance of the
> interpreter, or sharing the permitted part of the var table with the
> subordinate
> "threads", but it got overly wierd real fast. I didn't see it working.
>
> Well, we can now, with one of several interpreters in the RDS archives. But
> routine_id()s are not valid outside the program that they are in. You can't
> make a routine_id and pass it to a second program, unless it points to
> locked memory, which Rob says to *never* do.
I don't mean it as separate instance nor thread, just an include file or part of
the
program.
> > has its own table of variables
>
> And cannot pass them back. See, you'd need an include in both programs
> that knows what vars exist, and their types. You cannot do this in an Eu
> script:
Yes you'd have to keep the list manually.
>
> > end procedure
> >
> > procedure exec(sequence s)
> > t = tokenize(s)
> > setVarsForExec()
> > for i=1 to length(t)
> > execCode(t)
> > end for
> > setVarsFromExec()
>
> How will you setVarsFromExec() without knowing what vars were already
> predefined in the calling code? And their types?
>
> > end procedure
> >
> > It isn't as fast as exec() built-in into interpreter,
> > but allows the code to be translated to C.
>
> Using Eu only as glue language? Cusswords, i wanted a language to write
> the whole program in!
There are thousands of successfull programs written without exec().
Anyway, if you want to create some scripting database or
some other scripting, it would be too dangerous to allow exec()
to do any code / access internal values. You have to
create internal 'playground' for the script, which my solution
provides.
> > So the only thing that would make exec() easier, is
> > the ability to reference variables via their name
> > like routine_id() does. But this would introduce
> > pointers...
>
> Well, pointers can be hidden from the Eu users, like the items in sequences
> are pointers.....
>
> I think we are at the empasse where Rob wants to keep the language as the
> ideal he held 12 years ago, rather than make it more broadly attractive and
> infinitely useable. It's a given that interpreters are going to be slower than
> compiled languages, i accept that. But interpreters can also be smarter. I
> draw the line at the language semantically parsing the language syntax like
> Rebol, but some new commands, like goto and eval(),
Well, there are two ways Euphoria can take:
a) fast, multi-purpose, C-like language, but with cleaner data types and syntax,
easy to learn.
b) slow, obscure, yet-another scripting language, with weird syntax, difficult
to learn,
usable only for some scripts like bash, perl, python, awk etc.
I prefer way a). I would even like to see true Euphoria compiler without the
Eu2C step.
(maybe GCC frontend?). You apparently choose way b). Then you should instead of
still
complaining rather bring sequences to mirc.
> and better integration
> into the OSs that Eu runs on, such as exw supporting kernal32 disk file calls
> transparently to the programmer, are overdue. I once thought Rob might take
> a cue from MS integrating things that had been addons (remember
> Stacker?), and usurping the original code authors, but now i see the opposite
> is happening, Rob isn't adding anything that people are finding universally
> useful, it's mostly all in win32lib! I mean !really!, i used seek() in pascal
> for
> years, in every program, even writing machine code to expand what pascal
> provided, and now i can't use it in Eu??
Yes, but it is difficult to write cross-platform libraries because platform A
has an extra
feature other platforms have and platform B lacks feature other platforms have.
Rather
give
users the chance to access full power of the platform via .dll/.so/machine code
and let
them
choose. Visual Basic users even don't know how the API works because they have
an ActiveX
component for everything, and they aren't able to survive without Microsoft.
But I agree the distribution should have basic wrappers - like header files
distributed
with C compilers.
Martin
