May 2001 - Libraries - Haskell.org

RE: The next step
by Simon Marlow 29 May '01

29 May '01

> Don't libraries need their own build system anyway if they > are to be portable? I imagined putting the standard libraries in a single source repository. By the "standard libraries", I mean loosely speaking those libraries which are going to be distributed with most compilers (i.e. like the current hslibs setup). The libraries could have a standalone build system, but at least for GHC this would mean duplicating most of the fptools build system in the libraries tree (because we need to support ways, GHCi .o files, DLLs, split object files etc. etc.), but NHC and Hugs require a much more minimal build system. > How do we want to handle libraries (eg, Gtk+Haskell) that > > * are in a different repository (Gnome repository) and/or > > * need special tools (C->Haskell)? I wasn't planning to do anything differently to the way we have it now, except that Gtk+Haskell gets allocated a place in the hierarchy. It can still be distributed separately and have a different license - and for GHC at least you'll have to give extra flags such as '-package gtk' in order to be able to import Graphics.UI.Gtk. Cheers, Simon

2 1

RE: The next step
by Manuel M. T. Chakravarty 29 May '01

29 May '01

"Steinitz, Dominic J" <Dominic.J.Steinitz(a)BritishAirways.com> wrote, > Can someone explain what licenses are commonly avaible and > what they mean or point me at some references? Here is GNU's take of the license landscape: http://www.gnu.org/philosophy/license-list.html And that of the OSI (Open Source Initiative): http://www.opensource.org/licenses/index.html Hope that helps, Manuel

1 0

RE: The next step
by Simon Marlow 28 May '01

28 May '01

Frank Atanassow writes: > Some people don't see it that way. They would say that the > GPL is the _less_ > restrictive license because it ensures that everybody > benefits (equally) from > everybody else's improvements. From that perspective, > companies benefit also > since they may use and improve the code, provided they > "publish" it. Will they > lose some potential revenue that way? Possibly. As I understand it, the situation is worse than that. The mere existence of GPL code poses a threat to commercial software: if a programmer happens to read some GPL code and then goes on to use similar techniques in proprietary code, the owner of the proprietary code is in a legally difficult position. So not only is a programmer working on GPL code not generating any revenue, they are potentially threatening the intellectual property that the company already owns. Better all round for them just to avoid GPL code altogether. Cheers, Simon

2 1

RE: The next step
by Simon Marlow 28 May '01

28 May '01

> -----Original Message----- > From: Steinitz, Dominic J > [mailto:Dominic.J.Steinitz@BritishAirways.com] > Sent: Monday, May 28, 2001 2:06 PM > To: Simon Marlow > Cc: chak; libraries > Subject: RE: The next step > > > Can someone explain what licenses are commonly avaible and > what they mean or point me at some references? > > Dominic. > > -------------------------------------------------------------- > ----------------------------------- > 21st century air travel http://www.britishairways.com >

1 0

RE: The next step
by Steinitz, Dominic J 28 May '01

28 May '01

Can someone explain what licenses are commonly avaible and what they mean or point me at some references? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

The next step
by Simon Marlow 26 May '01

26 May '01

Hi folks, I'd like to propose a way forward for developing the library collection. Apologies for the huge message ... ;-) The guiding principle I think we should use is one of "devolved responsibility": that is, rather than choose a committee of people to oversee the project, we let the community at large do it. Individual libraries will have their own keepers: either authors or a small group of interested individuals. Having said that, there will occasionally be a need for a way to resolve disputes and a driving force to keep the project headed in the right direction. Therefore I suggest we start with a single representative from each compiler camp (to avoid any drift toward one particular implementation and try to keep us on the straight and narrow portability-wise). Initially this would be Malcolm, myself, and someone from the Hugs camp yet to be decided. Our primary responsibilities would be - assigning control of libraries to individuals, - allocating places in the "managed" portion of the hierarchy - advising on style and portability policies, developing and maintaining style and portability guidelines - trying to keep things consistent across the hierarchy The next step is to write a document setting out the conventions and guidelines for the library collection. There's a rough outline below, which mentions several points we still need to resolve. - Haskell Libraries Document --------------- - License (specify?) - Hierarchy design guidelines - Hierarchy layout guidelines/policy. - Allocation of top-level categories: - "managed" categories - domain names or email addresses - Naming policy for modules - abbreviate / don't abbreviate (Network vs. Net) - pluralise / don't pluralise (Generics, Dynamic) - follows name of type/class or describes functionality - capitalization of acronyms - Library status - experimental/stable - compiler-specific/portable. - Portability considerations - Library ownership - responsibilities of library owner - Documentation - HaskellDoc? - Versioning - of the whole collection - of individual modules (can a module exist with several versions simultaneously, can you import a specific version?) - Haskell library style and naming conventions - function/type/class naming guidelines - assume qualified import? (IORef.new vs. newIORef) - for a module which provides an instance, should it also export non-overloaded versions of the methods (like Edison)? - standard module header - copyright - status (stable, experimental) - portability (standard, specific to certain compilers) - Testing policy - libraries should come with a test suite. ------------------------------- Comments and opinions on any of the issues from the list above are welcome... here are a couple of thoughts off the top of my head: - License: I'd prefer to specify a BSD-style (without advertising clause) license, with copyright on individual files remaining with the authors. GPL code creates particular problems for us here, so I'm keen to avoid it if possible. - Let's aim for HaskellDoc long term, but since we're not close to arriving at a proposal for the documentation syntax we shouldn't wait for it - libraries can be converted to HaskellDoc later. For the centralised source repository we can use cvs.haskell.org, with a new 'libraries' module; library owners can be given accounts to maintain their own libraries. The source tree will need build systems for the different compilers (for GHC I'll probably arrange things so that libraries can be grafted onto fptools/ and use the build system there). Cheers, Simon

3 2

Library hierarchy, contd.
by Simon Marlow 25 May '01

25 May '01

Dear library folks, Having finished my current batch of compiler hacking I'd like to kickstart the libraries discussion again. As you may recall, we were stuck on the layout of the library hierarchy - below I've appended a new version (relative to Malcolm's last version) with some changes which I've listed first. I hope we can take this and converge on something which we're all happy with. I've also included an attempt at a set of guidelines for the contents of the top-level categories, as requested by one or two people: this should make it easier to place new libraries, and it's also useful to see some of the places where categories overlap. We should also write down guidelines on naming (not only for libraries themselves but also for functions, types and classes) at some point. There are several process-related issues to agree on before we can start actually writing code, but this message is too long already so I'll try to tackle them in separate mails tomorrow. Cheers, Simon Changes to the hierarchy - Data and Structures merged. The distinction between the two isn't clear: eg. IORef and STRef could be considered structures, as could Complex, Maybe, Either, List, PackedString etc. Put them all under Data - I think Data.Array, Data,Trees etc. look quite natural. - Moved Control back up to the top level (was previously in System). I'll give way on the Lang issue, but I think we'll have to expand the remit of Data to include not only data types themselves but also operations and classes over data (we already have Data.Memo), so now Dynamic and Generics fit in there too. Having a 'Type' hierarchy doesn't seem appropriate, because most libraries in Data also define types and it would just create confusion. - Moved Monad back into Control. - Added hypothetical Network.Protocol.{HTTP,FTP,SMTP,...} - Added Data.Bool, Data.Tuple - Added Text.Show & Text.Read - Moved Prelude.ShowFunctions to Text.Show.Functions. - Clarified that Numeric exports the Haskell 98 numeric classes (Num, Integral, Real etc.). - Renamed URL back to URI. - Capitalised NHC (hope that's OK). - Algebra & Numeric could be merged (as suggested by Dylan Thurston in the previous thread), I haven't made any changes here yet though. Numeric seems an appropriate place for the existing numeric operations and classes, but 'Math' would be less so. - There are still a few things left in the Prelude that don't have a home elsewhere: curry, uncurry, id, const, (.), asTypeOf, seq, ($!). ------------------------------------------------------------------------ ----- Hierarchy guidelines Control Libraries which provide functions, types or classes whose purpose is primarily to express control structure. Data Libraries which provide data types, operations over data types, or type classes, except for libraries for which one of the other more specific categories is appropriate. Algebra ? (someone more knowledgable please fill this in) Database Libraries for providing access to or operations for building databases. Debug Support for debugging Haskell programs. FileFormat Support for reading and/or writing various file formats (except language source which lives in Language, and textual file formats which are catered for in Text). Foreign Interaction with code written in a foreign programming language. Graphics Libraries for producing graphics or providing graphical user interfaces. Language Libraries for operating on or generating source code in various programming languages, including parsers, pretty printers, abstract syntax definitions etc. Numeric Functions and classes which provide operations over numeric data. Network Libraries for communicating over a network, including implementations of network protocols and standards. System Libraries for communication with the system on which the Haskell program is running (including the runtime system). Text Libraries for parsing and generating data in a textual format (including structured textual formats such as XML, HTML, but not including programming language source, which lives in Language). Others: GHC, NHC, Edison Further top-level names will be allocated on an as-needed basis. ------------------------------------------------------------------------ ----- Prelude -- Haskell98 Prelude (mostly just re-exports other parts of the tree). Control Exception -- (opt, inc. error & undefined) Concurrent -- as hslibs/concurrent CVar -- these could all be moved under Data Chan MVar Merge QSem QSemN SampleVar Semaphore Parallel -- as hslibs/concurrent/Parallel Strategies Monad -- Haskell 98 Monad library ST -- ST defaults to Strict variant? Strict -- renaming for ST Lazy -- renaming for LazyST Either -- monad libraries State Error etc. Data Bits Bool -- &&, ||, not, otherwise Tuple -- fst, snd Char -- H98 Complex -- H98 Dynamic Either Int Maybe -- H98 List -- H98 PackedString Ratio -- H98 Word IORef STRef Binary -- Haskell binary I/O Digest MD5 ... -- others (CRC ?) 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 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 -- exports std. H98 numeric type classes DSP FastFourierTransform Noise Oscillator Network -- won't need to be optional (will use FFI only) Socket -- redesign (merged Socket, SocketPrim, BSD) URI -- general URI parsing CGI -- one in hslibs is ok? Protocol HTTP FTP SMTP System -- Interaction with the "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 ...) Text Read Show Functions -- optional instance of Show for functions. Regex -- previously RegexString PrettyPrinter -- default (HughesPJ?) HughesPJ Wadler ... Html -- HTML combinator lib Xml Combinators Parse Pretty Types ParserCombinators -- no default Parsec Hutton_Meijer ... GHC Primitives UnboxedTypes ... NHC Stuff

5 7

RE: Library hierarchy, contd.
by Simon Marlow 25 May '01

25 May '01

> Dylan mentions "matrix classes" and then concludes: > > > Maybe "Computational" would be a better name than "Numeric"? > > I've been trying to demonstrate that there more to > "matrix" than just data structure or just simple linear > equation solver. It is easy to come up with the latter, > or with a set of primitive product operations. But people > seem to be ignoring the fact that there is much more to linear > algebra than those trivialities. Eigenproblems for > example... Dense cases, sparse cases and all that Pandorra > box of non-trivial engineering tools. > > These things are still alive, thank you very much, and > the papers are still written about them every day. Neither > the problems nor the papers are trivial. > > Yet they are being ignored in your hierarchy. > Please, mark at least some spot for them. And do not tie them > to "matrix" because "matrix" is just one specific representation > of operator algebra -- as I am showing in some modules > of mine, for example. > I do not care what name you choose. Computational? > Linear algebra? But please do not ignore them altogether. We're not ignoring these issues, sorry if you got that impression. I'd certainly like to see a suggestion (better still, a proposal) for organising these libraries from people such as yourself and Dylan. Cheers, Simon

1 0

RE: Library hierarchy, contd.
by Simon Marlow 24 May '01

24 May '01

> Me: > Likewise. I'm very happy with the broad structure now. There are > only minor nits left (such as already mentioned by other people, > e.g. FileFormat.Graphics -> FileFormat.Image). Already made that change in my local copy. Great - it looks like we're converging. One other nit which I forgot about: can we capitalise Xml and Html to XML & HTML to be consistent (I think we already agreed to do this). Cheers, Simon

3 2

Re: Library hierarchy, contd.
by Ashley Yakeley 24 May '01

24 May '01

At 2001-05-24 09:06, Malcolm Wallace wrote: >I vaguely remember agreeing the opposite - to use InitCaps throughout >rather than ALLCAPS. Whatever. Strictly, 'HTML' and 'XML' are IC... -- Ashley Yakeley, Seattle WA

1 0