Re: GHC licence

[Fergus Henderson]

On 22-Jul-1998, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> I do think that the GNU license would be a mistake -- as I understand, it   
> would prevent the use of GHC in commercial projects, and I'm pretty sure   
> that's something Simon wants to *encourage*.

There are two simple ways to avoid this problem.

One is to license the compiler itself under the GPL but the libraries
and runtime system under the LGPL (GNU Library General Public License).
For example, this is the approach we used for the Mercury implementation.

Another is to license them all under the GPL but to add a special exception
that means that programs linked with the libraries and runtime are not
covered by the GPL.  This is the approach taken by GNU C and GNU Ada.

Here's the exact wording of the exception used for the GNU C runtime
(from libgcc2.c in the gcc distribution):

/* As a special exception, if you link this library with other files,
   some of which are compiled with GCC, to produce an executable,
   this library does not by itself cause the resulting executable
   to be covered by the GNU General Public License.
   This exception does not however invalidate any other reasons why
   the executable file might be covered by the GNU General Public License.  */

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: Scoped typed variables.

[Ralf Hinze]

|   This sounds great, but it could break old code, of course.  This would have a
| different type under Ralf's proposal than Haskell 1.4:
| (id :: a -> a, id :: a -> a)
| However, I think something like it is the only sane way to go.  Whatever we do, type
| variables should scope consistently.  With proposal "A" as is (such that it wouldn't
| break old code, and just like in hugs 1.3c), a type variable would scope differently 
|if
| it was in a pattern verses being in an expression.  Ralf's proposal fixes that 
|nicely,
| and I don't think the cost in old code here would be very high.

By the way note that currently it is not possible to enfore that two
subexpressions have the same type (asTypeOf works only for some special
cases). So if the intent is that both occurences of `id' have the same
type
(id :: a -> a, id :: a -> a)
does not work.

Ralf

Re: Fw: Could Haskell be taken over by Microsoft?

[Jorgen Frojk Kjaersgaard]

Dinesh Vadhia wrote:

> The recent thread of notes to "Could Haskell be taken over by Microsoft?"
> bears out what I've been thinking over the past year about Haskell which is
> ... "How on Earth is this Haskell stuff, not withstanding its merits, ever
> going to make it in the real world?".  From what I've read and seen I really
> see Haskell as nothing more than another 'interesting' computer language but
> ultimately confined to the academic/research community.
>
> The situation would change dramatically if say, a Microsoft, picked it up
> and ran with it.  But they wouldn't do it unless they had full control over
> the language which the Haskell community wouldn't allow.

Every popular language, except Java, is in some respect "public domain". The
language definitions of C, C++, Modula-2, Oberon, Pearl, you name it, are all
public domain and not under control of a single company but by a commission or
a group of researchers. These languages have good public domain implementations
as well. I do believe that a language must be public domain and have public
domain implementations to gain success in the long run. Being public domain
makes a language accessible to everybody from students and hobbyists to large
corporations. I know a company that works for military (NATO and the DoD) that
changed from Ada to C++ solely because they could get the Gnu C++ compiler for
free for all their supported platforms. Few languages can do without commercial
implementations, though,  since there are companies that will not use a PD
compiler for their work. We need the best of both worlds.

> On the other hand, Haskell could follow the Linux route with a GNU license.
> No problem with this except how many customers are seriously going to take
> the leap of faith.  It is a sad fact of life that the majority of the "real"
> market consists of conservative customers who look for a number of
> (non-product) things from a technology component including supplier status,
> pricing, support, and so on.  Having a a number of small companies providing
> Haskell support won't cut the mustard in the real 'big' world.

I think you seriously underestimate the GNU/Linux world. The GNU C and C++
compilers are probably the most popular compilers in the world. It's hard to
prove, but I don't think C++ had gained its very large popularity had it not
been for its PD definition and its good PD implementations.

I believe it is possible to make Haskell very popular if we focus more on its
practical use. We should focus more on developing libraries for "everyday
programming" and on improving code quality. Sure, it will benefit Haskell if a
commercial company develops libraries and more optimized compilers, but we, the
Haskell community, could also do it ourselves if more people got involved, also
outside the universities. The Linux community has shown that an OS can be built
by a large number of volunteers, so why not a compiler, development environment
and library?

> If the Haskell community wants Haskell to be a significant product in the
> computer language and software development markets then the only route open
> is to setup a company whose sole purpose is that ... Everything else (for
> the Haskell community) is just wishful thinking.

Can you mention any example of a company that has been established to maintain
a programming language, except JavaSoft, which can exist only because it is
sponsored by Sun?

regards, Joergen

--

Joergen Froejk Kjaersgaard
Systems Engineer, Informaticon Systemeering
...Linux - for freedom of choice... www.linux.org

Re: Scoped typed variables.

[Ralf Hinze]

| > > Just as a sanity check, following an augmented proposal "A" where we can also
| > > annotate the return type as well, consider these:
| > >
| > > f :: a -> (a -> a) -> a
| > > f x = \g -> (g :: a -> a) x
| > >
| > > f (x :: a) :: (a -> a) -> a = \g -> (g :: a -> a) x
| > >
| > > Which of these two is correct, and why?  Why not both?
| >
| > Under "A+B", these would be equivalent.  Under "A++" (Mark's original
| > "A", only, plus the return types), the second of these is "correct"
| > (assuming a restricted interpretation of "a" is what was intended), but
| > in the first, the a's in sig and body are bound quite separately, so the
| > local type annotation would be too general.
| >
| 
| I'm not sure what the parenthetical comment about the interpretation of a means -
| take the definition at face value.
| 
| I should have been more explicit - I'm interested not in why the first one would
| be incorrect, but how, for example, you would explain that to someone learning
| Haskell.  It's not at all clear to me that people should expect the a's to be
| different - I can't think of a good rationale for it (aside from the "don't break
| old code" argument, which, if that's the only argument, doesn't seem strong enough
| to me).

One could also argue that the culprit is Haskell's interpretation of
type variables of which Report (p. 34) says: `[...] the type variables
in a Haskell expression are all assumed to be universally quantified
[..]'. Here is an even more irritating list of possibilities ...

rapply  :: a -> (a -> a) -> a
rapply a f  =  f a
rapply (a :: a) f   =  f a
rapply a (f :: a -> a)  =  f a
rapply a f :: a =  f a
rapply a f  =  (f :: a -> a) a
rapply a f  =  f (a :: a)
rapply a f  =  f a :: a

rapply a=  \f -> f a
rapply (a :: a) =  \f -> f a
rapply a:: (a -> a) -> a=  \f -> f a
rapply a=  \(f :: a -> a) -> f a
rapply a=  \f -> f a :: a

and so forth ... A solution could be to consider the type variables
universally quantified at the _outermost_ possible level (currently
it's the innermost). So `f e1 ... en = e' means `forall a1 .. am.f e1
... en = e' where the `ai's are the type variables occuring free in the
definition. If we had explicit syntax for universal quantification
(which I consider absolutely necessary) the former interpretation could
be recovered using explicit quantifiers: ... (f :: forall a.a -> a)
...

Ralf

PS: I don't like the scope-mixture of type signatures and definitions.

Re: Scoped typed variables.

[Alex Ferguson]

Jeff Lewis:
> I'm not sure what the parenthetical comment about the interpretation of a 
means -
> take the definition at face value.

My point was: were they _intended_ to be same "a", or different?  What
is "face value" is surely simply begging the question.


> It's not at all clear to me that people should expect the a's to be
> different - I can't think of a good rationale for it (aside from the "don't 
break
> old code" argument, which, if that's the only argument, doesn't seem strong 
enough
> to me).

For Standard Haskell at least, it ought to be a pretty strong argument.

I don't accept that the "a"'s being different is bizarre and inexplicable
 -- up until the discussion of wanting to write these more restricted
types, I'd certainly never heard any criticism of it on those grounds.
Signatures and definitions were simply regarded as having quite separate
scopes.

Slainte,
Alex.

Re: Scoped typed variables.

[Alex Ferguson]

Hi Jeff.

> > http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
> >
> > I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
> > that worries me, for the reasons I alluded to.  If "beefed up A"
> > does the job, I'm equally happy as with a more conservation syntax for
> > "B".

> Just as a sanity check, following an augmented proposal "A" where we can also
> annotate the return type as well, consider these:
> 
> f :: a -> (a -> a) -> a
> f x = \g -> (g :: a -> a) x
> 
> f (x :: a) :: (a -> a) -> a = \g -> (g :: a -> a) x
> 
> Which of these two is correct, and why?  Why not both?

Under "A+B", these would be equivalent.  Under "A++" (Mark's original
"A", only, plus the return types), the second of these is "correct"
(assuming a restricted interpretation of "a" is what was intended), but
in the first, the a's in sig and body are bound quite separately, so the
local type annotation would be too general.

Slainte,
Alex.

Re: instances of types.

[Alex Ferguson]

Sergey Mechveliani writes:
> Second, some compilers say at this:
> "
> (the instance type must be of form (T a b c)
> where T is not a synonym, and a,b,c are distinct type variables)
> "
> Maybe, they treat  Int Int  as a repeated variable?

Not quite, Int isn't a type variable at all, but an actual type.
Basically it's disallowing instance heads more than one type
constructor deep.  So for example, "instance C (T Int Char)" would
also be disallowed.

It isn't necessary for this to be anything like this restrictive, of
course, but basically it's (a sledgehammer) to enforce (the nut of)
non-overlap of instances.

SPJ et al proposed relaxing this for [Standard] Haskell [2.0],
and ghc will allow the more general cases with -fgla-exts, provided
the instances don't _actually_ overlap.  (Older versions of ghc
(3.00?) allow some overlap, too)

Slainte,
Alex.

Re: avoiding repeated use of show

[Ralf Hinze]

| I would be more inclined to use <<.  The reason is typing efficiency.
| '&' is awkward to be typing frequently immediately after '"'.

I do not type that fast ;-).

| You are acutally using (.) below.  Is there a way to do that (via
| Fran like lifting?)?

I'm afraid no.

| > > instance Stringable ShowS where
| > > toStrings =  id
| > 
| > This instance declaration is necessary to make `&' useable. Note that
| > this is not (Standard) Haskell but works only with Hugs 1.3c (and
| > probably with GHC's next release).
| 
| Why does this instance declaration require 1.3c?  Also, are there
| substantive differences between Hugs 1.3c and GHC 3.3?  Are people
| prototyping w/ 1.3c and then planning to build with the next GHC?

Haskell requires that the instance head is of the form C a1 ... ak
where ai are type variables. However, the code _does_ work with GHC 3.2
if the flag `-fglasgow-exts' is on (sorry for the incomplete
information).

| > > (&)   :: (Stringable a, Stringable b) => a -> b -> 
|ShowS
| > > a & b =  toStrings a . toStrings b
| > 
| > Note that `&' yields `ShowS' and not `String'.
| > 
| > > val = "the sum of 2 and 2 is " & (2 + 2 :: Int) & " whenever."
| 
| > Furthermore note that `val' has type `ShowS'. If quadratic time
| > behaviour is not a problem (does not occur?) you can safely omit the
| > `Stringable ShowS' instance and change `&' to `toString a ++ toString b'.
| 
| I am not understanding this last bit.  Can you explain further?

Well. If you change (<<) to

> (<<)  :: (Stringable a, Stringable b) => a -> b -> String
> a << b=  toString a ++ toString b

and make nested calls to (<<) you may experience quadratic time
behaviour. The standard example involves printing a tree:

> data Bush a   =  Leaf a | Fork (Bush a) (Bush a)
>  deriving (Show)
>
> lay   :: (Stringable a) => Bush a -> String
> lay (Leaf a)  =  "(Leaf " << a << ")"
> lay (Fork l r)=  "(Fork " << lay l << lay r << ")"

Simply try

lay $ leftist [1 .. 1 :: Int]

where leftist is defined as follows.

> leftist   =  foldl1 Fork . map Leaf

BTW With the original definition of (<<) it is quite easy to make
`Bush' an instance of `Stringable'.

> instance (Stringable a) => Stringable (Bush a) where
> toStrings (Leaf a)=  "(Leaf " << a << ")"
> toStrings (Fork l r)  =  "(Fork " << l << r << ")"

Maybe cunning, but I like it ;-).

Ralf

RE: Re: Scoped typed variables.

[Mark P Jones]

Ok, back to the main list we go!

| But the problem is that I need the type name c inside the body of
| the function!  I'm assuming always that I can solve a typeing
| problem by adding an explicit type signature wherever it's needed;
| however, that implies that I need to be able to get at the type
| names.

I was replying to your suggestion that you needed the extra line
to specify the context (Num c).  Yes, I agree that you might need
a way to name the result type c.  That can be handled in the way
we discussed earlier:  f xs :: c = ...  But why do you think that
you need some way to write down the context too?  I don't think
you do!

All the best,
Mark

Re: avoiding repeated use of show

[Sven Panne]

Simon L Peyton Jones wrote:
> [...] Let me advertise Olivier Danvy's very cunning idea to implement
> printf in Haskell/ML.
> 
> http://www.brics.dk/RS/98/5/index.html

Very cunning, indeed. But it has as small efficiency problem because
of the use of (++). This can be easily cured by using ShowS:


-- Slightly inefficient "Formatting Strings in Haskell" version of
-- Olivier Danvy's "Formatting Strings in ML"

-- p_ is like i_, but works for everything Show-able
p_ :: Show b => (String -> a) -> String -> b -> a
p_ k s x = k (s ++ show x)

s_ :: (String -> a) -> String -> String -> a
s_ k s x = k (s ++ x)

l_ :: String -> (String -> a) -> String -> a
l_ x k s = k (s ++ x)

n_ :: (String -> a) -> String -> a
n_ k s = k (s ++ "\n")

format :: ((String -> String) -> String -> a) -> a
format c = c id ""



-- (Hopefully) improved version

p_ :: Show c => (ShowS -> a) -> ShowS -> c -> a
p_ k s x = k (s . shows x)

s_ :: (ShowS -> a) -> ShowS -> String -> a
s_ k s x = k (s . showString x)

l_ :: String -> (ShowS -> a) -> ShowS -> a
l_ x k s = k (s . showString x)

n_ :: (ShowS -> a) -> ShowS -> a
n_ k s = k (s . showChar '\n')

format :: ((ShowS -> ShowS) -> ShowS -> a) -> a
format c = c id id


Example:
   format (l_ "Foo" . p_ . s_ . p_ . n_) (2+2) "y" True ""
   => "Foo4yTrue\n"

-- 
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen  Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne

RE: Scoped typed variables.

[Mark P Jones]

Hi Alex,

| > I think the way that Hugs 1.3c handles it ...
| ...
| AKA "Proposal A" in SPJ's recent message on this topic:
|
| http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274

Exactly, although I hadn't been referring to that at the
time.  The only negative point for proposal A listed there
is that:  "Can't capture variables appearing within type contexts".
I don't actually see why this is needed.

| it's "B" (and hence, SPJ's Composite Motion, A+B)
| that worries me, for the reasons I alluded to.

I share your concerns!

| > In recent discussions with Simon, we discovered that
| > this approach also works better if existential types are included in the
| > language.
|
| That makes at least intuitive sense to me (a "monomorphic type
| varible" _is_ some sort of existential quantification, isn't it,
| in at least some vague, hand-wavey way?) -- could you expand a
| little on the details of this, though?

Sure.  I think I can see where you're headed with your comments,
but I actually meant something else.  Specifically, if you allow
datatypes like:

data Twee = forall a. MkTwee (a -> Int) a

where the a parameter is locally quantified, and you write functions
like:

f (MkTwee g u) = ...

then you can use a type annotation such as:

f (MkTwee g (u::a)) = ...

if you want to refer to the type of the existentially quantified
variable in the body of f.  There's no way to name that type with
the B proposal alone.

Hope that clears things up!

Mark

Re: GHC licence

[Simon Marlow]

[EMAIL PROTECTED] (Bob Hutchison) writes:

> There are *two* GNU licenses. The GPL is meant for tools, like GHC, and
> would prevent certain uses of GHC. There is a second GNU license for
> libraries, called LGPL, and this is important. The runtime components of
> GHC should be licensed using the library license (just like the GNU
> runtimes are). Using both licenses appropriately would allow for the use
> of GHC in commercial software (as long as GHC itself was not included).
> Any improvements GHC or its runtime would still have to be made public
> by the commercial entity.

Sure, but what happens when someone wants to include GHC in a
commercial system?  Do you really think they are going to provide
source code for the rest of the system?  Perhaps they make some
modifications to GHC but don't want to release the ideas in source
form?  Really, the GNU license is innapropriate for most commercial
use.

Don't get me wrong, I'm a free software fanatic.  That's "free" as in
"freedom", not as in "you must give everyone your source code" (1/2 :-)

Cheers,
Simon

-- 
Simon Marlow [EMAIL PROTECTED]
University of Glasgow   http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key

RE: Scoped typed variables.

[Alex Ferguson]

Hi Mark (and all).

> I think the way that Hugs 1.3c handles it would meet your goals.  All that
> it requires is a strict extension to the syntax for patterns to allow type
> annotations.  These can be useful in their own right, but also can be
> applied to problems like the one that you gave:
> 
>   f :: [a] -> a -> [a]
>   f ((x::a):xs) y = g y
>  where
>g :: a -> [a]
>g q = [x,q]

AKA "Proposal A" in SPJ's recent message on this topic:

http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274

I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
that worries me, for the reasons I alluded to.  If "beefed up A"
does the job, I'm equally happy as with a more conservation syntax for
"B".


> In recent discussions with Simon, we discovered that
> this approach also works better if existential types are included in the
> language.

That makes at least intuitive sense to me (a "monomorphic type varible"
_is_ some sort of existential quantification, isn't it, in at least some
vague, hand-wavey way?) -- could you expand a little on the details of
this, though?

Slainte,
Alex.

RE: Re: Scoped typed variables.

[michael]

CC: [EMAIL PROTECTED]


But the problem is that I need the type name c inside the body of the   
function!  I'm assuming always that I can solve a typeing problem by   
adding an explicit type signature wherever it's needed; however, that   
implies that I need to be able to get at the type names.

 --
From:  mpj
Sent:  22 July 1998 14:44
To:  [EMAIL PROTECTED]
Cc:  [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:   Re: Scoped typed variables.

| Yes, I've always tended to think that the parameters of a function need   


| to be given types explicity.

I'm not sure I'd want to go as far as this as I think it could become
quite a burden.  I'm only expecting the types-on-the-left-hand-side
syntax to be used occasionally.  Most of the time, I prefer to write
separate type declarations for top-level functions so that they can be
understood independently of the function's definition.

| Simon missed one interesting line from my
| example -- something is needed to specify the context in a form that
| makes it usable within the body of the function.  How about this:
|
|  (Num c) =>
|   (f (xs::[a]))::c =
|...

I don't actually see why it should be *needed*.  From the perspective of
what the type checker needs to do, it certainly isn't necessary.  From
the perspective of a programmer who wants to document what their program
does, there is perhaps more motivation.  But that can be done with an
explicit type signature instead:   f :: Num c => [a] -> c.

All the best,
Mark

Re: GHC licence

[Tony Finch]

[EMAIL PROTECTED] wrote:
>
>I do think that the GNU license would be a mistake -- as I understand, it   
>would prevent the use of GHC in commercial projects, and I'm pretty sure   
>that's something Simon wants to *encourage*.

The GPL explicitly allows commercial use. The commercially problematic
aspect of the GPL is that derived versions of GPLed software must be
distributed with source (and all the intellectual property exposed).
This does not propagate to works created using GPLed software.

Tony.
-- 
F.A.N.Finch  [EMAIL PROTECTED]
[EMAIL PROTECTED]   +44-7970-401-426
"Plenty more letters in the alphabet"

Fw: Could Haskell be taken over by Microsoft?

[Dinesh Vadhia]

This note from Simon says it all precisely and what I alluded to in my
earlier note ...

Dinesh


-Original Message-
From: Simon Marlow <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: Jorgen Frojk Kjaersgaard <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Date: Wednesday, July 22, 1998 3:43 AM
Subject: Re: Could Haskell be taken over by Microsoft?


Marko Schuetz <[EMAIL PROTECTED]> writes:

> If they find (economic) interest in the language I am sure they will
> try to take over control of the language in their typical
> way, as they have done or tried to do with numerous technologies (Java
> being the most recent), by:
>
> - 'technical enhancement': that is introducing some features into
>   Haskell and omitting/changing some others, while continuing to call
>   it Haskell
>
> - 'bundling': connecting this MS-Haskell to some widespread software
>   eg IE, making that software refuse to properly execute the majority
>   of non-MS-Haskell programs.

Let's face it, this would be better than the situation we have now,
with only a handful of people worldwide who get paid to actively
develop Haskell compilers.  As a result, I can count the number of
good Haskell compilers on the fingers of half a hand.  And even those
don't have a decent GUI or development environment.  Ok, us hackers
are happy to use emacs, but that's not going to cut it in the real
world.

IMO, Haskell suffers too much from being a research vehicle.  I
believe the emphasis should be less on "let's protect our beautiful
language" and more on developing great tools and actually making the
thing *usable* for real-world tasks.  Languages don't get anywhere on
elegance alone.  Sad but true.

Cheers,
Simon

BTW, I'm moving to Microsoft too.

--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key

Re: GHC licence

[Bob Hutchison]

On Wed, 22 Jul 1998 08:51:47 GMT, you wrote:

>CC: Simon L Peyton Jones <[EMAIL PROTECTED]>
>
>
>I do think that the GNU license would be a mistake -- as I understand, it   
>would prevent the use of GHC in commercial projects, and I'm pretty sure   
>that's something Simon wants to *encourage*.
>

There are *two* GNU licenses. The GPL is meant for tools, like GHC, and
would prevent certain uses of GHC. There is a second GNU license for
libraries, called LGPL, and this is important. The runtime components of
GHC should be licensed using the library license (just like the GNU
runtimes are). Using both licenses appropriately would allow for the use
of GHC in commercial software (as long as GHC itself was not included).
Any improvements GHC or its runtime would still have to be made public
by the commercial entity.

For example, Tower Eiffel has use GNU compilers for some time. The
runtime libraries of GNU compilers are protected by the library license.
Yet Tower Eiffel is certainly used for commercial products.

Cheers,
Bob
---
Bob Hutchison, [EMAIL PROTECTED], (416) 760-0565
([EMAIL PROTECTED] until INTERNIC fixes problems)
RedRock, Toronto, Canada

Re: Scoped typed variables.

[Jeffrey R. Lewis]

Ralf Hinze wrote:

> One could also argue that the culprit is Haskell's interpretation of
> type variables of which Report (p. 34) says: `[...] the type variables
> in a Haskell expression are all assumed to be universally quantified
> [..]'. Here is an even more irritating list of possibilities ...

> and so forth ... A solution could be to consider the type variables
> universally quantified at the _outermost_ possible level (currently
> it's the innermost). So `f e1 ... en = e' means `forall a1 .. am.f e1
> ... en = e' where the `ai's are the type variables occuring free in the
> definition. If we had explicit syntax for universal quantification
> (which I consider absolutely necessary) the former interpretation could
> be recovered using explicit quantifiers: ... (f :: forall a.a -> a)
> ...
>

  This sounds great, but it could break old code, of course.  This would have a
different type under Ralf's proposal than Haskell 1.4:
(id :: a -> a, id :: a -> a)
However, I think something like it is the only sane way to go.  Whatever we do, type
variables should scope consistently.  With proposal "A" as is (such that it wouldn't
break old code, and just like in hugs 1.3c), a type variable would scope differently if
it was in a pattern verses being in an expression.  Ralf's proposal fixes that nicely,
and I don't think the cost in old code here would be very high.

--Jeff

RE: Scoped typed variables.

[michael]

CC: [EMAIL PROTECTED]


Yes, I've always tended to think that the parameters of a function need   
to be given types explicity.  Simon missed one interesting line from my   
example -- something is needed to specify the context in a form that   
makes it usable within the body of the function.  How about this:

 (Num c) =>
  (f (xs::[a]))::c =
   -- do I need an explicit fromInteger here?
   if len > 3 then len else 0 where
len :: c = length xs
?

It's not very pretty, but I'm not sure that's important just now...

 --
From:  mpj
Sent:  22 July 1998 12:00
To:  Simon L Peyton Jones <[EMAIL PROTECTED]>;   
[EMAIL PROTECTED]
Cc:  [EMAIL PROTECTED]
Subject:   RE: Scoped typed variables.

To: Simon L Peyton Jones <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: RE: Scoped typed variables.

| Michael suggested
|
|  f :: [a] -> c
|  f xs = if len > fromInteger 3 then len else 0
|   where
|len :: c
|len = length xs
|
| This relies on the 'c' from the type signature scoping over
| the definition, which is on alternative notation for scoped
| type variables.

Hmm, interesting.  Perhaps we need to allow type annotations on
left hand sides as well as embedded in patterns:

  f xs :: c = ...

I know it looks a bit ugly ... add a few more parens and it
starts to remind me of Pascal! :-)

All the best,
Mark

Re: avoiding repeated use of show

[Patrik Jansson]

This might be a reasonable solution for the the "concatenation" operator
you want:
[This does not solve the numeric ambiguity - I think that is impossible.]

infixl 1 <<

class Stringable a where
  (<<) :: String -> a -> String

instance Stringable a => Stringable [a] where
  s << [] = s
  s << (x:xs) = s << x << xs

instance Stringable Int where
  s << x = s ++ show x
  
instance Stringable Char where
  s << x = s ++ [x]

main = print $ "Maybe " << (2+2::Int) << " is " << 'a' << " solution"

I hope you find << sufficiently keyboard friendly ;-)
(If you don't like having to put a string as the first argument you could
  define a constant

  cout :: String
  cout = ""

 and write

  cout << "Maybe " << (2+2::Int) << " is " << 'a' << " solution"
)

Worth noting is that many variants of this theme is possible using other
types than String to store the information:

(<<) :: Printable a => IO () -> a -> IO ()
(<<) :: Pretty a => Doc -> a -> Doc
...


Patrik Jansson

Re: Scoped typed variables.

[Jeffrey R. Lewis]

Alex Ferguson wrote:

> Hi Jeff.
>
> > > http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
> > >
> > > I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
> > > that worries me, for the reasons I alluded to.  If "beefed up A"
> > > does the job, I'm equally happy as with a more conservation syntax for
> > > "B".
>
> > Just as a sanity check, following an augmented proposal "A" where we can also
> > annotate the return type as well, consider these:
> >
> > f :: a -> (a -> a) -> a
> > f x = \g -> (g :: a -> a) x
> >
> > f (x :: a) :: (a -> a) -> a = \g -> (g :: a -> a) x
> >
> > Which of these two is correct, and why?  Why not both?
>
> Under "A+B", these would be equivalent.  Under "A++" (Mark's original
> "A", only, plus the return types), the second of these is "correct"
> (assuming a restricted interpretation of "a" is what was intended), but
> in the first, the a's in sig and body are bound quite separately, so the
> local type annotation would be too general.
>

I'm not sure what the parenthetical comment about the interpretation of a means -
take the definition at face value.

I should have been more explicit - I'm interested not in why the first one would
be incorrect, but how, for example, you would explain that to someone learning
Haskell.  It's not at all clear to me that people should expect the a's to be
different - I can't think of a good rationale for it (aside from the "don't break
old code" argument, which, if that's the only argument, doesn't seem strong enough
to me).

--Jeff

RE: Scoped typed variables.

[Mark P Jones]

| Michael suggested
| 
|  f :: [a] -> c
|  f xs = if len > fromInteger 3 then len else 0
|   where
| len :: c
| len = length xs
| 
| This relies on the 'c' from the type signature scoping over
| the definition, which is on alternative notation for scoped
| type variables.

Hmm, interesting.  Perhaps we need to allow type annotations on
left hand sides as well as embedded in patterns:

  f xs :: c = ...

I know it looks a bit ugly ... add a few more parens and it
starts to remind me of Pascal! :-)

All the best,
Mark

Re: Scoped typed variables.

[Jeffrey R. Lewis]

Alex Ferguson wrote:

> > I think the way that Hugs 1.3c handles it would meet your goals.  All that
> > it requires is a strict extension to the syntax for patterns to allow type
> > annotations.  These can be useful in their own right, but also can be
> > applied to problems like the one that you gave:
> >
> >   f :: [a] -> a -> [a]
> >   f ((x::a):xs) y = g y
> >  where
> >g :: a -> [a]
> >g q = [x,q]
>
> AKA "Proposal A" in SPJ's recent message on this topic:
>
> http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
>
> I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
> that worries me, for the reasons I alluded to.  If "beefed up A"
> does the job, I'm equally happy as with a more conservation syntax for
> "B".

Just as a sanity check, following an augmented proposal "A" where we can also
annotate the return type as well, consider these:

f :: a -> (a -> a) -> a
f x = \g -> (g :: a -> a) x

f (x :: a) :: (a -> a) -> a = \g -> (g :: a -> a) x

Which of these two is correct, and why?  Why not both?

Next check.  Consider these:

f g = ... (g :: a -> a) ...
f (g :: a -> a) = ... g ...

Which of these is correct, and why?  Why not both?

--Jeff

Re: Scoped typed variables.

[Simon L Peyton Jones]

> I think the way that Hugs 1.3c handles it would meet your goals.  All that
> it requires is a strict extension to the syntax for patterns to allow type
> annotations.  These can be useful in their own right, but also can be
> applied
> to problems like the one that you gave:
> 
>   f :: [a] -> a -> [a]
>   f ((x::a):xs) y = g y
>  where
>g :: a -> [a]
>g q = [x,q]
> 
> The only change I've made here is to replace "x" on the left hand side of
> the definition for f with "(x::a)".  As a result, the type variable "a"
> will be in scope when the signature of g is encountered, and so will not
> be subjected to the usual, implicit universal quantification.

The monomorphism discussion highlighted a disadvantage with
the pattern notation for scoped type variables that I hadn't realised
before.  Michael suggested

  
 f :: [a] -> c
 f xs = if len > fromInteger 3 then len else 0
  where
  len :: c
  len = length xs

This relies on the 'c' from the type signature scoping over
the definition, which is on alternative notation for scoped
type variables.  On the whole I think the 'put signatures in patternss'
approach is nicer, but I don't think it can express this example,
because the relevant type is (only) in the result.  Maybe it's
Just Too Bad, but it is a pity.


Simon

Re: Lisence [was: Fw: Could Haskell be taken over by Microsoft?]

[Manuel M. T. Chakravarty]

From: Dinesh Vadhia <[EMAIL PROTECTED]>
Subject: Fw: Could Haskell be taken over by Microsoft?
Date: Tue, 21 Jul 1998 14:49:07 -0700

[...]
> The situation would change dramatically if say, a Microsoft, picked it up
> and ran with it.  But they wouldn't do it unless they had full control over
> the language which the Haskell community wouldn't allow.
> 
> On the other hand, Haskell could follow the Linux route with a GNU license.
> No problem with this except how many customers are seriously going to take
> the leap of faith.  It is a sad fact of life that the majority of the "real"
> market consists of conservative customers who look for a number of
> (non-product) things from a technology component including supplier status,
> pricing, support, and so on.  Having a a number of small companies providing
> Haskell support won't cut the mustard in the real 'big' world.
> 
[...]
>
> If the Haskell community wants Haskell to be a significant product in the
> computer language and software development markets then the only route open
> is to setup a company whose sole purpose is that ... Everything else (for
> the Haskell community) is just wishful thinking.

I don't believe this.  Look at Perl.  It is distribute by
the "Artistic License" and I think everybody on this list
would be happy if Haskell had only a tenth of the popularity
of Perl.  (Even GHC's compiler driver is written in Perl ;-)

Cheers,

Manuel

Re: instances of types. Reply.

[S. Alexander Jacobson]

On Wed, 22 Jul 1998, S.D.Mechveliani wrote:
> Second, some compilers say at this:
> "
> (the instance type must be of form (T a b c)
> where T is not a synonym, and a,b,c are distinct type variables)
> "
> Maybe, they treat  Int Int  as a repeated variable?

That seems to be it.  It seems that this is allowed:
> instance Eq (a->b) where x==y = True

But this is not allowed:

> instance Eq (a->a) where x==y = True

I guess this makes sense because if both were defined, the choice of
function would be ambiguous.  

-Alex-

___
S. Alexander Jacobson   i2x Media  
1-212-697-0184 voice1-212-697-1427 fax

Re: avoiding repeated use of show

[S. Alexander Jacobson]

On Wed, 22 Jul 1998, Ralf Hinze wrote:
> What about `&' for catenation?

I would be more inclined to use <<.  The reason is typing efficiency.
'&' is awkward to be typing frequently immediately after '"'.

You are acutally using (.) below.  Is there a way to do that (via
Fran like lifting?)?
 
> > instance Stringable ShowS where
> > toStrings   =  id
> 
> This instance declaration is necessary to make `&' useable. Note that
> this is not (Standard) Haskell but works only with Hugs 1.3c (and
> probably with GHC's next release).

Why does this instance declaration require 1.3c?  Also, are there
substantive differences between Hugs 1.3c and GHC 3.3?  Are people
prototyping w/ 1.3c and then planning to build with the next GHC?

> > (&) :: (Stringable a, Stringable b) => a -> b -> ShowS
> > a & b   =  toStrings a . toStrings b
> 
> Note that `&' yields `ShowS' and not `String'.
> 
> > val = "the sum of 2 and 2 is " & (2 + 2 :: Int) & " whenever."

> Furthermore note that `val' has type `ShowS'. If quadratic time
> behaviour is not a problem (does not occur?) you can safely omit the
> `Stringable ShowS' instance and change `&' to `toString a ++ toString b'.

I am not understanding this last bit.  Can you explain further?
 
> `render' is quite flexible:
> 
> ? render val
> the sum of 2 and 2 is 4 whenever.
> ? render (toString "aaa")
> aaa
> ? render "aaa"
> aaa
> ? render (toStrings "aaa")
> aaa

Very cool.  Thank you.
 
> ===
> 
> > Is there any way to convince Haskell to just resolve these numbers to
> > SOMETHING by default?  Then I can just declare that type an instance of
> > Stringable.
> 
> Unfortunately not. I did not succeed in persuading SPJ ;-). See
> 
> http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=445

It sounds like he just wants more votes for this change.  I just added
mine (for whatever thats worth :-))

-Alex-

___
S. Alexander Jacobson   i2x Media  
1-212-697-0184 voice1-212-697-1427 fax

Re: Could Haskell be taken over by Microsoft?

[Simon Marlow]

Marko Schuetz <[EMAIL PROTECTED]> writes:

> If they find (economic) interest in the language I am sure they will
> try to take over control of the language in their typical
> way, as they have done or tried to do with numerous technologies (Java
> being the most recent), by: 
> 
> - 'technical enhancement': that is introducing some features into
>   Haskell and omitting/changing some others, while continuing to call
>   it Haskell
>
> - 'bundling': connecting this MS-Haskell to some widespread software
>   eg IE, making that software refuse to properly execute the majority
>   of non-MS-Haskell programs.

Let's face it, this would be better than the situation we have now,
with only a handful of people worldwide who get paid to actively
develop Haskell compilers.  As a result, I can count the number of
good Haskell compilers on the fingers of half a hand.  And even those
don't have a decent GUI or development environment.  Ok, us hackers
are happy to use emacs, but that's not going to cut it in the real
world.

IMO, Haskell suffers too much from being a research vehicle.  I
believe the emphasis should be less on "let's protect our beautiful
language" and more on developing great tools and actually making the
thing *usable* for real-world tasks.  Languages don't get anywhere on
elegance alone.  Sad but true.

Cheers,
Simon

BTW, I'm moving to Microsoft too.

-- 
Simon Marlow [EMAIL PROTECTED]
University of Glasgow   http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key

Re: avoiding repeated use of show

[Ralf Hinze]

> I would like to avoid using show all the time for printing strings e.g.
> 
> > val = "the sum of 2 and 2 is "++(show $ 2 + 2)++" whenever."
> 
> I would prefer to type something like:
> 
> > val = "the sum of 2 and 2 is "./(2+2)./" whenever." 
> > -- i can' find a better haskell compatible operator
> 
> I can't simply "show" the arguments of (./) because showing strings adds
> quotation marks which I don't want in this context.
> 
> So I tried creating my own Stringable class:
> > class Stringable a where
> >  toString::a -> String
> 
> > (./) :: (Stringable a,Stringable b)=> a->b->String
> > x./y = (toString x)++(toString y)

Nice idea. I polished the code somewhat ...

===

> infixr 0 &

What about `&' for catenation?

> toString  :: (Stringable a) => a -> String
> toString a=  toStrings a ""

> class (Show a) => Stringable a where
> toStrings :: a -> ShowS
> toStringList  :: [a] -> ShowS
>
> toStrings =  shows
> toStringList []   =  showString "[]"
> toStringList (a : as) =  showChar '[' . toStrings a . showl as
> where showl []=  showChar ']'
>   showl (a : as)  =  showString ", " . toStrings a . showl as

The class `Stringable' uses the `ShowS' mechanism to avoid quadratic
time behavior and employs the standard trick to allow overlapping
instances (Eric Meijer has written a short note about that topic):
[Char] and [a] should be treated differently.

> instance Stringable Char where
> toStringList s=  showString s

This instance declaration print strings as they are ...

> instance Stringable Int
>
> instance Stringable Integer
>
> instance Stringable a => Stringable [a]  where
> toStrings =  toStringList
>
> instance Stringable ShowS where
> toStrings =  id

This instance declaration is necessary to make `&' useable. Note that
this is not (Standard) Haskell but works only with Hugs 1.3c (and
probably with GHC's next release).

> (&)   :: (Stringable a, Stringable b) => a -> b -> ShowS
> a & b =  toStrings a . toStrings b

Note that `&' yields `ShowS' and not `String'.

> val = "the sum of 2 and 2 is " & (2 + 2 :: Int) & " whenever."

Furthermore note that `val' has type `ShowS'. If quadratic time
behaviour is not a problem (does not occur?) you can safely omit the
`Stringable ShowS' instance and change `&' to `toString a ++ toString b'.

> render:: (Stringable a) => a -> IO ()
> render a  =  putStr (toString a)

`render' is quite flexible:

? render val
the sum of 2 and 2 is 4 whenever.
? render (toString "aaa")
aaa
? render "aaa"
aaa
? render (toStrings "aaa")
aaa

===

> Is there any way to convince Haskell to just resolve these numbers to
> SOMETHING by default?  Then I can just declare that type an instance of
> Stringable.

Unfortunately not. I did not succeed in persuading SPJ ;-). See

http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=445

HTH, Ralf

Re: avoiding repeated use of show

[S. Alexander Jacobson]

On Wed, 22 Jul 1998, Simon L Peyton Jones wrote:

> Let me advertise Olivier Danvy's very cunning idea to implement
> printf in Haskell/ML.
> 
>   http://www.brics.dk/RS/98/5/index.html

Printf isn't really what I want, but I am happy to take a look.
I am really looking for a my scripting like solution -- ideally one that
allows me to embed Haskell expressions directly in strings the way TCL
does.  The overhead of "foo"./expr./"bar" as opposed to "foo $expr$ bar"
is not large, but it is not small either. The most ideal case would be
"foo" expr "bar" -- which is distinct from "foo" `expr` "bar".  I suppose
existential types will allow a variant using the (,) operator e.g.
["foo",expr,"bar"] where expr is an instance of Stringable (or Show).
 
> There's no technical issue here. One could relax the defaulting
> restriction, at the cost of (perhaps) sometimes unexpected behaviour.
> Or, as you show, you can just tell it which type to use:
> 
>   res = (2+2)::Int ./ "hello"

Well, I was actually hoping that there was a way to tell Haskell to treat
all numeric literals as Float and force the programmer to do conversions
where desired.  Having Haskell guess the type gets you back into the
automatic type conversion discussion from last week that I don't think
ever got resolved.  In other words, why should the prelude have different
semantics for numeric literals than the rest of the language?

-Alex-

___
S. Alexander Jacobson   i2x Media  
1-212-697-0184 voice1-212-697-1427 fax

Re: Could Haskell be taken over by Microsoft?

[Erik Meijer]

-Original Message-
From: Wolfgang Beck <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Tuesday, July 21, 1998 10:14 AM
Subject: Re: Could Haskell be taken over by Microsoft?


>
>Step 1: MS introduces Haskell with all their marketing power
>
>Step 2: VisualBasic programmers switch to Haskell after having
> read about Haskell in all those colorful magazines.
>
>Step 3: As they don't understand the concept of functional
> languages, they complain about it. MS 'improves'
> Haskell by adding C-like constructs and variable
> assignments to the language.  It is now neither C nor
> functional, but they love it (not the member of this
> list I suppose).

Stop dreaming and let's get back to work. Microsoft is NOT 
interested in Haskell; they already have a functional language
that satisfies step 3: JScript, used in more web pages than Java
and soon taking over VB in Outlook98 and Visual Studio.

http://www.microsoft.com/Scripting/JScript/Jslang/jsobjFunction.htm.
http://premium.microsoft.com/msdn/library/periodic/period98/html/mind0498rs.htm

> Look what they have done to HTML, and you know what I mean.

What's wrong with DHTML? Netscape has done the same, but slightly
different.

instances of types. Reply.

[S.D.Mechveliani]

S. Alexander Jacobson <[EMAIL PROTECTED]>  wrote

> Haskell doesn't seem to allow
>
>> instance Num (Int->Int) where ...
> or
>> instance Stringable String where ...
>
>How come?
>
>PS I am sure this has been discussed before, but I missed it...


First, Num, needs Eq to be defined. Consider

   module T where
   instance Eq  (Int->Int) where  f==g = (f 0)==(g 0)
   instance Num (Int->Int) where  f+g  = \x->(f x)+(g x)

Second, some compilers say at this:
"
(the instance type must be of form (T a b c)
where T is not a synonym, and a,b,c are distinct type variables)
"
Maybe, they treat  Int Int  as a repeated variable?
At least, we may try to use some extension of Haskell-1.4.
For example in ghc, it helps  -fglasgow-exts.

--
Sergey Mechveliani
[EMAIL PROTECTED]

RE: Scoped typed variables.

[Mark P Jones]

Hi Alex,

| Further to discussion on the StdHask site, and (of all places) ghc-bugs,
| I remain concerned about the program-breaking proposal to have typesigs
| scope over equation groups, thereby binding any type variable occurrences
| in local signatures.  But I agree with the need to add this expressivity.
| Surely it's possible to do this by a purely conservative
| extension, though?

I think the way that Hugs 1.3c handles it would meet your goals.  All that
it requires is a strict extension to the syntax for patterns to allow type
annotations.  These can be useful in their own right, but also can be
applied
to problems like the one that you gave:

  f :: [a] -> a -> [a]
  f ((x::a):xs) y = g y
   where
 g :: a -> [a]
 g q = [x,q]

The only change I've made here is to replace "x" on the left hand side of
the definition for f with "(x::a)".  As a result, the type variable "a"
will be in scope when the signature of g is encountered, and so will not
be subjected to the usual, implicit universal quantification.  I like this
approach because it is a strict extension, it has other (and more
interesting)
uses than the one shown here, and it has some history (in SML, for example
...
I didn't invent it).  In recent discussions with Simon, we discovered that
this approach also works better if existential types are included in the
language.

All the best,
Mark

Re: GHC licence

[michael]

CC: Simon L Peyton Jones <[EMAIL PROTECTED]>


I do think that the GNU license would be a mistake -- as I understand, it   
would prevent the use of GHC in commercial projects, and I'm pretty sure   
that's something Simon wants to *encourage*.

 --
From:  jfk
Sent:  21 July 1998 20:20
To:  Simon L Peyton Jones <[EMAIL PROTECTED]>; [EMAIL PROTECTED];   
[EMAIL PROTECTED]
Subject:   Re: GHC licence (was Could Haskell be t


Simon L Peyton Jones wrote:

> > Simon L Peyton Jones wrote:
>
> > Do you mean "public domain" literally, i.e. are you renouncing all
> > copyright?  (The source code contains copyright notices, but no
> > licence, as far as I can see.)
>
> No I am not renouncing all copyright.  By "public domain" I mean freely
> available for anyone to use for any purpose other than making money
> by selling the compiler itself.  That isn't a formal definition,
> but I'm sure you see the intent.
>
> I have carefully avoided getting tangled up in legal red tape, which
> is why there is no formal license.  It may be that my move to Microsoft
> will force me to spend time sorting this out.  But it's never been
> a problem so far, and I doubt it will in the future, so I'm reluctant
> to invest the time until pressed to do so.

It might be a good idea to publish GHC under the GNU Public License or
something similar. It grants everybody the right to use the software for
any purpose, including making extensions or modifications of it - as long
as the "derived work" is published under GPL as well. This ensures that   
no
company can take the product, make some small modifications to it and   
call
it their own. Whatever you choose to do, I think you need to be more
explicit about which rights you grant the users of GHC to avoid unwanted
use/misuse by anyone.

regards,

Joergen

Re: avoiding repeated use of show

[Simon L Peyton Jones]

> I would like to avoid using show all the time for printing strings e.g.
> 
> > val = "the sum of 2 and 2 is "++(show $ 2 + 2)++" whenever."
> 
> I would prefer to type something like:
> 
> > val = "the sum of 2 and 2 is "./(2+2)./" whenever." 
> > -- i can' find a better haskell compatible operator

Let me advertise Olivier Danvy's very cunning idea to implement
printf in Haskell/ML.

http://www.brics.dk/RS/98/5/index.html


> So I tried creating my own Stringable class:
> > class Stringable a where
> >  toString::a -> String
> 
> > (./) :: (Stringable a,Stringable b)=> a->b->String
> > x./y = (toString x)++(toString y)
> 
> The trouble is that when I try doing things like:
> 
> > res = (2+2) ./ " hello"
> 
> I get an "Unresolved top-level overloading" error.
>
> Is there any way to convince Haskell to just resolve these numbers to
> SOMETHING by default?  Then I can just declare that type an instance of
> Stringable.

What's going on is this.  You've got the context

(Stringable a, Num a)

arising from the RHS of res, and no further info about what "a" is.
Under extremely restricted circumstances Haskell will choose 
particular type for you, namely

when the classes involved are all standard prelude classes
and at least one is numeric.

Why so restrictive?  Because it it *might* make a massive difference
which type is chosen.  Suppose you had

instance Stringable Int where
   toString n = "Urk!"

instance Srringable Integer where
   toString n = ".Ha ha."

Now whether your program yields "Urk" or "...Ha ha" depends on
which type Haskell chooses.

There's no technical issue here. One could relax the defaulting
restriction, at the cost of (perhaps) sometimes unexpected behaviour.
Or, as you show, you can just tell it which type to use:

res = (2+2)::Int ./ "hello"

Simon 

Re: instances of types

[Simon L Peyton Jones]

> Haskell doesn't seem to allow
> 
> > instance Num (Int->Int) where ...
> 
>  or
> 
> > instance Stringable String where ...

Haskell requires you to write instances of the form

instance context => T a1..an where ...

where T is a type constructor and a1..an are type variables.

This is a conservative, but sound, design choice.  Haskell 2,
some versions of Hugs, and GHC 3.02 and later, all accept more
instance declarations.

There's extensive discussion in
http://www.dcs.gla.ac.uk/~simonpj/multi.ps.gz

and a summary of the state of play in
http://www.dcs.gla.ac.uk/~simonpj/multi-param.html

Simon

Re: GHC licence

[Fergus Henderson]

On 21-Jul-1998, Hans Aberg <[EMAIL PROTECTED]> wrote:
> At 23:28 +1000 98/07/21, Fergus Henderson wrote:
> >I ANAL, but I believe the phrase "public domain" is a well-defined concept.
> >It does not mean why Simon L Peyton Jones means by it, though.
> >If something is public domain, then anyone can use it for anything.
> 
>   I recall from the eighties about what wordings like "public domain",
> "free-ware" etc really meant, and it turned out that people meant different
> things.
> 
>   So to be one the sure side, I think ine should the wording "This software
> is public domain, that is, ...", spelling it out.
> 
>   (By the way, what does the "I ANAL" you use mean?)

IANAL stands for "I am not a lawyer".

(The space between the "I" and "A" was a typo.)

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.