March 2001 - Libraries

Re: Hierarchies layout
by Dylan Thurston 26 Mar '01

26 Mar '01

On Thu, Mar 22, 2001 at 10:18:52AM +0000, Malcolm Wallace wrote: > Algebra > ... > Numeric These two seem closely related to me. Perhaps they should both be under "Math"? If they are not combined, where would, say, arbitrary precision real arithmetic go? I'd also like to see some explicit guidelines for organizing the tree. Best, Dylan Thurston

1 0

RE: Lang. (was Re: Alternative hierarchy proposal)
by Simon Marlow 24 Mar '01

24 Mar '01

> 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

6 6

RE: Lang. (was Re: Alternative hierarchy proposal)
by Simon Marlow 23 Mar '01

23 Mar '01

> Simon Marlow wrote: > > > I must admit, I'm not keen on the name "Control" - it's > meaning isn't > > clear in the context of Haskell, and it sounds forced. > Let's face it, > > we're trying to find a unifying concept for a mixed bag of abstract > > libraries, and there just isn't one. > > Doesn't that very fact suggest that these libraries should /not/ be > grouped together? Perhaps, but who knows what abstract language concepts/features the Haskell community is going to come up with next? I'm keen to make sure that we're likely to have a good home for anything that comes along in the future. > > FWIW, I just took a poll of the 4 people in our office > (inc. me) and the > > vote came out unanimously in favour of calling it "Lang". > > And our office (of 2) continues to have a unanimously opposite view... > > So if these libraries really don't belong together, as you admit, we > need to find alternative homes for them. Here's one suggestion: > > Monad -> Data.Structures.Monad debatable, but I could live with it. > Exception -> System.Control.Exception ew. System currently contains libraries that communicate with the outside world and the "system" on which the program is running. It's a stretch of the imagination to put Exception in this category. > Generics -> Type.Generics hmm. Generics is more about generic code than types. > Dynamic -> Type.Dynamic ok. but if we have a Type category, folk might expect to find types in there: i.e. everything we have in Data. > Unique -> Data.Structures.Unique fine. > Concurrent -> System.Control.Concurrent > Parallel -> System.Control.Parallel dubious, for the same reasons as Exception. All these choices leave me with a slightly uneasy feeling, as if we're trying too hard to categorise things that don't fit into a particular category. Concurrency and exceptions aren't "system"-y things, in my mind they're nothing more than language features. Ok, so eventually we'd like to have a proper "home" for everything currently in the Prelude, right? Then the Prelude is just a convenient set of entities which are commonly used and therefore deemed useful to have in scope by default. Most things in the Prelude have a logical home: eg. all the numeric classes go in Num, basic data types in Data, IO in System.IO, etc. The following are left: Eq, Ord, seq, error, ($!), undefined, flip, (.), and a few others. Where do they go? Eq is neither Control nor Data, and doesn't seem to fit anywhere else in the hierarchy. For comparison, Java has "lang", but not "data". The documentatation describes "lang" as "Provides classes that are fundamental to the design of the Java programming language.", which is suitably ambiguous. Cheers, Simon PS. I took a poll of the office next door (i.e. Simon P.J.), and he suggested "Control" or "Effects".

1 0

Re: Hierarchy layout
by Ashley Yakeley 22 Mar '01

22 Mar '01

At 2001-03-22 02:18, Malcolm Wallace wrote: >Structures etc. Trivial point, but I think sticking to singular and "root" words would be helpful. -- Ashley Yakeley, Seattle WA

1 0

Hierarchy layout
by Malcolm Wallace 22 Mar '01

22 Mar '01

Modulo some discussion about the role of Lang, I think we have come to a reasonable agreement about the general rules for constructing a library hierarchy layout. To help further discussions, I've pulled together lots of the ideas expressed about individual modules, their names, and their locations. Here is a complete revised hierarchy tree proposal. It is largely based on Simon's proposal, modified in the light of all the comments on the list, with a few extra tweaks of my own. I have tried to spell names out in full rather than use abbreviations, but in some cases, it was clearer to rename a module altogether than to expand an abbreviation. Regards, Malcolm ------------ Prelude -- Haskell98 Prelude ShowFunctions -- small 'obvious' additions to the Prelude Data Bits Char -- H98 Complex -- H98 Either -- H98 Int Maybe -- H98 List -- H98 PackedString Ratio -- H98 Word IORef STRef Binary -- Haskell binary I/O Digest MD5 ... -- others (CRC ?) Structures -- top-level? or should it be Data.Structures? Array -- Haskell 98 Array library Overloaded -- (opt) IArray - GHC's overloaded arr libs Mutable -- (opt) MArray IO -- mutable arrays in the IO/ST monads ST Trees AVL RedBlack BTree Queue Bankers FIFO Collection Graphs FiniteMap Set Memo -- (opt) Unique Monad -- Haskell 98 Monad library ST -- ST defaults to Strict variant? Strict -- renaming for ST Lazy -- renaming for LazyST Either -- monad libraries State etc. Algebra DomainConstructor -- formerly DoCon Geometric -- formerly BasGeomAlg Database MySQL PostgreSQL ODBC Debug Trace Quickcheck Observe -- choose a default amongst the variants Textual -- Andy Gill's release 1 ToXmlFile -- Andy Gill's XML browser variant GHood -- Claus Reinke's animated variant Edison -- (opt, uses multi-param type classes) Prelude -- large self-contained packages should have Collection -- their own hierarchy? Like a vendor branch. Queue -- Or should the whole Edison tree be placed ... -- under [Data.]Structures? FileFormat -- 'Codec' might be a more accurate name? Compression Gzip Bzip2 Graphics Jpeg Ppm Png Audio Wav Mp3 Video Mpeg QuickTime Avi Foreign Ptr StablePtr ForeignPtr -- rename to FinalisedPtr? to void confusion with Foreign.Ptr Storable Marshal Alloc Array Errors Utils C Types Errors Strings Graphics UI Gtk FranTk Fudgets CleanIO Drawing HOpenGL Format -- use FileFormat.Graphics instead Language Haskell -- hslibs/hssource Syntax Abstract Core Lexer Parser Pretty Python? C? Numeric DSP FastFourierTransform Noise Oscillator Network -- won't need to be optional (will use FFI only) Socket -- redesign (merge w/ SocketPrim) BSD -- remove?? URL CGI -- one in hslibs is ok? System IO -- H98 + IOExts - IOArray - IORef Directory Select Console GetOpt Readline Posix -- redesigned, use FFI only IO -- there was a suggestion to split Posix into Process -- separate chunks like IO + Process Win32 -- the full win32 operating system API Mem -- rename from cryptic 'GC' WeakPointer -- (opt) StableName -- (opt) Time -- H98 + extensions Locale -- H98 CPUTime -- H98 -- split H98 "System" (too generic) into: Exit Environment (getArgs, getProgName, getEnv ...) Control Exception -- (opt) Concurrent -- as hslibs/concurrent CVar -- Most of these type names are cryptic Chan MVar Merge QSem QSemN SampleVar Semaphore Parallel -- as hslibs/concurrent/Parallel Strategies Text Regex -- previously RegexString PrettyPrinter -- default (HughesPJ?) HughesPJ Wadler ... Html -- HTML combinator lib Xml Combinators Parse Pretty Types ParserCombinators -- no default Parsec Hutton_Meijer ... Type Generics -- (opt) Dynamic -- (opt) GHC Primitives UnboxedTypes ... Nhc Stuff ------------

1 0

RE: Lang. (was Re: Alternative hierarchy proposal)
by Simon Marlow 22 Mar '01

22 Mar '01

Malcolm writes: > 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 I must admit, I'm not keen on the name "Control" - it's meaning isn't clear in the context of Haskell, and it sounds forced. Let's face it, we're trying to find a unifying concept for a mixed bag of abstract libraries, and there just isn't one. FWIW, I just took a poll of the 4 people in our office (inc. me) and the vote came out unanimously in favour of calling it "Lang". The unifying concept is nothing more specific than "support for language features or concepts that don't belong in Data". It's not perfect, but I'd be happy with it. Cheers, Simon

2 1

Re: Process issues (was Re: Lang)
by Ashley Yakeley 20 Mar '01

20 Mar '01

At 2001-03-14 23:55, Marcin 'Qrczak' Kowalczyk wrote: >> Should it be required of source files that they explicitly import >> the Prelude? > >Please no. I treat Prelude like elements of syntactic sugar - >something available by default, because used almost everywhere. >If it's written everywhere, it should not be explicit. If the Prelude is to be assembled from modules in the library, we need a way of specifying whether or not a given file imports the Prelude. The simplist method would be use of "import Prelude". I don't see it as much more onerous than "#include <stdlib.h>" in a C file. -- Ashley Yakeley, Seattle WA

2 1

RE: Process issues (was Re: Lang)
by Simon Marlow 16 Mar '01

16 Mar '01

> 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. Again, I'm wary of getting into this discussion before we've sorted out some of the other issues, but I'd advocate keeping the meta-information in the source code. I have a vision of a single source tree used by all the compilers, kept in a CVS repo, with documentation generated by HaskellDoc, and meta-information in the source and hence also the docs. Cheers, Simon

2 1

RE: Process issues (was Re: Lang)
by Ashley Yakeley 15 Mar '01

15 Mar '01

At 2001-03-14 02:54, Simon Marlow wrote: >In the long term, I think it would be a good idea to redesign the >Prelude to be more minimal. But for the time being, we should provide >the Haskell98 Prelude exactly as-is but place it in the new namespace >somewhere. Should it be required of source files that they explicitly import the Prelude? -- Ashley Yakeley, Seattle WA

2 1

RE: Process issues (was Re: Lang)
by Simon Marlow 14 Mar '01

14 Mar '01

> At 2001-03-13 09:04, Dylan Thurston wrote: > > >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? > > Is a Prelude even necessary? Might it not be better to import > what you > want explicitly? In the long term, I think it would be a good idea to redesign the Prelude to be more minimal. But for the time being, we should provide the Haskell98 Prelude exactly as-is but place it in the new namespace somewhere. Cheers, Simon

1 0