[Prev][Next][Index][Thread]

Re: Some Dylan improvements

In article <38E1B578.BC05AD4E@cup.hp.com>, eric_gouriou@pobox.com wrote:

>  Proposed changes (more comments below):
> A) specify a naming convention for libraries

Yes.  This is one of the good things about Java, even if it's only sugar
(which I'm not sure is true, given the way Java implementations use nested
diretories to mirror the names).

> B) add a way to specify a module interface beyond mere names

Yes, *if* the compiler checks that it is correct.  If this area was played
with I'd like to see language support for pre-/post-conditions as well.

> C) add #nil to the language

NO.

>  false-or(<my-type>) is not clean and is inadequate when
> #f is an instance of <my-type>.

Which means only <boolean> or type-union(<boolean>, ...).

All your suggested uses are *exactly* what #f is for now.  What you're
suggesting is really to rename #f to #nil, which is at once barely an
improvement and will break every existing program.
If you really want to be able to express (true, false, don't-know) then I
suggest you use your own symbols instead of <boolean>.

> Another problem would be to decide if #nil is true or false ?

Only false makes sense, but in that case it is nearly indistinguishable
from #f and practically adds overhead to *every* conditional test, which
presently only needs to check for equal to or not equal to address-of(the
#f object).


> D) move .lid files to an XML format
>  Enough said ?

Well, actually, I don't really understand the advantage, other than
buzzword-compliance.


> E) add <C-int32> <C-uint32>, etc. to the C-FFI

Yes.


> F) standardize FO procedural macros (the #foo:"..." proposal) 

Yes.


> G) standardize a way to do conditional compilation (based on F?)

What is there here that can't be done with macros on the one hand or if()
statements based on compile-time constants on the other hand?


> 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.

Not if the $unsupplied object is not exported from the module.


> I) get size() to return an integer or signal an error on
>    infinite size collections

This is consistently the nastiest performance problem I see in d2c code as
well.  I'd assumed that maybe d2c just wasn't smart enough yet, especially
since element() so often gets nicely optomised.  But maybe you're correct.

-- Bruce
References: