Wish List
OK, as long threatened, my fairly complete and horribly long wishlist. Many
of these have been on my list for a long time - I even implemented some of
them in PP (my ancient pre-processor). Some of these have been implemented
in Pete's version of Euphoria as well.
I'm intentionally leaving out my favorite item, cross-platform
compatibility. In addition to having a common GUI, it's important that
Euphoria have a common way of creating directories, files, using protocols
(such as HTTP), etc. But these can all be added by plugging some vendor's
toolkit into Euphoria. Instead, I've concentrated on features that can only
be added by Robert by enhancing or changing the current behavior of
Euphoria.
I hope Robert has his ThickSkin(tm) on...
[ Namespaces ]-----------------------------------
Something like this:
include <filename> as <namespace> [import <proclist...>]
We've been promised that they *will* happen; I just want to throw in my 2
cents. I rather liked the way Python did it's namespaces, but depending on
the filename for the namespace's name has some problems:
- namespace collisions
- DOS 8.3 name limits
- case sensitivity
I propose seperating the filename from the namespace's name. I also think
that the code including the library should name it, not the other way
around. Pete's implementation in Peuphoria looks like this:
begin namespace <namespace>
...
end namespace
But I think this is a Bad Idea (sorry Pete!).
The 'import' keyword allows only certain routines/variables/constants to be
imported into the namespace - another idea nicked from Python. Here's a
breakdown of what I might want to do, and how the syntax *might* look.
1. I want to be able to break a file up into several files, and combine them
into the current namespace as if they all belonged to the same source file.
The keyword 'local' refers to the current namespace. This is akin to
Python's "import <namespace> *":
include file1.e as local
include file2.e as local
include file3.e as local
2. I want to be able to use a library referring to the namespace. This is
akin to Python's "import namespace":
include math.e as math
3. I want to combine two libraries into the same namespace. For example, Irv
might have published a cool math library that overlaps Jiri's, but Jiri's is
more complete. This is akin to Python's "import <namespace> [proc, proc
...]":
-- import all of jiri's routines into the math namespace
include jiri_math as math
-- but only import irv's pow, arcsin and hyp into the match namespace
include irv_math as math import pow, arcsin, hyp
4. Unlike Java and Python, Euphoria namespaces should probably not be
cumulative. Do you really want to write:
sys.math.trig.sin(x)
I reserve the right to change my mind about this, though.
[ routine_id Scope ]-----------------------------
routine_id should see items at the time that it's called, not at the time
the routine it is in was declared. Among other things, I could actually add
error checking to the routines, like this:
id = routine_id( callback )
if id = -1 then
abort_err( "Fatal: The callback %s has not been declared.", {callback}
)
end if
This becomes more important as Euphoria tries to other toolkits, like GTK+,
or any C library that wants a callback.
It would also be nice if routine_id were able to call system routines,
although I'm sure there are internal reasons why we currently can't.
[ Shorthand in Slices for length(s) ]----------
For example, something like:
s[n..end]
s[n..]
instead of:
s[n..length(s)]
There are a lot of other shorthand operators that I could suggest (take a
look in Python, for example), but this is so common one, it gets tiresome to
write.
[ Multiple Receivers on Assignments ]------------
For example:
x, y = get_mouse_position()
instead of:
tmp = get_mouse_position()
x = tmp[1]
y = tmp[2]
What's not to like about it? Even a beginner can grasp what's happening, and
it neatly completes the symmetry of functions returning sequences.
[ '=' Instead of equal() ]-----------------------
For example:
if s = "foo" then
instead of:
if equal( s, "foo" ) then
Of course, all the other relational operators should come along with it. The
only downside I can see to it is that it makes it hard to transition back
from Euphoria to C. But is there anyone (even C coders) that prefers
Euphoria's current behavior?
[ Assigment During Declarations ]-----------------
For example:
integer foo = 12, bar = 23
Less errors, clearer code. What's not to like?
[ crash_routine ]----------------------------------
For example:
crash_routine = routine_id("my_handler")
This would run in the case of fatal errors, instead of aborting. Bringing
the program to a crashing halt is fine for debugging, but the last thing I
want to have happen in an end product. Give me the power to save the user
from from run-time errors! I can't possibly catch _all_ my bugs - I somehow
even got EE to crash on me last night (and lost all my work) - and that's
been around forever. With crash_routine, I would have been able to recover,
lost nothing, and possibly even restarted.
If you are worried about people abusing this to get around the 300 line
limit, make this an 'advanced' feature.
[ shorthand for s1 = func( s1 ... ) ]-------------
For example, something like:
s.append( "foo" )
s:append( "foo" )
me.append( s, "foo" )
instead of:
s = append( s, "foo" )
It would be nice if it worked for procedures as well:
document.print()
I'm not hung up over the syntax, especially since the dot notation is
probably reserved for namespaces. Yes, it's only syntactic sugar. But I
think it's a useful syntax (Lua uses it, for example) that gets around the
"problem" of Euphoria only passing by value. I really think this would be a
Good Thing.
[ for <var> in <sequence> ]-----------------------
For example:
for name in namelist do
...
end for
Sure, it's more syntactic sugar. It's not at the top of my wish list,
either. But it would still be nice.
[ Classes ]-----------------------------------------
It had to be mentioned somewhere. 
[ routine_id Starts at Zero ]---------------------
I moved this to the bottom of my list, because I suppose that the routine_id
code is just too entrenched to change. But starting routine_id values at
zero when everything else starts at one was just a Bad Plan.
Thanks!
-- David Cuny
|
Not Categorized, Please Help
|
|
