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

Re: Some Dylan improvements

Eric Gouriou <eric_gouriou@cup.hp.com> writes:

> A) specify a naming convention for libraries

It's probably a good idea to prevent clashes. I'm not sure it's
possible that many people will stick to it though.

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

Would it be possible for the compiler to infer these type
specifications? By putting that stuff in the module section, wouldn't
it be just a duplication of what is already there?

> I would also like to see it for "documentation" purposes, ie being
> able to use a library/module without opening the source file.

I use the class browser to find the information out when using FD. I
see your point though when just working with a text editor - or with
an implementation with no browser. I just don't like the idea of
duplicating everything and changing it in two places when I change
things. 

But this may be a reflection of my personal Dylan programming style
which tends to be not declaring types in methods until late in the
development process - if at all.

>    method do-bar(<bar>, <sequence>),

'method' might not be a good choice as it's not methods that are being
exported, but generic functions.

> D) move .lid files to an XML format

The format of the .lid files follows the same keyword convention as
the .dylan source files. Perhaps another optional import format using
.XML instead of changing .lid files? What are the advantages of going
with XML though?

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

What is the #foo:"..." proposal?

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

It may be possible to factor out the different code for the compilers
in seperate .dylan files, and have different .lid files for the
implementations, each .lid pulling in the correct file for the
implementation. Unfortunately this is a pain - I've done it for some
of the GD libraries so I can use them in FD and it complicates things
somewhat.

There is the possibility of using 'if' on constants and having the
compiler optimise out the branches not used - but this won't work for
code that is syntactically incorrect for an implementation - like the
destructuring-let macro discussed recently on the gd list.

One small thing that I'd like to see is a way of accessing
class/each-subclass slots without having to have an instance of that
class. For some discussion on this last year have a look at the
article http://www.deja.com/article/462244248 and others in the
thread.

In a nutshell, the problem is demonstrated with something like Andy's
singleton-class:

---------------------8<--------------
define class <singleton-class> (<object>)
  each-subclass slot singleton-instance :: 
      false-or(subclass(<singleton-class>)) = #f;
end class;

define method make
  (class :: subclass(<singleton-class>), #key)
=> (object :: <singleton-class>)
  class.singleton-instance  // not valid Dylan here
    |begin
       class.singleton-instance := next-method()
     end
end;

define class <my-class> (<singleton-class>)
end class <my-class>;
---------------------8<--------------

But in Dylan you can't access the singleton-instance slot without
having an instance of the class to call it - but we want to know if
there is anything in the slot to know whether to make an instance of
the class. To work around it I did:

---------------------8<--------------
// An implementation of the singleton pattern - based on example
// posted to comp.lang.dylan by Andy Armstrong.

define constant *singleton-instances* = make(<table>);

define open abstract class <singleton-class> (<object>)
//  each-subclass slot
//    singleton-instance :: 
        false-or(subclass(<singleton-class>)) = #f;
end class <singleton-class>;

define method make ( class :: subclass(<singleton-class>), #key )
 => (object :: <singleton-class>)
  element(*singleton-instances*, class, default: #f) 
    | begin
        *singleton-instances*[class] := next-method()
      end
end method make;
---------------------8<--------------

It's not really a problem I guess, but it just seems nicer to be able
to use each-subclass. And it mirrors the way static methods/variables
work in some languages.

Personally, I'd like to see more implementations of the current Dylan
spec on multiple platforms and libraries of useful code available than
lots of language tweaking.

Chris.
-- 
http://www.double.co.nz/dylan
Follow-Ups: References: