RE: Lang. (was Re: Alternative hierarchy proposal)
Simon Marlow wrote:
I disagree. Lang (or Language if you like, or HaskellLanguageFeatures) is a *semantic* category. It contains libraries which provide access to language features.
Are you saying that there are language features which cannot be accessed without these libraries?
but in most cases it's obvious what belongs in Lang, and that's the main thing.
That's just the trouble: I don't find the contents of Lang to be obvious at all. I simply don't see the semantic relationship between the various modules. If I, as a Haskell language implementor, have difficulty understanding it, I'm sure other people will too.
Ok, it was wrong to assume that because it was obvious to me it was also obvious to everyone else :-) I'll try an alternative. How about this: - Foreign moves to the top level, - Array moves to Data.Structures.Array (Lang was the wrong place for it, on reflection). I'm not sure where to put the rest of the contents of Lang, it seems to me that we need somewhere to put libraries that provide access to, or support for, language features that don't belong in Data. For example: Exceptions, Monads, Dynamic, etc. Where do these go in your proposal?
On the other hand, Haskell in your proposal isn't a semantic category. The similarity between the contents seems to be in name only: it's like saying that "Biography" and "Biology" books belong on the same shelf because they both begin with "Bio".
Well, I disagree completely. I proposed "Haskell." precisely because it /is/ a semantic category, in contrast to "Lang." But that's just my view. Both you and Marcin don't see the connection, so I'll happily retract that part of my layout proposal, and search for an even better categorisation.
Sorry, that comment was a bit blunt (it was Monday morning :). I'll try to be more specific: the trouble is that the Haskell.Plus hierarchy doesn't group libraries by functionality, it groups them by status (language extensions). And Haskell.Language doesn't have anything in common with Haskell.Plus functionality-wise.
I understand. I'm even beginning to shift my point of view towards yours. But there remains a difficulty. What if two people develop similar extensions, but with different syntax/semantics, each in a different compiler?
Either: - neither library gets in until they agree a common interface, or - both libraries get in, with different names so that we can experiment with them before deciding on a unified interface. Like Pretty.HugesPJ, Pretty.UU etc. I'd rather wait until we've pinned down the hierarchy before discussing the process for accepting new libraries, but I guess to a certain extent the issues are interrelated. Briefly, what I had in mind is: each module in the hierarchy has a status, ranging from experimental to standard. The closer to "standard", the less likely the interface is to change. The hierarchy as a whole would need a version number, so that applications can conditionally compile code for changing libraries if they need to. In addition to standard/experimental there needs to be portable/non-portable for libraries that depend on or provide language extensions. A "standard" library would only be able to depend on certain extensions (eg. FFI and module-namespace only). Cheers, Simon
I'll try an alternative. How about this:
- Foreign moves to the top level,
- Array moves to Data.Structures.Array (Lang was the wrong place for it, on reflection).
I'm not sure where to put the rest of the contents of Lang, it seems to me that we need somewhere to put libraries that provide access to, or support for, language features that don't belong in Data. For example: Exceptions, Monads, Dynamic, etc. Where do these go in your proposal?
Right. I'm reasonably happy for Foreign to move to the top level. Array always did belong in Data.Structures - now you see why I was confused about Lang! I've had a hard think about what remains in Lang now. For these: Monad Exception Generics Dynamic Unique and also the following that aren't in Lang: Concurrent Parallel as far as I can see, the common unifying concept is that of "Control Structure" - or the closest that functional languages get to it. It isn't quite data structures (although Monads might be that), but it is more correctly the idea of structuring computations. I don't think there is really a simple term for the concept, since it covers such a wide range of structuring mechanisms, but "control structure" is the best I can come up with for now. How does the "Control." hierarchy sound? Control Monad Exception Generics Dynamic Unique Concurrent Parallel That just leaves Memo and ShowFunctions in Lang. I would guess Memo really ought to be in Data.Structures.Memo. And perhaps Prelude.ShowFunctions is the right place for that one - in the sense that it is something missing from the standard prelude that one might expect to be there? Ok, now I've de-populated Lang, I want to re-use it for real language-related things. :-) Language C Python Java ML Haskell Parse TypeCheck And maybe Foreign really does belong under this /new/ Language hierarchy.... Regards, Malcolm
Malcolm Wallace wrote (on 13-03-01 15:00 +0000):
I've had a hard think about what remains in Lang now. For these:
Monad Exception Generics Dynamic Unique
and also the following that aren't in Lang:
Concurrent Parallel
as far as I can see, the common unifying concept is that of "Control Structure" - or the closest that functional languages get to it.
I generally agree with Marcin's categorizing criteria, but I don't think there is any a priori reason to expect that these modules should be related in _any_ way other than by the fact that they are extensions (except Monad and Unique). Maybe there is something Control-like about them, but honestly it seems forced to me. For example, I think Dynamic and Generics (again: why is only one plural?!) are sort of type related, so I might argue with equal confidence that they belong in a Types subtree. If you really want to be faithful to Marcin's scheme, then they should probably go at the top-level, but I don't think that would be a good idea. Maybe we should just accept that they are only really related by the fact that they are extensions and put them in an Extensions or Miscellaneous subtree or something. These things are too abstract and complex for us to expect to find a reasonable place for them within a simple tree structure. BTW, I think Monad should go in Data.Structure. And Unique too, if it is the GHC unique-name module I'm thinking of. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379
Tue, 13 Mar 2001 15:00:27 +0000, Malcolm Wallace
Control Monad Exception Generics Dynamic Unique Concurrent Parallel
IMHO Monad (these are several modules), Exception, Concurrent and Parallel indeed are all about the same thing: the order of computation, program flow or control flow, imperativeness. If not Control, maybe Execution or Computation. Unique can perhaps be there too. This is (ab)using IO as a state monad. Generics and Dynamic don't fit. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
I'll try to be more specific: the trouble is that the Haskell.Plus hierarchy doesn't group libraries by functionality, it groups them by status (language extensions). And Haskell.Language doesn't have anything in common with Haskell.Plus functionality-wise.
Ok, I acknowledge that. I think we seem to be gradually coming to a consensus on Marcin's point - that the functionality of a library should be paramount in the naming scheme, regardless of implementation, standardness, portability, etc. This is good.
Briefly, what I had in mind is: each module in the hierarchy has a status, ranging from experimental to standard. The closer to "standard", the less likely the interface is to change. The hierarchy as a whole would need a version number, so that applications can conditionally compile code for changing libraries if they need to.
In addition to standard/experimental there needs to be portable/non-portable for libraries that depend on or provide language extensions. A "standard" library would only be able to depend on certain extensions (eg. FFI and module-namespace only).
This seems reasonable in principle. There are quite a few attributes of each library module that we need to know, quite separate from the actual name and source code. Again, it begs the question of how this meta-information will be maintained. One common database for all Haskell compilers/interpreters would be ideal. Sounds like about the right size for a small student project actually.... Has anyone got any small students? :-) Regards, Malcolm
On Tue, 13 Mar 2001, Malcolm Wallace wrote:
Ok, I acknowledge that. I think we seem to be gradually coming to a consensus on Marcin's point - that the functionality of a library should be paramount in the naming scheme, regardless of implementation, standardness, portability, etc. This is good.
Just to add my vote to the direction everything is going now: I am also in the opinion that the user's perspective should be of the primary consideration. Standardness, portability, quality are kind of extra scores, which could be stressed in a presentation layer of database of modules. For example, some kind of a standard color scheme could be used to quickly inform the user about those extra attributes of the module hierarchy. As I understand, the Std/ NonStd classification has been abandoned. That's good, because one does not need to move modules around when promoting them from the non-standard to the standard status; all one needs to do is to change the module attribute - not its position within the hierarchy. Readability of the module hierarchy is important too and I support the "no abbreviations" proposal, as voiced by Malcolm. Good job guys! Jan
On Tue, Mar 13, 2001 at 03:18:32PM +0000, Malcolm Wallace wrote:
Ok, I acknowledge that. I think we seem to be gradually coming to a consensus on Marcin's point - that the functionality of a library should be paramount in the naming scheme, regardless of implementation, standardness, portability, etc. This is good.
With the exception of the Prelude, right? --Dylan Thurston
participants (6)
-
Dylan Thurston -
Frank Atanassow -
Jan Skibinski -
Malcolm Wallace -
qrczak＠knm.org.pl -
Simon Marlow