From princepawn@earthlink.net Wed May 2 02:28:28 2001
Date: Tue, 1 May 2001 18:28:28 -0700
From: Terrence Brannon princepawn@earthlink.net
Subject: Dimensional analysis with fundeps (some physics comments)
Excuse me for playing referee here, as I am looking at this discussion
from a very abstract level, as I am a beginning functional-logic
programmer. But my question (primarily for Fergus) is: "has Ashley
shown in her example a means of automating a toUnits imperative in
Haskell that must be done explicitly in Mercury?" If so, then we have
the start of the Haskell-Mercury comparison document which shows an
advantage of Haskell over Mercury.
> I'm cross-posting this to the Libraries list...
>
> At 2001-04-10 18:02, Fergus Henderson wrote:
>
> >Still, the need to insert explicit `toUnits' is
> >annoying, and it would be nice to have a system where every number was
> >already a dimensionless unit.
>
> That's easy:
>
> --
> type Unit rep = Dimensioned Zero Zero Zero rep;
>
> instance (Real a) => Real (Unit a) where
> {
> -- put instances here
> };
> --
>
> Of course you'll have to appropriately declare superclasses of Real, such
> as Num, Ord, Show, Eq etc.
>
> --
> Ashley Yakeley, Seattle WA
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From reid@cs.utah.edu Tue May 8 22:17:50 2001
Date: Tue, 8 May 2001 15:17:50 -0600 (MDT)
From: Alastair Reid reid@cs.utah.edu
Subject: lookupFM vs Prelude.lookup
This is somewhat well known but I just got caught by it yet again so
I'd like to add it to the list of things that need fixed in hslibs.
Prelude.lookup and lookupFM _almost_ have the same type:
Prelude.lookup :: <context> => a -> [(a,b)] -> Maybe b
lookupFM :: <context> => FM a b -> a -> Maybe b
Close enough that your mind treats them the same, different enough
that Haskell won't.
It'd be much better if these took their arguments in the same order.
That is, either:
Prelude.lookup :: <context> => [(a,b)] -> a -> Maybe b
lookupFM :: <context> => FM a b -> a -> Maybe b
or:
Prelude.lookup :: <context> => a -> [(a,b)] -> Maybe b
lookupFM :: <context> => a -> FM a b -> Maybe b
Despite being on the library committee at the time, I don't understand
why H98 went for the argument order it did (I prefer the FiniteMap
order) but, since it's the standard, I propose that they get swapped
in FiniteMap when things get reorganised.
(I know this will be very painful for people who use FMs heavily
(e.g., GHC) but it's easier to make these changes relatively early.)
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
ps Since FM provides, essentially, the same functionality as Arrays,
it really ought to have a much more similar interface. I'll leave off
the details for now (just apply s/FiniteMap/Array/ to the types of FM
functions and check them off against the Array interface).
pps Is there a list of things to be done to hslibs? It'd be good to
have a place in a CVS tree somewhere where we could add things or to
have John Hughes' Standard Haskell web page software
(http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=0) or
something. The current mail archive isn't as good because it doesn't
have enough structure and there's no place you can go to to find what
is currently agreed on, what is still open to discussion and what is
being ignored. (The same goes for the ffi list.)
From simonmar@microsoft.com Wed May 23 17:43:01 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 23 May 2001 17:43:01 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
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=20
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=20
Libraries which provide functions, types or classes whose purpose
is primarily to express control structure.
=09
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
From qrczak@knm.org.pl Wed May 23 20:16:33 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 23 May 2001 19:16:33 GMT
Subject: Library hierarchy, contd.
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Wed, 23 May 2001 17:43:01 +0100, Simon Marlow pisze:
> below I've appended a new version (relative to Malcolm's last
> version) with some changes which I've listed first.
I will only say that I like it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From m@ryangunter.com Thu May 24 01:51:34 2001
From: m@ryangunter.com (Mike Gunter)
Date: 23 May 2001 17:51:34 -0700
Subject: Library hierarchy, contd.
In-Reply-To: "Simon Marlow"'s message of "Wed, 23 May 2001 17:43:01 +0100"
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <87ofsjtvqh.fsf@c966553-A.frmt1.sfba.home.com>
> FileFormat -- 'Codec' might be a more accurate name?
> Graphics
> Jpeg
> Ppm
> Png
A nit: "Image" not "Graphics" would be consistent with the terminlogy
of those fields.
mike
From dpt@math.harvard.edu Thu May 24 13:32:59 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 24 May 2001 08:32:59 -0400
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Wed, May 23, 2001 at 05:43:01PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010524083259.A6728@math.harvard.edu>
On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote:
> Data
> Complex -- H98
This seems decidedly out of place here: complex numbers are not
interesting as a data structure, but as a mathematical construct.
(I.e., the instance of Num is the interesting part.)
Part of the motivation for a "Mathematics" hierarchy is to have a
natural place where, e.g., "Complex" would belong.
> Data
> Int
This seems somewhat less out of place, since, IIRC, the functions in
this library deal with low-level representation.
> Algebra
> DomainConstructor -- formerly DoCon
> Geometric -- formerly BasGeomAlg
> Numeric -- exports std. H98 numeric type classes
> DSP
> FastFourierTransform
> Noise
> Oscillator
You make a good point that these current libraries do not fit all that
well under "Mathematics". Maybe we should keep "Numeric" and create a new
"Mathematics" hierarchy which would contain:
- the std. H98 classes. [Incidentally, I agree with Sergio
Mechvelliani that the "Num" class is badly named. I would vastly
prefer to call the class "Ring".]
- the Complex class
- Mechvelliani's classes
- arbitrary precision arithmetic
- matrix classes
Maybe "Computational" would be a better name than "Numeric"?
Best,
Dylan Thurston
From dpt@math.harvard.edu Thu May 24 13:36:35 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 24 May 2001 08:36:35 -0400
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Wed, May 23, 2001 at 05:43:01PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010524083635.B6728@math.harvard.edu>
On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote:
> 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?
In this particular instance, I'd like to use the Edison structures,
and I'd like them to be available in a standard place. But maybe this
just means there should be copies of some of these libraries under the
Data hierarchy.
Best,
Dylan Thurston
From jans@numeric-quest.com Thu May 24 09:37:29 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Thu, 24 May 2001 04:37:29 -0400 (EDT)
Subject: Library hierarchy, contd.
In-Reply-To: <20010524083259.A6728@math.harvard.edu>
Message-ID:
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.
Jan
From simonmar@microsoft.com Thu May 24 15:14:55 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 15:14:55 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
> On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote:
> > Edison -- (opt, uses multi-param type classes)
> > Prelude -- large self-contained packages should have
> > Collection -- their own hierarchy? Like a=20
> vendor branch.
> > Queue -- Or should the whole Edison tree be placed
> > ... -- under [Data.]Structures?
>=20
> In this particular instance, I'd like to use the Edison structures,
> and I'd like them to be available in a standard place. But maybe this
> just means there should be copies of some of these libraries under the
> Data hierarchy.
The only reason that Edison is in a subtree of its own is that no-one
has "decided" what the API for the standard versions of these libraries
should be. Maybe that choice will be to adopt Edison as-is, but that
would rule out using these modules from NHC because of Edison's use of
multi-parameter type classes.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Thu May 24 16:42:37 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 16:42:37 +0100
Subject: Library hierarchy, contd.
In-Reply-To:
Message-ID:
Simon Marlow :
> > below I've appended a new version (relative to Malcolm's last
> > version) with some changes which I've listed first.
Marcin Kowalczyk:
> I will only say that I like it.
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).
Regards,
Malcolm
From Malcolm.Wallace@cs.york.ac.uk Thu May 24 17:06:54 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 17:06:54 +0100
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115898@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <6x0AAJ4xDTtQWgAA@cs.york.ac.uk>
> 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).
I vaguely remember agreeing the opposite - to use InitCaps throughout
rather than ALLCAPS. Whatever.
One other point - I have noticed that there is at least one other
Haskell XML processing library (by Peter Thiemann) out there besides
my HaXml. I don't want to claim any monopoly on the `best' or
`standard' way of doing XML, so I'm inclined to go for `HaXml' as
the base name of my package rather than stealing `Xml' prematurely.
Hence, my vote would be for
Text
Html
HaXml
Regards,
Malcolm
From simonmar@microsoft.com Thu May 24 16:58:04 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 16:58:04 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115898@TVP-MSG-01.europe.corp.microsoft.com>
> 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
From ashley@semantic.org Thu May 24 22:27:23 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 24 May 2001 14:27:23 -0700
Subject: Library hierarchy, contd.
Message-ID: <200105242127.OAA14088@mail4.halcyon.com>
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
From igloo@earth.li Thu May 24 22:39:23 2001
From: igloo@earth.li (Ian Lynagh)
Date: Thu, 24 May 2001 22:39:23 +0100
Subject: Library hierarchy, contd.
In-Reply-To: <6x0AAJ4xDTtQWgAA@cs.york.ac.uk>; from Malcolm.Wallace@cs.york.ac.uk on Thu, May 24, 2001 at 05:06:54PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6115898@TVP-MSG-01.europe.corp.microsoft.com> <6x0AAJ4xDTtQWgAA@cs.york.ac.uk>
Message-ID: <20010524223923.A32050@stu163.keble.ox.ac.uk>
On Thu, May 24, 2001 at 05:06:54PM +0100, Malcolm Wallace wrote:
> > 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).
>
> I vaguely remember agreeing the opposite - to use InitCaps throughout
> rather than ALLCAPS. Whatever.
>
> One other point - I have noticed that there is at least one other
> Haskell XML processing library (by Peter Thiemann) out there besides
> my HaXml. I don't want to claim any monopoly on the `best' or
> `standard' way of doing XML, so I'm inclined to go for `HaXml' as
> the base name of my package rather than stealing `Xml' prematurely.
>
> Hence, my vote would be for
>
> Text
> Html
> HaXml
Would
Text
Html
Xml
HaXml
the_other_one
not make more sense?
And personally I think XML and HTML should be all caps as they tend to
be elsewhere.
Ian
From simonmar@microsoft.com Fri May 25 10:12:11 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 10:12:11 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD703@TVP-MSG-01.europe.corp.microsoft.com>
> Dylan mentions "matrix classes" and then concludes:
>=20
> > Maybe "Computational" would be a better name than "Numeric"?
>=20
> I've been trying to demonstrate that there more to=20
> "matrix" than just data structure or just simple linear=20
> equation solver. It is easy to come up with the latter,=20
> or with a set of primitive product operations. But people=20
> 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.=20
>=20
> These things are still alive, thank you very much, and=20
> the papers are still written about them every day. Neither
> the problems nor the papers are trivial.
> =20
> Yet they are being ignored in your hierarchy.
> Please, mark at least some spot for them. And do not tie them=20
> 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
From dpt@math.harvard.edu Fri May 25 12:45:15 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Fri, 25 May 2001 07:45:15 -0400
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Wed, May 23, 2001 at 05:43:01PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010525074515.A10432@math.harvard.edu>
Here's a concrete proposal for a Mathematics subtree. Following Jan
Skibinski's comment about linear algebra and some thought, I convinced
myself that there is no natural division between
numerical/computational libraries and more "pure" mathematics.
Description:
Mathematics
Libraries for mathematical structures or algorithms.
------
Mathematics
Prelude -- The so-called "numeric" hierarchy from
-- the H98 Prelude
Complex -- Standard H98
Ratio -- Standard H98
DSP
FastFourierTransform
Noise
Oscillator
LinearAlgebra -- Provides a simple-minded matrix implementation
Sparse
LUDecomposition -- Various algorithms/representations go here,
... -- Somebody help me with a good hierarchy.
DomainConstructor -- Mechveliani's library
ExactReal -- Various people have done good work here.
-- Unfortunately, no-one seems to have published
-- their source code in library format.
From simonmar@microsoft.com Fri May 25 13:05:23 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 13:05:23 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com>
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
=20
- Library status
- experimental/stable
- compiler-specific/portable.
=20
- 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
From jans@numeric-quest.com Fri May 25 13:24:41 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Fri, 25 May 2001 08:24:41 -0400 (EDT)
Subject: Library hierarchy, contd.
In-Reply-To: <20010525074515.A10432@math.harvard.edu>
Message-ID:
Sorry for the lengthy discourse, but I was unable
to cut it down even after I re-read it twice :-).
On Fri, 25 May 2001, Dylan Thurston wrote:
> Here's a concrete proposal for a Mathematics subtree. Following Jan
> Skibinski's comment about linear algebra and some thought, I convinced
> myself that there is no natural division between
> numerical/computational libraries and more "pure" mathematics.
Good!
I'll start with some critical comments first, taking
one of the items from your list as an example.
> Description:
> Mathematics
> Libraries for mathematical structures or algorithms.
>
> ------
> Mathematics
> Prelude -- The so-called "numeric" hierarchy from
> -- the H98 Prelude
> Complex -- Standard H98
> Ratio -- Standard H98
> DSP
> FastFourierTransform
Why here? Unless you are referring to one specific
FFT implementation (Donatio?) the FFT can be looked upon
as just one of many tools of linear algebra.
Why FFT? What so sanctimonious about it? Nothing; it
is popular because of its speed, and it is versatile
because of its popularity (I admit, I exaggerate quite a bit
here to make my point :-)). In fact, DFT is one of many
possible vector transformations, and FFT is its fast
implementation. In this case - the unitary transformation.
But you can implement it on many levels: using streams
of bits, blocks of complex numbers (vectors, matrices), etc.
But other unitary transformations have their uses too.
Have you ever heard about Walsh transformation, with
its (orthogonal) basis vectors made of (+1, -1) components, such
as: [1,1,1,1,1,1,1,1], [1,1,1,1,-1,-1,-1,-1], etc? Geophysists
used to employ it (or still do it?) for analysis of their seismic
data. Incidentally, there is also a Walsh-Hadamard transform, a
basic mixing transformation for quantum computations.
How about Hilbert transformation? You can use it to upgrade
real signals to their complex equivalents, such as
sin k*n -> exp i*k*n. Imagine a plot of your original
real signal in X-T coordinates, suddenly augmented by Y-T
"wing", as by some miracle. Very useful, believe me!
Sorry for ruining the FFT altar, but I think we should keep
certain things in a proper perspective. I believe there will
be many implementations of FFT in Haskell libraries - all
depending on the context. DSP, images, generic linear
algebra, etc. would all want their own versions of FFT,
because of specific representation they use.
And that brings me to the second point I want to make.
If I could describe an algorithm, such as FFT, in generic
terms than I would have and example of a fine generic
algorithm. Unfortunately, more often than not I must be datatype
specific. And that means some choice of Matrix and Vector.
A very controversial issue. How to design these two to
satisfy everyone?
I do not think it's possible at all. For a naive user of graphics
those are 2D or 3D entities (or 4D for implementation
reasons). And real too! Represented by arrows so to speak.
Some other users would like to have it n-dimensional
but Double, some need Complex Double, some would be
only happy with a generic "a". Then there is a question
of underlying implementations. Arrays? If yes, then
what kind of arrays? Would lists be satisfactory
and if yes with what size limitations? Or maybe I
can forget about lists and arrays and choose something
else altogether (as I do it in QuantumVector module)?
Facing all those possible choices, should I be arrogant
enough to claim the generic names Vector and Matrix for
something that I choose to implement my own way?
[We once sidestepped at least this controversial naming issue
by calling the things BasicVector and BasicMatrix, respectively.
For the same reason I have introduced the QuantumVector, not just
THE Vector].
------------------------------------------------------
But all those remarks were somewhat pessimistic and destructive.
So here are some constructive ideas:
+ Keep low profile regarding Matrix and Vector concepts.
Do not build anything around Matrix and Vector, but rather
think algorithmically instead. If you must use the two,
treat them more or less as your private stuff.
For example, my module Eigenproblem casts several algoritms in
terms of abstract Hilbert operators and Hilbert spaces.
This is as far as I was able to go abstract-wise for
a moment and I still might improve on it one day.
But that module relies on the lower level implementation module
LinearAlgoritms, which implements everything as lists. Why
lists? Because I still do not like Haskell Arrays as they are
and because I am lazy and lists are easy to work with. But
that's not the point. What is important are the ideas
implemented in those modules, which can be easily re-worked for
any data structure, Haskell arrays included.
+ Expect that each proposed linear algebra library covers a
significant chunk of such "territory" because only then it
can be proven useful and consistent. If a library just
defines a Matrix, it is useless by a virtue of arguments
presented before. If it goes only as far as LUDecomposition
it is naive and simple minded -- good only for solving
linear equations. If it inverts the equations and also
finds eigenvalues of symmetric matrices it is a step in
right direction. If it handles eigenproblems (eigenvalues
and eigenvectors - all or some) of Hermitian operators,
nonsymmetric real operators, up to any kind of operator
of small and medium size problems it is useful.
If it handles big eigenproblems (n > 1000 or so) - no
matter what technology (using "sparse" matrices perhaps)
it uses, it is very good. If it provides Singular Value
Decomposition on a top of all of the above than it should be
considered excellent.
+ Of course, any good linear algebra library would provide
many tools for handling the tasks which I outlined above.
But those are not the goals in themselves, they are
just the tools. What I have in mind here are all those
Choleskys and LUDecompositions, and triangularizations and
tridiagonalization procedures, and Hessenberg matrices,
and QR or QL decompositions, etc.
Do not measure the value of a library by a number of
such tools appearing in it. Value its consistency and
ability to achieve the final solution.
----------------------------------------------------------
Summarizing: LinearAlgebra appearing in hierarchy (after Dylan)
Mathematics
...
LinearAlgebra
NonlinearAlgebra (perhaps)
....
is just one element which should be clearly marked as very
important. But I'd suggest not to mark any of its specifics,
because that's very much the design and implementation choice.
But we could specify what should be expected from a good
linear algebra library, as I tried to describe it above.
Jan
From chak@cse.unsw.edu.au Sat May 26 08:31:27 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sat, 26 May 2001 17:31:27 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010526173127M.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> - 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.
I don't think that it is a good idea to specify a license.
For example, I am convinced that the (L)GPL is the better
licence for the community. Incidentally, the GPL is also
the license of one of the most successful free software
projects ever - Linux - which is certainly also one of the,
if not *the* commercially most successful free software
project. So, I don't buy this GPL is bad for companies
propaganda. In that context, I recommend to read
http://perens.com/Articles/StandTogether.html
Anyway, while I am happy to discuss my position with anybody
who is interested, I don't want to start a big licence
discussion here. All in all, I think, we should let authors
chose their license.
I am sorry (honestly) if that creates a problem for you, but
on the other hand, I am not keen on having a particular
company influence our licencing policies - certainly not in
something which we want to sell as a standard to the
community.
> - 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.
Absolutely.
> 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).
Don't libraries need their own build system anyway if they
are to be portable?
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)?
Cheers,
Manuel
From dpt@math.harvard.edu Sat May 26 13:27:07 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Sat, 26 May 2001 08:27:07 -0400
Subject: Licenses
In-Reply-To: <20010526173127M.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Sat, May 26, 2001 at 05:31:27PM +1000
References: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com> <20010526173127M.chak@cse.unsw.edu.au>
Message-ID: <20010526082707.A12896@math.harvard.edu>
On Sat, May 26, 2001 at 05:31:27PM +1000, Manuel M. T. Chakravarty wrote:
> "Simon Marlow" wrote,
>
> > - 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.
>
> I don't think that it is a good idea to specify a license.
> For example, I am convinced that the (L)GPL is the better
> licence for the community. ...
I'm a big fan of the GPL; however, you must know that picking the GPL
for a library (particularly a standard library) is a very political
act. Even the FSF only does this occasionally. The LGPL seems less
controversial to me, and would be my choice. (But I'm not the one to
choose, and I will be happy as long as the libraries are free (libre).)
I also think that a standard license for the standard libraries is
important. With every new license that gets involved in a project, I
have to make a decision; I'd rather make that decision just once, when
I decide to use Haskell.
[Apologies if this starts a big licensing discussion. I think this is
one of the very few times it is appropriate; I believe these issues
are important.]
Best,
Dylan Thurston
From simonmar@microsoft.com Mon May 28 10:17:03 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 10:17:03 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
Manuel writes:
> I don't think that it is a good idea to specify a license.
> For example, I am convinced that the (L)GPL is the better
> licence for the community. Incidentally, the GPL is also
> the license of one of the most successful free software
> projects ever - Linux - which is certainly also one of the,
> if not *the* commercially most successful free software
> project. So, I don't buy this GPL is bad for companies
> propaganda.
It's not propaganda. The fact is if any of the standard libraries use
the LGPL, then some people will be prevented from using them. That's
the last thing we want, right? Now you might argue from a moral
standpoint that the companies that these people work for are basing
their business models on intellectual property and therefore deserve
everything they get, but we're not trying to do open source advocacy
here, we're just trying to put together a set of libraries that everyone
can use.
Maybe it's possible to use a dual license (ie. "pick one of the
following licenses") scheme, but I'm not a license expert.
Cheers,
Simon
PS. usual employer-related disclaimers apply.
From simonmar@microsoft.com Mon May 28 11:55:40 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 11:55:40 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611589E@TVP-MSG-01.europe.corp.microsoft.com>
> 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
From Dominic.J.Steinitz@BritishAirways.com Mon May 28 14:05:48 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 28 May 2001 13:05:48 Z
Subject: The next step
Message-ID: <"035483B124D2C010*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
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
From igloo@earth.li Mon May 28 14:59:10 2001
From: igloo@earth.li (Ian Lynagh)
Date: Mon, 28 May 2001 14:59:10 +0100
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 10:17:03AM +0100
References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010528145910.A22527@stu163.keble.ox.ac.uk>
On Mon, May 28, 2001 at 10:17:03AM +0100, Simon Marlow wrote:
> Manuel writes:
> > I don't think that it is a good idea to specify a license.
> > For example, I am convinced that the (L)GPL is the better
> > licence for the community. Incidentally, the GPL is also
> > the license of one of the most successful free software
> > projects ever - Linux - which is certainly also one of the,
> > if not *the* commercially most successful free software
> > project. So, I don't buy this GPL is bad for companies
> > propaganda.
>
> It's not propaganda. The fact is if any of the standard libraries use
> the LGPL, then some people will be prevented from using them.
If there is an LGPLed library then you can write a new version which
matches the spec and release it under the BSD license if you wish.
Then in a similar way to how the implementation of a library you have
may use GHC extensions (say) you could use an implementation with a BSD
license. I would suggest that the specs be public domain and the
compilers can chose to ship whatever version they think best.
Ian
From simonmar@microsoft.com Mon May 28 15:14:03 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 15:14:03 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD717@TVP-MSG-01.europe.corp.microsoft.com>
> -----Original Message-----
> From: Steinitz, Dominic J=20
> [mailto:Dominic.J.Steinitz@BritishAirways.com]=20
> Sent: Monday, May 28, 2001 2:06 PM
> To: Simon Marlow
> Cc: chak; libraries
> Subject: RE: The next step
>=20
>=20
> Can someone explain what licenses are commonly avaible and=20
> what they mean or point me at some references?
>=20
> Dominic.
>=20
> --------------------------------------------------------------
> -----------------------------------
> 21st century air travel http://www.britishairways.com
>=20
From simonmar@microsoft.com Mon May 28 16:14:29 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 16:14:29 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A2@TVP-MSG-01.europe.corp.microsoft.com>
Frank Atanassow writes:
> Some people don't see it that way. They would say that the=20
> GPL is the _less_
> restrictive license because it ensures that everybody=20
> benefits (equally) from
> everybody else's improvements. From that perspective,=20
> companies benefit also
> since they may use and improve the code, provided they=20
> "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. =20
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
From ken@digitas.harvard.edu Mon May 28 16:49:37 2001
From: ken@digitas.harvard.edu (Ken Shan)
Date: Mon, 28 May 2001 11:49:37 -0400
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A2@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 04:14:29PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C61158A2@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010528114937.C5546@digitas.harvard.edu>
--dTy3Mrz/UPE2dbVg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> 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.
Really? I've assumed that GPL only deals with copyright, and
techniques one uses in code are matters of patents and trade secrets.
Here's a message on what license to use, from gnu.misc.discuss:
http://groups.google.com/groups?hl=3Den&lr=3D&safe=3Doff&ic=3D1&th=3D8e757e=
c573e5498,15&seekm=3Drjzoeoifn9.fsf%40ssv2.dina.kvl.dk
--=20
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
>>My SUV is bigger than your bike. Stay out of the damn road!
>Kiss my reflector, SUV-boy
I'm too busy sucking on my tailpipe, bike dude.
--dTy3Mrz/UPE2dbVg
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7EnORzjAc4f+uuBURAuvqAKDh5RWFlGNDEwFhJN0/Ee3Pp8F1mwCglex3
ZJDEGscrjHQi03h0Ly/9z/c=
=9zXR
-----END PGP SIGNATURE-----
--dTy3Mrz/UPE2dbVg--
From simonmar@microsoft.com Mon May 28 17:48:04 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 17:48:04 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
> On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> > 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=20
> to use similar
> > techniques in proprietary code, the owner of the=20
> proprietary code is in
> > a legally difficult position.
>=20
> Really? I've assumed that GPL only deals with copyright, and
> techniques one uses in code are matters of patents and trade secrets.
Sure, but if the code in the proprietary source ends up looking similar
enough to the GPL code, it might be hard to prove that it wasn't a
derived work. This is a risk you just don't want to take if your
business depends on keeping your sources non-free.
Cheers,
Simon
From chak@cse.unsw.edu.au Tue May 29 04:55:58 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 13:55:58 +1000
Subject: The next step
In-Reply-To: <"035483B124D2C010*/c=GB/admd=ATTMAIL/prmd=BA/o=British
Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
References: <"035483B124D2C010*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways
PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID: <20010529135558P.chak@cse.unsw.edu.au>
"Steinitz, Dominic J" 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
From chak@cse.unsw.edu.au Tue May 29 05:42:05 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 14:42:05 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529144205R.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> > > 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.
> >
> > Really? I've assumed that GPL only deals with copyright, and
> > techniques one uses in code are matters of patents and trade secrets.
>
> Sure, but if the code in the proprietary source ends up looking similar
> enough to the GPL code, it might be hard to prove that it wasn't a
> derived work. This is a risk you just don't want to take if your
> business depends on keeping your sources non-free.
This is the first time, I have heard about such a scenario
and I don't think that it is realistic. For an infringement
of copyright (rather than a patent), non-trivial amounts of
code must be basically the same. This won't happen unless
the programmer has a photographic memory or actually copies
parts of the code.
Consider that companies like IBM and SGI happily deal in
GPLed code.
Cheers,
Manuel
From chak@cse.unsw.edu.au Tue May 29 06:49:42 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 15:49:42 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529154942V.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> Manuel writes:
> > I don't think that it is a good idea to specify a license.
> > For example, I am convinced that the (L)GPL is the better
> > licence for the community. Incidentally, the GPL is also
> > the license of one of the most successful free software
> > projects ever - Linux - which is certainly also one of the,
> > if not *the* commercially most successful free software
> > project. So, I don't buy this GPL is bad for companies
> > propaganda.
>
> It's not propaganda. The fact is if any of the standard libraries use
> the LGPL, then some people will be prevented from using them. That's
> the last thing we want, right? Now you might argue from a moral
> standpoint that the companies that these people work for are basing
> their business models on intellectual property and therefore deserve
> everything they get, but we're not trying to do open source advocacy
> here, we're just trying to put together a set of libraries that everyone
> can use.
Depends on the library. I agree with you that the really
core stuff and in particular the "language
extension"-related libraries should be completely
unrestricted.
However, many libraries in the current hslibs and, judging
from the discussion so far, many new libraries are not
belonging to this core. What is the problem if they are
LGPL? LGPL code can be linked into proprietary code without
any problems. There is lots of proprietary code being based
on code generated by gcc and linked against its C library.
> Maybe it's possible to use a dual license (ie. "pick one of the
> following licenses") scheme, but I'm not a license expert.
It is possible. Perl does it. But why? If a license is
released under the LGPL, it can be used in proprietary code.
Only if the library itself is modified, modifications have
to be contributed back. And, yes, if I write a library and
somebody improves it and distributes the improvements[1], I
want them, too. What's wrong with this?
Cheers,
Manuel
[1] Note that if GPL or LGPL code is modified and only used
in-house, there is no need to release the modifications.
From chak@cse.unsw.edu.au Tue May 29 06:52:04 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 15:52:04 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589E@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611589E@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529155204L.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > 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.
Technically, I think, it might be cleaner to have build
system for the libraries that works with all compilers,
rather than different build systems for different
compilers.
Cheers,
Manuel
From franka@cs.uu.nl Tue May 29 12:15:09 2001
From: franka@cs.uu.nl (Frank Atanassow)
Date: Tue, 29 May 2001 13:15:09 +0200
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 05:48:04PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529131509.C5078@cs.uu.nl>
Simon Marlow wrote (on 28-05-01 17:48 +0100):
>
> > On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> > > 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.
> >
> > Really? I've assumed that GPL only deals with copyright, and
> > techniques one uses in code are matters of patents and trade secrets.
>
> Sure, but if the code in the proprietary source ends up looking similar
> enough to the GPL code, it might be hard to prove that it wasn't a
> derived work. This is a risk you just don't want to take if your
> business depends on keeping your sources non-free.
Not that I buy this latest doublethink [1], but some people might call that
poetic justice.
Some people might.
But not me. No, sir...
[1] doublethink
--
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-3791
From simonmar@microsoft.com Tue May 29 11:45:55 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 11:45:55 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A5@TVP-MSG-01.europe.corp.microsoft.com>
> > Sure, but if the code in the proprietary source ends up=20
> looking similar
> > enough to the GPL code, it might be hard to prove that it wasn't a
> > derived work. This is a risk you just don't want to take if your
> > business depends on keeping your sources non-free.
>=20
> This is the first time, I have heard about such a scenario
> and I don't think that it is realistic. For an infringement
> of copyright (rather than a patent), non-trivial amounts of
> code must be basically the same. This won't happen unless
> the programmer has a photographic memory or actually copies
> parts of the code.
Right or wrong, the L?GPL simply scares the bejeezus out of corporate
types (with notable exceptions like IBM & HP). I'm not going to argue
whether this is right or wrong - I'm just asking whether those who
favour the LGPL could compromise slightly and make life a little easier
for some of us. There's no problem with "external" libraries like
Gtk+Haskell, just the libraries we're going to keep in the main
repository (call it the core set or whatever, basically the libraries
we're going to end up distributing with GHC).
On the other hand, I certainly don't want to discourage people from
contributing because they don't like our license requirements. But
things are going to get real messy if every file has its own license.
Looking down the hierarchy we have at the moment, much of the existing
code (from hslibs, the FFI project etc.) is either under the GHC license
or is licenseless. So would it be too painful to ask that anyone who
wants to contribute code under the LGPL does it in a separate part of
the repository?
Cheers,
Simon
From simonmar@microsoft.com Tue May 29 11:27:57 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 11:27:57 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD71C@TVP-MSG-01.europe.corp.microsoft.com>
> > I imagined putting the standard libraries in a single=20
> 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=20
> to support
> > ways, GHCi .o files, DLLs, split object files etc. etc.),=20
> but NHC and
> > Hugs require a much more minimal build system.
>=20
> Technically, I think, it might be cleaner to have build
> system for the libraries that works with all compilers,
> rather than different build systems for different
> compilers.=20
The problem with this is, the Hugs & NHC guys don't want the GHC build
system, and I don't want to rewrite our build system to do the same
stuff it already does (and likely the Hugs & NHC guys wouldn't like the
results anyway :-). We are doomed to multiple build systems I'm afraid.
Cheers,
Simon
From chak@cse.unsw.edu.au Tue May 29 14:40:02 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 23:40:02 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD71C@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C6058DD71C@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529234002D.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > > 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.
> >
> > Technically, I think, it might be cleaner to have build
> > system for the libraries that works with all compilers,
> > rather than different build systems for different
> > compilers.
>
> The problem with this is, the Hugs & NHC guys don't want the GHC build
> system, and I don't want to rewrite our build system to do the same
> stuff it already does (and likely the Hugs & NHC guys wouldn't like the
> results anyway :-). We are doomed to multiple build systems I'm afraid.
I am just worrying that this will put off potential library
authors or at least lessen their motivation to make the
library portable.
Cheers,
Manuel
From chak@cse.unsw.edu.au Tue May 29 14:50:47 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 23:50:47 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A5@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61158A5@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529235047N.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > > Sure, but if the code in the proprietary source ends up
> > looking similar
> > > enough to the GPL code, it might be hard to prove that it wasn't a
> > > derived work. This is a risk you just don't want to take if your
> > > business depends on keeping your sources non-free.
> >
> > This is the first time, I have heard about such a scenario
> > and I don't think that it is realistic. For an infringement
> > of copyright (rather than a patent), non-trivial amounts of
> > code must be basically the same. This won't happen unless
> > the programmer has a photographic memory or actually copies
> > parts of the code.
>
> Right or wrong, the L?GPL simply scares the bejeezus out of corporate
> types (with notable exceptions like IBM & HP). I'm not going to argue
> whether this is right or wrong - I'm just asking whether those who
> favour the LGPL could compromise slightly and make life a little easier
> for some of us. There's no problem with "external" libraries like
> Gtk+Haskell, just the libraries we're going to keep in the main
> repository (call it the core set or whatever, basically the libraries
> we're going to end up distributing with GHC).
>
> On the other hand, I certainly don't want to discourage people from
> contributing because they don't like our license requirements. But
> things are going to get real messy if every file has its own license.
> Looking down the hierarchy we have at the moment, much of the existing
> code (from hslibs, the FFI project etc.) is either under the GHC license
> or is licenseless. So would it be too painful to ask that anyone who
> wants to contribute code under the LGPL does it in a separate part of
> the repository?
Maybe I haven't paid enough attention to the previous
discussion about the library organisation, but what are the
criteria for libraries to be in the magic set which should
not use the LGPL?
Anyway, if everybody else thinks that requiring a BSD style
license is a good idea, just ignore me.
Cheers,
Manuel
From simonmar@microsoft.com Tue May 29 15:17:13 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 15:17:13 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A6@TVP-MSG-01.europe.corp.microsoft.com>
> > On the other hand, I certainly don't want to discourage people from
> > contributing because they don't like our license requirements. But
> > things are going to get real messy if every file has its=20
> own license.
> > Looking down the hierarchy we have at the moment, much of=20
> the existing
> > code (from hslibs, the FFI project etc.) is either under=20
> the GHC license
> > or is licenseless. So would it be too painful to ask that=20
> anyone who
> > wants to contribute code under the LGPL does it in a=20
> separate part of
> > the repository?
>=20
> Maybe I haven't paid enough attention to the previous
> discussion about the library organisation, but what are the
> criteria for libraries to be in the magic set which should
> not use the LGPL? =20
I wasn't planning to separate the libraries logically (i.e. you still
get all the libraries when you install GHC), only separate them
physically by keeping the sources in different parts of the repository.
This is I think the minimum we need to do if we have code with different
licenses in the same tree. I'll do this on a lazy basis: as soon as
someone comes along with LGPL code they want to contribute, we'll set up
the repository.
The criteria for a library to be in the "magic set" (I'm going to call
it the core set for now) is nothing more than conforming to a set of
guidelines that we've yet to decide on. I'm drafting up a proposal at
the moment.
Cheers,
Simon
From qrczak@knm.org.pl Tue May 29 15:47:15 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Tue, 29 May 2001 16:47:15 +0200 (CEST)
Subject: The next step
In-Reply-To: <20010529235047N.chak@cse.unsw.edu.au>
Message-ID:
On Tue, 29 May 2001, Manuel M. T. Chakravarty wrote:
> Anyway, if everybody else thinks that requiring a BSD style
> license is a good idea,
I don't. It's ok for my contributions to be BSD, but I'm not sure that we
should ban licenses like LGPL.
--
Marcin 'Qrczak' Kowalczyk
From cwitty@newtonlabs.com Wed May 30 00:24:11 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 29 May 2001 16:24:11 -0700
Subject: The next step
In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Tue, 29 May 2001 15:49:42 +1000"
References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com> <20010529154942V.chak@cse.unsw.edu.au>
Message-ID:
"Manuel M. T. Chakravarty" writes:
> However, many libraries in the current hslibs and, judging
> from the discussion so far, many new libraries are not
> belonging to this core. What is the problem if they are
> LGPL? LGPL code can be linked into proprietary code without
> any problems. There is lots of proprietary code being based
> on code generated by gcc and linked against its C library.
To link your code with LGPL code, you effectively must either provide
the user with object files for your code, or arrange for the LGPL code
to be contained in a shared library (the actual requirement is that
the user be able to modify the LGPL code and obtain a version of your
program that uses these modifications). The former option is a
significant cost in terms of how annoying it is to distribute your
code. I don't know if the latter is even possible -- can all the
Haskell implementations create shared libraries?
At any rate, while it is certainly possible to link proprietary code
with LGPL code, I wouldn't say that the combination is "without any
problems".
Carl Witty
From chak@cse.unsw.edu.au Wed May 30 11:29:41 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 30 May 2001 20:29:41 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A6@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61158A6@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010530202941S.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > > On the other hand, I certainly don't want to discourage people from
> > > contributing because they don't like our license requirements. But
> > > things are going to get real messy if every file has its
> > own license.
> > > Looking down the hierarchy we have at the moment, much of
> > the existing
> > > code (from hslibs, the FFI project etc.) is either under
> > the GHC license
> > > or is licenseless. So would it be too painful to ask that
> > anyone who
> > > wants to contribute code under the LGPL does it in a
> > separate part of
> > > the repository?
> >
> > Maybe I haven't paid enough attention to the previous
> > discussion about the library organisation, but what are the
> > criteria for libraries to be in the magic set which should
> > not use the LGPL?
>
> I wasn't planning to separate the libraries logically (i.e. you still
> get all the libraries when you install GHC), only separate them
> physically by keeping the sources in different parts of the repository.
> This is I think the minimum we need to do if we have code with different
> licenses in the same tree. I'll do this on a lazy basis: as soon as
> someone comes along with LGPL code they want to contribute, we'll set up
> the repository.
That's certainly a good idea.
> The criteria for a library to be in the "magic set" (I'm going to call
> it the core set for now) is nothing more than conforming to a set of
> guidelines that we've yet to decide on.
That's, I think, the crucial point. I am happy to define a
core for which we ask to use a BSD-style license in terms of
how fundamental the provided functionality is. Outside of
this fundamental functionality, I am against prescribing a
license (except requiring it to be "open source", as defined
by the OSI).
To give you an idea of what I mean by fundamental
functionality. For example, the FFI libraries are
fundamental. Their use should be unrestricted. A library
like Edison is on the borderline. QuickCheck or HOpenGL are
clearly outside of the core functionality.
Cheers,
Manuel
From simonmar@microsoft.com Wed May 30 14:42:27 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 14:42:27 +0100
Subject: Draft Libraries Document
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD732@TVP-MSG-01.europe.corp.microsoft.com>
I'm drafting up a document along the lines I mentioned in my previous
message. For the time being, I'll keep the latest version here:
http://www.haskell.org/~simonmar/libraries/libraries.html
it's pretty minimal at the moment with only a few sections containing
material. Suggestions and comments on what is there already are
welcome.
Cheers,
Simon
From simonmar@microsoft.com Wed May 30 16:42:08 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 16:42:08 +0100
Subject: Draft Libraries Document
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com>
> http://www.haskell.org/~simonmar/libraries/libraries.html
has been updated, now contains descriptions of the top-level names in
the hierarchy, and some text in the programming conventions section
(mostly copied over from the hslibs docs).
Cheers,
Simon
From simonmar@microsoft.com Thu May 31 14:54:31 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 31 May 2001 14:54:31 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158AE@TVP-MSG-01.europe.corp.microsoft.com>
> "Manuel M. T. Chakravarty" writes:
>=20
> > However, many libraries in the current hslibs and, judging
> > from the discussion so far, many new libraries are not
> > belonging to this core. What is the problem if they are
> > LGPL? LGPL code can be linked into proprietary code without
> > any problems. There is lots of proprietary code being based
> > on code generated by gcc and linked against its C library.
>=20
> To link your code with LGPL code, you effectively must either provide
> the user with object files for your code, or arrange for the LGPL code
> to be contained in a shared library (the actual requirement is that
> the user be able to modify the LGPL code and obtain a version of your
> program that uses these modifications). The former option is a
> significant cost in terms of how annoying it is to distribute your
> code. I don't know if the latter is even possible -- can all the
> Haskell implementations create shared libraries?
>=20
> At any rate, while it is certainly possible to link proprietary code
> with LGPL code, I wouldn't say that the combination is "without any
> problems".
Thanks, I wasn't aware of that particular restriction in the LGPL. And
having thought about it, I don't think it is reasonable to put libraries
under the standard LGPL in Haskell. Here's why:
- the license requires that any program linked with the library
is provided as object code that can be relinked with a modified
version of the library. In order to do this with GHC, you have
to compile your application with all cross-module optimisation
turned off (although the license does have a cryptic sentence
in section 6(a) that sounds like it might apply to this situation,
but I don't know what a "definitions file" is).
The LGPL also goes into some detail about when a program becomes
a derived work by virtue of "including things from header files",
in particular it says that inline functions may be "ten lines or
less" If we translate this to mean cross-module optimisation, it
essentially means that we have to turn off this optimisation or
change the license to say something that makes sense for Haskell.
=20
- You can't make any local incompatible modifications to GHC and
not distribute them, if you intend to link your non-free program
with LGPL libs (since you have to be able to recompile modified
versions of the libs and re-link to the original program). =20
- Similarly, you can't use a non-free compiler.
- You have to be able to compile your modified version of the
library. That means the library can't depend on any non-free
libraries, which places extra restrictions on what you can do with
any BSD licensed libraries you're using, if I'm not mistaken.
In a nutshell, the LGPL makes sense when (a) there is a well-defined
calling convention between application and library, and (b) compilers
are interchangeable. Neither of these is true for Haskell (indeed, they
are becoming less true for C and C++ these days).
Given these extra restrictions, I imagine that anyone producing a
non-free program would have to avoid the LGPL libraries altogether.
Cheers,
Simon
From malcolm@abbess.demon.co.uk Thu May 31 22:30:30 2001
From: malcolm@abbess.demon.co.uk (Malcolm Wallace)
Date: Thu, 31 May 2001 22:30:30 +0100
Subject: Draft Libraries Document
References: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <3B16B7F6.E219F613@abbess.demon.co.uk>
Simon Marlow wrote:
>
> > http://www.haskell.org/~simonmar/libraries/libraries.html
>
> has been updated, now contains descriptions of the top-level names in
> the hierarchy,
I notice you have gone for a "Numeric" category, rather than the
"Mathematics" top-level category suggested by Dylan. I know there
hasn't been much discussion about the layout and contents of the
specifically mathematical parts of the hierarchy, but Dylan's is
the only current proposal from anyone who claims to know the subject
in depth. :-) My instinct would be to go with the more general
"Mathematics", whatever we later decided to put inside it.
Regards,
Malcolm
From reid@cs.utah.edu Thu May 31 23:27:14 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 31 May 2001 16:27:14 -0600
Subject: Draft Libraries Document
In-Reply-To: <3B16B7F6.E219F613@abbess.demon.co.uk>
References: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com>
<3B16B7F6.E219F613@abbess.demon.co.uk>
Message-ID:
Malcolm Wallace writes:
> I notice you have gone for a "Numeric" category, rather than the
> "Mathematics" top-level category suggested by Dylan.
While pondering what else we'd put in mathematics other than numeric
stuff, I hit upon the crazy idea of adding:
Mathematics.Monad
instead of putting Monad in Control (which is the current proposal, I
believe).
For:
o it is accurate
o monads which have nothing to do with control (List, Maybe, Parser?)
will fit in quite nicely
Against:
o the Haskell learning curve gets even steeper
o There's a bit of a conflict between being easy to use and being
mathematically pure (e.g., Num is almost a ring but not quite
(fromInteger springs to mind)). If we put things in Mathematics,
the mathematicians have a strong argument for doing things the
"Right Way" but if we leave it in Control, then the pragmatists
retains some, ummm, control.
I'm not sure myself if I think this is a good thing but I thought I'd
throw it out and see if anyone else likes it enough to pick up.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
ps Irrespective of this, I think Mathematics is a good idea because
sooner or later, someone is going to add matrix ops, rings, monoids,
categories, etc. to the library and they will want a place to hold
them.
From reid@cs.utah.edu Thu May 31 23:44:40 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 31 May 2001 16:44:40 -0600
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Simon Marlow writes:
> The only reason that Edison is in a subtree of its own is [...]
Maybe the right thing to do here and in the case of LUD decomposition,
FFT, and other things that Dylan mentioned is to keep these libraries
in the User or Org hierarchies for a while longer. Once things settle
down a bit, we can first of all add "symbolic links" to the real
library:
module Math.FFT( module User.Dylan.FFT2 ) where { import User.Dylan.FFT2 }
and then, when we're really sure that Dylan's version is the right one
to adopt as "the FFT", we could copy the code over and remove Dylan's
copy.
[Yeah, I know that the gist of Dylan's message is that there is no
such thing as "the FFT" - but I'd already typed the example...]
So I propose that we add:
User.Edu.Columbia.Cs.Okasaki.Edison (or whatever Chris's email is)
or that it goes under the name of the current maintainer.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From dpt@math.harvard.edu Thu May 31 23:50:39 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 31 May 2001 18:50:39 -0400
Subject: Draft Libraries Document
In-Reply-To:
References: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com> <3B16B7F6.E219F613@abbess.demon.co.uk>
Message-ID: <20010531185039.A14326@math.harvard.edu>
On Thu, May 31, 2001 at 04:27:14PM -0600, Alastair David Reid wrote:
> While pondering what else we'd put in mathematics other than numeric
> stuff, I hit upon the crazy idea of adding:
>
> Mathematics.Monad
>
> instead of putting Monad in Control (which is the current proposal, I
> believe).
I'd vote against this. Monads are not terribly prominent in
mathematics. They're used in category theory, but the reason they're
in Haskell is because of their usefulness as a control structure.
> o There's a bit of a conflict between being easy to use and being
> mathematically pure (e.g., Num is almost a ring but not quite
> (fromInteger springs to mind)). If we put things in Mathematics,
> the mathematicians have a strong argument for doing things the
> "Right Way" but if we leave it in Control, then the pragmatists
> retains some, ummm, control.
As a side note, "fromInteger" is just fine and belongs with rings.
(See earlier posts). I'm much more annoyed by "abs" and "signum", not
to mention the name "Num" and the inheritance from "Show" (and "Eq").
But that's all irrelevant to the current discussion, except that I
support anything that leads to doing things the "Right Way". :-)
> ps Irrespective of this, I think Mathematics is a good idea because
> sooner or later, someone is going to add matrix ops, rings, monoids,
> categories, etc. to the library and they will want a place to hold
> them.
Hmm. Reading this list, categories don't seem to fit that well. On
reflection, "Mathematics" is extremely broad; perhaps too broad.
Maybe "Algebra" is better?
--Dylan Thurston
From dpt@math.harvard.edu Thu May 31 23:52:31 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 31 May 2001 18:52:31 -0400
Subject: Library hierarchy, contd.
In-Reply-To:
References: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010531185231.A14366@math.harvard.edu>
On Thu, May 31, 2001 at 04:44:40PM -0600, Alastair David Reid wrote:
>
> Simon Marlow writes:
>
> > The only reason that Edison is in a subtree of its own is [...]
>
> Maybe the right thing to do here and in the case of LUD decomposition,
> FFT, and other things that Dylan mentioned is to keep these libraries
> in the User or Org hierarchies for a while longer. ...
For the record, you're probably referring to a message of Jan Skibinski.
Best,
Dylan Thurston
From princepawn@earthlink.net Wed May 2 02:28:28 2001
From: princepawn@earthlink.net (Terrence Brannon)
Date: Tue, 1 May 2001 18:28:28 -0700
Subject: Dimensional analysis with fundeps (some physics comments)
In-Reply-To: <200104110116.SAA01777@mail4.halcyon.com>
References: <200104110116.SAA01777@mail4.halcyon.com>
Message-ID: <15087.25276.355189.814894@gargle.gargle.HOWL>
Excuse me for playing referee here, as I am looking at this discussion
from a very abstract level, as I am a beginning functional-logic
programmer. But my question (primarily for Fergus) is: "has Ashley
shown in her example a means of automating a toUnits imperative in
Haskell that must be done explicitly in Mercury?" If so, then we have
the start of the Haskell-Mercury comparison document which shows an
advantage of Haskell over Mercury.
> I'm cross-posting this to the Libraries list...
>
> At 2001-04-10 18:02, Fergus Henderson wrote:
>
> >Still, the need to insert explicit `toUnits' is
> >annoying, and it would be nice to have a system where every number was
> >already a dimensionless unit.
>
> That's easy:
>
> --
> type Unit rep = Dimensioned Zero Zero Zero rep;
>
> instance (Real a) => Real (Unit a) where
> {
> -- put instances here
> };
> --
>
> Of course you'll have to appropriately declare superclasses of Real, such
> as Num, Ord, Show, Eq etc.
>
> --
> Ashley Yakeley, Seattle WA
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From reid@cs.utah.edu Tue May 8 22:17:50 2001
From: reid@cs.utah.edu (Alastair Reid)
Date: Tue, 8 May 2001 15:17:50 -0600 (MDT)
Subject: lookupFM vs Prelude.lookup
Message-ID: <200105082117.f48LHoR58652@thistle.cs.utah.edu>
This is somewhat well known but I just got caught by it yet again so
I'd like to add it to the list of things that need fixed in hslibs.
Prelude.lookup and lookupFM _almost_ have the same type:
Prelude.lookup :: => a -> [(a,b)] -> Maybe b
lookupFM :: => FM a b -> a -> Maybe b
Close enough that your mind treats them the same, different enough
that Haskell won't.
It'd be much better if these took their arguments in the same order.
That is, either:
Prelude.lookup :: => [(a,b)] -> a -> Maybe b
lookupFM :: => FM a b -> a -> Maybe b
or:
Prelude.lookup :: => a -> [(a,b)] -> Maybe b
lookupFM :: => a -> FM a b -> Maybe b
Despite being on the library committee at the time, I don't understand
why H98 went for the argument order it did (I prefer the FiniteMap
order) but, since it's the standard, I propose that they get swapped
in FiniteMap when things get reorganised.
(I know this will be very painful for people who use FMs heavily
(e.g., GHC) but it's easier to make these changes relatively early.)
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
ps Since FM provides, essentially, the same functionality as Arrays,
it really ought to have a much more similar interface. I'll leave off
the details for now (just apply s/FiniteMap/Array/ to the types of FM
functions and check them off against the Array interface).
pps Is there a list of things to be done to hslibs? It'd be good to
have a place in a CVS tree somewhere where we could add things or to
have John Hughes' Standard Haskell web page software
(http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=0) or
something. The current mail archive isn't as good because it doesn't
have enough structure and there's no place you can go to to find what
is currently agreed on, what is still open to discussion and what is
being ignored. (The same goes for the ffi list.)
From simonmar@microsoft.com Wed May 23 17:43:01 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 23 May 2001 17:43:01 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
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=20
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=20
Libraries which provide functions, types or classes whose purpose
is primarily to express control structure.
=09
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
From qrczak@knm.org.pl Wed May 23 20:16:33 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 23 May 2001 19:16:33 GMT
Subject: Library hierarchy, contd.
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Wed, 23 May 2001 17:43:01 +0100, Simon Marlow pisze:
> below I've appended a new version (relative to Malcolm's last
> version) with some changes which I've listed first.
I will only say that I like it.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From m@ryangunter.com Thu May 24 01:51:34 2001
From: m@ryangunter.com (Mike Gunter)
Date: 23 May 2001 17:51:34 -0700
Subject: Library hierarchy, contd.
In-Reply-To: "Simon Marlow"'s message of "Wed, 23 May 2001 17:43:01 +0100"
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <87ofsjtvqh.fsf@c966553-A.frmt1.sfba.home.com>
> FileFormat -- 'Codec' might be a more accurate name?
> Graphics
> Jpeg
> Ppm
> Png
A nit: "Image" not "Graphics" would be consistent with the terminlogy
of those fields.
mike
From dpt@math.harvard.edu Thu May 24 13:32:59 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 24 May 2001 08:32:59 -0400
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Wed, May 23, 2001 at 05:43:01PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010524083259.A6728@math.harvard.edu>
On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote:
> Data
> Complex -- H98
This seems decidedly out of place here: complex numbers are not
interesting as a data structure, but as a mathematical construct.
(I.e., the instance of Num is the interesting part.)
Part of the motivation for a "Mathematics" hierarchy is to have a
natural place where, e.g., "Complex" would belong.
> Data
> Int
This seems somewhat less out of place, since, IIRC, the functions in
this library deal with low-level representation.
> Algebra
> DomainConstructor -- formerly DoCon
> Geometric -- formerly BasGeomAlg
> Numeric -- exports std. H98 numeric type classes
> DSP
> FastFourierTransform
> Noise
> Oscillator
You make a good point that these current libraries do not fit all that
well under "Mathematics". Maybe we should keep "Numeric" and create a new
"Mathematics" hierarchy which would contain:
- the std. H98 classes. [Incidentally, I agree with Sergio
Mechvelliani that the "Num" class is badly named. I would vastly
prefer to call the class "Ring".]
- the Complex class
- Mechvelliani's classes
- arbitrary precision arithmetic
- matrix classes
Maybe "Computational" would be a better name than "Numeric"?
Best,
Dylan Thurston
From dpt@math.harvard.edu Thu May 24 13:36:35 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 24 May 2001 08:36:35 -0400
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Wed, May 23, 2001 at 05:43:01PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010524083635.B6728@math.harvard.edu>
On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote:
> 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?
In this particular instance, I'd like to use the Edison structures,
and I'd like them to be available in a standard place. But maybe this
just means there should be copies of some of these libraries under the
Data hierarchy.
Best,
Dylan Thurston
From jans@numeric-quest.com Thu May 24 09:37:29 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Thu, 24 May 2001 04:37:29 -0400 (EDT)
Subject: Library hierarchy, contd.
In-Reply-To: <20010524083259.A6728@math.harvard.edu>
Message-ID:
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.
Jan
From simonmar@microsoft.com Thu May 24 15:14:55 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 15:14:55 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
> On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote:
> > Edison -- (opt, uses multi-param type classes)
> > Prelude -- large self-contained packages should have
> > Collection -- their own hierarchy? Like a=20
> vendor branch.
> > Queue -- Or should the whole Edison tree be placed
> > ... -- under [Data.]Structures?
>=20
> In this particular instance, I'd like to use the Edison structures,
> and I'd like them to be available in a standard place. But maybe this
> just means there should be copies of some of these libraries under the
> Data hierarchy.
The only reason that Edison is in a subtree of its own is that no-one
has "decided" what the API for the standard versions of these libraries
should be. Maybe that choice will be to adopt Edison as-is, but that
would rule out using these modules from NHC because of Edison's use of
multi-parameter type classes.
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Thu May 24 16:42:37 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 16:42:37 +0100
Subject: Library hierarchy, contd.
In-Reply-To:
Message-ID:
Simon Marlow :
> > below I've appended a new version (relative to Malcolm's last
> > version) with some changes which I've listed first.
Marcin Kowalczyk:
> I will only say that I like it.
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).
Regards,
Malcolm
From Malcolm.Wallace@cs.york.ac.uk Thu May 24 17:06:54 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 24 May 2001 17:06:54 +0100
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115898@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <6x0AAJ4xDTtQWgAA@cs.york.ac.uk>
> 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).
I vaguely remember agreeing the opposite - to use InitCaps throughout
rather than ALLCAPS. Whatever.
One other point - I have noticed that there is at least one other
Haskell XML processing library (by Peter Thiemann) out there besides
my HaXml. I don't want to claim any monopoly on the `best' or
`standard' way of doing XML, so I'm inclined to go for `HaXml' as
the base name of my package rather than stealing `Xml' prematurely.
Hence, my vote would be for
Text
Html
HaXml
Regards,
Malcolm
From simonmar@microsoft.com Thu May 24 16:58:04 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 16:58:04 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115898@TVP-MSG-01.europe.corp.microsoft.com>
> 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
From ashley@semantic.org Thu May 24 22:27:23 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 24 May 2001 14:27:23 -0700
Subject: Library hierarchy, contd.
Message-ID: <200105242127.OAA14088@mail4.halcyon.com>
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
From igloo@earth.li Thu May 24 22:39:23 2001
From: igloo@earth.li (Ian Lynagh)
Date: Thu, 24 May 2001 22:39:23 +0100
Subject: Library hierarchy, contd.
In-Reply-To: <6x0AAJ4xDTtQWgAA@cs.york.ac.uk>; from Malcolm.Wallace@cs.york.ac.uk on Thu, May 24, 2001 at 05:06:54PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6115898@TVP-MSG-01.europe.corp.microsoft.com> <6x0AAJ4xDTtQWgAA@cs.york.ac.uk>
Message-ID: <20010524223923.A32050@stu163.keble.ox.ac.uk>
On Thu, May 24, 2001 at 05:06:54PM +0100, Malcolm Wallace wrote:
> > 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).
>
> I vaguely remember agreeing the opposite - to use InitCaps throughout
> rather than ALLCAPS. Whatever.
>
> One other point - I have noticed that there is at least one other
> Haskell XML processing library (by Peter Thiemann) out there besides
> my HaXml. I don't want to claim any monopoly on the `best' or
> `standard' way of doing XML, so I'm inclined to go for `HaXml' as
> the base name of my package rather than stealing `Xml' prematurely.
>
> Hence, my vote would be for
>
> Text
> Html
> HaXml
Would
Text
Html
Xml
HaXml
the_other_one
not make more sense?
And personally I think XML and HTML should be all caps as they tend to
be elsewhere.
Ian
From simonmar@microsoft.com Fri May 25 10:12:11 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 10:12:11 +0100
Subject: Library hierarchy, contd.
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD703@TVP-MSG-01.europe.corp.microsoft.com>
> Dylan mentions "matrix classes" and then concludes:
>=20
> > Maybe "Computational" would be a better name than "Numeric"?
>=20
> I've been trying to demonstrate that there more to=20
> "matrix" than just data structure or just simple linear=20
> equation solver. It is easy to come up with the latter,=20
> or with a set of primitive product operations. But people=20
> 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.=20
>=20
> These things are still alive, thank you very much, and=20
> the papers are still written about them every day. Neither
> the problems nor the papers are trivial.
> =20
> Yet they are being ignored in your hierarchy.
> Please, mark at least some spot for them. And do not tie them=20
> 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
From dpt@math.harvard.edu Fri May 25 12:45:15 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Fri, 25 May 2001 07:45:15 -0400
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Wed, May 23, 2001 at 05:43:01PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6F1@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010525074515.A10432@math.harvard.edu>
Here's a concrete proposal for a Mathematics subtree. Following Jan
Skibinski's comment about linear algebra and some thought, I convinced
myself that there is no natural division between
numerical/computational libraries and more "pure" mathematics.
Description:
Mathematics
Libraries for mathematical structures or algorithms.
------
Mathematics
Prelude -- The so-called "numeric" hierarchy from
-- the H98 Prelude
Complex -- Standard H98
Ratio -- Standard H98
DSP
FastFourierTransform
Noise
Oscillator
LinearAlgebra -- Provides a simple-minded matrix implementation
Sparse
LUDecomposition -- Various algorithms/representations go here,
... -- Somebody help me with a good hierarchy.
DomainConstructor -- Mechveliani's library
ExactReal -- Various people have done good work here.
-- Unfortunately, no-one seems to have published
-- their source code in library format.
From simonmar@microsoft.com Fri May 25 13:05:23 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 13:05:23 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com>
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
=20
- Library status
- experimental/stable
- compiler-specific/portable.
=20
- 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
From jans@numeric-quest.com Fri May 25 13:24:41 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Fri, 25 May 2001 08:24:41 -0400 (EDT)
Subject: Library hierarchy, contd.
In-Reply-To: <20010525074515.A10432@math.harvard.edu>
Message-ID:
Sorry for the lengthy discourse, but I was unable
to cut it down even after I re-read it twice :-).
On Fri, 25 May 2001, Dylan Thurston wrote:
> Here's a concrete proposal for a Mathematics subtree. Following Jan
> Skibinski's comment about linear algebra and some thought, I convinced
> myself that there is no natural division between
> numerical/computational libraries and more "pure" mathematics.
Good!
I'll start with some critical comments first, taking
one of the items from your list as an example.
> Description:
> Mathematics
> Libraries for mathematical structures or algorithms.
>
> ------
> Mathematics
> Prelude -- The so-called "numeric" hierarchy from
> -- the H98 Prelude
> Complex -- Standard H98
> Ratio -- Standard H98
> DSP
> FastFourierTransform
Why here? Unless you are referring to one specific
FFT implementation (Donatio?) the FFT can be looked upon
as just one of many tools of linear algebra.
Why FFT? What so sanctimonious about it? Nothing; it
is popular because of its speed, and it is versatile
because of its popularity (I admit, I exaggerate quite a bit
here to make my point :-)). In fact, DFT is one of many
possible vector transformations, and FFT is its fast
implementation. In this case - the unitary transformation.
But you can implement it on many levels: using streams
of bits, blocks of complex numbers (vectors, matrices), etc.
But other unitary transformations have their uses too.
Have you ever heard about Walsh transformation, with
its (orthogonal) basis vectors made of (+1, -1) components, such
as: [1,1,1,1,1,1,1,1], [1,1,1,1,-1,-1,-1,-1], etc? Geophysists
used to employ it (or still do it?) for analysis of their seismic
data. Incidentally, there is also a Walsh-Hadamard transform, a
basic mixing transformation for quantum computations.
How about Hilbert transformation? You can use it to upgrade
real signals to their complex equivalents, such as
sin k*n -> exp i*k*n. Imagine a plot of your original
real signal in X-T coordinates, suddenly augmented by Y-T
"wing", as by some miracle. Very useful, believe me!
Sorry for ruining the FFT altar, but I think we should keep
certain things in a proper perspective. I believe there will
be many implementations of FFT in Haskell libraries - all
depending on the context. DSP, images, generic linear
algebra, etc. would all want their own versions of FFT,
because of specific representation they use.
And that brings me to the second point I want to make.
If I could describe an algorithm, such as FFT, in generic
terms than I would have and example of a fine generic
algorithm. Unfortunately, more often than not I must be datatype
specific. And that means some choice of Matrix and Vector.
A very controversial issue. How to design these two to
satisfy everyone?
I do not think it's possible at all. For a naive user of graphics
those are 2D or 3D entities (or 4D for implementation
reasons). And real too! Represented by arrows so to speak.
Some other users would like to have it n-dimensional
but Double, some need Complex Double, some would be
only happy with a generic "a". Then there is a question
of underlying implementations. Arrays? If yes, then
what kind of arrays? Would lists be satisfactory
and if yes with what size limitations? Or maybe I
can forget about lists and arrays and choose something
else altogether (as I do it in QuantumVector module)?
Facing all those possible choices, should I be arrogant
enough to claim the generic names Vector and Matrix for
something that I choose to implement my own way?
[We once sidestepped at least this controversial naming issue
by calling the things BasicVector and BasicMatrix, respectively.
For the same reason I have introduced the QuantumVector, not just
THE Vector].
------------------------------------------------------
But all those remarks were somewhat pessimistic and destructive.
So here are some constructive ideas:
+ Keep low profile regarding Matrix and Vector concepts.
Do not build anything around Matrix and Vector, but rather
think algorithmically instead. If you must use the two,
treat them more or less as your private stuff.
For example, my module Eigenproblem casts several algoritms in
terms of abstract Hilbert operators and Hilbert spaces.
This is as far as I was able to go abstract-wise for
a moment and I still might improve on it one day.
But that module relies on the lower level implementation module
LinearAlgoritms, which implements everything as lists. Why
lists? Because I still do not like Haskell Arrays as they are
and because I am lazy and lists are easy to work with. But
that's not the point. What is important are the ideas
implemented in those modules, which can be easily re-worked for
any data structure, Haskell arrays included.
+ Expect that each proposed linear algebra library covers a
significant chunk of such "territory" because only then it
can be proven useful and consistent. If a library just
defines a Matrix, it is useless by a virtue of arguments
presented before. If it goes only as far as LUDecomposition
it is naive and simple minded -- good only for solving
linear equations. If it inverts the equations and also
finds eigenvalues of symmetric matrices it is a step in
right direction. If it handles eigenproblems (eigenvalues
and eigenvectors - all or some) of Hermitian operators,
nonsymmetric real operators, up to any kind of operator
of small and medium size problems it is useful.
If it handles big eigenproblems (n > 1000 or so) - no
matter what technology (using "sparse" matrices perhaps)
it uses, it is very good. If it provides Singular Value
Decomposition on a top of all of the above than it should be
considered excellent.
+ Of course, any good linear algebra library would provide
many tools for handling the tasks which I outlined above.
But those are not the goals in themselves, they are
just the tools. What I have in mind here are all those
Choleskys and LUDecompositions, and triangularizations and
tridiagonalization procedures, and Hessenberg matrices,
and QR or QL decompositions, etc.
Do not measure the value of a library by a number of
such tools appearing in it. Value its consistency and
ability to achieve the final solution.
----------------------------------------------------------
Summarizing: LinearAlgebra appearing in hierarchy (after Dylan)
Mathematics
...
LinearAlgebra
NonlinearAlgebra (perhaps)
....
is just one element which should be clearly marked as very
important. But I'd suggest not to mark any of its specifics,
because that's very much the design and implementation choice.
But we could specify what should be expected from a good
linear algebra library, as I tried to describe it above.
Jan
From chak@cse.unsw.edu.au Sat May 26 08:31:27 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sat, 26 May 2001 17:31:27 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010526173127M.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> - 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.
I don't think that it is a good idea to specify a license.
For example, I am convinced that the (L)GPL is the better
licence for the community. Incidentally, the GPL is also
the license of one of the most successful free software
projects ever - Linux - which is certainly also one of the,
if not *the* commercially most successful free software
project. So, I don't buy this GPL is bad for companies
propaganda. In that context, I recommend to read
http://perens.com/Articles/StandTogether.html
Anyway, while I am happy to discuss my position with anybody
who is interested, I don't want to start a big licence
discussion here. All in all, I think, we should let authors
chose their license.
I am sorry (honestly) if that creates a problem for you, but
on the other hand, I am not keen on having a particular
company influence our licencing policies - certainly not in
something which we want to sell as a standard to the
community.
> - 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.
Absolutely.
> 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).
Don't libraries need their own build system anyway if they
are to be portable?
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)?
Cheers,
Manuel
From dpt@math.harvard.edu Sat May 26 13:27:07 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Sat, 26 May 2001 08:27:07 -0400
Subject: Licenses
In-Reply-To: <20010526173127M.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Sat, May 26, 2001 at 05:31:27PM +1000
References: <9584A4A864BD8548932F2F88EB30D1C611589B@TVP-MSG-01.europe.corp.microsoft.com> <20010526173127M.chak@cse.unsw.edu.au>
Message-ID: <20010526082707.A12896@math.harvard.edu>
On Sat, May 26, 2001 at 05:31:27PM +1000, Manuel M. T. Chakravarty wrote:
> "Simon Marlow" wrote,
>
> > - 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.
>
> I don't think that it is a good idea to specify a license.
> For example, I am convinced that the (L)GPL is the better
> licence for the community. ...
I'm a big fan of the GPL; however, you must know that picking the GPL
for a library (particularly a standard library) is a very political
act. Even the FSF only does this occasionally. The LGPL seems less
controversial to me, and would be my choice. (But I'm not the one to
choose, and I will be happy as long as the libraries are free (libre).)
I also think that a standard license for the standard libraries is
important. With every new license that gets involved in a project, I
have to make a decision; I'd rather make that decision just once, when
I decide to use Haskell.
[Apologies if this starts a big licensing discussion. I think this is
one of the very few times it is appropriate; I believe these issues
are important.]
Best,
Dylan Thurston
From simonmar@microsoft.com Mon May 28 10:17:03 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 10:17:03 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
Manuel writes:
> I don't think that it is a good idea to specify a license.
> For example, I am convinced that the (L)GPL is the better
> licence for the community. Incidentally, the GPL is also
> the license of one of the most successful free software
> projects ever - Linux - which is certainly also one of the,
> if not *the* commercially most successful free software
> project. So, I don't buy this GPL is bad for companies
> propaganda.
It's not propaganda. The fact is if any of the standard libraries use
the LGPL, then some people will be prevented from using them. That's
the last thing we want, right? Now you might argue from a moral
standpoint that the companies that these people work for are basing
their business models on intellectual property and therefore deserve
everything they get, but we're not trying to do open source advocacy
here, we're just trying to put together a set of libraries that everyone
can use.
Maybe it's possible to use a dual license (ie. "pick one of the
following licenses") scheme, but I'm not a license expert.
Cheers,
Simon
PS. usual employer-related disclaimers apply.
From simonmar@microsoft.com Mon May 28 11:55:40 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 11:55:40 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611589E@TVP-MSG-01.europe.corp.microsoft.com>
> 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
From Dominic.J.Steinitz@BritishAirways.com Mon May 28 14:05:48 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 28 May 2001 13:05:48 Z
Subject: The next step
Message-ID: <"035483B124D2C010*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
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
From igloo@earth.li Mon May 28 14:59:10 2001
From: igloo@earth.li (Ian Lynagh)
Date: Mon, 28 May 2001 14:59:10 +0100
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 10:17:03AM +0100
References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010528145910.A22527@stu163.keble.ox.ac.uk>
On Mon, May 28, 2001 at 10:17:03AM +0100, Simon Marlow wrote:
> Manuel writes:
> > I don't think that it is a good idea to specify a license.
> > For example, I am convinced that the (L)GPL is the better
> > licence for the community. Incidentally, the GPL is also
> > the license of one of the most successful free software
> > projects ever - Linux - which is certainly also one of the,
> > if not *the* commercially most successful free software
> > project. So, I don't buy this GPL is bad for companies
> > propaganda.
>
> It's not propaganda. The fact is if any of the standard libraries use
> the LGPL, then some people will be prevented from using them.
If there is an LGPLed library then you can write a new version which
matches the spec and release it under the BSD license if you wish.
Then in a similar way to how the implementation of a library you have
may use GHC extensions (say) you could use an implementation with a BSD
license. I would suggest that the specs be public domain and the
compilers can chose to ship whatever version they think best.
Ian
From simonmar@microsoft.com Mon May 28 15:14:03 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 15:14:03 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD717@TVP-MSG-01.europe.corp.microsoft.com>
> -----Original Message-----
> From: Steinitz, Dominic J=20
> [mailto:Dominic.J.Steinitz@BritishAirways.com]=20
> Sent: Monday, May 28, 2001 2:06 PM
> To: Simon Marlow
> Cc: chak; libraries
> Subject: RE: The next step
>=20
>=20
> Can someone explain what licenses are commonly avaible and=20
> what they mean or point me at some references?
>=20
> Dominic.
>=20
> --------------------------------------------------------------
> -----------------------------------
> 21st century air travel http://www.britishairways.com
>=20
From simonmar@microsoft.com Mon May 28 16:14:29 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 16:14:29 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A2@TVP-MSG-01.europe.corp.microsoft.com>
Frank Atanassow writes:
> Some people don't see it that way. They would say that the=20
> GPL is the _less_
> restrictive license because it ensures that everybody=20
> benefits (equally) from
> everybody else's improvements. From that perspective,=20
> companies benefit also
> since they may use and improve the code, provided they=20
> "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. =20
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
From ken@digitas.harvard.edu Mon May 28 16:49:37 2001
From: ken@digitas.harvard.edu (Ken Shan)
Date: Mon, 28 May 2001 11:49:37 -0400
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A2@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 04:14:29PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C61158A2@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010528114937.C5546@digitas.harvard.edu>
--dTy3Mrz/UPE2dbVg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> 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.
Really? I've assumed that GPL only deals with copyright, and
techniques one uses in code are matters of patents and trade secrets.
Here's a message on what license to use, from gnu.misc.discuss:
http://groups.google.com/groups?hl=3Den&lr=3D&safe=3Doff&ic=3D1&th=3D8e757e=
c573e5498,15&seekm=3Drjzoeoifn9.fsf%40ssv2.dina.kvl.dk
--=20
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
>>My SUV is bigger than your bike. Stay out of the damn road!
>Kiss my reflector, SUV-boy
I'm too busy sucking on my tailpipe, bike dude.
--dTy3Mrz/UPE2dbVg
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7EnORzjAc4f+uuBURAuvqAKDh5RWFlGNDEwFhJN0/Ee3Pp8F1mwCglex3
ZJDEGscrjHQi03h0Ly/9z/c=
=9zXR
-----END PGP SIGNATURE-----
--dTy3Mrz/UPE2dbVg--
From simonmar@microsoft.com Mon May 28 17:48:04 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 28 May 2001 17:48:04 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
> On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> > 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=20
> to use similar
> > techniques in proprietary code, the owner of the=20
> proprietary code is in
> > a legally difficult position.
>=20
> Really? I've assumed that GPL only deals with copyright, and
> techniques one uses in code are matters of patents and trade secrets.
Sure, but if the code in the proprietary source ends up looking similar
enough to the GPL code, it might be hard to prove that it wasn't a
derived work. This is a risk you just don't want to take if your
business depends on keeping your sources non-free.
Cheers,
Simon
From chak@cse.unsw.edu.au Tue May 29 04:55:58 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 13:55:58 +1000
Subject: The next step
In-Reply-To: <"035483B124D2C010*/c=GB/admd=ATTMAIL/prmd=BA/o=British
Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
References: <"035483B124D2C010*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways
PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Message-ID: <20010529135558P.chak@cse.unsw.edu.au>
"Steinitz, Dominic J" 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
From chak@cse.unsw.edu.au Tue May 29 05:42:05 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 14:42:05 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529144205R.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> > > 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.
> >
> > Really? I've assumed that GPL only deals with copyright, and
> > techniques one uses in code are matters of patents and trade secrets.
>
> Sure, but if the code in the proprietary source ends up looking similar
> enough to the GPL code, it might be hard to prove that it wasn't a
> derived work. This is a risk you just don't want to take if your
> business depends on keeping your sources non-free.
This is the first time, I have heard about such a scenario
and I don't think that it is realistic. For an infringement
of copyright (rather than a patent), non-trivial amounts of
code must be basically the same. This won't happen unless
the programmer has a photographic memory or actually copies
parts of the code.
Consider that companies like IBM and SGI happily deal in
GPLed code.
Cheers,
Manuel
From chak@cse.unsw.edu.au Tue May 29 06:49:42 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 15:49:42 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529154942V.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> Manuel writes:
> > I don't think that it is a good idea to specify a license.
> > For example, I am convinced that the (L)GPL is the better
> > licence for the community. Incidentally, the GPL is also
> > the license of one of the most successful free software
> > projects ever - Linux - which is certainly also one of the,
> > if not *the* commercially most successful free software
> > project. So, I don't buy this GPL is bad for companies
> > propaganda.
>
> It's not propaganda. The fact is if any of the standard libraries use
> the LGPL, then some people will be prevented from using them. That's
> the last thing we want, right? Now you might argue from a moral
> standpoint that the companies that these people work for are basing
> their business models on intellectual property and therefore deserve
> everything they get, but we're not trying to do open source advocacy
> here, we're just trying to put together a set of libraries that everyone
> can use.
Depends on the library. I agree with you that the really
core stuff and in particular the "language
extension"-related libraries should be completely
unrestricted.
However, many libraries in the current hslibs and, judging
from the discussion so far, many new libraries are not
belonging to this core. What is the problem if they are
LGPL? LGPL code can be linked into proprietary code without
any problems. There is lots of proprietary code being based
on code generated by gcc and linked against its C library.
> Maybe it's possible to use a dual license (ie. "pick one of the
> following licenses") scheme, but I'm not a license expert.
It is possible. Perl does it. But why? If a license is
released under the LGPL, it can be used in proprietary code.
Only if the library itself is modified, modifications have
to be contributed back. And, yes, if I write a library and
somebody improves it and distributes the improvements[1], I
want them, too. What's wrong with this?
Cheers,
Manuel
[1] Note that if GPL or LGPL code is modified and only used
in-house, there is no need to release the modifications.
From chak@cse.unsw.edu.au Tue May 29 06:52:04 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 15:52:04 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589E@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611589E@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529155204L.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > 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.
Technically, I think, it might be cleaner to have build
system for the libraries that works with all compilers,
rather than different build systems for different
compilers.
Cheers,
Manuel
From franka@cs.uu.nl Tue May 29 12:15:09 2001
From: franka@cs.uu.nl (Frank Atanassow)
Date: Tue, 29 May 2001 13:15:09 +0200
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 05:48:04PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C61158A3@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529131509.C5078@cs.uu.nl>
Simon Marlow wrote (on 28-05-01 17:48 +0100):
>
> > On 2001-05-28T16:14:29+0100, Simon Marlow wrote:
> > > 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.
> >
> > Really? I've assumed that GPL only deals with copyright, and
> > techniques one uses in code are matters of patents and trade secrets.
>
> Sure, but if the code in the proprietary source ends up looking similar
> enough to the GPL code, it might be hard to prove that it wasn't a
> derived work. This is a risk you just don't want to take if your
> business depends on keeping your sources non-free.
Not that I buy this latest doublethink [1], but some people might call that
poetic justice.
Some people might.
But not me. No, sir...
[1] doublethink
--
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-3791
From simonmar@microsoft.com Tue May 29 11:45:55 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 11:45:55 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A5@TVP-MSG-01.europe.corp.microsoft.com>
> > Sure, but if the code in the proprietary source ends up=20
> looking similar
> > enough to the GPL code, it might be hard to prove that it wasn't a
> > derived work. This is a risk you just don't want to take if your
> > business depends on keeping your sources non-free.
>=20
> This is the first time, I have heard about such a scenario
> and I don't think that it is realistic. For an infringement
> of copyright (rather than a patent), non-trivial amounts of
> code must be basically the same. This won't happen unless
> the programmer has a photographic memory or actually copies
> parts of the code.
Right or wrong, the L?GPL simply scares the bejeezus out of corporate
types (with notable exceptions like IBM & HP). I'm not going to argue
whether this is right or wrong - I'm just asking whether those who
favour the LGPL could compromise slightly and make life a little easier
for some of us. There's no problem with "external" libraries like
Gtk+Haskell, just the libraries we're going to keep in the main
repository (call it the core set or whatever, basically the libraries
we're going to end up distributing with GHC).
On the other hand, I certainly don't want to discourage people from
contributing because they don't like our license requirements. But
things are going to get real messy if every file has its own license.
Looking down the hierarchy we have at the moment, much of the existing
code (from hslibs, the FFI project etc.) is either under the GHC license
or is licenseless. So would it be too painful to ask that anyone who
wants to contribute code under the LGPL does it in a separate part of
the repository?
Cheers,
Simon
From simonmar@microsoft.com Tue May 29 11:27:57 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 11:27:57 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD71C@TVP-MSG-01.europe.corp.microsoft.com>
> > I imagined putting the standard libraries in a single=20
> 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=20
> to support
> > ways, GHCi .o files, DLLs, split object files etc. etc.),=20
> but NHC and
> > Hugs require a much more minimal build system.
>=20
> Technically, I think, it might be cleaner to have build
> system for the libraries that works with all compilers,
> rather than different build systems for different
> compilers.=20
The problem with this is, the Hugs & NHC guys don't want the GHC build
system, and I don't want to rewrite our build system to do the same
stuff it already does (and likely the Hugs & NHC guys wouldn't like the
results anyway :-). We are doomed to multiple build systems I'm afraid.
Cheers,
Simon
From chak@cse.unsw.edu.au Tue May 29 14:40:02 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 23:40:02 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6058DD71C@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C6058DD71C@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529234002D.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > > 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.
> >
> > Technically, I think, it might be cleaner to have build
> > system for the libraries that works with all compilers,
> > rather than different build systems for different
> > compilers.
>
> The problem with this is, the Hugs & NHC guys don't want the GHC build
> system, and I don't want to rewrite our build system to do the same
> stuff it already does (and likely the Hugs & NHC guys wouldn't like the
> results anyway :-). We are doomed to multiple build systems I'm afraid.
I am just worrying that this will put off potential library
authors or at least lessen their motivation to make the
library portable.
Cheers,
Manuel
From chak@cse.unsw.edu.au Tue May 29 14:50:47 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 29 May 2001 23:50:47 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A5@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61158A5@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010529235047N.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > > Sure, but if the code in the proprietary source ends up
> > looking similar
> > > enough to the GPL code, it might be hard to prove that it wasn't a
> > > derived work. This is a risk you just don't want to take if your
> > > business depends on keeping your sources non-free.
> >
> > This is the first time, I have heard about such a scenario
> > and I don't think that it is realistic. For an infringement
> > of copyright (rather than a patent), non-trivial amounts of
> > code must be basically the same. This won't happen unless
> > the programmer has a photographic memory or actually copies
> > parts of the code.
>
> Right or wrong, the L?GPL simply scares the bejeezus out of corporate
> types (with notable exceptions like IBM & HP). I'm not going to argue
> whether this is right or wrong - I'm just asking whether those who
> favour the LGPL could compromise slightly and make life a little easier
> for some of us. There's no problem with "external" libraries like
> Gtk+Haskell, just the libraries we're going to keep in the main
> repository (call it the core set or whatever, basically the libraries
> we're going to end up distributing with GHC).
>
> On the other hand, I certainly don't want to discourage people from
> contributing because they don't like our license requirements. But
> things are going to get real messy if every file has its own license.
> Looking down the hierarchy we have at the moment, much of the existing
> code (from hslibs, the FFI project etc.) is either under the GHC license
> or is licenseless. So would it be too painful to ask that anyone who
> wants to contribute code under the LGPL does it in a separate part of
> the repository?
Maybe I haven't paid enough attention to the previous
discussion about the library organisation, but what are the
criteria for libraries to be in the magic set which should
not use the LGPL?
Anyway, if everybody else thinks that requiring a BSD style
license is a good idea, just ignore me.
Cheers,
Manuel
From simonmar@microsoft.com Tue May 29 15:17:13 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 15:17:13 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A6@TVP-MSG-01.europe.corp.microsoft.com>
> > On the other hand, I certainly don't want to discourage people from
> > contributing because they don't like our license requirements. But
> > things are going to get real messy if every file has its=20
> own license.
> > Looking down the hierarchy we have at the moment, much of=20
> the existing
> > code (from hslibs, the FFI project etc.) is either under=20
> the GHC license
> > or is licenseless. So would it be too painful to ask that=20
> anyone who
> > wants to contribute code under the LGPL does it in a=20
> separate part of
> > the repository?
>=20
> Maybe I haven't paid enough attention to the previous
> discussion about the library organisation, but what are the
> criteria for libraries to be in the magic set which should
> not use the LGPL? =20
I wasn't planning to separate the libraries logically (i.e. you still
get all the libraries when you install GHC), only separate them
physically by keeping the sources in different parts of the repository.
This is I think the minimum we need to do if we have code with different
licenses in the same tree. I'll do this on a lazy basis: as soon as
someone comes along with LGPL code they want to contribute, we'll set up
the repository.
The criteria for a library to be in the "magic set" (I'm going to call
it the core set for now) is nothing more than conforming to a set of
guidelines that we've yet to decide on. I'm drafting up a proposal at
the moment.
Cheers,
Simon
From qrczak@knm.org.pl Tue May 29 15:47:15 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Tue, 29 May 2001 16:47:15 +0200 (CEST)
Subject: The next step
In-Reply-To: <20010529235047N.chak@cse.unsw.edu.au>
Message-ID:
On Tue, 29 May 2001, Manuel M. T. Chakravarty wrote:
> Anyway, if everybody else thinks that requiring a BSD style
> license is a good idea,
I don't. It's ok for my contributions to be BSD, but I'm not sure that we
should ban licenses like LGPL.
--
Marcin 'Qrczak' Kowalczyk
From cwitty@newtonlabs.com Wed May 30 00:24:11 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 29 May 2001 16:24:11 -0700
Subject: The next step
In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Tue, 29 May 2001 15:49:42 +1000"
References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com> <20010529154942V.chak@cse.unsw.edu.au>
Message-ID:
"Manuel M. T. Chakravarty" writes:
> However, many libraries in the current hslibs and, judging
> from the discussion so far, many new libraries are not
> belonging to this core. What is the problem if they are
> LGPL? LGPL code can be linked into proprietary code without
> any problems. There is lots of proprietary code being based
> on code generated by gcc and linked against its C library.
To link your code with LGPL code, you effectively must either provide
the user with object files for your code, or arrange for the LGPL code
to be contained in a shared library (the actual requirement is that
the user be able to modify the LGPL code and obtain a version of your
program that uses these modifications). The former option is a
significant cost in terms of how annoying it is to distribute your
code. I don't know if the latter is even possible -- can all the
Haskell implementations create shared libraries?
At any rate, while it is certainly possible to link proprietary code
with LGPL code, I wouldn't say that the combination is "without any
problems".
Carl Witty
From chak@cse.unsw.edu.au Wed May 30 11:29:41 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 30 May 2001 20:29:41 +1000
Subject: The next step
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C61158A6@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C61158A6@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010530202941S.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > > On the other hand, I certainly don't want to discourage people from
> > > contributing because they don't like our license requirements. But
> > > things are going to get real messy if every file has its
> > own license.
> > > Looking down the hierarchy we have at the moment, much of
> > the existing
> > > code (from hslibs, the FFI project etc.) is either under
> > the GHC license
> > > or is licenseless. So would it be too painful to ask that
> > anyone who
> > > wants to contribute code under the LGPL does it in a
> > separate part of
> > > the repository?
> >
> > Maybe I haven't paid enough attention to the previous
> > discussion about the library organisation, but what are the
> > criteria for libraries to be in the magic set which should
> > not use the LGPL?
>
> I wasn't planning to separate the libraries logically (i.e. you still
> get all the libraries when you install GHC), only separate them
> physically by keeping the sources in different parts of the repository.
> This is I think the minimum we need to do if we have code with different
> licenses in the same tree. I'll do this on a lazy basis: as soon as
> someone comes along with LGPL code they want to contribute, we'll set up
> the repository.
That's certainly a good idea.
> The criteria for a library to be in the "magic set" (I'm going to call
> it the core set for now) is nothing more than conforming to a set of
> guidelines that we've yet to decide on.
That's, I think, the crucial point. I am happy to define a
core for which we ask to use a BSD-style license in terms of
how fundamental the provided functionality is. Outside of
this fundamental functionality, I am against prescribing a
license (except requiring it to be "open source", as defined
by the OSI).
To give you an idea of what I mean by fundamental
functionality. For example, the FFI libraries are
fundamental. Their use should be unrestricted. A library
like Edison is on the borderline. QuickCheck or HOpenGL are
clearly outside of the core functionality.
Cheers,
Manuel
From simonmar@microsoft.com Wed May 30 14:42:27 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 14:42:27 +0100
Subject: Draft Libraries Document
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD732@TVP-MSG-01.europe.corp.microsoft.com>
I'm drafting up a document along the lines I mentioned in my previous
message. For the time being, I'll keep the latest version here:
http://www.haskell.org/~simonmar/libraries/libraries.html
it's pretty minimal at the moment with only a few sections containing
material. Suggestions and comments on what is there already are
welcome.
Cheers,
Simon
From simonmar@microsoft.com Wed May 30 16:42:08 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 16:42:08 +0100
Subject: Draft Libraries Document
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com>
> http://www.haskell.org/~simonmar/libraries/libraries.html
has been updated, now contains descriptions of the top-level names in
the hierarchy, and some text in the programming conventions section
(mostly copied over from the hslibs docs).
Cheers,
Simon
From simonmar@microsoft.com Thu May 31 14:54:31 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 31 May 2001 14:54:31 +0100
Subject: The next step
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158AE@TVP-MSG-01.europe.corp.microsoft.com>
> "Manuel M. T. Chakravarty" writes:
>=20
> > However, many libraries in the current hslibs and, judging
> > from the discussion so far, many new libraries are not
> > belonging to this core. What is the problem if they are
> > LGPL? LGPL code can be linked into proprietary code without
> > any problems. There is lots of proprietary code being based
> > on code generated by gcc and linked against its C library.
>=20
> To link your code with LGPL code, you effectively must either provide
> the user with object files for your code, or arrange for the LGPL code
> to be contained in a shared library (the actual requirement is that
> the user be able to modify the LGPL code and obtain a version of your
> program that uses these modifications). The former option is a
> significant cost in terms of how annoying it is to distribute your
> code. I don't know if the latter is even possible -- can all the
> Haskell implementations create shared libraries?
>=20
> At any rate, while it is certainly possible to link proprietary code
> with LGPL code, I wouldn't say that the combination is "without any
> problems".
Thanks, I wasn't aware of that particular restriction in the LGPL. And
having thought about it, I don't think it is reasonable to put libraries
under the standard LGPL in Haskell. Here's why:
- the license requires that any program linked with the library
is provided as object code that can be relinked with a modified
version of the library. In order to do this with GHC, you have
to compile your application with all cross-module optimisation
turned off (although the license does have a cryptic sentence
in section 6(a) that sounds like it might apply to this situation,
but I don't know what a "definitions file" is).
The LGPL also goes into some detail about when a program becomes
a derived work by virtue of "including things from header files",
in particular it says that inline functions may be "ten lines or
less" If we translate this to mean cross-module optimisation, it
essentially means that we have to turn off this optimisation or
change the license to say something that makes sense for Haskell.
=20
- You can't make any local incompatible modifications to GHC and
not distribute them, if you intend to link your non-free program
with LGPL libs (since you have to be able to recompile modified
versions of the libs and re-link to the original program). =20
- Similarly, you can't use a non-free compiler.
- You have to be able to compile your modified version of the
library. That means the library can't depend on any non-free
libraries, which places extra restrictions on what you can do with
any BSD licensed libraries you're using, if I'm not mistaken.
In a nutshell, the LGPL makes sense when (a) there is a well-defined
calling convention between application and library, and (b) compilers
are interchangeable. Neither of these is true for Haskell (indeed, they
are becoming less true for C and C++ these days).
Given these extra restrictions, I imagine that anyone producing a
non-free program would have to avoid the LGPL libraries altogether.
Cheers,
Simon
From malcolm@abbess.demon.co.uk Thu May 31 22:30:30 2001
From: malcolm@abbess.demon.co.uk (Malcolm Wallace)
Date: Thu, 31 May 2001 22:30:30 +0100
Subject: Draft Libraries Document
References: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <3B16B7F6.E219F613@abbess.demon.co.uk>
Simon Marlow wrote:
>
> > http://www.haskell.org/~simonmar/libraries/libraries.html
>
> has been updated, now contains descriptions of the top-level names in
> the hierarchy,
I notice you have gone for a "Numeric" category, rather than the
"Mathematics" top-level category suggested by Dylan. I know there
hasn't been much discussion about the layout and contents of the
specifically mathematical parts of the hierarchy, but Dylan's is
the only current proposal from anyone who claims to know the subject
in depth. :-) My instinct would be to go with the more general
"Mathematics", whatever we later decided to put inside it.
Regards,
Malcolm
From reid@cs.utah.edu Thu May 31 23:27:14 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 31 May 2001 16:27:14 -0600
Subject: Draft Libraries Document
In-Reply-To: <3B16B7F6.E219F613@abbess.demon.co.uk>
References: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com>
<3B16B7F6.E219F613@abbess.demon.co.uk>
Message-ID:
Malcolm Wallace writes:
> I notice you have gone for a "Numeric" category, rather than the
> "Mathematics" top-level category suggested by Dylan.
While pondering what else we'd put in mathematics other than numeric
stuff, I hit upon the crazy idea of adding:
Mathematics.Monad
instead of putting Monad in Control (which is the current proposal, I
believe).
For:
o it is accurate
o monads which have nothing to do with control (List, Maybe, Parser?)
will fit in quite nicely
Against:
o the Haskell learning curve gets even steeper
o There's a bit of a conflict between being easy to use and being
mathematically pure (e.g., Num is almost a ring but not quite
(fromInteger springs to mind)). If we put things in Mathematics,
the mathematicians have a strong argument for doing things the
"Right Way" but if we leave it in Control, then the pragmatists
retains some, ummm, control.
I'm not sure myself if I think this is a good thing but I thought I'd
throw it out and see if anyone else likes it enough to pick up.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
ps Irrespective of this, I think Mathematics is a good idea because
sooner or later, someone is going to add matrix ops, rings, monoids,
categories, etc. to the library and they will want a place to hold
them.
From reid@cs.utah.edu Thu May 31 23:44:40 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 31 May 2001 16:44:40 -0600
Subject: Library hierarchy, contd.
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Simon Marlow writes:
> The only reason that Edison is in a subtree of its own is [...]
Maybe the right thing to do here and in the case of LUD decomposition,
FFT, and other things that Dylan mentioned is to keep these libraries
in the User or Org hierarchies for a while longer. Once things settle
down a bit, we can first of all add "symbolic links" to the real
library:
module Math.FFT( module User.Dylan.FFT2 ) where { import User.Dylan.FFT2 }
and then, when we're really sure that Dylan's version is the right one
to adopt as "the FFT", we could copy the code over and remove Dylan's
copy.
[Yeah, I know that the gist of Dylan's message is that there is no
such thing as "the FFT" - but I'd already typed the example...]
So I propose that we add:
User.Edu.Columbia.Cs.Okasaki.Edison (or whatever Chris's email is)
or that it goes under the name of the current maintainer.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From dpt@math.harvard.edu Thu May 31 23:50:39 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 31 May 2001 18:50:39 -0400
Subject: Draft Libraries Document
In-Reply-To:
References: <9584A4A864BD8548932F2F88EB30D1C6058DD733@TVP-MSG-01.europe.corp.microsoft.com> <3B16B7F6.E219F613@abbess.demon.co.uk>
Message-ID: <20010531185039.A14326@math.harvard.edu>
On Thu, May 31, 2001 at 04:27:14PM -0600, Alastair David Reid wrote:
> While pondering what else we'd put in mathematics other than numeric
> stuff, I hit upon the crazy idea of adding:
>
> Mathematics.Monad
>
> instead of putting Monad in Control (which is the current proposal, I
> believe).
I'd vote against this. Monads are not terribly prominent in
mathematics. They're used in category theory, but the reason they're
in Haskell is because of their usefulness as a control structure.
> o There's a bit of a conflict between being easy to use and being
> mathematically pure (e.g., Num is almost a ring but not quite
> (fromInteger springs to mind)). If we put things in Mathematics,
> the mathematicians have a strong argument for doing things the
> "Right Way" but if we leave it in Control, then the pragmatists
> retains some, ummm, control.
As a side note, "fromInteger" is just fine and belongs with rings.
(See earlier posts). I'm much more annoyed by "abs" and "signum", not
to mention the name "Num" and the inheritance from "Show" (and "Eq").
But that's all irrelevant to the current discussion, except that I
support anything that leads to doing things the "Right Way". :-)
> ps Irrespective of this, I think Mathematics is a good idea because
> sooner or later, someone is going to add matrix ops, rings, monoids,
> categories, etc. to the library and they will want a place to hold
> them.
Hmm. Reading this list, categories don't seem to fit that well. On
reflection, "Mathematics" is extremely broad; perhaps too broad.
Maybe "Algebra" is better?
--Dylan Thurston
From dpt@math.harvard.edu Thu May 31 23:52:31 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Thu, 31 May 2001 18:52:31 -0400
Subject: Library hierarchy, contd.
In-Reply-To:
References: <9584A4A864BD8548932F2F88EB30D1C6115896@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010531185231.A14366@math.harvard.edu>
On Thu, May 31, 2001 at 04:44:40PM -0600, Alastair David Reid wrote:
>
> Simon Marlow writes:
>
> > The only reason that Edison is in a subtree of its own is [...]
>
> Maybe the right thing to do here and in the case of LUD decomposition,
> FFT, and other things that Dylan mentioned is to keep these libraries
> in the User or Org hierarchies for a while longer. ...
For the record, you're probably referring to a message of Jan Skibinski.
Best,
Dylan Thurston