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--
|
Not Categorized, Please Help
|
|
