Re: Garbage Collection (Real Features)
Vincent wrote:
>
> Improvements to the garbage collection system. This could mean switching from
> reference
> counting to mark/sweep, mark/compact or a copying collector. Possible benefits
> include
> faster execution and smaller size for translated code. Possible drawbacks
> include having
> to reserve more memory than is actually needed, and random noticable delays
> during
> execution while garbage is collected. Alternatively, we might simply find a
> way to
> tweak the reference counting system.
>
> clipped from: <a
> href="http://www.rapideuphoria.com/future.htm">http://www.rapideuphoria.com/future.htm</a>
>
>
>
> Robert, What do you mean by "tweaking" the reference counting system?
> How about you give us some "REAL" features for v3.0! Using UPX with EX.EXE,
> changing the GC system, 32x32 icons, etc.. offer us absolutely nothing new to
> the language
> specification. Just like the rewrite of Euphoria front-end with Euphoria
> (30/70 interpreter)
> offered us nothing, other than the PD source Euphoria, which only Matt Lewis
> and I
> have really used. Some of these are good ideas, but they do not count as
> actual features.
> All they are are internal changes and/or enhancements, NOT new features that
> we can
> use. We dont want to wait 1 to 2 years for silly internal
> changes/improvements; especially
> this time with Euphoria v3.0 (the next "major" release)!
>
> Here are some "REAL" feature ideas:
>
> * C++ style local & global namespaces
> * Current namespace system improvement (Matt's idea)
> * The use of '=' in conditional statements
> * Assignment on declaration
> * 'Continue' Interation' keyword
> * 'Repeat Current Iteration' keyword
> * 'Constant' declaration to be scoped at routine-level
> * Forward-referencing of routines
> * Forward referencing of data (variables and constants)
> * Multiple items to be on the left hand side of an assignment
> * Desequencing operator
> * Interpreter version routine
> * Return value from a function can be be ignored
> * Block commenting
> * 32 bit integers
> * 32 bit pointers
> * Char datatype
> * String datatype
> * Fixed length vectors (arrays)
> * Data type specifier of vector declarations
> * Heterogenous fixed-length vectors (structures)
> * Pass parameters by reference
> * Limited GOTO construct
> * Code blocks within routines with their own scope
> * Named loops and blocks
> * Memory mapped data (C structures/unions)
> * Expression evaluation: eval()
> * Run-time metadata access for programmers
> * Duplicated Constant Declarations
> * Display format specified at declaration time
> * Additional metadata for variables
> * Built-In routine to delete and insert elements into a sequence
> * Built-In absolute value routine
> * Specify non-contiguous elements in slices
> * Specify slice elements via a sequence
> * Specify sequence indexing and slicing on function calls
> * Specific warning ignores (without warning xxxxx,xxx,...)
> * Swap elements built-in routine
> * Insert Elements built-in routine
> * Delete Elements built-in routine
> * Assignment as an Expression
> * Extract Elements Expression
> * Case/Switch Statement
> * Dynamic variable routines
> * Macros
>
> Put a few of those on your list.
>
> BTW... you have a type O with "multi[ple" call stacks.
>
>
> Regards,
> Vincent
>
Some of the suggested features are obviously things
that are part of the core language and only RDS could
implement. Some of them however are things that the
Eu community could implement for themselves.
Obvious examples are routines that remove or insert
an element from/to a specified position in a sequence.
I would echo the concerns of one of the other respondents
to this post, about keeping the core language clean.
I personally like Euphoria because I don't need to read
a 900+ page manual to learn the language. At the same time
however, it would be great to have HashMaps, Sets, and
other kinds of cool collections available in Euphoria.
But the core language can easily be kept clean by expanding
the runtime library (a la Python or Java).
Here's my suggestion ...
Why not create a "community model" runtime library,
steered by some of the elders on this list?
Include the best user submissions in it and have
a "release fast, release often" model for its evolution.
The "community" runtime library wouldn't be that different
from the EuForum archive, except that some standardization
could be applied so that there would some continuity for
users writing applications with the "stable" release and
those pioneers looking to blaze new trails, could work
on the newest features of the "bleeding edge" version,
maturing them until they might evolve sufficiently to
become part of the stable release.
In time, features of the "community" runtime library might
be included by RDS in their own official runtime library,
so that they can benefit as well and continue to develop
the core language. If anyone thinks this unfair, consider
this ... all successful projects need a nucleus of people
at the helm and those people need to be able to devote
their time to the project if it's going to grow. Even if
Euphoria were totally Open Source, it would still have to
rely on donations and frankly the money that RDS charges
for Euphoria is at the "shareware donation" level and I
for one don't begrudge them any of it. I feel that we all
have a vested interest in seeing Euphoria grow. Those of
you who make money from developing In Euphoria will
benefit from this just as surely as RDS will. Also, just
look on the web at the endless graveyards of dead projects.
The first thing I look at when I'm trawling SourceForge,
is the last date of any activity. If the latest "news"
item is dated August 1998, adios!
I would hate to see Euphoria go this way.
And if you don't want to have your whizzy new parser be
part of the community runtime library (or, God forbid,
have RDS benefit from it) well ... just keep it to
yourself and don't submit it!
While it wouldn't address all the issues people might have
with the core language, a maintained, community runtime
library with a separate release track would answer some
of the the needs of the people on this list who would like
to see a more rapid evolution of Euphoria.
I would also point to the incredible success of Python as
a testament to the efficacy of this community model.
Any takers?
Best
Gordon
|
Not Categorized, Please Help
|
|
