Haskell Language Design Questions
1. Is the lack of dynamic binding of functions by design or because it was too much effort to be justified at the time the language was designed? In object oriented programming there can be several implementations of the same interface, and they can be stored in the same collection. 2. It seems to me that the Maybe monad is a poor substitute for exception handling because the functions that raise errors may not necessarily support it. For example, if I use someone elses custom type and a custom map function theirmap myApplicator SomeList and theirmap is not designed to support the Maybe monad, then it becomes hard to use if SomeFunction might raise an error. Am I missing something? Doug Ransom Systems Engineer Power Measurement Ltd. http://www.pml.com 250-652-7100 office 250-652-0411 fax mailto:[EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Learning Haskell and FP
Who are the audience for the books on Advanced Functional Programming? Academics with a theoretical CS background or someone with just a bit of understanding of FP? Ideally, I would like a course suited for someone who has completed a basic FP course. > -Original Message- > From: Johan Jeuring [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 28, 2000 6:06 AM > To: Doug Ransom > Cc: [EMAIL PROTECTED] > Subject: Re: Learning Haskell and FP > > > >Is there a good textbook on Functional Programming which > starts from a base > >point similar to "The craft of Functional Programming" but > more advanced in > >terms of introducing necessary topics like Category theory, > catamorphisms, > >monads, etc? I would find such a book very useful, especially if it > >concentrated on lazy functional programming. > > You might want to have a look at the series of three books on Advanced > Functional > Programming, published in LNCS, as LNCS 925, 1129, and 1608. I would > probably start with 925, which introduces monads, parser & > pretty-printing > combinators, monadic catamorphisms, constructor classes, etc. > > -- Johan Jeuring > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell newsgroup
That would only work if the haskell mailing list was either delete or mirrored onto a newsgroup. I would prefer a newsgroup myself for bandwidth reasons. > -Original Message- > From: i r thomas [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 28, 2000 12:53 AM > To: [EMAIL PROTECTED] > Subject: Haskell newsgroup > > > How about starting a Haskell newsgroup ? > The closest seems to be comp.lang.functional. > > > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Learning Haskell and FP
I have read "The Craft of Functional Programming" by Simon Thompson and a few paper on the web. "The Craft" is a good book, but it is an introduction to FP. It seems to me it there are a lot of books on OO design I can pick up at the bookstore, but in the FP world, one must worm their way through all sorts of papers. I have seen papers on Catamorphisms, Monads, Programming with Barbed Wire, folds, etc. I think these papers are hard to understand if you don't have the acadademic/mathematical background -- being papers and not textbooks these papers assume a fair bit of base knowledge. I know I can design a fold function to use in place of primitive recursion for most data structures -- I just don't know if I should. It is pretty easy to get through "The Craft of Functional Programming" without understanding what Category Theory , a Catamorphism , or a Kleisli Composition is. I can see lots of real Software Engineering oppurtunities for these various techniques if I could just put them together. Is there a good textbook on Functional Programming which starts from a base point similar to "The craft of Functional Programming" but more advanced in terms of introducing necessary topics like Category theory, catamorphisms, monads, etc? I would find such a book very useful, especially if it concentrated on lazy functional programming. Doug Ransom Systems Engineer Power Measurement Ltd. http://www.pml.com 250-652-7100 office 250-652-0411 fax mailto:[EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: ANNOUNCE: HaXml 1.00
I think it is important that a good haskell XML library be included as part of the haskell runtime library given XML's relevance. > -Original Message- > From: Malcolm Wallace [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 16, 2000 8:42 AM > To: [EMAIL PROTECTED] > Subject: ANNOUNCE: HaXml 1.00 > > > We are pleased to announce > > HaXml release 1.00 > > > HaXml is a library enabling the use of Haskell and XML together, > together with several auxiliary tools for useful XML jobs. Fuller > details are on the web page. > > > What's new since 0.9? > - > The main addition is a full treatment of the external subset for DTDs. > The DtdToHaskell tool can now slurp in a single DTD from multiple > files, and also now treats conditional sections (INCLUDE and IGNORE) > correctly. > > There is improved error-reporting: lexing and parsing errors > now report > the relevant filename, and the line/column positions are more > accurate. > > > Where do I get it? > -- > Web pages:http://www.cs.york.ac.uk/fp/HaXml/ > FTP site: ftp://ftp.cs.york.ac.uk/pub/haskell/HaXml/ > > An older version of HaXml is also included in GHC's hslibs, in package > "text". This will probably be updated to 1.00 at some time. > > Regards, > Malcolm > > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: XML Programming Languages...
I would think the tool of choice would be XSLT, not Haskell. The saxon xslt translator is pretty good for command line translation. The microsoft XSLT latest Beta xslt is good too. What xml parser are you using XML in haskell? I am familliar with this stuff: http://www.cs.york.ac.uk/fp/HaXml. I am thinking of building an XSLT translator in haskell and need some place to start. If there are any suggestions on tools and techniques I would be happy to hear them. I am researching combinator libraries now. I have configured this message so that replies should go to haskell-cafe automatically. > -Original Message- > From: Ketil Malde [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 14, 2000 1:23 AM > To: Jino Hyun > Cc: [EMAIL PROTECTED] > Subject: Re: XML Programming Languages... > > > "Jino Hyun" <[EMAIL PROTECTED]> writes: > > > - What XML Programming Language is. > > Dunno - a language with good libraries for XML parsing and > validation, > perhaps? I'm using Haskell to take a bunch of HTML-pages, extract > data from them, manipulate it a bit, and generate a new > HTML-page with > the results. > > For this, it is necessary to build and manipulate huge trees, > something Haskell (like most functional languages) does very well. > The usual benefits, like flexible static typing and quickly > developed, > correct programs also apply, of course. The few bugs that weren't > caught by the type checker, were quickly fixed when discovered. > > Unfortunately, and I'm going to agree with graham here, the resulting > program uses a lot of memory (parsing about one meg of HTML, > producing > about 200K of results makes my 128Mb machine suffer), and I get a > run-time error[1] if I feed it too much data. > > -kzm > > [1] Prelude.(!!) index too large. Sounds almost entirely, but not > quite, unlike out of memory. Anybody know? > -- > If I haven't seen further, it is by standing in the > footprints of giants >
RE: Usability of M$ specs [was: Haskell and the NGWS Runtime]
Are there formal semantics for either C# or common runtime? > -Original Message- > From: Matthias Kilian [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 11, 2000 8:32 AM > To: Andrew Kennedy > Cc: Erik Meijer; Ketil Malde; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > Marcin 'Qrczak' Kowalczyk; [EMAIL PROTECTED] > Subject: RE: Usability of M$ specs [was: Haskell and the NGWS Runtime] > > > On Mon, 11 Sep 2000, Andrew Kennedy wrote: > > > I agree that this construct is a touch under-specified; I've emailed > > the C# team with your criticism so hopefully it will get > fixed. However, > > it seems a little harsh to conclude that the .NET runtime > is to be avoided > > as a target. > > That was no conclusion but a question. If .NET is specified more > carefully than C#, it should be possible to port the runtime > env. to other > platforms. One additional question is how .NET interacts with the > remainder of ths system (file system etc.); it's clear that > Microsoft is > not interested in implementing any platform independent. However, if I > understand what I've read already, neither C# nor the .NET runtime > environment mentions any requirements to system libraries (as MFC for > example). > > I've no idea about how much system dependend code has to be written to > > - implement .NET on other platforms (i.e. several unices) > - implement .NET backends for Haskell and/or ML compilers > > at least for basic functionality (file system access, sockets) there > should be not too much problems. > > Regards, > Kili > > -- > Auf deutschem Boden darf nie wieder ein Joint ausgehen. > [Wolfgang Neuss] > >
RE: Patterns Catalog
Unfortunately there are only 3 idioms cataloged. Maybe someone could get a thesis or textbook out of this. Here is a link to a description of such a book for OO: http://www.chapters.ca/books/details/default.asp?ISBN=0201633612&mscssid=L5D 5PBN270S92G3S00AKHCJKTTGEF1C7&WSID=1009F699A2218A0411D4840A00508B629EDB4614 > Thanks to SLPJ for pointing out that it HAS been resurrected. It's at > > http://haskell.org/wiki/wiki > > and you should look at `CommonHaskellIdioms' > > --KW 8-) > -- > Keith Wansbrough <[EMAIL PROTECTED]> > http://www.cl.cam.ac.uk/users/kw217/ > Cambridge University Computer Laboratory. >
Patterns Catalog
I have worked through "Haskell: The craft of functional programming". Learning the language is one thing, applying FP is another. The next thing I would like to study would be a catalog of patterns for lazy functional programming. In the Object-oriented world, there are some catalogs of useful program techniques. I would like to know if there is anything like that in the Haskell/Functional Programming world. It is not clear to me when and how to use higher-ordereredness outside of map, filter, some partial applications and simple lambda expressions to be used in the above. Is there a catalog of patterns or some other book useful in becoming a skilled functional programmer?
RE: The importance and relevance of FP
I do believe FP is current 90 degrees out of phase with OO. I think the isue with tuples, lists, conses, etc. it the big problem. I currently see no way for someone to write a clever matrix library in Haskell and have it seamlessly integrate into the NGWS framework (the new object type and runtime system from MS likely here to stay for a long long time) and C#, VB, etc. The impedance mismatch is just too high. I think it is really far fetched to expect tuples, lists, etc. to be mainstream in an environment like NGWS -- the C#/Java/VB languages are just not going to make that step. NGWS will just provide a cool runtime for Haskell to sit on, but Haskell will still be off in its own little corner. -Original Message-From: Jacques Lemire [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 15, 2000 2:24 PMTo: haskellSubject: The importance and relevance of FP Mr Rawson wrote: = However, almost no one is even thinking about FP. I think NGWS willbe the kiss of death for FP in the large -- OO just seems 90 degrees out ofphase with FP. = On the contrary, languages like C++ (and Java) and C# are full of concepts and ideas coming from FP languages. For example, the catch/try/throw construct is coming directly from Common Lisp (Lisp is a (although impure) FP language). I would n ot be a bit suprise to see tuples, lists and cons(es) introduce in the next generation of languages. FP languages are to VB or C++ what F1 cars are to a Chevrolet or Diesel trucks. You don't get a liter of milk with a F1 car! Moreover, OO is only one way of doing things: it is amazing the numbers of projects (and working) that are *not* programmed with C++. If you what to see the limitations of OO and C++, take a look at the MFC, MFC architects had to introduce macros. Jacques Lemire [EMAIL PROTECTED]
RE: The importance and relevance of FP
> > If C# again makes it easy to write unsafe code, then in order > to avoid the learning curve, many current C/C++ programmers > are likely to continue programming in The Old Way. The trick > lies in the learning curve. > I think you are mistakening ignorance for stupidity. It is true that C/C++ programmers like to write OO and few have any idea about functional programming, but very few will miss the ability to constantly shoot themselves in the foot with uninitalized random pointers, weird memory access errors, and none will miss spending a couple of weeks at the end of the development cycle trying to find a memory leak. Doug Ransom > --Ben > -- > Benjamin L. Russell > [EMAIL PROTECTED] > [EMAIL PROTECTED] > "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho >
RE: Haskell and the NGWS Runtime
I think most C++ programmers realize C++ for what it is, a poorly designed portable object oriented assembler language. Most C++ programmers use C++ because they program for windows and COM, and the only other real choices of development environments are VB and Delphi (which I do not know anything about). VB does not fully support COM development nor object-oriented programming (nor any other kind of programming really), so developers have little choice but to play with the C++ gun and hope they do not shoot themselves in the foot. We use VB when we can and C++ when we must in our shop. I think almost every Windows developer is eager to move to the safer world of C#. However, almost no one is even thinking about FP. I think NGWS will be the kiss of death for FP in the large -- OO just seems 90 degrees out of phase with FP. -Original Message- From: Benjamin Leon Russell [mailto:[EMAIL PROTECTED]] Sent: Monday, August 14, 2000 8:10 AM To: Tyson Dowd; [EMAIL PROTECTED] Cc: Craig Dickson Subject: Re: Haskell and the NGWS Runtime On Sun, 13 Aug 2000 22:36:42 +1000 Tyson Dowd <[EMAIL PROTECTED]> wrote: > On 11-Aug-2000, Craig Dickson <[EMAIL PROTECTED]> wrote: > > Antony Courtney wrote: > > > > > > > will be coming from C and C++ where it is perfectly > normal to do all sorts > > of things that the compiler cannot guarantee to be > safe. This leads to all > > sorts of bugs such as buffer overflows, stack > corruption, page faults > > accessing unmapped memory, etc. By making it so > convenient to write unsafe > > code in C#, Microsoft has essentially given these C/C++ > coders an excuse not > > to bother learning how to write safe code, and many > programmers will take > > that excuse. > > I don't believe you can teach programmers anything by > trying to take > tools away from them. > > I believe you can only teach programmers by showing them > a better tool. Aha, but *which* programmers? The C/C++ programmers who will bother learning how to write safe code, or those who won't? Many programmers work on teams. Suppose you have 50 programmers on a team working under a tough time limit, and most of them have just switched from C/C++ (where they were accustomed to working with unsafe code most of the time) to C#. Will they choose to learn how to write the bulk of their procedures using safe code (possibly missing the deadline in the process), or just continue writing lots of unsafe code (and possibly meeting the deadline, but also likely introducing bugs such as memory leaks in the process)? > > > So long as the unsafe code is clearly labelled as such, > and cannot be > confused with safe code why does it have to be in a > different language? > > Why do you have to sacrifice all the features of the > language you are > currently using just because you need to write some > unsafe code? The problem is that many programmers will not focus on the safe features if the unsafe ones remain. It takes time to learn a new skill, and if the programmers already know how to write unsafe code that they are convinced will work (even if it also potentially introduces bugs), they are not likely suddenly to change their style and to write everything using safe code whenever possible, even if it happens to be better in each situation. They are working under pressure and want to meet the deadline. So, they will use whatever they already feel most comfortable with, including unsafe code even when it is not necessary. For example, if the C/C++ programmers are used to explicit memory management using malloc() and free(), then they are likely to keep writing all their methods using this old style, even when the running time is not crucial. This could potentially introduce more memory-related bugs than necessary. > > > If you can implement the unsafe stuff in a way that > doesn't harm > the rest of the implementation, and you can partition the > unsafe portion > of the language from the safe portion in a way that is > acceptable in > software engineering terms, then the programmers can have > an easier time > writing or interfacing to bit-twiddling, pointer > manipulation code. That's a *big* "if," though. Again, what if the programmers are undisciplined and undertrained former C/C++ programmers (most likely, a large portion of the programmers will be from this group), and most of the implementation winds up being unsafe? Then what? Suppose the manager starts the project by requiring that all the programmers write all non-time-critical portions of their code in pure C#. Suppose that the programmers are from the above group. If the language supports unsafe code, then the programmers are likely to write much of their code using unsafe code, simply because they are used to that style, even when unsafe code isn't completely necessary. If the language doesn't support unsafe code, then they are forced to learn how to write safe code, whether they want to or not, because that is the only way to wr
RE: Haskell and the NGWS Runtime
Interesting results might be generated if Microsoft were to provide the entire C# team and the team designing the virtual machine 2 weeks to learn Haskell and play with it. -Original Message- From: Tyson Dowd [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 09, 2000 9:26 PM To: Brent Fulgham Cc: [EMAIL PROTECTED] Subject: Re: Haskell and the NGWS Runtime On 09-Aug-2000, Brent Fulgham <[EMAIL PROTECTED]> wrote: > > Hopefully that won't be the case. However, I feel uncomfortable with > the whole .NET/C# situation. Like clockwork, MS releases yet another > new product that they claim will change the world. Meanwhile, there is > no C# implementation available, and the entire .NET framework as > described in their various white papers seems so large and complex > that probably only Microsoft will be capable of producing a working > implementation in any reasonable amount of time. You can download it here: http://msdn.microsoft.com/net/#sdk There is a C# compiler and runtime environment in the SDK. They used to say that only proprietary companies could possibly write something so large and complex as an operating system. It could never be done, for example, by a bunch of volunteers... > Microsoft indicates that C# will not support "genericity", through > even anything as crude as C++'s templates, so it is unlikely that > they will seek to support functional programming languages in the > short term. Perhaps this limitation is part of the impetus for the > Mondrian variant. They did add a tailcall instruction largely at the behest of certain functional language researchers at MSR Cambridge. They have developed a prototype C# implementation (and hence .NET runtime) with generics too. > When Microsoft decides to stop playing games, and works with the > rest of the developer community to build on existing standards for > their products I will start to pay attention. Until then, I will > not waste one minute of time working to support any of their > nefarious new products whose true aim is to prevent alternative > platforms from gaining widespread acceptance and use. Microsoft spent around $2M funding a bunch of groups working on research and industrial programming languages to give feedback on their work. (Haskell, Mercury, ML, Scheme, Oberon, Eiffel, Python, Oz, etc...) While they acknowledged from the start that getting any changes (apart from tailcall) into version 1 was pretty unlikely, they have been listening, taking notes, and even now the C# folks are getting excited about the idea of putting generics into the language. I understand your sentiment. Those of use working on the .NET stuff with Microsoft are also uncomfortable about the situation. However I'm sure that everyone involved is doing what they think is the best thing overall. Don't forget that many groups developed a .NET and a JVM backend at the same time using Microsoft's money! -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. [EMAIL PROTECTED]# http://www.cs.mu.oz.au/~trd #
RE: Haskell and the NGWS Runtime
Back to the language wars then. It does seem like integration of Haskell and the NGWS is a graunch, largely because Haskell is not OO. Is there anything preventing Haskell from becoming OO and seamlessly fitting into the NGWS? Or from designing a functional language that would be a good fit into the NGWS. A major problem I see is that there is probably a standard set of container classes in NGWS which have a high impedance mismatch with the lists functional languags use for their constructions. Can we ever have functional programming "in the large" given the OO paradigm and NGWS are both here to stay? This can not happen until I can get a language which seamlessly fits into NGWS (or some similar thing on a non-windows platform). -Original Message- From: Antony Courtney [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 06, 2000 3:49 PM To: Jürgen A. Erhard Cc: [EMAIL PROTECTED] Subject: Re: Haskell and the NGWS Runtime "Jürgen A. Erhard" wrote: > > > "Manuel" == Manuel M T Chakravarty <[EMAIL PROTECTED]> writes: > > Manuel> "Erik Meijer" <[EMAIL PROTECTED]> wrote, > >> [...] The lab is *sponsored* by Microsoft, but definitively not *at* > >> Microsoft. I doubt there are any Linux boxes at Microsoft :-) > > Manuel> [...] There have also been reports of Linux boxes in the main > Manuel> company, but the validity of these reports is of course not > > But easy to believe... I mean, wouldn't you take a good look at your > competition? Having spent five years doing Windows and Win32 hacking, and 10+ years doing Unix hacking before that, I can assure you there is little evidence that Microsoft are interested in learning anything whatsoever from Linux or any other Unix work-alike. Rather than re-iterate the argument, I'll simply point interested readers towards the excellent article "Working with Win32: the good, the bad and the ugly" by David G. Korn http://www.usenix.org/publications/login/1997-11/win32.html which mostly reinforces the quote: Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer Now that I've gotten MY little barb in, can we PLEASE end this tangent on OS wars, and return to our regularly scheduled language wars? :-) Thanks, -Antony (haskell list lurker) -- Antony Courtney [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
RE: Haskell and the NGWS Runtime
It is not what language that you want on your phone that matters -- you
didn't write the software. What matters is any development team can pick
the language they prefer to use and make their software portable to your
phone or your PC.
-Original Message-
From: Nigel Perry [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 04, 2000 12:54 AM
To: [EMAIL PROTECTED]
Subject: Re: Haskell and the NGWS Runtime
We're drifting a bit off Haskell here, but...
At 10:57 am +1000 4/8/00, Kevin Glynn wrote:
>I don't believe this says anything about support for other OS's. I
>think the devices here are hardware, (PCs, handhelds, phones, fridge
>interfaces, ...) Of course Microsoft believes that some day, very
>soon, all devices will run (a version of) Windows. Hence this
>statement refers to Microsoft's announced plans to port .NET to all
>Windows OS's, including WinCE.
>
>Do you have another reference which is more convincing?
I haven't seen a WinCE version but at a recent conference one of the
exhibitors was offering a .NET on WindowsCE course - however when I
inquired they just said "ask MS, we don't know, we just teach the
courses" (somehow I don't think I'll be recommending them!) So that's
not too convincing!
They are talking phones - but that has to be a stripped down version.
However I'm not sure why I want Haskell on my phone ("the phone with
higher-order polymorphic lazy dialing"?)
As to others OSES...
At 10:24 pm -0400 3/8/00, Chris Saunders wrote:
>It seems to me that this .Net thingy is a runtime
>and therefore could potentially be as portable
>as anything from Java. This runtime just needs
>to be ported to other operating systems similarily
>to the Java runtime.
Porting JVM is a big enough job (you find a lot of "native"
methods...) .NET has more paraphernalia than the JVM so it will be
quite a job. However I think MS is moving to "standardise" the IL
(the byte codes) which I guess is to suggest it is not a moving
target (not the the JVM really is but I hear the lack of JVM 2's has
been blamed on lack of info out of Sun - but that might be just
passing the blame)
At 5:59 pm +0200 3/8/00, Juan J. Quintela wrote:
>nigel> Disclaimer, as Fergus added one: I am working with Microsoft on .NET
>nigel> implementation, but I run Windows 2000 on my G3 PowerBook and take
it
>nigel> to Microsoft with me. I'm biased on everything :-)
>
>Windows 2000 in a G3 Powerbook? I am lost here :((
Why have any other computer when you can have a Mac?
Mine runs:
DVD Movies
MacOS
JVM
Playstation games
Windows 95
Windows 2000 (a bit slugglish)
and could run:
Linux (but I have no use for it at present)
At 2:07 am +1000 4/8/00, Fergus Henderson wrote:
> Note that on x86 there are only six general purpose registers,
> so you very quickly run out...
Who uses the x86? Oh I remember... ;-)
Cheers,
Nigel
--
--
Dr Nigel PerryEmail: [EMAIL PROTECTED]
IIST Tel: +64 6 350 5799 2477
Massey University Fax: +64 6 350 2259
Palmerston North FTP/WWW: smis-asterix.massey.ac.nz
New Zealand
It makes as much sense to wear a "cycle" style helmet in a car as on a
bike...
Choosing to wear one on a bike but not in a car is mere inconsistency.
Refusing to wear one in a car while insisting others do so on a bike
is pure hypocrisy.
Will the new Labour government repeal the National government's hypocrisy,
or will they insult cyclists' like their predecessors?
Politics and hypocrisy before safety - the NZ Helmet Law, NZ's Shame
RE: Haskell and the NGWS Runtime
The PDC slides and white papers should be available if you dig through this site: http://commnet.pdc.mscorpevents.com/default.asp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 02, 2000 9:43 AM To: Fergus Henderson Cc: [EMAIL PROTECTED] Subject: Re: Haskell and the NGWS Runtime Fergus Henderson <[EMAIL PROTECTED]> writes: > > The compiler hooks into GHC by translating Core into GOO > > and then after some source to source transformations it > > can spit out either C# or Java. Is there any publically available technical information on what you guys are talking about? I've been doing web searches, and searches on the Microsoft web site, and I can't find anything on GOO, IL, or "Common Language Specification". Carl Witty
Haskell and the NGWS Runtime
Does anyone know where there is some information on Haskell integration with the Microsoft NGWS runtime, which provides cross language integration and a common system for memory managment, library functions etc. I am curious to see if the haskell integration is a good fit or a graunch (square peg into a round hole). I know some work is being done on haskell in this regard, but exactly what I do not know.
Haskell and the NGWS Runtime
Does anyone know where there is some information on Haskell integration with the Microsoft NGWS runtime, which provides cross language integration and a common system for memory managment, library functions etc. I am curious to see if the haskell integration is a good fit or a graunch (square peg into a round hole). I know some work is being done on haskell in this regard, but exactly what I do not know.
Re: Clean and Haskell
I am curious. How much faster do you think GHC would run if it were written in C? Or how much slower would a C++ compiler be if it were written in Haskell instead of C++? It seems to me that a compiler would be an ideal candidate for writing in a functional language. The number of times C++ compilers have given out on me indicates that C++ is not suitable for writing anything as complicated as a C++ compiler. > Hello Steve, > > > I just want to say that Haskell is a fat old slow > > dinosaur compared with Clean. [...] > > By Haskell you probably mean the Glasgow Haskell Compiler (GHC). And > compilation by GHC is certainly slower than by the Clean compiler. On the > other hand, the generated code is comparable, sometimes faster, sometimes > slower. See: > > Benchmarking implementations of lazy functional languages II -- Two years > later > http://hypatia.dcs.qmw.ac.uk/SEL-HPC/Articles/GeneratedHtml/functional.imp > lemen.html#HartelPH1994a ) > > In this article you can read that GHC has improved considerably since the > first article and Clean "not significantly". If this is a trend then by now > (four years later) GHC's code could be always faster than Clean's. Maybe > it's time for a new benchmark. > > The reason that GHC's compilation times are longer is that it is written in > Haskell (as opposed to C for the Clean compiler). However, during > development many people use the Haskell interpreter Hugs. This interpreter > is fast, interactive and light-weight. So by using both GHC and Hugs you can > get speed in both areas. > > An advantage of a compiler written in Haskell is that it is easier to > maintain and that more people can experiment with it. The source code of the > Clean compiler is a secret. > > Another thing you mention is that Haskell is old. This remark shows that you > have not been paying attention to the Haskell community. Things move rather > fast. So fast that it has been decided to freeze Haskell at a certain point > (Haskell 98). But research continues on what you might call Haskell 2 or > Haskell 2000. Some features that have been implemented lately include > implicit arguments, extensible records and class constraints. > > I've used both languages a lot and I like them both. Where Clean stands out > in comparison to Haskell is that it has a library for making > platform-independent GUIs. In the Haskell world there is not yet a standard > GUI framework. I would love to see a library with the simplicity of TkGofer > for Hugs and/or GHC. > > In Haskell I like the IO monad very much. It gives you input and output, > exceptions and mutable variables. In combination with implicit arguments it > allows you to elegantly write down inherently imperative code. > > As a teacher I think the type systems of both languages are very complex, > possibly too complex. Therefore, error messages are often hard to > understand. If we want to make (more) students enthusiastic about functional > programming this is a problem that should be tackled in the near future. > > Arjan > teacher, former member of the Clean team, Haskell enthusiast and Mondrian > hacker > > >
