Re: Functional programming in Python
Interestingly enough, I have the same feeling with Python! As for the difficulty with imperative constructs, I agree it's not even an issue for many (Dylan, ML, et. al.) languages, but for Haskell it still is, in my humble opinion. I found the task of writing a simple program that did a few simple imperative things inordinately difficult. I know about the 'do' construct, and I understand the difference between and =. I've read a book on Haskell, and implemented functional programming support for Python, but trying to use Haskell to write complete programs still ties my brain in knots. I see there are people writing complete, non-trivial programs in Haskell, but I don't see how. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Interesting: Lisp as a competitive advantage
- Original Message - From: Norman Ramsey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 7:16 AM Subject: Re: Interesting: Lisp as a competitive advantage http://www.paulgraham.com/paulgraham/avg.html I wonder how Haskell compares in this regard. I loved Graham's characterization of the hierarchy of power in programming languages: - Languages less powerful than the one you understand look impoverished - Languages more powerful than the one you understand look weird Same for me; although you should not fall into the trap of reversing it, ie if the language looks weird is is more powerful! When I compare Lisp and Haskell, the big question in my mind is this: is lazy evaluation sufficient to make up for the lack of macros? Don't you get dynamic scoping as well with macros? I would love to hear from a real Lisp macro hacker who has also done lazy functional progrmaming. Norman ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Implict parameters and monomorphism
[...many lines deleted...] I think it's important to have a simple model of how many times expressions are evaluated. Function bodies are clearly evaluated many times, once for each call, but non-function bindings should be evaluated at most once to respect call-by-need semantics. Breaking the monomorphism restriction in ANY case makes both space and time cost of evaluation unpredictable, and brittle when program changes elsewhere introduce or remove an implicit parameter. It isn't good enough to say `the chances are' that a program has, for example, linear time and constant space complexity: the programmer should be able to convince himself of such properties. But a term with an implicit argument is a function no matter how you turn it, you just don't write the argument explicitely. As far as what one would `expect', it's in the very nature of dynamic binding that it makes the meaning of an expression depend on its context. I for one would certainly not expect that inlining a definition bound to such an expression should preserve its meaning! Inlining changes the context, so `of course' can change the meaning. So I strongly prefer (B)! John Hughes ___ 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: haskell.runtime.* ??
There is a working GHC-to-.Net runtime available at www.mondrian-script.org http://www.mondrian-script.org/ ; reving the Jva a backend should not be too much of a problem. Erik Message: 1 Subject: RE: haskell.runtime.* ?? Date: Sun, 29 Apr 2001 12:16:24 -0700 From: Simon Peyton-Jones [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: Kwanghoon Choi [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] , [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] I'm afraid that no one ever completed the GHC Haskell-Java story. The idea is that the JVM is the runtime, but of course you need to implement the standard libraries somehow,=20 and all the primitive operations GHC uses. Not a trivial task, but one we are undertaking for .NET. Bottom line: the reason you can't find a runtime is because you are supposed to compile the Java with a Java compiler and run that. But you'll need to do more than that to actually run programs Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Syntax for implicit parameters
As I was not involved in that discussion, why should the keyword "with" not be introduced? Just curious, Erik - Original Message - From: "Alastair Reid" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, April 18, 2001 10:31 AM Subject: Syntax for implicit parameters Some months ago, there was talk about making sure GHC and Hugs use the same syntax for implicit parameters and (most importantly) that that syntax should not introduce the keyword "with". As far as I can see (from looking at both parsers and trying examples), this discussion has not been acted on. Hugs seems to allow: dlet ?x = 'a' in ?x + 1 ?x + 1 with ?x = 'a' and GHC 5.0 only seems to support: ?x + 1 with ?x = 'a' Can the GHC people, the Hugs people and the implicit parameter designers come to some sort of agreement and implement the result? -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ Hugs-Bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/hugs-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Hello List Have an IO String question
use unsafePerformIO (that's this year's April fools' joke :-). Do a Google on "Monads Haskell" and you will find plenty of answers; in short you should "bind" the result of readFile using (=) : IO a - (a - IO b) - IO b. Erik - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 02, 2001 5:57 PM Subject: Hello List Have an IO String question I am new to the list and to Haskell, and would appreciate any help anyone can give me on a problem I am having. I am using Hugs98 in case that matters. My question involved reading from a file. I used the line: readFile "c:/myfile.txt" To read my file and this works fine. I now want to take the contents of the file and use it in a function that takes in a String, but am getting an error since readFile returns an IO String. Is there a way to convert an IO String to a normal String? Thank you all. Rob ___ 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: Just for your fun and horror
Why should we change and not C? Erik - Original Message - From: "Jan Skibinski" [EMAIL PROTECTED] To: "Jerzy Karczmarczuk" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, February 16, 2001 1:17 AM Subject: Re: Just for your fun and horror On Fri, 16 Feb 2001, Jerzy Karczmarczuk wrote: My inquiry proved beyond any doubt that my students are so conditioned by "C", that despite the fact that we worked with monads for several weeks, they *cannot imagine* that "return z" may mean something different than the value of "z". Any suggestions? Perhaps the name "return" in the monadic definitions could be replaced by something more suggestive of an action? How about running a little experiment next time, with a new name, to see whether this would remove this unfortunate association with C-like "return" in the minds of your students? Jan ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC Core output
I would *really* love to see GHC componetized (TM); it would even be better if it would become easier to use the pieces. I would like to do experiments on smaller bits of the compiler using Hugs (ideally the whole thing!). When I was working on the Java/.NET backend I had to rebuild the whole compiler just to test a few hundred lines of code that translated Core to Java which is a major pain in the butt; I don't get a kick out of dealing with installing Cygnus, recursive multi-staged makefiles, cpp, etc. Erik "do you get a kick out of runnning the marathon with a ball and chain at your feet?" Meijer - Original Message - From: "Andrew Tolmach" [EMAIL PROTECTED] To: "'Timothy Docker'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, February 06, 2001 2:53 AM Subject: RE: GHC Core output Timothy Docker [mailto:[EMAIL PROTECTED]] writes: We agreed that it would be a Jolly Good Thing if GHC could be persuaded to produce GHC-independent Core output, ready to feed into some other compiler. For example, Karl-Filip might be able to use it. ANDREW will write a specification, and implement it. A quick question. What is meant by "Core output"? Subsequent posts seem to suggest this is some "reduced Haskell", in which full Haskell 98 can be expressed. Am I completely off beam here? Not at all. "Core" is an intermediate language used internally by the GHC compiler. It does indeed resemble a reduced Haskell (but with explicit higher-order polymorphic types) and GHC translates full Haskell 98 into it. Currently Core has no rigorously defined external representation, although by setting certain compiler flags, one can get a (rather ad-hoc) textual representation to be printed at various points in the compilation process. (This is usually done to help debug the compiler). What we hope to do is: - provide a formal definition of Core's external syntax; - give a precise definition of its semantics (both static and dynamic); - modify GHC to produce external Core files, if so requested, at one or more useful points in the compilation sequence -- e.g., just before optimization, or just after. - modify GHC to accept external Core files in place of Haskell source files, again at one or more useful points. The first three facilities will let one couple GHC's front-end (parser, type-checker, etc.), and optionally its optimizer, with new back-end tools. Adding the last facility will let one implement new Core-to-Core transformations in an external tool and integrate them into GHC. It will also allow new front-ends to generate Core that can be fed into GHC's optimizer or back end; however, because there are many (undocumented) idiosynracies in the way GHC produces Core from source Haskell, it will be hard for an external tool to produce Core that can be integrated with GHC-produced core (e.g., for the Prelude), and we don't aim to support this. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: binary files in haskell
This is exactly what I proposed when fmap and the other weird names were introduced. Hopefully there are more allies now. Erik - Original Message - From: "Koen Claessen" [EMAIL PROTECTED] To: "The Haskell Mailing List" [EMAIL PROTECTED] Sent: Tuesday, February 06, 2001 6:25 AM Subject: Re: binary files in haskell Johannes Waldmann wrote: | Should this also apply to names in the standard | library? like Monad (filterM, zipWithM ,..) I mean, | theoretically yes, but is it feasible to change it? Obviously, these functions should have been called: Monad.filter, Monad.zipWith The lazy programmer can then say: import Monad as M(*) M.filter, M.zipWith Just (asymptotically) 1 character more! :-) | getLine - hGetLine always irritates me. How about: import Handle as H H.getLine (This is a good example where type classes would not help making this any better, since the types of getLine and H.getLine are very different.) While we're at it, how about instead of the "fmap" function: Functor.map (F.map) List.map (L.map) Maybe.map(M.map) The programmer can pick him/herself what function to use. (The Prelude really has too many functions in it, and very often the rationale for a function being in Prelude or in Char/List/Maybe/Monad/IO/etc. is not motivated.) What do people think about this? If people prefer these stylistic changes, I think we should not hesitate making them for Haskell/2 by completely redesigning the module structure and using more consistent naming conventions. /Koen. (*) What actually happened to the excellent proposal somebody made a while ago for Haskell98: import M = Monad ? I like it a lot! -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 mailto:[EMAIL PROTECTED] - Chalmers University of Technology, Gothenburg, Sweden ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
FFI in new Hugs beta
Is there any documentation on using the FFI in the just released Hugs beta?
For example, what steps should I take to call the following C function?
#include stdio.h
void Hello () { printf ("Hello from C"); }
Erik
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Haskell -- Java was Re: (no subject)
Have a look at http://www.mondrian-script.org Erik - Original Message - From: "Chris Angus" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 24, 2000 1:44 AM Subject: (no subject) I was wondering if Has anybody had access to a Haskell - Java compiler/translator. - Chris Angus Armature Enterprise House 1 Apex View Leeds LS11 9BH +44 113 2595253 [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Literate Programming
This one of the reasons why I never use literate programming. I always forget the blank lines, and then after being puzzled by the error, I remember it, and get completely turned off. C Literate comments [...] To capture some cases where one omits an "" by mistake, it is an error for a program line to appear adjacent to a non-blank comment line, where a line is taken as blank if it consists only of whitespace.
Re: Haskell and the NGWS Runtime
This runtime just needs to be ported to other operating systems similarily to the Java runtime. So it's a question of either source availability - or at least a very complete specification - or Microsoft strategy. With the SDK that you can download from MS comes a 500 page specification of the runtime and the IL. So if you have a free Saturday and you want to get famous, then give that Linux implementation a try. Some interesting background on MS plans to standardize this stuff is available at http://www2.hursley.ibm.com/tc39/mins-13jul00.html#csharp. Erik
Re: Haskell and the NGWS Runtime
I'm weird, but not a true 'CS' person. I run Linux -- do I need to move to NetBSD? The single Linux box we have in the Microsoft lab was severely hacked from the outside, they have moved to FreeBSD, which is supposed to be safer (I hope so). Erik
Re: Haskell and the NGWS Runtime
Not "at least" but "only". I haven't heard of plans for .NET on any non-Windows platform. Then you should listen more closely! a quote from the .NET whitepaper: Microsoft .NET proactively adapts to what you want to do, on any of your devices. This inversion of the traditional installation-dependent application model is a necessity in a world where users will enjoy the benefits of services on multiple devices. http://www.microsoft.com/net/ Erik
Re: Haskell and the NGWS Runtime
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 :(( No, Nigel is not breaking an NDA by accident and revealing that MS has ported W2K to the PowerPC. He uses VirtualPC (which effectively *is* a port of W2K to the PowerPC in some sense). Erik
RE: Haskell and the NGWS Runtime
Erik Meijer [EMAIL PROTECTED] wrote: ^^ Yes, that refers to the computer lab sponsored by MSR Cambridge and MS Netherlands in Utrecht. The plan is to have the release out the door by September 1st. Will that release support Haskell, or just Mondrian? 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. I'm afraid I have to disagree on that point. Basically you translate quite a few things by implementing your own virtual machine on top of the .NET runtime. For example, argument passing is done with explicit pushes and pops on your own virtual machine stack, rather than by using the .NET runtime's argument passing. This approach makes the compiler is fairly simple, but the generated code is not what _I_ would call elegant. As I explained the translation has to implement the features that the .NET runtime does not provide itself. Hence, must implement lazy evaluation and you must implement currying yourself. The same is true for Mercury. Since the .NET runtime does not support backtracking, you are simulating that by passing extra continuation arguments around. Don't you currently encode tail calls too? By exploiting tail-calls, which we don't do yet, you can use the underlying argument passing mechanism if you call a known function by calling one of its fast entry points. So you don't pay for currying and HO functions if you don't use them. The same is true for laziness btw. And what about type classes and polymorphism? By the time you reached Core, type classes are compiled away by the dictionary translation. To implement polymorphism for Haskell there is no need to carry around types at runtime. Also, as I understand it, Haskell/Mondrian programs that don't make use of currying -- e.g. those in which all functions have only one argument -- still get encoded, rather than being mapped directly. So the encoding is not done in way that you only pay for it when you use those features. This makes interoperability with other languages more difficult. Not true. It is extremely easy to interoperate with other languages. Yes, you do have to do some marshalling and unmarshalling, but again, you *must* do that to match up the semantic differences between the language of the caller and the callee. To call out from Haskell, you use a trivial wrapper function that pops the arguments from the stack (which is there to support currying), evaluate them to WHNF (because in Haskell the caller does not do that) and then directly calls the external function. In the current implementation there is no need to unmarshall the result. To call into Haskell, you use a trivial wrapper function that pushes the arguments on the stack and calls the underlying Haskell function. Or you call the function directly trough its fast entry point. Hmm, the "full" adjective here sounds like it might be a bit of an overstatement. Does that mean that I can call Mercury code from Haskell, have it all statically type checked, and not have to write any additional interface definitions or glue code? Including procedures which are polymorphic and/or use type classes? If so, I would be very surprised! I think the current level of interop supported is still a LONG way from what I would describe as "full" interoperability. Come on Fergus! You will never achieve interoperability on that level except when your semantic domains match exactly or when you have an extremely complicated intermediate language. For example, most languages don't make the distinction between values and computations as Haskell does, and I don't expect or want for example VB programmers to do that either. But it does mean that whenever I call a VB function, I must write a little glue code to compensate for the difference in semantics. The same is true for calling nondeterministic or multi-moded Mercury predicate. With "full" I mean that modulo the required semantic impedance matching you can call So, could you elaborate on what sense you mean when you say we have "full" bidirectional interop? For example, which of the various CLS (Common Language Specification) categories does the Haskell and/or Mondrian implementation comply with? In addition, I think your compiler also needs to support attributes? Aha, finally you hit a real issue. To be a CLS extender would require a lot of language extensions to a lot of languages, even to OO languages like Java! But for Haskell the situation is even more severe. Because Haskell does not have a notion of class (as in C#), there is no way that you can expect that Haskell can extend a class. Yet again, an extra level of indirection does the trick Since you can call Haskell from say C#, you just write a little wrapper class in C# whose methods are implemented in Haskell. On the Haskell side you call its constructor passing it the methods a
RE: Haskell and Java
I have to call Java compiled bytecodes from a Haskell program. So, I am looking for some kind of tool or library that implements this kind of functionality. The tool should implements this behavior in the same way as GHC allows calls to foreign C code. Hi Herman, This is what Lambada is all about. If you are interested in a copy please let me know. Erik
RE: A demodulizer for Haskell?
Have you looked at GHC? Erik == For our research, it would be helpful to have a "demodulizer" for Haskell --- that is, a program that can translate a Haskell program consisting of several modules into a single module. Ideally, this tool would also perform "tree shaking", removing functions that are not accessible from a specified root module. In particular, we would like to avoid including the entire prelude in every program. Stephen Weeks has written this sort of tool --- the defunctorizer --- for Standard ML of New Jersey. The defunctorizer has been very useful for adapting SML benchmarks for whole-program compilers. Is anyone aware of a similar tool for Haskell? Patricia Johann Franklyn Turbak
RE: When is an occurrence an occurrence
Since it's a Haskell 98 issue, I am in favour of (A): reverse :: [a] - [a] reverse xs = Prelude.reverse (tail xs) Alternative (B) looks rather ugly: M.reverse :: reverse :: [a] - [a] reverse xs = Prelude.reverse (tail xs) Cheers, Ralf I completely agree. Erik
RE: Haskell - Java bytecode?
Any particular reason for generating Java rather than JVM bytecode?
Does it make a difference?
Yes, we make *heavy* use of innerclasses and exceptions. So we are more than
happy to leave the dirty work to the Java compiler. (We are however
currently working on an "inner classes lifter" so that we can spit out flat
Java or even byte code directly.)
For example, the following program
main = do {
url - new_URL "http://www.mondrian-script.org";
protocol - (url # getProtocol) ();
putStr ("protocol = "); putStr (protocol);
host - (url # getHost) ();
putStr ("host = "); putStr (host);
};
is compiled into the following piece of Java (the current compiler actually
does a much better job when compiling monadic code like this, this gives a
fair impression of the kind of Java we generate. The great thing is that
even the code below runs pretty fast)
package demo.net.url;
public class main extends Object implements Code {
public Object ENTER () {
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.COLLECT(1, this);
final Object url = VM.POP();
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.COLLECT(1, this);
final Object protocol = VM.POP();
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.COLLECT(1, this);
final Object dummy$1 = VM.POP();
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.COLLECT(1, this);
final Object dummy$2 = VM.POP();
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.COLLECT(1, this);
final Object host =
VM.POP();
VM.PUSH(new Thunk(new
Code(){
public Object ENTER () {
VM.COLLECT(1, this);
final Object dummy$3
= VM.POP();
VM.PUSH(host);
return new putStr();
}
}));
VM.PUSH(new Thunk(new
Code(){
public Object ENTER () {
VM.PUSH(new
Nullary("host = "));
return new putStr();
}
}));
return new bind();
}
}));
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.PUSH(new Thunk(new
Code(){
public Object ENTER () {
return new Code[]{};
}
}));
VM.PUSH(new getHost());
VM.PUSH(url);
return new _35();
}
}));
return new bind();
}
}));
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.PUSH(protocol);
return new putStr();
}
}));
return new bind();
}
}));
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.PUSH(new Nullary("protocol = "));
return new putStr();
}
}));
return new bind();
}
}));
VM.PUSH(new Thunk(new
RE: Haskell - Java bytecode?
Hi Thomas,
Some quick answers in addition to Nigel's
1) tail recursion
We use the usual "trampoline" trick, with a little top-level interpretative
loop. Using the trick has a pleasant side effect that we can pass values on
the arguments stack as well.
2) polymorphism
All type informations gets erased, ie polymorphism in the source language
becomes "Object" in Java.
3) closures eval (i.e., laziness)
Below is the example code generated for S f g x = f x (g x). Thunk objects
intercept evaluation and update their code field. You recognize the
trampoline-trick as we return f instead of ENTER-ing it.
public class S implements Code {
public Object ENTER () {
VM.COLLECT(3, this);
final Object f = VM.POP();
final Object g = VM.POP();
final Object a = VM.POP();
VM.PUSH(new Thunk(new Code(){
public Object ENTER () {
VM.PUSH(a);
return g;
}
}));
VM.PUSH(a);
return f;
}
}
You will find a little more detail on
http://www.cs.uu.nl/~erik/MondrianDescription.html and on the Mondrian
homepage http://www.mondrian-script.org/.
We are trying to come with a new release real soon,
Erik
RE: When is it safe to cheat?
Hi Jan, When can I safely cheat haskell compiler/interpreter by pretending that I perform pure computations, when in fact they are not? If the computation is not pure, you cannot pretend it is. Here is a real example, from my Md5Digest module which works fine in Hugs: digest :: String - String digest string = unsafePerformIO ( marshall_string_ string = \x1 - prim_Md5Digest_digest x1 = \x2 - unmarshall_string_ x2 = \x3 - return x3 ) I gues that for digest it holds that s1 == s2 == digest s1 == digest s2 The only reason that the underlying function is impure is that is allocates memory to marshall its argument and then calls a C function. These side-effects don't influence the result of computing digest (it would be different if prim_Md5Digest_digest would take into account the actual address of its argument, or the time of day, the current Microsoft stockprice, ... currentSecond dummyInput = cheat expression involving dummyInput and unsafePerformIO This function however *should* return a different answer each time it is called, otherwise you will get distressed again that the clock stopped yet again. Some people pay lots of money to stop the time (they get a face-lift, take mega doses of vitamins, go jogging, or put their corpse in a freezer after they die). Perhaps we can sell them FP! Erik
RE: How to list all properties methods inside COM?
I am doing my final year project related to Haskell COM. I have to write a program that can read any COM display all the properties methods inside. Do you know how to solve this problem or would you please suggest some documents about this? Thank you very much, Phan Dung. You will have to use the type-library of a component to do this. Probably you can reuse a lot of code from H/Direct. Erik
RE: Die Meisterstu:cke of software engineering
Hi, I must admit that I got carried away by new extension, and have not come around to making a new release yet. On Oct. 4, 1999, I enquired here about availability of software described in that paper (Where is "Server Side Scripting" code?) and Erik's answer was, loosely speaking, "wait until I finish it". As far as I can tell nothing has changed in this respect. Probably you missed the announcement of mod_Haskell some time ago. Anyway, mod_Haskell gives you a Haskell98 update of my CGI-library integrated into Apache (yes, yes, that Linux-based webserver :-) At the same site http://losser.st-lab.cs.uu.nl:8080/ you will also find a pre-releas of Haskell Server Pages (HSP). Similar to ASP, JSP, PHP, PSP, etc it allows you to embed scripts directly inside HTML pages, but in addition you can recursively embed HTML inside HSP scripts. For example you can write % cells = [ [ (x,y) | x - [1..16] ] , y - [1..16] ] genData = \c - td bgcolor=% genColor c % % c % /td genRows = map (\r - tr% map genData r %/tr) % html body table border="1" % genRows cells % /table /body /html HSP are translated by a simple pre-processor to a "normal" CGI script. The great thing is that as a programmer you don't have to mess around with some (arbitrary) encoding of HTML. You just write *concrete* HTML syntax. HSP is a proof of concept for the viability of XMLambda (http://www.cse.ogi.edu/~mbs/pub/XMLambda.ps.gz, regrettably it was rejected for USENIX) which generalizes this to XML, so that you can define your own DTD and construct, transform, and pattern match XML documents using concrete syntax as well. Much better than XSL. Erik PS There is also a installshield Haskell98 compatible version of my library intended for IIS (the MS webserver) that includes a version of the JFP paper in HTML-help format. Unfortunately the student who made this left before he perfected the install script so you need to tweak a few things by hand.
RE: Component: Strongly typed or Loosely typed is better?
So, for a glue language, which one is better: a strongly typed language like Haskell or a loosely typed language like Perl, Visual Basic,...? Daan Leijen, Sigbjorn Finne, Simon Peyton Jones, Jim Hook, and myself have written a number of papers where we argue that Haskell is a great glue language, and that types are good. Erik
RE: Writing Apache modules in Haskell: mod_haskell
Hi Has anyone been able to access this site? I have tried several times over the past couple of weeks, and each time I have gotten a "No route to host" error. Because of Y2K paranoia we were forced to turn off our computers around the turn of the year and then we switched from Redhat to Suse. However, the mod_haskell site http://losser.st-lab.cs.uu.nl:8080/ is up and alive now. BTW the crew is now working on HSP, the one and only alternative for ASP, PHP, JSP, PSP, ... Yours, Erik Meijer
RE: CGI Scripts === mod_haskell sneak preview
CGI hackers might be interested in mod_haskell http://losser.st-lab.cs.uu.nl:8080/ that was developed by Eelco Dolstra and Armijn Hemel. Erik
Re: Where is Server Side Scripting code?
Erik Meijer, in his paper "Server Side Scripting in Haskell", FFP, Jan 98 (www.cs.uu.nl/~erik/) claims that his Haskell/CGI library is a part of the standard Hugs distribution. He also thanks the teams from Yale and Nottingham for including it as one of the demos in the standard distribution (of Hugs). I could not find it there though, nor on Erik's site. What is available from haskell.org are two much outdated versions of CGI library: one by Erik himself and one modified (and adopted to Haskell 98) by Sven Panne. By outdated I mean that they both are based on Erik's earlier work and much predate the refined and simplified concepts, quite nicely described in the paper. So where is the code in question? Is it still available to public and if yes - who is a keeper? Hi Jan (and the many others that have asked me about this :-) I have waited with updating the CGI library until my paper was accepted by JFP. Now that that has happened (in fact, I am checking the proofs right now) and since I will be teaching "Internet Programming" in November, there will be a new release soon. However, I am still wading to the 400+ email messages that accumulated in my mailbox during the last two weeks, most of them from [EMAIL PROTECTED]. This next release of Haskell/CGI will contain numerous bug-fixes that various people have pointed out to me, full support for cookies, and with wrappers for Active Server Pages and Servlets. So no matter wether you like plain old CGI scripts, MS, or Sun, you can use the *same* underlying script of type (Request - IO Response). Also, from the next version on the code will be under GPL. Erik Meijer
Haskell Workshop 1999 Proceedings Online
Hello Haskell Lovers,
The proceedings of the Haskell Workshop 1999 are now available online in PDF
format via my homepage http://www.cs.uu.nl/~erik == HaskellWorkshop or
via the departemental Technical Reports repository
http://www.cs.uu.nl/docs/research/publication/TechRep.html.
@PROCEEDINGS{HaskellWorkshop1999
, TITLE="Proceedings of the 1999 Haskell Workshop"
, YEAR="1999"
, EDITOR="Erik Meijer"
, SERIES="Technical Reports"
, ORGANISATION="Utrecht University Department of Computer Science"
, NUMBER="UU-CS-1999-28"
, NOTE="ftp://ftp.cs.uu.nl/pub/RUU/CS/techreps/CS-1999/1999-28.pdf"
}
See you all in Paris,
Erik Meijer
Re: Haskell Wish list: library documentation
[...] unzip = foldr (\(a,b) ~(as,bs) - (a:as,b:bs)) ([],[]) Not exactly intuitive. Could be better. I'm assuming that George's point is that this documentation leaves plenty of room for expansion. OK, you fire up Hugs and type :t unzip and Hugs tells you that unzip :: [(a,b)] - ([a],[b]) Completely clear, unzip takes a list of pairs and returns a pair of lists. The nice thing about Haskell is that the type of a polymorphic function tells you a lot about what the function does. If you want to know how much, read Phil Wadler's "Theorems for Free!" paper, a paper every functional programmer should reread at least once a year. Erik
Re: Licenses and Libraries
And, as a practical step, writing libraries seems like an excellent way to get involved --- especially if they're useable with multiple implementations. I can reveal a little secret (Sigbjorn is far away in the Norwegian woods :-) namely that soon H/Direct will directly support .h files, which means that it will even be easier than before to get automate all the boring work in making standard C libraries available to Haskell. Just drag and drop it onto H/Direct and off you go. Hopefully this will convince the COM criticasters and MS sceptists that H/Direct is cool indeed. Erik
Re: Licenses and Libraries
Whatever happened to the auto-import of java classes? That's what I am supposed to be working on while Sigbjorn is enjoying the fjords. We have a nasty bug having to do with the (what we thought as) clever way of representing JNI objects in Haskell. There is an elegant solution using implicit arguments, but alas that is only supported by Hugs :-) So keep tuned, Erik
Haskell99 Call for Participation
This is a multi-part message in MIME format.
--=_NextPart_000_0185_01BEE8CD.1649AF20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
[Apologies for any duplicates you may receive]
CALL FOR PARTICIPATION HASKELL99 WORKSHOP
FRIDAY OCTOBER 1ST, 1999, PARIS, FRANCE
http://www.haskell.org/HaskellWorkshop.html
The Third Haskell Workshop will take place in Paris, France
as part of PLI'99 http://pauillac.inria.fr/pli.
SCOPE
=3D=3D=3D=3D=3D
The purpose of the workshop is to discuss experience with Haskell, and
possible future developments of the language.
The lively discussions at the 1997 Haskell Workshop in Amsterdam about
the future of Haskell led to the definition of Haskell'98, giving
Haskell the stability that has so far been lacking. The road ahead to
Haskell-2 has many opportunities for developing and enhancing Haskell
in new and exciting ways. The Haskell99 workshop presents six
papers on the design, implementation, and use of Haskell.
In addition to longer presentations of pre-submitted papers, there
will be the opportunity for participants to make 10-minute informal
presentations, the wackier the better.
REGISTRATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
See the main PLI page http://pauillac.inria.fr/pli for information
on how to register for HASKELL99 and the other events making up PLI99.
The deadline for early registration is August 20.
PROGRAM FRIDAY OCTOBER 1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Each contributed presentation will last 45 minutes, including
questions. The proceedings will be published as an Utrecht University
technical report and will be available at the time of the workshop.
We still accept slot bookings for the 10-minute talks on a first come
first served basis.
8:30 - 9:30 PLI Invited talk
Mobility in the Join-Calculus
Georges Gonthier (INRIA Rocquencourt, France)
---
9:45 - 10:45 Session 1 (Sigbjorn Finne)
---
Typing Haskell In Haskell
Mark Jones (Oregon Graduate Institute, USA)
Haskell library template effort (10 minute slot)
Andy Gill (Oregon Graduate Institute, USA)
---
10:45 - 11:15 Coffee break
---
11:15 - 12:45 Session 2 (Byron Cook)
Embedding Prolog in Haskell
Mike Spivey and Silvija Seres (Oxford University, UK)
Logical Abstractions in Haskell
Jeff Lewis, John Launchbury and Nancy Day (Oregon Graduate Institute,
USA)
---
12:45 - 14:30 Lunch
---
---
14:30 - 16:00 Session 3 (Koen Claessen)
---
The Syntactical Subtleties of Haskell (Invited Talk)
Simon Marlow (Microsoft Research Cambridge, UK)
Lightweight Extensible Records for Haskell
Mark Jones (Oregon Graduate Institute, USA) and
Simon Peyton Jones(Microsoft Research Cambridge, UK)
--
16:00 - 16:30 Tea time
--
---
16:30 - 18:00 Session 4 (Graham Hutton)
---
A Generic Programming Extension for Haskell
Ralf Hinze (Bonn University, Germany)
Restricted Datatypes in Haskell
John Hughes (Chalmers University, Sweden)
18:00 - 18:30 Session 5 (Colin Runciman)
The future of Haskell (Discussion)
PROGRAM COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Koen Claessen (Chalmers)
Byron Cook (OGI)
Sigbjorn Finne (Glasgow)
Gregory Hager (John Hopkins)
Fergus Henderson (Melbourne)
Graham Hutton (Nottingham)
Alexander Jacobson (shop.com)
Erik Meijer (Utrecht)
Colin Runciman (York)
Phillip Wadler (Bell Labs, Lucent Technologies)
Send questions and comments to [EMAIL PROTECTED]
--=_NextPart_000_0185_01BEE8CD.1649AF20
Content-Type: text/x-vcard;
name="Erik Meijer.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Erik Meijer.vcf"
BEGIN:VCARD
VERSION:2.1
N:Meijer;Erik
FN:Erik Meijer
ORG:Utrecht University;Computer Science
TITLE:Asscoiate Professor
TEL;WORK;VOICE:+31-30-256
TEL;HOME;VOICE:+31-24-3585250
TEL;WORK;FAX:+31-30-2513791
ADR;WORK:;A104;POBox 80.089;Utrecht;;3508 TB;The Netherlands
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:A104=3D0D=3D0APOBox =
80.089=3D0D=3D0AUtrecht 3508 TB=3D0D=3D0AThe Netherlands
ADR;HOME:;;Zwenkgras 13;Malden;;6581 RK;The Netherlands
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Zwenkgras 13=3D0D=3D0AMalden 6581 =
RK=3D0D=3D0AThe Netherlands
X-WAB-GENDER:2
URL:http://www.cs.uu.nl/~erik/
URL:http://www.cs.uu.nl
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:19990817T142016Z
END:VCARD
--=_NextPart_000_0185_01BEE8CD.1649AF20--
Re: How to pass a data structure between Haskell and other language? (for example C ?)
I want to pass some data structure (such as a record ... ) between Haskell and C. If you know anybody who did this or you have any ideas about this, would you please advise me? Thank you very much ! H/Direct (http://www.dcs.gla.ac.uk/fp/software/hdirect/) is the way to go, or since you seem to be using C anyway you could resort to GreenCard. Erik
Re: Zipping two sequences together with only cons, empty, foldr
Koen wrote, I think Lambert Meertens calls this a "paramorphism". It is basically a catamorphism (fold), where you also have access to the structure you are recursing on, not just the result after recursion. But since the FP culture changed from: catamorphism == fold anamorphism== unfold I think paramorphism == recurse is just as well :-) I think it is also somewhere in Erik Meijer's thesis, but I don't have it here, so I don't know. (But maybe he doesn't want to be reminded of his banana period anymore :-) That's correct (twice :-). It is a really nice subject, but I have move on to other hunting grounds. If you look at the bananas paper (http://www.cs.uu.nl/~erik/Research/Body.html) that was refered to by Lazlo earlier in this thread, you find the following definition for the "barbed wire" paramorphism h = [b,plus] over lists h [] = b h (a:as) = a `plus` (as, h as) and later this is generalized for arbitrary recursive types. Lennart's proposes recurse operator is indeed a special case of a paramorphism over list-like datatypes. I think however, that the type should constrain c over Functor (long live fmap :-) recurse :: Functor c = (a - c a - b - b) - b - c a - b Zipping lists however is *much* easier expressed using anamorphisms or unfold. The reason is that when zipping two lists you are co-inductively *constructing* a list, and not so much inductively destructing a list. Hence the trick of inductively destructing a list that returns a function that inductively destructs the second list and build the resulting list of pairs. I would like to point everybody that is interested in this corner of FP to Graham Hutton (http://www.cs.nott.ac.uk/~gmh/) and Jeremy Gibbons (http://www.brookes.ac.uk/~p0071749/home.html) who are still active in this area and have written a number of really nice papers on folds, unfolds and friends. Richard Bird and Ross Paterson have some nice papers of doing folds etc on nested datatypes. Have fun! Erik BTW there is an interesting correspondence between COM's composite monikers and monadic parsers.
Lambdaman GIF
This is a multi-part message in MIME format. --=_NextPart_000_006B_01BEBD3E.82A75920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone have a GIF of (I think Phil Wadler's) Lambda-man? I mean the = one that appeared with its friend the chip on the old FPCA proceedings? Erik --=_NextPart_000_006B_01BEBD3E.82A75920 Content-Type: text/x-vcard; name="Erik Meijer.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Erik Meijer.vcf" BEGIN:VCARD VERSION:2.1 N:Meijer;Erik FN:Erik Meijer ORG:Utrecht University;Computer Science TITLE:Asscoiate Professor TEL;WORK;VOICE:+31-30-256 TEL;HOME;VOICE:+31-24-3585250 TEL;WORK;FAX:+31-30-2513791 ADR;WORK:;A104;POBox 80.089;Utrecht;;3508 TB;The Netherlands LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:A104=3D0D=3D0APOBox = 80.089=3D0D=3D0AUtrecht 3508 TB=3D0D=3D0AThe Netherlands ADR;HOME:;;Zwenkgras 13;Malden;;6581 RK;The Netherlands LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Zwenkgras 13=3D0D=3D0AMalden 6581 = RK=3D0D=3D0AThe Netherlands X-WAB-GENDER:2 URL:http://www.cs.uu.nl/~erik/ URL:http://www.cs.uu.nl EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:19990623T040619Z END:VCARD --=_NextPart_000_006B_01BEBD3E.82A75920--
Re: Lambdaman GIF
I wrote Does anyone have a GIF of (I think Phil Wadler's) Lambda-man? I mean the one that appeared with its friend the chip on the old FPCA proceedings? Many people pointed me at versions of the gif (including http://ls5-www.informatik.uni-dortmund.de/~peter/Lambda). You can see the result of retouching at http://www.cs.uu.nl/~erik -- Lambada. Erik "waiting for Sun to sue me" Meijer
Unable to run main.hs example for win32 distribution
After a smooth installation of GHC, I get an incomprehensible error message
when trying to compile "Hello Workd!".
==
bash-2.02$ ghc-4.03 -v -o main main.hs
The Glorious Glasgow Haskell Compilation System, version 4.03, patchlevel 0
Effective command line: -v -o main
Ineffective C pre-processor:
echo '{-# LINE 1 "main.hs" -}' /tmp/ghc1026.cpp cat main.hs
/tmp/ghc1026.cpp
deleting... /tmp/ghc1026.cpp
rm -f /tmp/ghc1026*
bash-2.02$
======
Erik Meijer
April fools joke
This is a multi-part message in MIME format. --=_NextPart_000_0255_01BEA206.F6CDD2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Guys, John P's April fools joke has caused quite some excitement on the design = patterns mailing list of all places!! For a good laugh, look at = http://www.distributedobjects.com/portfolio/archives/patterns/discussion= /msg03277.html Erik :-) --=_NextPart_000_0255_01BEA206.F6CDD2A0 Content-Type: text/x-vcard; name="Erik Meijer.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Erik Meijer.vcf" BEGIN:VCARD VERSION:2.1 N:Meijer;Erik FN:Erik Meijer ORG:Utrecht University;Computer Science TITLE:Asscoiate Professor TEL;WORK;VOICE:+31-30-256 TEL;HOME;VOICE:+31-24-3585250 TEL;WORK;FAX:+31-30-2513791 ADR;WORK:;A104;POBox 80.089;Utrecht;;3508 TB;The Netherlands LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:A104=3D0D=3D0APOBox = 80.089=3D0D=3D0AUtrecht 3508 TB=3D0D=3D0AThe Netherlands ADR;HOME:;;Zwenkgras 13;Malden;;6581 RK;The Netherlands LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Zwenkgras 13=3D0D=3D0AMalden 6581 = RK=3D0D=3D0AThe Netherlands X-WAB-GENDER:2 URL:http://www.cs.uu.nl/~erik/ URL:http://www.cs.uu.nl EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:19990519T125040Z END:VCARD --=_NextPart_000_0255_01BEA206.F6CDD2A0--
Re: Contexts on data type declarations
Interesting! Phil, Mark, and Jeff all have a different interpretation of
how contexts on how data type declarations work than I did. So unless
some other people chime in, I will therefore adopt their interpretation,
since (a) I'm in the minority and (b) it's not a big deal at all.
I agree with Phil, Mark, and Jeff. Here is another explanation. The "meaning" of an
overloaded function f :: P a = F a - G a is the set of functions { f :: F a - T a |
P a}, now if we take the inverse of these functions we get the set { g :: T a - F a |
P a } which is the meaning of the qualified type g :: P a = T a - F a. Selectors
form "the inverse" of constructors (you know what I mean :-) hence they should be
overloaded as well.
Erik
Re: Haskell 98: randomIO
I think that the report should definitly rule out the possiblity that every evaluation of randomIO uses the *same* initial seed. I agree. In fact, I would be most happy with a function getRandom :: IO Double that returns a random number between 0 and 1. I have not been able to hack such a function using Hugs' randomIO function. What I have done instead is encapsulating the JavaScript random function in a scriptlet and then using that via H/Direct's Automation binding. Not exactly a very portable solution :-) Anyway, I don't see why anyone would want randomIO to return a list of random numbers, given that you are in the IO monad so that randomIO could return the next element of this list at every subsequent call. Erik
Re: MonadZero (concluded)
Hi Alex,
Ok, then I am officially complaining about the elimination of ++ and
MonadPlus. It is a much more radical change than changing default
default and it will break a lot of MY code at very least.
The existing implementation in hugs allows you to write extremely concise
and clean code. If I want to replace Maybe in my code with a list
implementation then I can do that. You are taking that away!!
Why are you specializing ++ to lists? Can you at leat leave ++ as a
function in a class like:
class Concat a where
(++)::a-a-a
Or as per my prior mail, define a List class in which I can override ++.
Either way, please please please don't specialize ++ to lists. It is a
radical and unwarranted change.
I completely agree with you, but most people thought that it is confusing to
overload "list" functions like (++) and (map) to arbitrary monads. Hopefully
you are not relying on monad-comprehensions, because they have been
unoverloaded as well. You don't have to be desparate though. It is easy to
translate from comprehension- to do-notation.
The do-notation is still there for arbitrary monads, and is now even simpler
because (zero) has been moved from MonadZero to Monad. This is really the
only thing that is hardwired in the language and that you cannot change
yourself. From this point you design your own idealized prelude on top of
what is given by hiding, renaming and adding classes and functions. For
example, for the Concat class you want things would look like:
module Alexander'sPrelude where
import Prelude hiding ((++))
import qualified Prelude
class C a where{ (++) :: a - a - a }
instance C ([a]) where { (++) = (Prelude.++) }
-- In non-Hugs Haskell you would use
-- newtype L a = L ([a] - [a])
-- but then I don't like to wrap and unwrap
-- all those silly constructors.
type L a = ([a] - [a]) in ccL, toL, fromL
ccL :: L a - L a - L a
ccL = (.)
toL :: [a] - L a
toL as = \as' - as ++ as'
fromL :: L a - [a]
fromL as = as []
instance C (L a) where { (++) = ccL }
Do you get the idea? As I said before in an earlier message, an extra level
of indirection keeps the doctor away. The pots (do-notation) and the furnace
(the Haskell core language) must be there and work. There is no disputing
about tastes, so as long as I can spice my own food, I am a happy man.
Erik "Haskell98 burns hotter" Meijer
Re: derive conflicts with multiply-defined and module level import
Another reason is that allowing definitions to be split up without any special syntax indicating this would harm readability. If I see a definition, I can't be sure it's complete without examining the whole module. Since the order of clauses affects the semantics, I don't think it would be a good idea to allow them to be widely separated. If the proposal was to allow them to be separated, but only with some special declaration, e.g. a keyword "noncontiguous", prefixed to each clauses, that wouldn't be so bad for readability. But if we have to add new syntax to make it work then it is getting to be more trouble than its worth. This is *exectly* the reasoning I am opposed to. It is not to the language designer to decide for me what is readable of not! Erik "warrior against the Edith Bunkerizing of programming languages" Meijer
Re: derive conflicts with multiply-defined and module level import
Hi Alex, [...] [ describes that he wants interleave the definitions of several functions ] [ but Haskell does not allow this ] [...] This restriction is very frustrating because I want to add names to a function lookup table as they are derived. Is there a strong reason for disallowing this syntax? Well, it depends on what you call *strong*. The only reason that I heard is that it prevents users from making possibly unwanted errors. The reasoning behind this is that no sane programmer would write data Shape = Circle Float | Rectangle Float Float; area, perimeter :: Shape - Float area (Circle r) = ... perimeter (Circle r) = ... area (Rectangle w h) = ... perimeter (Rectangle w h) = ... so if someone does it is probably a mistake. I think it sometimes makes sense to sort definitions accoring to their argument pattern (the OO-style), and sometimes according to their name (the FP-style). The compiler can sort them as it wants later. In my opinion a language should not be patronizing, it should not prevent me from writing programs in what the language police thinks is bad style (that's why unsafePerformIO is my big friend ;-). For me this is particulary thorny because my idea of what is good style tends to be very different from the mainstream. I used to be the lone voice in the wilderness on this issue too, great to have a partisan! 2. local import A module only needs to import a class definition if a type in the module derives that class. It would be nice to have locally scoped import so that the user does not both have to add derive statements and have to add import statements (and deal with name space conflicts) What do you mean? That if you write data Foo . deriving (Bar) you automatically import the module in which the Bar class is defined? I think what you want is import statements at arbitrary places in a module. Something that was dropped from Haskell98. Erik "warrior against gratuitous restrictions" Meijer
Re: MonadZero (concluded)
Phil's proposal: delete class MonadZero, MonadPlus delete filterM, guard, mfilter, concatM This is ok by me. Does anyone object? No, not at all. The prelude should be as small as possible. Erik
Re: Haskell 98 progress
Lennart wrote: Sorry, I'm not happy with this proposal. Monads are a well defined mathematical concept and I think the Monad class should reflect this. Having a mzero (and mfail) method seems weird to me. I would suggest a MonadZero class having these methods, and that do notation on works for the MonadZero class (regardless of if you use patern matching or not). This is even worse, especially when you appeal to mathematical elegance. Moreover, with the current proposal, it is still possible to pretend that your monads have structure. If you have a monad with a non-trivial zero, you define an empty MonadZero class and replace contstraints Monad m to MonadZero m. Usually when you write a definition for a monadic value you get an unresolved toplevel overloading error anyway, so you must already put in a type signature yourself. Phil wrote: There is no need to have both `mzero' and `mfail' in every monad. Just have `mfail'. Leave `zero' and `plus' to MonadPlus. This should make Eric partially happy. That is more or less what Mark proposed, except that in that case we should keep MonadZero and MonadPlus. On the other hand, you can define anything on top of Monad yourself now. The do-notation is only depending on Monad and not on MonadZero anymore. Append is unoverloaded so there is no need anymore for a MonadPlus class. In this light I'd rather goo for brevity than for partial happiness. The names `mzero' and `mfail' are horrible. I like Ralph's suggestion to change `fail' to `raise' in the IO monad, and use `fail' for `mfail'. If that doesn't work, try something else, but please pick names that have a simple meaning in English (as with `return') not monsters like `mzero' and `mfail'. Yes!, names should be pronouncable. Too much exposure to Squiggol ((| |), ( )], |,...), Unix (cat, lpr, mv, ...) and Microsoft Hungarian (LPUNKNOWN FAR *lppUnk, LPCTSTR lpszClassName, ...) makes people become blunted about this issue I guess. I unsuccesfully tried this argument in the case of fmap an its other now unoverloaded friends and proposed to use the module system to disambiguate the names (Alastairs suggestion). The suggestion to replace fail by raise in the IO monad and mzero and mfail by zero and fail is a good one. On the other hand you can easily achieve the effect yourself using some hiding and adding a handfull of definitions, which is what I will probably end up doing. An extra level of indirection can do wonders. The important thing is the translation of the do-notation, which you cannot influence as a user. Erik
Re: MonadZero
John,
Of course we would all like Haskell to catch as many errors as possible,
and statically. But a chain is only as strong as its weakest link. When
there are already weak links in a chain, it makes no sense to build others
of some hi-tech super strong material. The most efficient design occurs when
all the links are approximately the same strength.
[...]
So the question is, with the rest of Haskell as it is, what choice for
MonadZero most closely matches the rest of the language?
I am more convinced than ever: nuke MonadZero.
I agree with your your premisses, but not with your conclusion. If you take
your reasoning to the extreme (and that's what I like to do :-) the
conclusion is that we only need one class for types of kind *, one for types
of kind * - *, etc. That is not what we want, I hope.
Let me try to sketch a design methodology for introducing type classes, and
convince you that aside from issues of type safety or the do-notation it is
good to separate Monad and MonadZero. This should also answer Phil's
question wether
there is "anyone out there who values the separation of Monad and MonadZero
for purposes other than `do' notation?".
rule 0: Class introduction
Introduce a class Foo a where { foo :: ...a...} when there are at least two
types X and Y with non-trival and different definitions for fooX :: ...X...
and fooY :: ...Y, and you want to abstract from X and Y when using foo.
The instances for Foo are instance Foo X where { foo = fooX } and Foo Y
where { foo = fooY }.
When there is just a single type Z for which you can define fooY :: ...Y...
there is no need to abstract over it, and fooY can just as well be
identified with foo.
When for all types a the definitions of fooa are the same, we can just
define foo :: ...a... as a polymorphic function.
It is good style to define non-overloaded versions of class methods outside
of the class instead of inlining them in the instance declaration. For
example the usual instance declaration Eq a = Eq [a] is utterly confusion.
Instead first define eqList :: Eq a = [a] - [a] - Bool and then simple
say instance Eq a = Eq [a] where { (==) = eqList }.
It is bad style to have trivial definitions for class methods, in which case
you are lying to the user.
Often there are different implementations for fooX and fooY where Y and X
overlap (e.g. X=[Char] and Y = [a]) but where you don't want to make the
less general one abstract (e.g. I dont want to define newtype String =
String [Char]).
rule 1: Subclass introduction
Introduce a sublass Foo a = Bar a where { bar :: ...a... } when rule 1
tells you to introduce Bar for a proper subset of the instances of Foo.
When all instances of Foo are also instances of Bar, you should add bar to
the methods of Foo.
When there are instances of Bar that are not instances of Foo, Bar should be
a seperate class.
According to these rules Monad and MonadZero should be different classes,
and MonadZero and MonadPlus should be merged. Why Monad? Because we have
{bindId, returnId}, {bindReader, returnReader}, {bindMaybe, returnMaybe},
{bindList, returnList}, {bindIO, returnIO}, {bindST, returnST}. Why
MonadZero? Because we don't have non-trivial definitions for {zeroId},
{zeroReader}, and {zeroST}, but we do have {zeroMaybe}, {zeroList}, and
{zeroIO}. Why merge MonadZero and MonadPlus? Because we have {plusMaybe},
{plusList}, and {plusIO}.
According to these rules we should *not* have Show and Eq as subclasses for
Num.
I think that it is good that recursion, undefined and (less so for) seq are
polymorphic and thus that all Haskell functions are implicitely partial.
According to these rules, there should be no Eval class.
According to these rules, much of the rest of the Numeric class hierarchy
can be justified, and I guess that the original designers used a similar
methodology as I gave.
It is disheartening however, that we want to flatten a hierarchy that is
flat and simple, while it is a taboo to talk about simplifying and
collapsing the complex and deep numeric hierarchy. About 80% of the problems
my students have when doing their programming exercises is with these
classes. We are hunting something tiny and neglect something big.
Erik, Haskell Certified Software Engineer, Meijer
Re: code for XML things? sysadmin things?
Hi, folks. I'm noodling around on some (Unix) sysadmin ideas, and would like to use Haskell and XML (http://www.xml.com). Does anyone have code to share that might be *vaguely* useful for XML-ish things? -- I'm mainly interested in it as a data-exchange format. Or for any sysadmin-ish purpose whatsoever? As always in these things, *don't* wait until "I can tidy it up a bit", or "this version isn't too good, wait for the next one". As Joe Armstrong used to say, "Freeze and sell!" Your "customers" will tell you if it's any good, soon enough. (Haskell really needs more code of all kinds in circulation; the Perl module people, for example, produce more in a week than we do in a year.) Should anything come of my noodling, it will be freely available in the usual way. Thanks, The HTML parser and pretty-printer of my CGI-library will happily parse XML as well, ignoring the DTD all together. You may find that a good starting point. Erik
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
Hi Tim, The Haskell Server page claims that one advantage of COM is that it "ships for free with windows". This suggests that the existence of a genuinely free CORBA ORB has been overlooked. IMHO ignoring CORBA is cutting Haskell off from the open software world (including about 7 million Linux users), and from those who dislike/fear Microsoft or just want a non-proprietary standard. We have been blinded by the MS propaganda I guess, but now I agree with you completely that we are missing a big market by doing only COM so a CORBA binding is now high on my priority list. As Sigbjorn said in his reply, it is hard to decide which ORB to use, and I did not know about omniORB. Great new project for the new academic year! Erik
Re: Could Haskell be taken over by Microsoft?
-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.
Re: GHC/Hugs Status (was Re: simple interface to web?)
Indeed, I do expect that most of the people on this list will go straight to (the moving target of) Haskell 2. The purpose of Std Haskell is to address the needs of people who don't need the latest greatest, but do need something stable. For example, the fact that Haskell keeps moving (which in many ways is good) discourages people from writing books, which in turn makes it less attractive for people who aren't already converted. This argument is somewhat of a red herring. For example Richard Bird's new book does not touch any of the more advanced subjects, i.e. his book is backwards compatible with adding multiple parameter type classes, existentials, scoped type variables and all those other nice things. On the other hand Paul Hudak's book explains Monad comprehensions. In fact, 120 students at Utrecht University and who knows how many at Yale now expect that Haskell has Monad comprehensions, so taking them out of Standard Haskell will cause problems. Simon "desparately trying to keep the lid on the can of worms" PJ Beware of the herring worm: Anisakis simplex (herring worm), Pseudoterranova (Phocanema, Terranova) decipiens (cod or seal worm), Contracaecum spp., and Hysterothylacium (Thynnascaris) spp. are anisakid nematodes (roundworms) that have been implicated in human infections caused by the consumption of raw or undercooked language design. To date, only A. simplex and P. decipiens are reported from human cases in North America.
Re: GHC/Hugs Status (was Re: simple interface to web?)
I am very dubious about making getURL pure. Right, and I don't understand why people are so afraid of the IO monad. Anyway, using the Haskell-COM interface it is easy to use IWebBrowser, which gives you anything you want in terms of web access. The downside is that you are stuck in the brain dead world of MS Windows. Erik
Re: Syntax dubion
In an ideal world, the Haskell grammar would be simplified by merging the rules for pattern syntax with those for expression syntax. Yes, Alastair is right once again! Hurray for less syntax but more static semantics. Erik
Re: Standard Haskell: More lexical/syntactic issues (from Alastair Reid)
If you want a functional scripting language with H-M type inference and type classes and monads, that's great, but maybe it should be something separate from Haskell. I have been promoting Haskell exactly for this purpose for some time now, and I don't buy your points, e.g that in a scripting language, it is desirable to have lots of defaults, etc. so that there is as little time as possible between the time you start to write a program and the time you get it running. Scripting languages should optimize programmer's time, by making the language small, simple, readable, type-safe, .. I think that all of Alastair's points help reducing that.
Re: Teaching Haskell
Speaking of this, when is someone going to write an fp book that teaches all the interesting stuff? Monads, advanced use of classes, advanced types in general, exceptions, etc... [here's an idea: after comprehending the book, the student should be able to follow the discussion on this mailing list without difficulty] In my opinion, such a book should assume the reader has already been through Bird and Wadler or whatever, is familiar with the lambda calculus, and has written substantial programs. Please, no more "introduction to fp" books! This is exactly why the summerschools on advanced functional programming are there. After one in Sweden and one in the USA, the third school will be in Braga, Portugal: http://alfa.di.uminho.pt/~afp98/ All the notes were published as Springer LNCS, LNCS 925 and LNCS 1129. I know Paul Hudak is working on something interesting. Anyone else? Don't be shy. Paul's book is great, but does not really deal with advanced topics. But as you see, there is plenty advanced material around. If you want to learn about monads in particular, I would recommend visiting Phil Wadler's homepage (http://www.cs.bell-labs.com/~wadler/) or Graham Hutton's homepage (http://www.cs.nott.ac.uk/~gmh/). To see some cool applications of Haskell, have a look at http://www.haskell.org and especially http://www.haskell.org/active/activehaskell.html So, that will keep you busy for a few weeks :-) Erik Meijer ( formerly know as the "Banana man" , now volunteer COM and Microsoft evangelist ) BTW My spellchecker suggests to change Haskell to Hassle!
Re: Press Release
Well done!! Erik
Re: FP Naming/Directory Service
Hi Alex, I just started playing with Haskell for CGI applications. I would like to try writing a more serious CGI app, but missing infrastructure makes it more difficult than conventional approaches. In decreasing order of preference, is there an available implementation of: * an equivalent to Java's Naming and Directory Services interface * an LDAP client for some particular LDAP server If you don't mind to restrict yourself to Windows, and these applications are available as COM Automation objects you are done. We already interfaced to the ADSI components, would that be enough? In theory we can interoperate with any plain COM component, but the technology for that is not yet stable. And as Alastair pointed out GreenCard can be used to interface to plain C libraries. * an XML editor Perhaps you mean an XML parser/unparser. The MS XML parser is an Automation object, so it can be scripted from Haskell. Implementing a full XML parser and pretty-printer in Haskell is not hard. A generic XML parser that ignores the DTD but parses any well-nested document can be programmed using a few lines of parser combinators. * a generic ODBC/JDBC database client * an interface to berkeleyDB (or some persistent hashtable implementation) This is high on our list too. I suppose that I could have Haskell talk to Jacl to access the Java implementations of these capabilities, but this seems like a hack. Any pointers? Hop this helps, if you need more specifc information don't hesitate to contact me. To answer Tommy: I think there are two major causes to this effect: one is the high emphasize on theoretical aspects of the language and a disproportional low effort on plain practial aspects. I agree, if only I had the resources! Erik
