1. WISHLIST.TXT
C'est un message de format MIME en plusieurs parties.
------=_NextPart_000_0005_01C249DB.03F5C8A0
boundary="----=_NextPart_001_0006_01C249DB.03F5C8A0"
------=_NextPart_001_0006_01C249DB.03F5C8A0
charset="iso-8859-1"
Hello, dear EUfolks !
Here is a wish list in which I compiled everything I could think as an =
useful enhancement for Euphoria (exchanged some mails with R. Craig on =
this).
By the way, wouldn't it be a good idea to have a "Plans for the future" =
page on the website stating:
-what is definitely not planned as an evolution for Euphoria;
-what is definitely planned, possibly with a timetable ("by 12/06/02", =
"not before 2008", whatever...)
- what remains in a gray area in vetween.
This could be useful for people who spend time to build preprocessors, =
for instance...
Hope to submit a regular expression library next week. It is =
significantly richer than P. Hazel's, and noncompliance with Perl =
standard is minimal if not nil (didn't check all the specs). Its =
philosophy is based on C. Schank's BE text editor regexp handling (very =
good DOS shareware, now unsupported I think; registering was just for =
tech support and direct upgrades).
Have a nice day !
Chris
------=_NextPart_001_0006_01C249DB.03F5C8A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello, dear EUfolks !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here is a wish list in which I compiled =
everything I could think as an useful enhancement for Euphoria =
(exchanged some mails with R. Craig on this).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>By the way, wouldn't it be a good idea =
to have a=20
"Plans for the future" page on the website stating:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-what is definitely not planned as an =
evolution for=20
Euphoria;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-what is definitely planned, possibly =
with a=20
timetable ("by 12/06/02", "not before 2008", whatever...)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- what remains in a gray area in=20
vetween.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This could be useful for people who =
spend time to=20
build preprocessors, for instance...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Hope to submit a regular expression =
library next=20
week. It is significantly richer than P. Hazel's, and noncompliance with =
Perl=20
standard is minimal if not nil (didn't check all the specs). Its =
philosophy=20
is based on C. Schank's BE text editor regexp handling (very good =
DOS=20
shareware, now unsupported I think; registering was just for tech =
support and=20
direct upgrades).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have a nice day !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Chris</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
------=_NextPart_001_0006_01C249DB.03F5C8A0--
------=_NextPart_000_0005_01C249DB.03F5C8A0
Content-Type: text/plain;
name="WISHLIST.TXT"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="WISHLIST.TXT"
A Wish List for enhancing Euphoria
=20
by C. Cuvier, ccuvier at free.fr
=20
Motivation and overview.
Euphoria's main innovation as a pprogramming language is an almost=20
intuitive treatment of sequences. This is closer to human natural =
thinking=20
than most common languages. As a consequence, it has the potential to =
attract
a large part of the programming community. When it is easier to code as =
you
think, there are much less bugs, and the various built-in error checkers =
greatly
help reduce it further. Everybody can figure out the benefits.
Windows API support seems just as good as C; so, this is probably not
an issue there. Which does not mean it was not an enormous work.
Euphoria does not miss any feature of Basic, if you add the OOP =
dimension.
So, programmers that are not stuck with VBA can switch easily to =
Euphoria.
C/C++ programmers may miss the flexibility of C. It's a racing car, =
which
means high performane at the price of tedious debugging. For Euphoria to =
attract
these people, it is likely that some enhancements are needed.
Most of the following is already implemented by preprocessors, albeit =
probably
quite inefficiently compared with built-in implementation.
Type-saving enhancements.
-------------------------
Implicit slice bounds:
s[a..] would mean s[..length(s)], s[..a] would mean s[1..a].
s[..-a] would mean s[1..length(s)-a]
Cross-dimensional sequences:
s<slice1>...<slice n> would mean s with all objects the k-th =
dimension of=20
which is not in <slice k> removed. Thus, m[..][3] could be the third =
line of=20
a matrix specified by a sequence of columns.
Assignment to explicit sequence.
Direct indexing of implicit sequences would make some codin much =
shorter. That
is the date()[MONTH] exemple.
A seemingly obvious generalization of this is to be able to assign a
sequence to an explicit sequence {var_1,...,var_n}. In the last writing, =
only
variable and slices would be allowed.
Dot notation:
Make x.f(args) a synonym of x=3Df(x,args). Much clearer. =
x=3Dy.f(args) may
not be an useful generalization.
Code clarity enhancers.
-----------------------
Variable declaration anywhere:
Putting all variable declarations first mixes all variables together, =
whatever the generality of their use. If you can declare variables when =
you
use them, it is much clearer for somebody else reading the source that =
it is
now that your variable will be of any use. Declaration should come =
before first
reference, of course.
Limited scope:
In large routines, it often happens that some variables are of very =
local
use. So, defining local scopes where these variables are meaningful =
could allow
a faster comprehension of what the variable is meant to. Could be =
implemented
with the pair of keywords *scope* and *end scope*. End scope statement =
would
discard all variables declared within the scope being closed.
One-layer visibility in includes.
An include file used as a library must contain the user function as =
well as
theauxiliary functions they use. The only differenc between them is that =
the
first category is declared global. Would be much clearer if the =
auxiliaries
coud be in another file. What if the auxiliaries themselves need =
lower-level
utilities? You must either declare them as global in another include =
file, or
mix them in the library.
A solution to the confusion could be a *friend* keyword that could =
apply to
any local symbol. It would mean:"make this symbol known to a file that =
includes
this file". This way, you can have one file by functional layer.
(Not too many) new statements.
------------------------------
Resume statement:
A "resume" statement would give control to the first statement in a =
loop,
performing the operations that an *end loop* normally would. After all,
a new keyword is not even necessary: end while and end for can be uesd =
just
as well.
Execute statement:
Takes a character string as argument and executes the statement(s) it =
is
supposed to contain. This dynamic definition of statements could avoid a =
lot
of conditional blocks and temporary variables.
Select/case statement:
Well, any usual language has it, and nobody thinks it is useless, so =
why
not in Euphoria? As in C, the exit keyword would control what happens =
after
a case is processed.
Variable accessibility.
-----------------------
Right now, there are only three scopes for a variable: routine-wide =
(private),
file-wide (local) and project-wide (global). So, when two separate =
routines=20
(most of the time, one is calling the other) need to access a variable, =
this
variable must be at least file-wide.=20
Assume now that routine R1 and R2 need variable V12, R2 and R3 need =
V23 and=20
so forth: all symbols end up in the same file, while a small portion of =
the=20
file uses each of them. This is a worst case scenario, but it happens.
Here are several ways to overcome this:
=20
1/ Symbolic array. This trick could solve several problems at the same =
time.
Description: the statement
array myname var_1 ... var_n
would create a sequence whose k-th term is var_k. var_k can then be =
accessed=20
either as var_k or myvar[k]. This is handy to backup and restore bundles =
of=20
variables, or passing them as arguments.
Making the array global would allow any routine to access the =
variable(s),=20
in a way that precludes any unintentional access.
2/ Procedure nesting. This is Pascal's solution.
Consider the following piece of hypothetical code:
routine A
<A's vars>
routine B
<B's vars>
routine C
<C's vars>
<C's cide>
end routine
routine D
<D's vars>
<D's code>
end routine
end routine
end routine
It would mean the following:
- Only A can call B (through a routine_id)
- B, C and D can refer to A's smbols
- Only B (and A?) can call C or D.
- C (respectively D) symbols are known only to C (resp. D)
- B symbols can be accessed by C or D, but not A
Since there is often a hierarchical relation between the routines =
that
need to share a variable (often, a main routine dispatches work to =
auxiliary=20
routines), this mechanism makes for intermediate scopes that reflect =
more
closely the actual use of variables. It makes code more modular, which=20
generally means more maintainable.
Referring to a upper-level symbol could generate a warning, for =
debugging
purposes.
3/ Namespacing
After all, a routine defines a namespace inside which some symbols =
have a=20
different meaning. So, a good way to share variables could be for a =
routine to=20
refer to the variable as routinename:varname.
This avoids accidents, but considers variable sharing as rather rare, =
which=20
is not quite true.
Miscellaneous
-------------
Namespace instantiation
Sometimes it would be much clearer to let the same file be designated =
by
two (or more) different namespaces, reflecting the use that is made of =
the file.
Also, decoupling the uses later (replacing the single file by several =
files)
would be much easier.
Static variables
In some fields, it is not rare that we need to remember some values =
taken=20
by routine variables. Declaring them static would allow them to retain =
their
value between two calls.
Optional argument for exit statement
What happens if you first defined a loop with exit statements, then =
improved
it so that the exit statement is inside an inner loop? Answer: the eit =
statement
must be accompanied by the setting of an auxiliary variable (sort of =
error code).
And, at the end of the loop, you must test the variable and =
conditionally exit
the outer loop (only one level was added, right?).
An elegant solution to this bloated coding would be for *exit* to =
have an
optional argument specifying the number of levels to jump up out. =
Default value
(see below) would be 1.
Default values for arguments in routines
Overloading is prohibited, and it is not very easy sometimes to =
detect
coding errors arising from this feature. Anyway, in quite a few cases,
the processing of aruments may change completely if one or more =
arguments
have special values which are not intuitive, or whose passing as =
argument is
not.
The ability to code: routine r(arg_1,...,arg_k=3Ddef_value,...) would =
reduce
the overhead of unintuitively passing special values for argument. To =
use
the default for a given arument, omit the las or put nothing between the =
commas
(just like basic).
Lagging variables
This feature comes from the SAS language, as well as the symbolic =
array.
This would introduce a *lag=3Dk* top-level statement, which may occur =
in any
number and at any place in the program, as well as the *without lag* =
one,
and a function *lag* (sequence x, integer n).
If variable myvar was declared while a *while lag=3Dk* statement was =
in effect,=20
lag("myvar",n) would cause an error if n>k and return the n-th last =
value of
myvar otherwise.
Negative arguments of lag could be allowed, with the same meaning as =
for=20
slices.
A *with lag=3D* * statement would mean "retain every assignment that =
was made=20
to the following variables". Can be useful if you know the variable may =
change
not too often, but you need the series of all former values. Quite a few =
recurrence schemes require this.
A final note on pointers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
True, "Euphoria does not have pointers, and does not need them".=20
But programmers do, and that's why they keep programmong in C or =
like-mided=20
languages, with all the hassles of unintended modifying, uninitialized =
things=20
and so much time lost in tracking elusive bugs.
Pointers are too dangerous, OK. So, a very good language would keep =
them=20
away from programmers while still providing the same services.
So why do we need pointers after all?
Here is a list of 99% of the uses, in my opinion:
1 Because a library routine, or an external interface, requires them
2 Because we want to pass large chunks of data to a routine
3 Because we want to link data into trees, lists and the like
4 Because we want to modify the calling parameters, often to return them
5 Because we want to dynamically access data at different locations, =
assuming
a fixed layout for these.
Euphoria solves (1), (3) and, with an optimistic reading of the docs, =
(2). So,
if it could address (4) and partially (5), it would upgrade from an =
interesting language
to a really powerful, easier to use than to fool, language. Some of the
solutions above would do the trick.
For advanced platform or machine-specific code hackery, C will always =
be
there, but the risks will become acceptable because of their very =
limited scope.
************************************
------=_NextPart_000_0005_01C249DB.03F5C8A0--
2. Re: WISHLIST.TXT
Hi Christian,
I do not wish to dishearten you, in fact I'm glad to see yet another person
requesting change. However there is very little new in what you have asked
for. Except for a couple of your ideas, they have been asked for in one form
or another over the years. What I, and many others, have discovered is that
RDS is very resistant to change. But please keep up the pressure - maybe one
day we might all get a pleasant surprise.
I think the new ideas you have presented include the 'friend' scope for
variables, and 'lagging' variables. I can see the usefulness of a friend
scope and wouldn't mind that at all.
As for lagging, I don't think I've ever needed this concept in my code. The
closest I've come to this is a stack-type arrangement, in which the program
might always refer to the 'current' value of a variable but there would be a
routine to assign a new value while saving the previous value, and another
function to restore the previous value. I implement this in a sequence
thus...
sequence v v = {}
function setVar(sequence v, object x)
return prepend(v, x)
end function
function restoreVar(sequence v)
return v[2..length(v)]
end function
function getVar(sequence v)
return v[1]
end function
----------------
cheers,
Derek Parnell
3. Re: WISHLIST.TXT
Christian <christian.cuvier at education.gouv.fr> wrote:
> Hello, dear EUfolks !
> Here is a wish list in which I compiled everything I could think as an
> useful enhancement for Euphoria (exchanged some mails with R. Craig on
> this).
<snip>
Here is an extract of "wishlist.txt", which was attached to your post:
------------------------------------------------------------------------
<snip>
> Direct indexing of implicit sequences would make some codin much shorter.
> That
> is the date()[MONTH] exemple.
Even simpler: date(MONTH)
<snip>
> One-layer visibility in includes.
> An include file used as a library must contain the user function as well as
> theauxiliary functions they use. The only differenc between them is that the
> first category is declared global. Would be much clearer if the auxiliaries
> coud be in another file. What if the auxiliaries themselves need lower-level
> utilities? You must either declare them as global in another include file, or
> mix them in the library.
> A solution to the confusion could be a *friend* keyword that could apply
> to
> any local symbol. It would mean:"make this symbol known to a file that
> includes
> this file". This way, you can have one file by functional layer.
Very good idea! I mean: "_very_ good"! Did I already mention, that this
in my opinion is a *very* good idea? 
)) IMO this fits perfectly to
the Euphoria philosophy.
<snip>
> Resume statement:
> A "resume" statement would give control to the first statement in a loop,
> performing the operations that an *end loop* normally would. After all,
> a new keyword is not even necessary: end while and end for can be uesd just
> as well.
I'm afraid I didn't understand what you mean. Could you please give an
example?
<snip>
> Variable accessibility.
> -----------------------
> Right now, there are only three scopes for a variable: routine-wide
> (private),
> file-wide (local) and project-wide (global). So, when two separate routines
> (most of the time, one is calling the other) need to access a variable, this
> variable must be at least file-wide.
> Assume now that routine R1 and R2 need variable V12, R2 and R3 need V23 and
> so forth: all symbols end up in the same file, while a small portion of the
> file uses each of them. This is a worst case scenario, but it happens.
> Here are several ways to overcome this:
<snip>
4) Here is another way, IMO simpler to use than #1-3 (the variable can
be accessed by any routine, that declares it as "shared")
function r1()
shared integer v12
-- etc.
end function
function r2()
shared integer v12, v23
-- etc.
end function
function r3()
shared integer v23
-- etc.
end function
> Static variables
> In some fields, it is not rare that we need to remember some values taken
> by routine variables. Declaring them static would allow them to retain their
> value between two calls.
Static variables will be useful.
> Optional argument for exit statement
> What happens if you first defined a loop with exit statements, then
> improved
> it so that the exit statement is inside an inner loop? Answer: the eit
> statement
> must be accompanied by the setting of an auxiliary variable (sort of error
> code).
> And, at the end of the loop, you must test the variable and conditionally exit
> the outer loop (only one level was added, right?).
> An elegant solution to this bloated coding would be for *exit* to have an
> optional argument specifying the number of levels to jump up out. Default
> value
> (see below) would be 1.
<snip>
This will be very useful!
(For instance, in PowerBASIC you can write "exit,exit,exit" but it's of
course much more elegant to write "exit 3".)
------------------------------------------------------------------------
Regards,
Juergen
4. Re: WISHLIST.TXT
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: WISHLIST.TXT
>
> Hi Christian,
> I do not wish to dishearten you, in fact I'm glad to see yet another
person
> requesting change. However there is very little new in what you have asked
> for. Except for a couple of your ideas, they have been asked for in one
form
> or another over the years. What I, and many others, have discovered is
that
> RDS is very resistant to change. But please keep up the pressure - maybe
one
> day we might all get a pleasant surprise.
>
> I think the new ideas you have presented include the 'friend' scope for
> variables, and 'lagging' variables. I can see the usefulness of a friend
> scope and wouldn't mind that at all.
>
> As for lagging, I don't think I've ever needed this concept in my code.
The
> closest I've come to this is a stack-type arrangement, in which the
program
> might always refer to the 'current' value of a variable but there would be
a
> routine to assign a new value while saving the previous value, and another
> function to restore the previous value. I implement this in a sequence
> thus...
>
> sequence v v = {}
>
> function setVar(sequence v, object x)
> return prepend(v, x)
> end function
>
> function restoreVar(sequence v)
> return v[2..length(v)]
> end function
>
> function getVar(sequence v)
> return v[1]
> end function
>
> ----------------
> cheers,
> Derek Parnell
Hello...
Well, I pretty well know that most of what I suggest has been implemented
already in preprocessors or in variants of Euphoria. It is mainly a problem
of performance, and the time spent to write a preprocessor (obviously
starting from an existing one). And there are things I don't see how I can
implement them in plain Euphoria.
RDS may resist to change, which is not unhealthy by itself. If they could
position themselves on possible evolutions (mine or anyone else's, of
course), it will already be easier. And I really think they may miss a huge
growth potential if they resist too much or too long. If I did not think
this language has a future, I wouldn't care much. The day they see variants
being preferred to their stuff, they won't resist as much, I guess.
As for lagging variables, there are a convenience to avoid saving former
values into a ton of intermediate variables which easily evolve into a bunch
of bugs. Actually, the sequence scheme in the way I implement it in an
embryo of preprocessor (not before several tyears, I guess).
Regards.
Chris
5. Re: WISHLIST.TXT
Chris writes:
> Here is a wish list in which I compiled everything I could think
> as an useful enhancement for Euphoria
> (exchanged some mails with R. Craig on this).
Thanks. Your ideas are well thought out.
> By the way, wouldn't it be a good idea to have a
> "Plans for the future" page on the website
It sounds good, but I'm just not that methodical.
Sometimes I do put major plans on the news page.
> This could be useful for people who
> spend time to build preprocessors, for instance...
If there's something you want to add with a preprocessor,
go ahead. It's not too likely that I will come out with a similar
feature just after you release yours.
Since doing the FreeBSD port, I've spent a lot of
time writing various Euphoria application programs,
so I haven't done that much yet on Euphoria itself.
I've also spun off the Euphoria program used to moderate
this list into a little side business:
http://www.ListFilter.com
I'll have more time for Euphoria development soon.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: WISHLIST.TXT
Hey,
I like Euphoria the way it is,and I know you do too,so please don't
get me wrong,but let me tell you why I am kind of resistant to MAJOR
changes to the language.
1.Pointers.Though I understand them,I am the type of person who has
enough trouble with the direct approach,let alone the indirect one,One
of the reasons I stopped using C was because of their complexity.
2.Loops.I have found that the while,if,for loops work for anything
I need,and quickly too.
3.The reason why I like Euphoria is because its small,fast and I can
keep track of it.It helps me focus on my program not programming.
4.As far as portability is concerned,we got windows,linux and now
freebsd.Lets let the rest of the world become compatible with us
and not vice-versa
5.Their are some real smart people programming with it--somebody is
going to make a game or some other popular graphics program with it
(hopefully me) and the language will take off--guaranteed.
6.Low price,I like that,and I don't think Robert should release his
source code(another subject)
7.That darn interpreter is reliable.Adding all kinds of new complexity
could jeopardize the stability of the thing,that wouldn't be good.
8.I'm sorry if I'm not seeing the whole picture,I really am. But
from my standpoint I'd like to see as little change in it as possible,
because change means that you have to adapt to more.If I ever need
more from a language I'll find a new one,its a no brainer for me.
There are many features I'd like to see implemented,I'd like to just
type "Write my Program" and have it done. As in all things in life
there is what we want\need and what actually exists,our challenge is
to line up what we need to what actually exists.
Once again I apologize if my opinion offends,but I think you can
see that this is just one man's opinion. Maybe I'm wrong--probably am,
but best of luck to you,regardless,
Jason
>From: christian.cuvier at education.gouv.fr
>Reply-To: EUforum at topica.com
>To: EUforum <EUforum at topica.com>
>Subject: WISHLIST.TXT
>Date: Thu, 22 Aug 2002 12:54:12 +0200
>
>
>Hello, dear EUfolks !
>
>Here is a wish list in which I compiled everything I could think as an
>useful enhancement for Euphoria (exchanged some mails with R. Craig on
>this).
>
>By the way, wouldn't it be a good idea to have a "Plans for the future"
>page on the website stating:
>-what is definitely not planned as an evolution for Euphoria;
>-what is definitely planned, possibly with a timetable ("by 12/06/02", "not
>before 2008", whatever...)
>- what remains in a gray area in vetween.
>
>This could be useful for people who spend time to build preprocessors, for
>instance...
>
>Hope to submit a regular expression library next week. It is significantly
>richer than P. Hazel's, and noncompliance with Perl standard is minimal if
>not nil (didn't check all the specs). Its philosophy is based on C.
>Schank's BE text editor regexp handling (very good DOS shareware, now
>unsupported I think; registering was just for tech support and direct
>upgrades).
>
>Have a nice day !
>
>Chris
>
>
>
7. Re: WISHLIST.TXT
----- Original Message -----
From: "Juergen Luethje" <jluethje at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: WISHLIST.TXT
>
> Christian <christian.cuvier at education.gouv.fr> wrote:
>
> <snip>
> > Resume statement:
> > A "resume" statement would give control to the first statement in a
loop,
> > performing the operations that an *end loop* normally would. After all,
> > a new keyword is not even necessary: end while and end for can be uesd
just
> > as well.
>
> I'm afraid I didn't understand what you mean. Could you please give an
> example?
>
Hi!
The *end for* or *end while* statements - I'll call them *end loop* -
return control to the top control statement in the loop (the *for* or
*while* thing, with condition testing and everything).
In Euphoria, *end loop* statement can appear only as the closing
statement of the loop.
My suggestion is that it could appear anywhere inside the loop,
returning control as described above.
In other languages, this functionality is assumed by specific keywords:
*resume* (SAS), *iterate* (some Basics), *continue* (C)... . My observation
was that a new keyword is not needed, just extend the availability of an
existing one.
So, instead of writing
while <cond1> do
...
if not(<cond2>) then
...
if not(<cond3>) then
...
end if
end if
end while
you'd have the much cleaner, and completely synonym:
while <cond1> do
...
if <cond2> then end while end if
...
if <cond3> then end while end if
...
end while
If it is a problem to tweak the interpreter into understanding this use of
*end loop*, then one of the other known keywords (*resume* is shorter) could
be introduced for this specific purpose.
Clearer?
BTW: on dubetyrant statement:
>7.That darn interpreter is reliable.Adding all kinds of new complexity
>could jeopardize the stability of the thing,that wouldn't be good.
Obviously, stability is an issue, and that's why I said resisting too change
is not unhealthy by itself. Some features may never be mplemented, although
they would be very convenient, for this very reason.
Frankly, I think that 90% of what I'm suggesting cannot compromise Euphoria
interpreter stability in any way. As for the remaining 10%, I don't know. I
paid special attention in seeing to it that nothing proposed could break
existing code.
The "Not planned in any future" section I suggested could state some of
these features that might be too risky to implement, with a sketch of the
reason why. Careful reading could then clarify issues and give a better
understanding of how Euphoria works, which will mean better Euphoria coding.
>2.Loops.I have found that the while,if,for loops work for anything
>I need,and quickly too.
Hey, very smart people coded marvelous things in Fortran77 30 years ago.
Want to use this again? It is most of the time a matter of convenience in
writing and code readability and maintainability.
After all, one could say: Euphoria can interface with C and ASM, so do any
advanced trickery through this interface. I don't think it is either clean,
desirable or secure, but it may work...
Best regards.
Chris
8. Re: WISHLIST.TXT
----- Original Message -----
From: <christian.cuvier at education.gouv.fr>
To: "EUforum" <EUforum at topica.com>
Subject: Re: WISHLIST.TXT
>
> while <cond1> do
> ...
> if <cond2> then end while end if
> ...
> if <cond3> then end while end if
> ...
> end while
>
> If it is a problem to tweak the interpreter into understanding this use of
> *end loop*, then one of the other known keywords (*resume* is shorter)
could
> be introduced for this specific purpose.
>
> Clearer?
>
Not really. By "end loop" I assume you are telling the interpreter to finish
looping through the current loop block. If so, what is the difference
between "end loop" and the current "exit" statement?
By the way. currently in Euphoria, the "end while" statement is a place
marker to tell the interpreter where a loop block ends. It is not an action
statement that tells the interpreter to do something. It just marks a spot
in the code, much like a label does in other languages.
----------------
cheers,
Derek Parnell
9. Re: WISHLIST.TXT
----- Original Message -----
From: "Matthew Lewis" <matthewwalkerlewis at YAHOO.COM>
To: "EUforum" <EUforum at topica.com>
Subject: RE: WISHLIST.TXT
> > Not really. By "end loop" I assume you are telling the
> > interpreter to finish
> > looping through the current loop block. If so, what is the difference
> > between "end loop" and the current "exit" statement?
>
> No, he means to go back to the top of the loop for the next iteration.
> Here's a silly example:
>
> for i = 1 to 10
> if remainder(i,3) = 0 then
> resume
> end if
> printf(1, "%d is divisible by 3!\n", i)
> end for
>
> So you should see:
>
> 3
> 6
> 9
>
> I typically use a big if statement to do that sort of thing (of course
this
> is really trivial):
>
> for i = 1 to 10
> if remainder(i,3) != 0 then
> printf(1, "%d is divisible by 3!\n", i)
> end if
> end for
>
Thanks Matt. I proposed a statement that is similar to 'exit <name>'. I
propose that we have a 'next <name>' statement. This would go to the *next*
iteration of the named loop block.
Main:for j = 1 to 5 do
sum = 0
for i = 1 to 10
if sequence(x[j][i]) then
next Main
end if
if remainder(x[j][i],3) = 0 then
next
end if
sum += x[j][i]
printf(1, "%d is divisible by 3!\n", i)
end for
printf(1, "The sum is %d\n", sum)
end for
----------------
cheers,
Derek Parnell
10. Re: WISHLIST.TXT
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: WISHLIST.TXT
> Not really. By "end loop" I assume you are telling the interpreter to
finish
> looping through the current loop block. If so, what is the difference
> between "end loop" and the current "exit" statement?
>
Not really. I'd like to tell the interpreter to finish the current iteration
in this loop block and immediately start next iteration. So, current *exit*
transfers control after end of block, and *end loop* would transfer control
to top loop statement. Thus they differ.
> By the way. currently in Euphoria, the "end while" statement is a place
> marker to tell the interpreter where a loop block ends. It is not an
action
> statement that tells the interpreter to do something. It just marks a spot
> in the code, much like a label does in other languages.
>
Alas !
By the way: block naming to use in exit statement is OK with me.
Regards
Chris
11. Re: WISHLIST.TXT
On 23 Aug 2002, at 17:54, christian.cuvier at education.gouv.fr wrote:
>
>
> ----- Original Message -----
> From: "Derek Parnell" <ddparnell at bigpond.com>
> To: "EUforum" <EUforum at topica.com>
> Subject: Re: WISHLIST.TXT
>
>
> > Not really. By "end loop" I assume you are telling the interpreter to
> finish
> > looping through the current loop block. If so, what is the difference
> > between "end loop" and the current "exit" statement?
> >
>
> Not really. I'd like to tell the interpreter to finish the current iteration
> in
> this loop block and immediately start next iteration. So, current *exit*
> transfers control after end of block, and *end loop* would transfer control to
> top loop statement. Thus they differ.
Yet another arguement FOR goto! It's one word, and it does what it says:
:restartloop:
-- initvars
for loop = 1 to something do
--code
if whatever1 then goto restartloop end if
if whatever2 then goto endloop end if
if whatever3 then goto resumeloop end if
--code
:resumeloop:
-- possible code
end for
:endloop:
Kat
12. Re: WISHLIST.TXT
> :restartloop:
> -- initvars
> for loop = 1 to something do
> --code
> if whatever1 then goto restartloop end if
> if whatever2 then goto endloop end if
> if whatever3 then goto resumeloop end if
> --code
> :resumeloop:
> -- possible code
> end for
> :endloop:
I've never gotten involved in any arguments regarding goto because I really
don't care. I don't use them... wouldn't use them... etc... But, I don't
care if they're part of the language, as long as code without gotos doesn't
suffer.
Kat, my question is, would there be some extra garbage collection required
if you jump out of a loop that hasn't completed? In your example above, when
whatever2 is true, would the interpreter know that you've exited the loop
and will never return? Does the interpreter even need to know that? I'm just
thinking that stuff would be left hanging, and that doesn't seem very
efficient to me unless the interpreter is smart enough to know where you've
gone and what you've left undone.
Just curious,
ck
13. Re: WISHLIST.TXT
Knowing what to do with goto's, I agree with your position.
But, over time, letting people to use goto led to programs controlled by
goto's rather than controlled goto's.
So I'm not optimistic about uncontrolled goto creeping into Euphoria,
while there is a case to be made in favor of controlled forms (call it
resume or whatecver, named exit,...)
Chris
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, August 23, 2002 6:46 PM
Subject: Re: WISHLIST.TXT
>
> On 23 Aug 2002, at 17:54, christian.cuvier at education.gouv.fr wrote:
>
> >
> > ----- Original Message -----
> > From: "Derek Parnell" <ddparnell at bigpond.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Friday, August 23, 2002 4:51 PM
> > Subject: Re: WISHLIST.TXT
> >
> >
> > > Not really. By "end loop" I assume you are telling the interpreter to
> > finish
> > > looping through the current loop block. If so, what is the difference
> > > between "end loop" and the current "exit" statement?
> > >
> >
> > Not really. I'd like to tell the interpreter to finish the current
iteration in
> > this loop block and immediately start next iteration. So, current *exit*
> > transfers control after end of block, and *end loop* would transfer
control to
> > top loop statement. Thus they differ.
>
> Yet another arguement FOR goto! It's one word, and it does what it says:
>
>
> :restartloop:
> -- initvars
> for loop = 1 to something do
> --code
> if whatever1 then goto restartloop end if
> if whatever2 then goto endloop end if
> if whatever3 then goto resumeloop end if
> --code
> :resumeloop:
> -- possible code
> end for
> :endloop:
>
> Kat
>
>
>
>
14. Re: WISHLIST.TXT
If you consider loop blocks as contexts (this is what suggests the named
exit and friends), the answer is simple: everything that was local to an
exited context is lost, just like a for-variable when you exit.
If the interpreter knows what to do on *exit*, it will know what to do
while jumping out of several contexts.
Obviously, jumping into a non-nested context should not be allowed,
since things might be undefined.
See you monday morning, all folks.
Chris
----- Original Message -----
From: "C. K. Lester" <cklester at yahoo.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, August 23, 2002 6:55 PM
Subject: Re: WISHLIST.TXT
>
> > :restartloop:
> > -- initvars
> > for loop = 1 to something do
> > --code
> > if whatever1 then goto restartloop end if
> > if whatever2 then goto endloop end if
> > if whatever3 then goto resumeloop end if
> > --code
> > :resumeloop:
> > -- possible code
> > end for
> > :endloop:
>
> I've never gotten involved in any arguments regarding goto because I
really
> don't care. I don't use them... wouldn't use them... etc... But, I don't
> care if they're part of the language, as long as code without gotos
doesn't
> suffer.
>
> Kat, my question is, would there be some extra garbage collection required
> if you jump out of a loop that hasn't completed? In your example above,
when
> whatever2 is true, would the interpreter know that you've exited the loop
> and will never return? Does the interpreter even need to know that? I'm
just
> thinking that stuff would be left hanging, and that doesn't seem very
> efficient to me unless the interpreter is smart enough to know where
you've
> gone and what you've left undone.
>
> Just curious,
> ck
>
>
>
>
15. Re: WISHLIST.TXT
On 23 Aug 2002, at 11:55, C. K. Lester wrote:
>
> > :restartloop:
> > -- initvars
> > for loop = 1 to something do
> > --code
> > if whatever1 then goto restartloop end if
> > if whatever2 then goto endloop end if
> > if whatever3 then goto resumeloop end if
> > --code
> > :resumeloop:
> > -- possible code
> > end for
> > :endloop:
>
> I've never gotten involved in any arguments regarding goto because I really
> don't care. I don't use them... wouldn't use them... etc... But, I don't care
> if
> they're part of the language, as long as code without gotos doesn't suffer.
>
> Kat, my question is, would there be some extra garbage collection required
> if you jump out of a loop that hasn't completed? In your example above, when
> whatever2 is true, would the interpreter know that you've exited the loop and
> will never return? Does the interpreter even need to know that? I'm just
> thinking that stuff would be left hanging, and that doesn't seem very
> efficient
> to me unless the interpreter is smart enough to know where you've gone and
> what
> you've left undone.
The way i see it, the loop is treated like a local function in Eu (it was in
turbo
pascal), which is why you don't haveto declare the loop variable. Any jump to
*outside* this function will generate default cleanup code exactly as it does
now. Forward jumps are easy to add, backwards jumps to *before* the loop
start are more difficult, it's a few more steps (exit loop, cleanup, reinit the
loop var, find the target (that's easy, we passed over it before, we know
where it is), and jmp there with everything else unchanged. The fun part is
the loops are simply exited, triggering the same cleanup as now exists, in
the compiled code,, i assume the interpreter is smart enough too.
This way of treating the loops allowed another neat trick in TP: the
embedded procedure or function. Which would fullfill another request made in
this thread, a request made before a few times too: a 3rd level of var scope.
In Pascal, i can do this (pseudocode):
procedure 1()
declare vars for procedure 1()
function 2() -- vars' scope is procedure 1()
end function2
procedure 4() -- vars' scope is procedure 1()
end procedure
procedure 1()'s code here
call function 2()
more procedure 1()'s code here
call procedure 4()
more procedure 1()'s code here
procedure 1()'s code here
call function 2()
end procedure 1()
For scoping problems, this was ideal, and in the disassembler, it looked a lot
like the loop's machine code, anything in the loop was scoped to the calling
procedure as well.
Also, see: Karl's Bach / Bliss in the archives. 
> Just curious,
Curious is good.
Kat
16. Re: WISHLIST.TXT
Derek <ddparnell at bigpond.com> wrote:
<snip>
> Thanks Matt. I proposed a statement that is similar to 'exit <name>'.
Very nice!
> I propose that we have a 'next <name>' statement. This would go to the
> *next* iteration of the named loop block.
Among all proposed keywords for this purpose (resume, iterate, continue)
"next" is the most intuitive for me.
> Main:for j = 1 to 5 do
> sum = 0
> for i = 1 to 10
> if sequence(x[j][i]) then
> next Main
> end if
> if remainder(x[j][i],3) = 0 then
> next
> end if
> sum += x[j][i]
> printf(1, "%d is divisible by 3!\n", i)
> end for
> printf(1, "The sum is %d\n", sum)
> end for
> ----------------
> cheers,
> Derek Parnell
Regards,
Juergen
17. Re: WISHLIST.TXT
Hello,
Christian <christian.cuvier at education.gouv.fr> wrote:
> ----- Original Message -----
> From: "Juergen Luethje" <jluethje at gmx.de>
> To: "EUforum" <EUforum at topica.com>
> Subject: Re: WISHLIST.TXT
>
>> Christian <christian.cuvier at education.gouv.fr> wrote:
>>
>> <snip>
>>> Resume statement:
>>> A "resume" statement would give control to the first statement in
>>> a loop, performing the operations that an *end loop* normally would.
>>> After all, a new keyword is not even necessary: end while and end
>>> for can be uesd just as well.
>>
>> I'm afraid I didn't understand what you mean. Could you please give
>> an example?
>
> Hi!
> The *end for* or *end while* statements - I'll call them *end loop* -
> return control to the top control statement in the loop (the *for* or
> *while* thing, with condition testing and everything).
> In Euphoria, *end loop* statement can appear only as the closing
> statement of the loop.
> My suggestion is that it could appear anywhere inside the loop,
> returning control as described above.
>
> In other languages, this functionality is assumed by specific keywords:
> *resume* (SAS), *iterate* (some Basics), *continue* (C)... . My observation
> was that a new keyword is not needed, just extend the availability of an
> existing one.
Thanks for the additional explanation, now I understand what you mean
(I know the ITERATE keyword). I agree that such an additional keyword
could be nice in some cases.
> So, instead of writing
> while <cond1> do
> ...
> if not(<cond2>) then
> ...
> if not(<cond3>) then
> ...
> end if
> end if
> end while
>
> you'd have the much cleaner, and completely synonym:
>
> while <cond1> do
> ...
> if <cond2> then end while end if
> ...
> if <cond3> then end while end if
> ...
> end while
I wouldn't go so far to say "much cleaner", but at least not so deeply
nested. On the other side, for someone who is not familiar with this
statement, maybe it could look *less* clean?
> If it is a problem to tweak the interpreter into understanding this use of
> *end loop*,
I don't know if it's a problem for the interpreter ...
> then one of the other known keywords (*resume* is shorter) could
> be introduced for this specific purpose.
... but this should be done at least for human readability!
I cannot say it better than Derek. He wrote:
"currently in Euphoria, the 'end while' statement is a place
marker to tell the interpreter where a loop block ends. It is not an
action statement that tells the interpreter to do something."
Using "end for/end while" for different purposes can (and did already)
cause much confusion, and would considerably reduce the readability of
the source code.
> Clearer?
Regards,
Juergen
PS: I don't know, where the following text came from, and how it came
inside your reply. Formally it looks, as if the following text which
is quoted with ">>", was part of my previous post. This is not the
case, nothing of the following was written by me.
> BTW: on dubetyrant statement:
>>7.That darn interpreter is reliable.Adding all kinds of new complexity
>>could jeopardize the stability of the thing,that wouldn't be good.
> Obviously, stability is an issue, and that's why I said resisting too change
> is not unhealthy by itself. Some features may never be mplemented, although
> they would be very convenient, for this very reason.
> Frankly, I think that 90% of what I'm suggesting cannot compromise Euphoria
> interpreter stability in any way. As for the remaining 10%, I don't know. I
> paid special attention in seeing to it that nothing proposed could break
> existing code.
> The "Not planned in any future" section I suggested could state some of
> these features that might be too risky to implement, with a sketch of the
> reason why. Careful reading could then clarify issues and give a better
> understanding of how Euphoria works, which will mean better Euphoria coding.
>>2.Loops.I have found that the while,if,for loops work for anything
>>I need,and quickly too.
> Hey, very smart people coded marvelous things in Fortran77 30 years ago.
> Want to use this again? It is most of the time a matter of convenience in
> writing and code readability and maintainability.
> After all, one could say: Euphoria can interface with C and ASM, so do any
> advanced trickery through this interface. I don't think it is either clean,
> desirable or secure, but it may work...
> Best regards.
> Chris
18. Re: WISHLIST.TXT
On 0, Kat <gertie at PELL.NET> wrote:
>
> On 23 Aug 2002, at 17:54, christian.cuvier at education.gouv.fr wrote:
>
> >
> > ----- Original Message -----
> > From: "Derek Parnell" <ddparnell at bigpond.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Friday, August 23, 2002 4:51 PM
> > Subject: Re: WISHLIST.TXT
> >
> >
> > > Not really. By "end loop" I assume you are telling the interpreter to
> > finish
> > > looping through the current loop block. If so, what is the difference
> > > between "end loop" and the current "exit" statement?
> > >
> >
> > Not really. I'd like to tell the interpreter to finish the current iteration
> > in
> > this loop block and immediately start next iteration. So, current *exit*
> > transfers control after end of block, and *end loop* would transfer control
> > to
> > top loop statement. Thus they differ.
>
> Yet another arguement FOR goto! It's one word, and it does what it says:
>
>
> :restartloop:
> -- initvars
> for loop = 1 to something do
> --code
> if whatever1 then goto restartloop end if
> if whatever2 then goto endloop end if
> if whatever3 then goto resumeloop end if
> --code
> :resumeloop:
> -- possible code
> end for
> :endloop:
>
> Kat
>
Well, after reading this thread, I'll try to seperate from rparse.ex a
gparse.ex (i.e. a goto-only parser of course). If anyone has some hints
abot how to clean up rparse's goto conversion code so the final product
looks neater (by conversion code I mean the code outputed from rparse,
not
rparse's own code, which will always be messy :) I'd be glad to hear
them.
jbrown
--
19. Re: WISHLIST.TXT
On 0, Juergen Luethje <jluethje at gmx.de> wrote:
>
> Derek <ddparnell at bigpond.com> wrote:
>
> <snip>
>
> > Thanks Matt. I proposed a statement that is similar to 'exit <name>'.
>
> Very nice!
>
> > I propose that we have a 'next <name>' statement. This would go to the
> > *next* iteration of the named loop block.
>
> Among all proposed keywords for this purpose (resume, iterate, continue)
> "next" is the most intuitive for me.
>
> > Main:for j = 1 to 5 do
> > sum = 0
> > for i = 1 to 10
> > if sequence(x[j][i]) then
> > next Main
> > end if
> > if remainder(x[j][i],3) = 0 then
> > next
> > end if
> > sum += x[j][i]
> > printf(1, "%d is divisible by 3!\n", i)
> > end for
> > printf(1, "The sum is %d\n", sum)
> > end for
>
> > ----------------
> > cheers,
> > Derek Parnell
>
> Regards,
> Juergen
>
Didn't Rob Craig once post that he'd implement continue for Eu 2.3?
I seem to remember him writing this shortly after I asked this list
about
emulating it so I could create a continue statement for forref.
jbrown
--
20. Re: WISHLIST.TXT
jbrown105 <jbrown105 at speedymail.org> wrote:
> On 0, Juergen Luethje <jluethje at gmx.de> wrote:
>>
>> Derek <ddparnell at bigpond.com> wrote:
<snip>
>>> I propose that we have a 'next <name>' statement. This would go to the
>>> *next* iteration of the named loop block.
>>
>> Among all proposed keywords for this purpose (resume, iterate, continue)
>> "next" is the most intuitive for me.
<snip>
> Didn't Rob Craig once post that he'd implement continue for Eu 2.3?
Unfortunately, I cannot remember.
> I seem to remember him writing this shortly after I asked this list
> about emulating it so I could create a continue statement for forref.
> jbrown
Regards,
Juergen
21. Re: WISHLIST.TXT
- Posted by kbochert at copper.net
Aug 24, 2002
-------Phoenix-Boundary-07081998-
You wrote on 8/23/02 6:15:38 PM:
>
>
>Well, after reading this thread, I'll try to seperate from rparse.ex a
>gparse.ex (i.e. a goto-only parser of course). If anyone has some hints
>abot how to clean up rparse's goto conversion code so the final product
>looks neater (by conversion code I mean the code outputed from rparse,
>not
>rparse's own code, which will always be messy :) I'd be glad to hear
>them.
>
I put much thought into the subject when writing Goo -- gave up.
Karl Bochert
-------Phoenix-Boundary-07081998---
22. Re: WISHLIST.TXT
On 0, kbochert at copper.net wrote:
>
> You wrote on 8/23/02 6:15:38 PM:
> >
> >
> >Well, after reading this thread, I'll try to seperate from rparse.ex a
> >gparse.ex (i.e. a goto-only parser of course). If anyone has some hints
> >abot how to clean up rparse's goto conversion code so the final product
> >looks neater (by conversion code I mean the code outputed from rparse,
> >not
> >rparse's own code, which will always be messy :) I'd be glad to hear
> >them.
> >
>
> I put much thought into the subject when writing Goo -- gave up.
>
> Karl Bochert
>
I already have seperated gotos and pointers from rparse into gparse (it
seems
that rparse's method of handling variables is required in order to get
gotos
to function correctly), unforutantly the outputed code is still ugly
and
it is not 1:1 with the source code (with something like an emulated
goto thats
flat out impossible). As a compromise I'm adding code to output the
original
line numbers as comments to both rparse and gparse.
jbrown
--
23. Re: WISHLIST.TXT
- Posted by kbochert at copper.net
Aug 24, 2002
-------Phoenix-Boundary-07081998-
You wrote on 8/24/02 10:53:18 AM:
>
>I already have seperated gotos and pointers from rparse into gparse (it
>seems
>that rparse's method of handling variables is required in order to get
>gotos
>to function correctly), unforutantly the outputed code is still ugly
>and
>it is not 1:1 with the source code (with something like an emulated
>goto thats
>flat out impossible). As a compromise I'm adding code to output the
>original
>line numbers as comments to both rparse and gparse.
>
That might help some but I still think a preproccesor has a hard row
to hoe here. The user still has to find the reported error in the
preprocessed code and then translate back to what in the original
code caused it. Its a nuisance that get worse as the preprocessor
becomes more powerful. Even with a 1:1 preprocessor like Goo I
found it hard to get used to.
For large-scale additions, a modified interpreter seems to have
insurmountable advantages: speed, error messages where they belong,
complex features hidden in simple syntax and so forth.
I think the best use for a preprocessor is to provide syntactic sugar
-- new features like goto, exceptions etc. will always be problematical.
Karl Bochert
-------Phoenix-Boundary-07081998---
24. Re: WISHLIST.TXT
Hello Jason (and everyone else),
I'd just like to add my general support to Jason's standpoint. The reason
I like Euphoria so much is that it is _very_ stable and while any language
does need to evolve I appreciate the way RDS has a very controlled approach
to change. I'd rather wait for the right changes than go on a roller
coaster of more frequent experimental changes.
Coming from a computer systems administration background I tend to follow
the "if it isn't broken then don't try and fix it" mentality. Now I know
you can only take that so far but my personal take is that I'm not the sort
of person who likes coding up stuff in the latest "bleeding edge"
technology. Give me something stable, proven and well documented and I'm
away.
I found Euphoria two years ago because I was looking for a language that
would run on DOS/Windows and Linux, had built in support for recursive
directory manipulation (walk_dir()) and when on DOS would allow direct
calls to the BIOS (dos_interrupt()). I'm sure that other languages fit
this bill (and maybe more so than Euphoria) but I found Euphoria did the
job and more. The fact that it is very well documented and easy to pick us
was bonus. The biggest bonus of course was the Eu community via this email
list.
Now IMHO the main reason Euphoria is so stable is because RDS obviously
puts each release through rigorous testing. This takes time - a lot of it
when you do it properly. Frequent new releases would mean less testing
than normal and this will lead to "less than best" testing and hence buggy
releases. I'd rather wait a year for a well tested release (2.3 an
excellent example) than have my old code break on buggy releases.
All this said I have some "wishes" myself. An unlink() function to delete
files for one and #ifdef, #endif style preprocessor directives to aid
platform independant code but I know I'll be waiting a good long while.
But that isn't a problem because for now I can code around it. An unlink()
function with appropriate calls to platform() is easy and #ifdef, #endif
can be achieved if I write my own preprocessor.
In summary change is good for some and stability is good for others (maybe
both). I guess if I don't like changes in a new version of Euphoria then
nothing would stop me declining and upgrade and staying with 2.3. Somehow
though I don't think RDS will have me making such a dramatic decision.
Everybody's milage varies - almost constantly infact
Regards,
Andy Cranston.
At 19:03 22/08/02 -0400, you wrote:
>
>Hey,
>I like Euphoria the way it is,and I know you do too,so please don't
>get me wrong,but let me tell you why I am kind of resistant to MAJOR
>changes to the language.
>1.Pointers.Though I understand them,I am the type of person who has
>enough trouble with the direct approach,let alone the indirect one,One
>of the reasons I stopped using C was because of their complexity.
>2.Loops.I have found that the while,if,for loops work for anything
>I need,and quickly too.
>
>3.The reason why I like Euphoria is because its small,fast and I can
>keep track of it.It helps me focus on my program not programming.
>4.As far as portability is concerned,we got windows,linux and now
>freebsd.Lets let the rest of the world become compatible with us
>and not vice-versa
>5.Their are some real smart people programming with it--somebody is
>going to make a game or some other popular graphics program with it
>(hopefully me) and the language will take off--guaranteed.
>6.Low price,I like that,and I don't think Robert should release his
>source code(another subject)
>7.That darn interpreter is reliable.Adding all kinds of new complexity
>could jeopardize the stability of the thing,that wouldn't be good.
>8.I'm sorry if I'm not seeing the whole picture,I really am. But
>from my standpoint I'd like to see as little change in it as possible,
>because change means that you have to adapt to more.If I ever need
>more from a language I'll find a new one,its a no brainer for me.
>There are many features I'd like to see implemented,I'd like to just
>type "Write my Program" and have it done. As in all things in life
>there is what we want\need and what actually exists,our challenge is
>to line up what we need to what actually exists.
> Once again I apologize if my opinion offends,but I think you can
>see that this is just one man's opinion. Maybe I'm wrong--probably am,
>but best of luck to you,regardless,
> Jason
>
>
>>From: christian.cuvier at education.gouv.fr
>>Reply-To: EUforum at topica.com
>>To: EUforum <EUforum at topica.com>
>>Subject: WISHLIST.TXT
>>Date: Thu, 22 Aug 2002 12:54:12 +0200
>>
>>
>>Hello, dear EUfolks !
>>
>>Here is a wish list in which I compiled everything I could think as an
>>useful enhancement for Euphoria (exchanged some mails with R. Craig on
>>this).
>>
>>By the way, wouldn't it be a good idea to have a "Plans for the future"
>>page on the website stating:
>>-what is definitely not planned as an evolution for Euphoria;
>>-what is definitely planned, possibly with a timetable ("by 12/06/02", "not
>>before 2008", whatever...)
>>- what remains in a gray area in vetween.
>>
>>This could be useful for people who spend time to build preprocessors, for
>>instance...
>>
>>Hope to submit a regular expression library next week. It is significantly
>>richer than P. Hazel's, and noncompliance with Perl standard is minimal if
>>not nil (didn't check all the specs). Its philosophy is based on C.
>>Schank's BE text editor regexp handling (very good DOS shareware, now
>>unsupported I think; registering was just for tech support and direct
>>upgrades).
>>
>>Have a nice day !
>>
>>Chris
>>
>>
>
>
>
25. Re: WISHLIST.TXT
On 0, kbochert at copper.net wrote:
>
> You wrote on 8/24/02 10:53:18 AM:
>
> >
> >I already have seperated gotos and pointers from rparse into gparse (it
> >seems
> >that rparse's method of handling variables is required in order to get
> >gotos
> >to function correctly), unforutantly the outputed code is still ugly
> >and
> >it is not 1:1 with the source code (with something like an emulated
> >goto thats
> >flat out impossible). As a compromise I'm adding code to output the
> >original
> >line numbers as comments to both rparse and gparse.
> >
>
> That might help some but I still think a preproccesor has a hard row
> to hoe here. The user still has to find the reported error in the
> preprocessed code and then translate back to what in the original
> code caused it. Its a nuisance that get worse as the preprocessor
> becomes more powerful. Even with a 1:1 preprocessor like Goo I
> found it hard to get used to.
>
> For large-scale additions, a modified interpreter seems to have
> insurmountable advantages: speed, error messages where they belong,
> complex features hidden in simple syntax and so forth.
>
> I think the best use for a preprocessor is to provide syntactic sugar
> -- new features like goto, exceptions etc. will always be problematical.
>
> Karl Bochert
>
Speed is the largest unsolvable problem wiht a preprocessor. If it were
to output pure euphorian code, then it'd be tough to speed it up. I
don't plan to
address this issue in rparse until it becomes too large a problem to be
ignored.
As for error messages, I'll make rparse smarter so it catches more
errors at
compile time, as well as writing an rparse.err file. Also, I'll work on
a
utility which will automaticly try to convert an ex.err file to a
rparse.err
file. This should make it MUCH easier to debug rparse programs.
The next release of rparse which feature red, which will have builtin
support
for all of these features. red, for rparse ed, will be the native
editor for
rparse programs. Finally, to address the biggest issue, I am willing
to take suggestions from this list for a new name.
While a modified interpreter does have many advantages, I still have
two
excuse for liking preprocessors written in pure Eu better: First, what
language
is better and easier to use than Euphoria? Second, How many modified
interpreters
run on linux?
jbrown
--
26. Re: WISHLIST.TXT
<snip>
> Juergen
>
>
> PS: I don't know, where the following text came from, and how it came
> inside your reply. Formally it looks, as if the following text which
> is quoted with ">>", was part of my previous post. This is not the
> case, nothing of the following was written by me.
>
>
> > BTW: on dubetyrant statement:
>
</snip>
It came through cut and paste, when I eventually decided to merge boyh
answers.
Chris
27. Re: WISHLIST.TXT
Rob Craig wrote:
> Since doing the FreeBSD port, I've spent a lot of
> time writing various Euphoria application programs,
> so I haven't done that much yet on Euphoria itself.
> I've also spun off the Euphoria program used to moderate
> this list into a little side business:
>
> http://www.ListFilter.com
That's interesting. I wish some other lists I am subscribed
to would use this. I just hate recieving up to 10 Korean
"hot sex" (bad word++) offers spam a day. (And also Korean
encoding seems to mess up Outlook) But I fear GNU/Linux
people won't pay even the 2 cents I wonder how many
messages per day do you drop on this list? Did this prevented "MTS"
from returning from darkness back to the world of mortals?
PS#1 I wonder whether I am in Good People :)
PS#2 "goto" should goto Bad Words :)
Martin
