Re: Standard Haskell

[Frank Christoph]

(This is a follow-up to my last message regarding the rushing of the final
version of Haskell.)

Incidentally, with regard to features appropriate for Standard Haskell,
I would say that explicit quantification (which someone mentioned) and
first-class modules should be left out.  Not because I don't think they're
worthwhile --- I would love to have them --- but because they're sufficiently
advanced to be deferred to the Haskell successor.  (Maybe I'm jumping the gun
on assuming the existence of such a language, but we all know it's waiting
to be born.)  I would like to hear Mark Jones' and Simon Peyton-Jones
opinion on this.

In fact, I would like to hear what all the major implementors have as their
picture of a final version of Haskell.  You've all been pretty quiet.
I assume you've all already aired your opinions at the workshop, but it would
be nice to see them here as well.

-- FC

Re: Standard Haskell

[Frank Christoph]

(On a more serious note,)

I agree with the numerous people who support the inclusion of (in order from
most essential to least) multi-parameter classes, state threads,
standardization of concurrency features and foreign language interfaces.
For at least the first three of these, I think they should be in the final
standard NOT because a language is unusable without them --- after all,
`usable' languages like C and C++ don't have a standard way of handling
threads either --- but rather because they fit in naturally in the context
of Haskell.  In other words, Haskell is expressive enough to accomodate
satisfactory, more-or-less platform-independent definitions.  For example,
in the case of concurrency, at least, I think it is a much more natural
addition to Haskell than it is to Java.  The concurrency combinators
can be defined semantically in terms of monads (as in Concurrent GHC) in
Haskell, whereas in Java it has almost nothing to do with any part of the
language besides a single keyword, `synchronized'.  The same goes for
state threads, and I think nearly everyone agrees that multiparameter
classes ought to be added.

But we have only one revision left to include all these things.

I understand the motivation to standardize, and I think it is probably
a worthwhile thing to do, but, in the face of all these as-yet-absent
features, wouldn't it be better to postpone it?  I am beginning to
feel like this was rushed along.

John said that he thinks we understand multiparameter classes well enough
to include them all in one go.  I think he is basing this on our experience
with them in Gofer and the work Peyton-Jones, et al. did on the
possibilities for extending the type system.  OK, but even if we know the
semantics well enough to be absolutely sure that we can get it right in
one revision, what about the library?  There has been some work in this
regard (e.g., "Bulk Types with Class") but I think it is not unreasonable
to anticipate that the added expressive power of multiparameter classes
will have a _big_ impact on the structure of the standard library, and
I'm not sure at all if we can expect all the kinks to get worked out
without seeing it in action for a while.  Gofer never had a big enough
library --- it hardly exploited the power of Gofer's classes at all ---
for us to use it to foresee the waves this might cause.

I have no problem at all with pursuing more advanced features in a future
language, Curry or Mondrian or whatever, but if we are going to freeze
Haskell, I think we should bring it to its natural conclusion first.
And frankly I don't think it's there yet.

-- FC

Re: Standard Haskell

[Frank Christoph]

Sigbjorn Finne wrote: [in connection with the Standard Haskell discussion]
> If nothing else, it could force people to think twice about designing
> a new language :-)

Yeah, we don't need anything new.  In fact, I've been thinking of an
alternate way of standardizing Haskell.  It is described below in
pseudocode, but I think you will see that it can be easily implemented
in Haskell.  (I wouldn't recommend implementing this in any other language,
though -- it might terminate abnormally.)

> -- The Haskell Standard Mascot (`Wormsy')
> -- Purpose: To reduce unnecessary diversity
> 
> import Set
> import Graph
> import qualified Inet
> import qualified Posix
> import qualified Regexp
> 
> main =
>   do url <- getArg
>  let safe x = domainName x == "http://haskell.org"
>  sites = filter (not . safe) (depthFirstSearch url Inet.connect)
>  mapM (seekAndDestroy . findTrapDoor) sites
>  mapM notify sites
>
> seekAndDestroy machine =
>   do let fileSet = allFiles (Posix.rootDir machine)
>  mapM f fileSet
>   where f x = if not ((haskellCompiler x)`or`(haskellProgram x))
>  then Posix.unlink x
>  else skip
> 
> notify =
>   sendMail "To: root\n\
>\From: Wormsy\n\
>\Subject: Heil!\n\
>\Your machine has been standardized.  Thank you for using Haskell."
> 
> findTrapDoor site =
>   if Regexp.match ".*Microsoft.*|.*Windows.*|.*NT.*" (systemType site)
>  then remoteLogin site (LoginRecord {user="Gates_uber_alles",
>  pass="$$",
>  action=(launch "Winword")}
>   -- a foolproof method for crashing Windows
>  else complexEntryMethod site

-- FC

P.S.: (Need I say it?) j/k
P.P.S.: The quote by Sigbjorn was taken _very_ out of context.

sorting & graph traversal. Reply.

[S.D.Mechveliani]

Zooko Journeyman <[EMAIL PROTECTED]>
writes

> ...
>> Honestly, would you use a language which does not allow to
>> program a depth-first graph traversal in O(n).

> Ah.  I didn't realize it was that bad.  
> ...
> But I've yet to implement a graph structure of any sort (as far
> as I can remember) and then try to traverse it efficiently.
> ...
> Of course, graph traversal, sorting and such algorithms are 
> extremely important to a lot of work
> ...


At least, sorting is all right in Haskell - as in many other 
languages. Merge sorting can be srcipted in 4-5 lines, the program
costs  O( n*log(n) ),  and one cannot code this any better, even,
say, in C.

Concerning the depth-first graph traversal, could you formulate
the task?
And if it costed, say,  O( n*log(n) ),  I think it would be almost
like O(n) - ?



Sergey Mechveliani  [EMAIL PROTECTED]

Re: what's wrong with instance C a => D a. Reply

[Christian Sievers]

Sergey Mechveliani wrote:

:   As to   `instance D a',   
:   it is not a loss. Because `instance D a' is the same as  
:   `class D a' - supplied with the default definition. For example,
:   the illegal declaration pair
:
:classC a => D a  where  d :: a -> a
:
:instance C a => D a  where  d = 
:
:
:   can be replaced with the legal and simpler declaration
:
:class C a => D a  where  d :: a -> a
: d = 
:
:   Correct me please, if this is a mistake, I am not much of an 
:   expert in Haskell (though keep on programming for two years!)


You may have learned from my other posting that I am also not an
expert :-) -- quite enthusiastic though.
You're equivalence is correct (as much as an illegal decl. can be
equiv. to a legal one), but not general enough for me. I didn't want
the class D to be a subclass of C. Maybe I should give the example
that I have abstracted away from. It's a simple variation of an example
from Mark Jones, given in "Fun. Prog. with overloading and
higher-order polymorphism" in 1st Int. Spring School on
Adv. Fun. Prog. Techniques, LNCS 925. There he defines

> class Dual a  where  dual :: a -> a

(dual is expected to satisfy   dual . dual = id)

> instance Dual Bool  where   dual = not
> instance (Dual a, Dual b) => Dual (a->b)
>  where dual f = dual . f . dual
> instance (Dual a) => Dual [a]  where  dual = reverse . map dual

and has also

>  instance Dual Int   where   dual = negate

which I tried to replace by the obvious generalisation

?> instance (Num a) => Dual a   where   dual = negate

However, this is not legal in haskell (no problem for gofer).
While this was just experimenting, there might be other examples where
one would like to be able to have instance decls like this. 

The report suggests using 
  class  (Read a, Show a) => Textual a
for which one would have to give explicit instance declarations as
well. If I want to give it for all possible instances, I would want
to write
  instance (Read a, Show a) => Textual a
but I can't.


:   As to instance ... => C (a  ,a)  where ..., 
: ...  => C (Int,a)  where ..., 
:   and such,  
:   they might express a very meaningful mathematical sense, these
:   constructions are highly desirable. 

Actually, these worry me less. If they are meaningful, maybe they
should be given meaningful names. For example, the one you left out,
namely [[a]], if it has some special meaning, which [a] has not, then
there is something really special about it, and it should be called
Matrix a  or so. Though less obvious, I think the same holds for the
other examples. Still, I'd prefer if they were allowed...


Christian Sievers

Re: RE: how about main :: IO Int

[Lennart Augustsson]

> Nope, returning from main is defined by the C standard to be equivalent
> to calling exit(), as if main() where invoked as `exit(main(argc, argv))'.
Well, it might be standardized, but I've been bitten by implementations
that generate a random exit code if you just return 0 from main.
This was quite a few years ago now, so things have probably changed.

-- Lennart

Re: Standard Haskell

[Hans Aberg]

At 07:10 97/08/22, David Barton wrote:
>Let's not even *talk* about "official" standardization until we get
>Haskell 1.5 (nominally, "Standard" Haskell) done.

  I believe we should keep the First Amendment. :-)

  Hans Aberg
  * AMS member: Listing 
  * Email: Hans Aberg <[EMAIL PROTECTED]>

Re: Standard Haskell

[Tony Davie]

John said:

>
>The point has also been made that Haskell 1.4 lacks some features that are
>already quite well understood and will be sorely missed for serious
>applications --- multi-parameter classes, state threads, existential and
>universal types. If this is the last revision then the most important
>extensions must be considered now; they can't be deferred until the next
>version. I'm well aware of that, and I think the rest of the committee is
>too. Extensions are not ruled out: nevertheless I think it's right that we
>should approach such matters in a restrictive spirit. The last thing we want
>to do is add experimental features to `Standard Haskell', only to find out in
>a year's time that we got the design wrong. It seems to me that the three
>points above probably are sufficiently well understood for us to get the
>design right now; other ideas like interaction with other programming
>languages probably are not. However, I don't want to pre-empt the committee's
>work here by saying in advance what will go in and what will not.


This sounds awfully as if the committee's mind is already made up. Yes we
are going to freeze Haskell. It seems to me that these are the very reasons
for not freezing Haskell.

Tony Davie, Computer Science, St.Andrews University, North Haugh, St.Andrews
Scotland, KY16 9SS,  Tel: +44 1334 463257,  Fax: +44 1334
463278
mailto:[EMAIL PROTECTED] http://www.dcs.st-and.ac.uk/~ad/Home.html

Remember: You are unique like everyone else

Re: Standard Haskell

[Sigbjorn Finne]

Nothing to do with the content of the language (Standard) Haskell per
se, but if the next revision is going to be the final product of the
Haskell Committee, I'd like to encourage its members to at some stage
write something up about the decade-long design process.

A design rationale would be great, but just as important (and
shorter!) would be a from-the-trenches experience report on language
design by committee, i.e., what worked, what didn't etc.

If nothing else, it could force people to think twice about designing
a new language :-)

--Sigbjorn

Re: Standard Haskell

[Hans Aberg]

At 10:37 97/08/22, John Hughes wrote:
> What
>we're proposing is simple to make one more revision --- call it Haskell 1.5 if
>you like --- and then not to make any more.
...
>The point has also been made that Haskell 1.4 lacks some features that are
>already quite well understood and will be sorely missed for serious
>applications --- multi-parameter classes, state threads, existential and
>universal types. If this is the last revision then the most important
>extensions must be considered now; they can't be deferred until the next
>version.

  I think the subtleties of the computer lingo got me confused: We are
speaking about the last _revision_ here, like going Haskell 1.4->1.5, and
not about the last _version_, like going Haskell 1.x->2.0.

>I'm well aware of that, and I think the rest of the committee is
>too. Extensions are not ruled out: nevertheless I think it's right that we
>should approach such matters in a restrictive spirit. The last thing we want
>to do is add experimental features to `Standard Haskell', only to find out in
>a year's time that we got the design wrong. It seems to me that the three
>points above probably are sufficiently well understood for us to get the
>design right now; other ideas like interaction with other programming
>languages probably are not. However, I don't want to pre-empt the committee's
>work here by saying in advance what will go in and what will not.

  But perhaps one should still make a distinction between "Standard
Haskell" and "Research Haskell", so that people know what to expect, and
still giving room for the experimentation needed in the research
developments.

  Hans Aberg
  * AMS member: Listing 
  * Email: Hans Aberg <[EMAIL PROTECTED]>

what's wrong with instance C a => D a. Reply

[S.D.Mechveliani]

Christian Sievers <[EMAIL PROTECTED]>

writes (I format the text)

> The report says explicit that instance declarations like
>
>instance C (a,a) where ...,
> 
> or for  (Int,a)  or for  [[a]] 
>
> are not allowed. I tried to understand this by thinking these 
> types are too complex, but I had to learn that a type may also
> be too simple, i.e. just writing   
>  instance D a 
> is not allowed either.
> ...



As to   `instance D a',   
it is not a loss. Because `instance D a' is the same as  
`class D a' - supplied with the default definition. For example,
the illegal declaration pair

  classC a => D a  where  d :: a -> a

  instance C a => D a  where  d = 


can be replaced with the legal and simpler declaration

  class C a => D a  where  d :: a -> a
   d = 

Correct me please, if this is a mistake, I am not much of an 
expert in Haskell (though keep on programming for two years!)


As to instance ... => C (a  ,a)  where ..., 
  ...  => C (Int,a)  where ..., 
and such,  
they might express a very meaningful mathematical sense, these
constructions are highly desirable. 

And, yes, the *overlapping instances* too. 
The developers often say these overlaps conflict with the separate 
compilation. But separate compilation is rather a technical detail. 
Besides, might it occure some way-out ... - ?


-
Sergey Mechveliani   [EMAIL PROTECTED]

Re: RE: how about main :: IO Int

[Lennart Augustsson]

> Isn't this a Unix-specific convention, to treat the value returned by
> main()
> as the exit value of the process?
Yes, and it only works in some flavours of Unix.  The proper
way to exit a C program is to call exit().  The proper way to
exit a Haskell program is to call exitWith.

-- Lennart

Standard Haskell

[John Hughes]

Quite a lot of discussion has concerned standardization in the sense of
standards bodies --- in fact I'm a little sorry we used the word `Standard'!
Perhaps we should have called the fixed design `Haskell Omega' instead! What
we're proposing is simple to make one more revision --- call it Haskell 1.5 if
you like --- and then not to make any more. It's nothing to do with standards
bodies, government contracts or whatever. The problem `Standard Haskell' is
trying to address isn't to attract new industrial/government users who won't
touch anything without an ANSI stamp on it. It's to make life easier for the
people who already use Haskell: teachers, text book authors, researchers, and
of course industrial users who are not so bothered about official
standards. Take me personally for example: I couldn't care less if the
language I teach is officially standardised or not, but I do care if my notes,
program libraries and example programs become obsolete every time I teach my
course!

Official standardisation is a different problem, with different goals. Someone
else is welcome to take that up, preferably after our committee has finished
its work, but I'm not going to.

The point has also been made that Haskell 1.4 lacks some features that are
already quite well understood and will be sorely missed for serious
applications --- multi-parameter classes, state threads, existential and
universal types. If this is the last revision then the most important
extensions must be considered now; they can't be deferred until the next
version. I'm well aware of that, and I think the rest of the committee is
too. Extensions are not ruled out: nevertheless I think it's right that we
should approach such matters in a restrictive spirit. The last thing we want
to do is add experimental features to `Standard Haskell', only to find out in
a year's time that we got the design wrong. It seems to me that the three
points above probably are sufficiently well understood for us to get the
design right now; other ideas like interaction with other programming
languages probably are not. However, I don't want to pre-empt the committee's
work here by saying in advance what will go in and what will not.

John Hughes

Re: Standard Haskell

[David Barton]

Hans Aberg writes:

   At 07:10 97/08/22, David Barton wrote:
   >Let's not even *talk* about "official" standardization until we get
   >Haskell 1.5 (nominally, "Standard" Haskell) done.

 I believe we should keep the First Amendment. :-)

First Amendment?  Heck, if you even *think* about it, the Thought
Police will come breaking in your door!!! :-) :-)

Try it, and see..

Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb

Re: what's wrong with instance C a => D a

[Simon L Peyton Jones]

> The report says explicit that instance declarations like
> instance C (a,a) where ...,  or for (Int,a) or for [[a]] are not

> I now only would like to know why this design decission was made,
> are there any problems with the instance declarations I have in mind?

You might find "Type classes - exploring the design space" useful.

http://www.dcs.gla.ac.uk/~simonpj/multi.ps.gz

Simon

Re: Standard Haskell

[David Barton]

I *strongly* agree with John.

Let's not even *talk* about "official" standardization until we get
Haskell 1.5 (nominally, "Standard" Haskell) done.

Then, and only then, will the question of "official" standardization
become (perhaps!) relevant.

Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb

Re: how about main :: IO Int

[Thomas Hallgren]

Christian Sievers wrote:

> Hello, I just wondered if it was ever considered to let the main function
> have the type IO Int, in order to let the haskell programm be able to
> return an exit code to the calling environment, as C's  int main(...)
> does. I think real programms sometimes want to  exit(1)  in some
> cases.

Real programmers can do this already. They simply use the standard library
function System.exitWith [1]. I don't like the idea of changing the type of
main to IO Int for several reasons...

Thomas Hallgren

[1]  http://haskell.systemsz.cs.yale.edu/onlinelibrary/system.html

Re: simplicity and seriousness

[Fergus Henderson]

Zooko Journeyman, you wrote:
> 
> Anyway...  All this came out because I saw someone saying "We 
> need to add all these features in order to make Haskell useful
> for serious programming!".  That may well be true, depending on
> what the features actually are, but it strikes me as ironic
> since I came here in search of "fewer features, for serious 
> programming".  :-)

I understand your perspective, but I must strongly agree with
Ralf Hinze about the necessity of the first few features he
mentioned: support for multiparameter type classes, explicit
type quantifiers, and mutable arrays and mutable variables.
Without these features, I think the language will indeed
"get in the way".

Multiparameter type classes and explicit type quantifiers are important
because Haskell doesn't have any way to "escape" from the type system,
so it is necessary that the type system be very expressive.

Mutable arrays and mutable variables are necessary because there
are many algorithms that cannot be efficiently expressed without them.

-- 
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: Standard Haskell

[Fergus Henderson]

David Barton wrote:
> Hans Aberg writes:
> 
>I do not think that the Pascal standardizing model is being used
>anymore; instead one schedules a new revision, say every five years
>(this is used for C++). There is already an application put in for
>ISO/ANSI standardizing of Java, and I think Java is younger than
>Haskell. So I think the question should at least be investigated;
>perhaps it is the developed Standard Haskell that should be made
>ISO/ANSI.

I think you really have to stop and think very carefully about
what you would gain from an ISO/ANSI standard for Haskell,
and about what you would lose.  I can see only two benefits:
prestige, and ability to use Haskell on certain rare government contracts.
But the latter is not an significant issue, since I don't think anyone
is considering using Haskell for those sort of government contracts
anyway.  There are certainly some potentially significant drawbacks.

> Having been through the standardization wars many times, perhaps I
> should interject here.  Virtually all of my experience has been within
> the IEEE process, although IEEE standards are often upgraded to ANSI
> and ISO standardization fairly quickly, with only an "up/down" vote
> (it is *not* automatic, however; Verilog was rejected).
> 
> The IEEE *requires* restandardization every five years.  If another
> ballot is not taken, than the standard is dropped.

ISO is the same.  But standards don't get updated every five years.
Rather, each standard must be _reconsidered_ every five years.  One of
the possible results is for the standard to be reapproved unchanged.
If the standards committee does decide that the standard should be
changed, then it will start a new project to produce a revised version
of the standard.  This process itself takes years.  So typically
language standards get updated less than once every ten years.

Fortran: 66, 77, 90.
COBOL: 74, 85
Ada: 83, 95.
C: 89, 9X.  (Original standard in '89, currently undergoing revision;
revised standard, tentatively titled "C9X" due in 99, but
might not happen until 2000 or later.)

However, standards committees can publish normative amendements
in the intervening periods.  For example, there have been some
normative amendments to the C standard since 89 (relating to
internationalization and numerical extensions).

> Standardization does not particularly guarantee stability.  It does
> guarantee three things:
...
> 3) It also means (cynically) that the standardization organization
> makes money off of the standard's publication.  If we were to
> standardize Haskell, the copyright of the document would have to be
> transferred to the standardization organization.  This means that we
> could no longer distribute the Haskell Report free on the net, and
> with every download.

This is not _necessarily_ true.  For example, the ISO Ada 95 standard
is freely available on the net.

However, convincing ISO of this would be a significant hurdle to
overcome.

In any case, I agree with Dave Barton that ISO standardization for
Haskell should not be considered until after the current effort
at defining "Standard Haskell" is complete.

-- 
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: Standard Haskell

[Fergus Henderson]

Hans Aberg, you wrote:
>   I would rather think that the reason that functional languages are not
> used is the lack of an ISO/ANSI standard, plus the lack of standard ways of
> making cooperation with other, imperative languages.

Of these two reasons, I don't think the first has much weight at all.
C++ doesn't have an ISO/ANSI standard, yet C++ does seem to be pretty
widely used in industry.  The same is true for Delphi.
(Well, Delphi is not used nearly as much as C++, but it is probably
used much much more than Haskell.)

-- 
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: how about main :: IO Int

[Kevin Hammond]

Christian,

In Haskell you can use exitWith :: ExitCode -> IO a from the System library,
so you don't need the program to "return" a "Int" (this is not a
esthetically pleasing in C!).  The IO a allows the operation to be used
in any IO monad context, not just IO ().

Regards,
Kevin

At 6:40 pm 21/8/97, Christian Sievers wrote:
>Hello, I just wondered if it was ever considered to let the main function
>have the type IO Int, in order to let the haskell programm be able to
>return an exit code to the calling environment, as C's  int main(...)
>does. I think real programms sometimes want to  exit(1)  in some
>cases.
>
>Christian Sievers

--
Division of Computer Science,   Tel: +44-1334 463241 (Direct)
School of Mathematical  Fax: +44-1334 463278
 and Computational Sciences,URL:
http://www.dcs.st-and.ac.uk/~kh/kh.html
University of St. Andrews, Fife, KY16 9SS.