1. RE: Version 2.4 and beyond
Derek Parnell wrote:
[snip]
>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 think from meory I have supported your push before regarding a
mission statement from RDS regarding the objectives of Euphoria.
I suspect your 100% correct with minimulism, speed, size, and
platform.
I also think RDS should have an official documented plan for the
future of Euphoria.
Ray Smith
http://www.geocities.com/ray_223
2. RE: Version 2.4 and beyond
> 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.
Speaking of, I suggest you develop a "propaganda" list for people who
currently program in, or are considering, Python, Perl, <other language
here>... like the propaganda docs you have for Basic and C users.
> Structures, classes, etc. are tempting, but I've studied them
> carefully over the years, and decided not to include them.
What detriments outweighed what benefits?
> 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?
> "planning" stifles creativity.
Unless you plan to create... :)
3. RE: Version 2.4 and beyond
Rob,
> Structures, classes, etc. are tempting, but I've studied them
> carefully over the years, and decided not to include them.
Of the OOP implementataions, do you think they are good starts?
sufficient already? necessary at all?
4. RE: Version 2.4 and beyond
On 13 Feb 2002, at 21:49, C. K. Lester wrote:
Note: i still don't have Robert's original email containing these quotes.....
> > Structures, classes, etc. are tempting, but I've studied them
> > carefully over the years, and decided not to include them.
>
> What detriments outweighed what benefits?
/me listens.. As much as i dislike OOP, classes *without limits* could be
interesting. By "without limits" i mean buildable at runtime, importable as
needed during runtime, non-failmode if called and they aren't there, a means
to detect if they are there or not (ditto the methods internally), allow
multiple
inheritances and descendants, and you can prolly guess all the other
restrictions i don't want on them. Basically, make them extremely useable
and user friendly, like sequences are.
> > "planning" stifles creativity.
>
> Unless you plan to create... :)
Also known as: allow expansion of Eu into areas you had not considered,
like Ai, even as a Lisp/Scheme/Prolog replacement. I am sure Khaled had
not considered anyone would use mirc as an Ai frontend, or any part of an Ai
for that matter, but we exchanged a number of emails on how i did it (seems
he didn't know all of the tricks in mirc coding!). 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)) ?
Kat,
eagerly waiting on Karl's interpreter to hit the user contrib page
5. RE: Version 2.4 and beyond
The exec(sequence) idea sounds pretty interesting. If a public class is
just data and it's associated methods, wouldn't allowing executable
sequences be roughly equivalent to a public class?
You'd have a sequence
sequence glob
glob = {int a, int b, procedure initial, procedure doStuff}
Sure looks a lot like a public class to me.
6. RE: Version 2.4 and beyond
Irv:
But if you develop applications in Python or Perl.
I thought that you could not charge for them or copyright them ?
Bernie
7. RE: Version 2.4 and beyond
Mike Nelson wrote:
> C. K. Lester wrote:
> 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:
Wouldn't it be wiser and less imposing for us
develop some basic mechanism that would allow a
any user to easily extend the interpter externally.
It seems to me that there are enough clever and
skilled programmers here to come up with some
simple yet powerful mechanism to allow this.
The mechanism needs to allow assembler or "C"
modules to attach directly into a interpeter API.
I say "C" or assembler because they would not require
the compilcations of OOP code.
If we start thinking along these directions this
will allow everyone to contribute ideas even if
they don't have the source code.
This keeps the interpeter at present size and speed.
Then if something becomes obviously usefull it could
be considered by Rob for embedding in the interpeter.
Bernie
8. RE: Version 2.4 and beyond
Bernie Ryan wrote:
>
> Irv:
> But if you develop applications in Python or Perl.
> I thought that you could not charge for them or copyright them ?
> Bernie
That doesn't sound right to me. I think if you took the original source
for Perl or Python and used that to make a custom version of either
language, then they might insist that the terms of the license is such
that those changes should be made public under the same terms as the
original code. However, code written in either language is separate
from (though dependent upon) the open source interpreters. I don't
believe that there is a requirement that your applications which use
either of those languages require you to make them public. Now, it
might be that some of the packages which are available could have such a
restriction, but I think that it is the same situation. If you modify
the package (as opposed to simply including it) then they might require
that you make the modified package available. However, I doubt that
anyone would expect an application using standard packages be made
freely available just because they use those packages.
Of course, I could be wrong! 
However, if you search for perl
applications on the web (cgi applications are quite common) it is not
hard to find applications for which fees are required for usage (maybe
only for commercial use of the application) and I would expect that this
would have drawn the ire of the perl community if all perl applications
were required to be made freely available.
-JoKeR
9. RE: Version 2.4 and beyond
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
> > > I'm still waiting to see a fast action game
> > > written in Python or Perl.
> >
> 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
