[Prev][Next][Index][Thread]
Some Dylan improvements
Hello,
Following the module/library discussion, I would expose to the
community some ideas I have on how Dylan could be improved.
My goal is to evaluate the amount of support each one of those
ideas would find among the community. I certainly do not expect
to see any of those changes appearing in FD 2.0 (or even 2.x),
nor do I expect GD to implement those before an agreement is
reached.
Proposed changes (more comments below):
A) specify a naming convention for libraries
B) add a way to specify a module interface beyond mere names
C) add #nil to the language
D) move .lid files to an XML format
E) add <C-int32> <C-uint32>, etc. to the C-FFI
F) standardize FO procedural macros (the #foo:"..." proposal)
G) standardize a way to do conditional compilation (based on F?)
H) robust argument-supplied?
I) get size() to return an integer or signal an error on
infinite size collections
Comments:
-----------------
A) specify a naming convention for libraries
For example:
Standard libraries:
Dylan
IO
DUIM
Environment-specific libraries:
Fun-o.DOOD
Gwydion.internationalization
ISV-provided libraries:
HP.e-speak.server
Oracle.ddbc.objects
Apple.Aqua-FFI
Individual-provided libraries:
john_smith..project.gtk-FFI
linus_torvald.kernel.internals ( :-) )
-----------------
B) add a way to specify a module interface beyond mere names
That has just been suggested by Hugh for performance reasons.
I would also like to see it for "documentation" purposes,
ie being able to use a library/module without opening the source
file.
define module foo
...
export
class <bar> (<object>),
method do-bar(<bar>, <sequence>),
method nice-bar? (<bar>),
macro with-bar,
constant $default-bar :: <bar>,
variable *last-bar* :: <bar>
...
You get the idea.
-----------------
C) add #nil to the language
false-or(<my-type>) is not clean and is inadequate when
#f is an instance of <my-type>.
I would like to have #nil for those times where you want
to express that nothing is there.
Then replace false-or with nil-or.
Provide a nil?() macro (expands to == #nil)
I do not want #nil to be equivalent to the C NULL of to Java's null.
I only want #nil to derive from <nil> or similar, itself a sealed
class heriting from <object>.
I do not believe that the performance impact would be significant
for GD, but adding another "special object" may be difficult for
the FO runtime.
Another problem would be to decide if #nil is true of false ?
Should the conditional expressions be forced to have a <boolean>
type ? (I vote in favor of strict <boolean> checking, but only if
performance does not suffer too much in practice).
Then how should the operators & and | be (re-)specified ?
-----------------
D) move .lid files to an XML format
Enough said ?
Maybe expand to .lid format to include more of the .hdp
information ?
-----------------
E) add <C-int32> <C-uint32>, etc. to the C-FFI
Those days a lot of well-programmed interfaces use
the C types defined in inttypes.h or stdints.h (C99).
The common types are intN_t and uintN_t, where N represent
a bit size (8, 16, 32, 64, etc.).
It would be good to have the corresponding types available
in the C-FFI.
Of course those types can just be aliases for the "real"
underlying C types, <C-int>, <C-long>, etc.
(I fact I have already done this once).
It would still be good to have this provided by the environment
(especially if/when the environments allow us to choose
between 32 and 64bits models and/or multiple compilation
targets)
-----------------
F) standardize FO procedural macros (the #foo:"..." proposal)
I'd like to see FO document it's macro extensions and offer
them for standardization.
Having them as compiler extensions would be a very good
first step. Ultimately a fairly generic procedural macro
capability would be perfect.
-----------------
G) standardize a way to do conditional compilation (based on F?)
Ok, conditional compilation sucks, but let's face it, it
is still needed. Dylan does not have Java portability goals
and anyway implementing low-level libraries will always require
quite a bit of platform-specific code. I prefer to see this
code in Dylan than in a C adaptation layer.
#if:( defined?(#"DEBUG") & defined?(#"IA-64"))
...
#elseif:( defined?(#"PA-RISC"))
...
#endif
Of course, if we are to define this, we'd better get it right.
So it may be good to force the libraries to declare which variables
they depend on (in the .lid or even in the language). Then
the compiler can present a decent UI to choose the different
build flavors.
I prefer an "in-language" solution rather than using a pre-processor.
Dylan should be good enough to handle this cleanly.
-----------------
H) robust argument-supplied?
It would be good to resolve the $unsupplied hack in a clean way.
$unsupplied cannot work reliably as the client of a method is
always free to use $unsupplied as an argument.
What would be good would be to specify an argument as maybe
supplied with the given type or unsupplied.
Then the access to the argument should be checked by the compiler
as in the case of a slot access. Ie an access to a not supplied argument
should signal an <error>.
In particular, a function call using the argument should be
considered as an access to the argument. (no propagation of
unsupplied arguments).
define method foo (x :: <bar>, y :: <baz>,
#key fast? :: unsupplied-or(<boolean>))
let quick? = argument-supplied?(fast?) & fast?;
...
end foo;
OK, bad example, as the current default value is #f, ie exactly
what Dylan provides now. But I trust you to find better examples,
or I can do it if you want.
-----------------
I) get size() to return an integer or signal an error on
infinite size collections
size() seems to be a performance problem in my code, as it
is very difficult for the compiler (FO) to know that the
result is almost always an <integer> and not #f.
I would rather see size() signal an exception when an abnormal
size (infinite or unknown) is required.
-----------------
I await comments eagerly - Eric
--
Eric Gouriou eric_gouriou@pobox.com
Follow-Ups: