Re: Standard Haskell
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: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
Re: Standard Haskell
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: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
Re: how about main :: IO Int
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.
Re: how about main :: IO Int
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
what's wrong with instance C a = D a. Reply
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 = definition can be replaced with the legal and simpler declaration class C a = D a where d :: a - a d = definition 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: what's wrong with instance C a = D a
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
Standard Haskell
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: RE: how about main :: IO Int
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
Re: Standard Haskell
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: Standard Haskell
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
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 http://www.ams.org/cml/ * Email: Hans Aberg [EMAIL PROTECTED]
Re: Standard Haskell
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
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: Standard Haskell
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.
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
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 = definition : : : can be replaced with the legal and simpler declaration : :class C a = D a where d :: a - a : d = definition : : 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
