Lambda the Ultimate

The syntax of Dylan is quite different than the C family of languages but I think I could get used to it without too much pain. The dispatch mechanism is unlike most other Object Oriented Programming languages - similar to CLOS and Cecil. The difference is actuality one of it's main drawing powers, in that multiple dispatch comes right out of the box. Bottom line is that the Visitor Pattern that gets convoluted in many other OO languages, is downright easy in Dylan.

On the downside, I can't understand how a language can be designed in this day and age around the concepts of modules, without ever actually specifying the syntax for exporting and importing definitions. Yes, the various Dylan implementations do provide a mechanism, but it's vendor specific. The format for the export and library header files is quite different between the two implementations that I used: Functional Objects and Gwydion. And the documentation on the subject of export files is not what I consider up to snuff.

Other than my frustration with the import/export files, I find the language to be quite good for Object Oriented Programming. Maybe I'll get around to figure the in's and out's of import and exporting, but till then it's kind of caused me grief in breaking the modules and definitions along the boundaries that I'm trying to achieve.

(Can't hang around - only connected for a minute; having problems with firewalls, but will be back posting in a day or two)

One man's pattern is another man's language idiom

What a sexist remark! But how would you translate it into non-sexist IDIOMATIC English? 'Person' just destroys the way it sounds.

However, I find this in the DRM:

Some languages have module systems with distinct support for exporting variables, functions, types, and classes. Dylan modules operate only on bindings. Because functions and classes are commonly named by bindings, access to them is controlled by controlling access to the bindings that name them. By exporting the binding naming a class or function, a program has effectively exported the class or function. If the binding is not exported, then the class or function is effectively private.[1] (chapter 3)

Can you elaborate on your statement? What is exactly the problem you see with the Dylan approach? (I don't know the language, and was surprised at what you said, so I read a bit. Now I am even more confused...)

Can you elaborate on your statement? What is exactly the problem you see with the Dylan approach? (I don't know the language, and was surprised at what you said, so I read a bit. Now I am even more confused...)

First, I misspoke about the standardization of modules. The only thing that's not standardized is the make file - this would be the .lid file in Gwydion or the .hdp in FunO. Considering that few languages really specify the entirety of the make process, I don't think it's a strike against the language.

As to what I am trying to do: There are two types of statements used for the export definitions:

   define library what-ever-library 
      use dylan;
      export what-ever-module;
   end library what-ever-library;


   define module what-ever-module
      use dylan;
      export <what-ever-class>;
      export what-ever-method;
end module what-ever-module;

If I put the define library and all define modules into a single source file onto itself, everything works fine. However, what I want is the capability to be able to add a class without touching the file that contains the module definitions. In other words, I'd rather have the define module statements be in the same file that the module is being defined (similar to the way Haskell and Erlang define their exports) or have a seperate interface file (similar to Modula-3 interface files).

What is not clear from the documentation is whether there should be any limitations on the placement of the library and module definitions. I don't see why they particularly require a file of their own.

Which reminds me of a problem that I see in Meyer's use of privileges within Eiffel. The class file itself must determine what can and can not be modified by other routines, going as far as allowing the class to determine what classes have rights to specific features. The problem, though, is that this requires the class to be made aware of what subclasses are doing with the base class. So you've got implicit knowledge within the base class that is telling the subclasses how to behave. Which means the base class must have some foresight on how the features are going to be used by the descedents.

To make a long story short, I think the stipulation of access rights within the base class (techniques used by Eiffel, Java, C#, and C++) violates the Open-Closed Principle. If a base class is not declared with privileges in a way that is necessary for the base class extension, the base class will have to be modified for the priviledge changes.

An alternative method that I've seen is in Modula-3, where the privileges to the class are defined in an external interface file. The real beauty of this approach is that a single class can have more than a single interface. If the current privileges don't match the requirements, you can add a new interface file without touching the current code.

Ok, so this got off track. Dylan only allows one definition per module. The only thing I'm trying to figure out is where that statement can be placed. But the idea of exports is something fresh on my mind since I'm having trouble along these lines.

In general public inheritance of interfaces is the most straightforward and safe use of inheritance. But other uses have their uses too (pun intended).

As to you favoring interface definitions decoupled from the component. This raises many questions. In a sense you want a meta-language, on top of the programming language. But if so, why not stick to things like CORBA/COM etc. which are REALLY outside the language? How deep into the language should these (software engineering) issues be integrated?

In my Ada book I try to analyze various things you may want to do with interfaces (and their corresponding implementations) and how they can be implemented using the Ada approach and tools. Not all the things you may do in an "interface defintion" are safe - and so some should not be inside a good programming language. On the other hand the mainstream tools (information hiding, layering, inheritance, composition etc.) solve most of the problems quite will.

I still feel comfortable with the one spec/one implementation apporahc for modules (packages in Ada) and the use of inheritance to provide different implementations to the same (possible abstract) inetrface. But I am also pretty sure this is not the last word on these issues.

One more note along these lines: The privileges and rights required for subclassing are of a different concern than those use for composition. For the most part, I think an object should pretty well control it's destiny when used directly through composition. However, the concerns of inheritance are slightly different, in that we know that the subclass is either specializing behavior or generalizing it further. Though the base class should always define the message protocols (methods & functions), the subclass should always be in charge of how it wants to implement those messages.

As a side note, I did notice in the C# standard that they fixed a slight quirk in Java. Specifically, Java does not allow you to give access to a subclass but deny access from composition. A method declared 'protected' in Java is available to both subclasses and any other class within the package. They originally had 'private protected' in version 1.0 but it no longer works.

And while I'm talking about subclassing, I mind as well get one thing else off my mind: Final methods and classes are bad for re-usability. Ok, so they're necessary for optimization purposes, but they break any possibility of subclassing or refinement of behavior. What I wouldn't give to have class categories (like in Objective-C) in the Java language.

Oh well, enuf griping for one night. My Dylan stuff is coming along pretty good, but I really need to go get a book. The Dylan Reference Manual is a bit too terse for my tastes.