Re: [Haskell] ASCII higher than 127
On 2006-10-17 at 16:31+0200 "Andreas Marth" wrote: > How was that with Haskell and Unicode??? I think this probably belongs on ghc-users rather than Haskell. Anyhow, there aren't any ASCII characters higher than 127. > While up to ghc-6.4.2 the following function worked it now doesn't compile: > > isSpezGermanChar :: Char -> Bool > isSpezGermanChar 'ä' = True > isSpezGermanChar 'ö' = True > isSpezGermanChar 'ü' = True > isSpezGermanChar 'Ä' = True > isSpezGermanChar 'Ö' = True > isSpezGermanChar 'Ü' = True > isSpezGermanChar 'ß' = True > isSpezGermanChar _ = False > > (For those of you who will only read garbage it are/were some letters from > the german alphabet.) > > I hoped we move forward to easier internationalization. > Any ideas what to do now? (I would like to keep the code readable and not > use '\220' and so on. What ought to work is to use Unicode for input. If the files you want to process with your programme are encoded in ISO-8859-1, you may have to do something yourself to handle that. If my mailer is behaving itself, this message will have been translated into Unicode, so the table above might work. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell web forum
On 2006-09-20 at 21:19+0200 "Niklas Broberg" wrote: > A mailing list will never be enough. Really? > A forum has way way more potential. More potential than what we have already: http://dir.gmane.org/gmane.comp.lang.haskell.general >? Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
On 2006-05-20 at 11:58EDT Robert Dockins wrote: > On Saturday 20 May 2006 06:53 am, Jon Fairbairn wrote: > > Make allows one to set up rules about what depends > > on what, so why can't we just arrange it so that someone who > > wants to install the thing just hast to type > > > > ./runhaskell Setup.hs install > > > FWIW, it's almost identical to the incantation necessary > for projects based on autotools, where it usually reads > something like: > > ./configure > make > make install I know. That's the fashion I'm complaining about! I think we shouldn't follow it if we can possibly avoid it. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
On 2006-05-20 at 12:00+0200 "Sebastian Sylvan" wrote: > A quick sales pitch: usually you, the library user, can just type: > > ./runhaskell Setup.hs configure > ./runhaskell Setup.hs build > ./runhaskell Setup.hs install > > And it will Do The Right Thing(TM), which is nice. This is something I've never understood about the current fashion. Make allows one to set up rules about what depends on what, so why can't we just arrange it so that someone who wants to install the thing just hast to type ./runhaskell Setup.hs install ? I'm aware that part of this process might require root privileges, and that it would be bad to do the rest of it as root, but there are ways around that, surely? Even if not, the first line ought to be unnecessary, since configure produces something that build depends upon. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Haskell Weekly News: March 13, 2006
On 2006-03-17 at 06:58GMT Aaron Denney wrote: > On 2006-03-17, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: > > Well, there is a way -- it's fairly easy with the right regex -- but > > is it really ambiguous? Do people find it confusing? What do other sites do? > > Why not the ISO standard -MM-DD? Surely. This is, after all, an international effort. I can't see why people don't just use this format in general, nowadays. Certainly it makes sense to use it in any context where the nationality of the reader is unknown. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Fonts on haskell.org
On 2005-11-14 at 10:38EST John Peterson wrote: > If someone sends me a new css file I'll be happy to throw it on > haskell.org for you. Please send an email to this list if you want to > do this so nobody else wastes their time. Is anything more needed than the attached patch? If so, I'm willing to give it a go provided it's not much work. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk 5c5 < color: CC; --- > color: #CC; 7d6 < font-size:80%; ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Making Haskell more open
On 2005-11-14 at 11:13+0100 Wolfgang Jeltsch wrote: > Maybe I changed Konqueror's font settings already. The point is that my > settings are in such a way that text with the default font size is well > readable while not taking up too much space. The problem is with > haskell.org's links. They have a font size of 80% of the default. If the > default font size satisfies me, 80% of it is too small. If I change the > default size so that 80% of it produces well readable text, the default size > itself is too large, IMO. This sort of thing is a frequent topic among CSS hacks. The general opinion among the more seasoned ones is that site designers should /always/ specify that the text size of normal paragraphs is 100%, exactly for the reason you give. People with poor eyesight may set the default to be the smallest they can comfortably read to get more use out of the screen, and allowing for some difficulty in reading small print. If a site sets the main body text size smaller than 100%, it will significantly inconvenience such people (without giving any benefit to anyone else). > I wonder why the links have to use a smaller font size > than ordinary text at all. This looks especially strange > if a link occurs as part of a running text. That just sounds like bad design. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Newbie quick questions
On 2005-10-04 at 00:01EDT Mike Crowe wrote: > Hi folks, > > I ran across Haskell at the Great Win32 Computer Language Shootout. A > friend approached me with a potential large application to develop. The > idea of a language which can reduce time to design and make better code > is very intriguing. > 1) Can I develop a Windows application to sell? Or is Haskell not > really geared for that? I don't see any reason why not, though the GUI aspect of Haskell is as well developed as some other aspects of the language. > 2) Say a team wants to develop a larger application, like a CRM system. > In "thinking" in functional programming, can a team split up work and > implementation and work together? In other words, how easily does > Haskell adapt to a team approach? At least as well as any other language. > 3) Again, using a CRM tool as an example, what is the advantage to > developing an application like this in Haskell vs. any other language? > If I really invest the time, can I get this done quicker in Haskell? > Sell me on this, please. Whether you can get it done quicker depends on how long it takes you to "get" functional programming. It's very easy to understand Haskell just well enough to write C programmes in it. It takes a significantly greater effort -- and time -- to get into the appropriate state of mind to write real Haskell programmes. > 3) I'm a very top-down programmer. I like to start at the "big-picture" > and work my way down in implementation. Does this adapt to Haskell, or > am I missing the point? Haskell is very good for this. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] offside rule question
On 2005-07-15 at 10:49+0200 Tomasz Zielonka wrote: > But you can format it this way: > > let a very long definition of "a" = > and the body has to be here is a very long application to "and" > but using long arguments like definition is not that bad > in or > > let a very long definition of "a" > = and the body has to be here is a very long application to "and" >but using long arguments like definition is not that bad > in Though I happen to think that the offside rule isn't exactly right; you can probably find something I've said about this in the archive. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] How to make Haskell more popular
1) If another language has a feature, add it to Haskell, so that absolutely everything can be done in more than one way. This allows people to write Haskell programmes without going through the tiresome process of learning Haskell.` 2) Overload the syntax so that the Hamming distance between syntactically valid programmes is very small 3) Allow casting of any type to any other. 2 and 3 together mean that the programmer wins the "fight" with the compiler more often, and can get on with the exciting business of debugging. 4) Add lots of libraries with widely different styles of interface lacking any recognisable algebraic properties. This makes it hard to learn the libraries, so the programmer gets increased satisfaction when the task is finally completed, and a programmer who understands a given library becomes more valuable in the market. 4a) write the libraries at a low level of abstraction, using as few sophisticated features as possible. This makes it easier for novice programmers to modify libraries and add *features* 5) Static type checking is for wimps. Move it all to runtime, so debugging is even more exciting. With 3, this allows us the glorious possibility of using the same value in different types with different meanings, mimicking PHP's wonderful strpos etc, where the return value zero indicates failure if it's a boolean or success if it's an integer. 6) Use strings for abbreviated syntax, so avoiding even syntax checking at compile time. 7) On second thoughts, all syntax checking is for wimps. Move the rest of it to runtime too. After all, /part/ of the programme might produce plausible output, and we wouldn't want to miss out on that. This adds the further exciting possiblity that end-users will get to see Haskell syntax errors, so more of the world will hear of Haskell. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Type of y f = f . f
On 2005-02-28 at 23:10EST Jim Apple wrote: > Jon Fairbairn wrote: > > If you allow quantification over higher > > kinds, you can do something like this: > > > >d f = f . f > > > >d:: âa::*, b::*â*.(b a â a) â b (b a)â a > > > > What's the problem with > > d :: (forall c . b c -> c) -> b (b a) -> a > d f = f . f > > to which ghci gives the type > > d :: forall a b. (forall c. b c -> c) -> b (b a) -> a It's too restrictive: it requires that the argument to d be polymorphic, so if f:: [Int]->[Int], d f won't typecheck. It also requires that the type of f have an application on the lhs, so f :: Int->Int won't allow d f to typecheck either. In the imaginary typesystem I was thinking of above, we could instantiate b with (Îx.x). As others have pointed out, there are other typesystems that allow different types that also work. Incidentally, I think Ponder would have assigned types to the examples, just not very useful ones; d head would have come out as (Ît.[t])->(Ît.[t]) (assuming anything came out at all). -- JÃn Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type of y f = f . f
On 2005-02-28 at 18:03GMT Ben Rudiak-Gould wrote: > Pedro Vasconcelos wrote: > >Jim Apple <[EMAIL PROTECTED]> wrote: > >>Is there a type we can give to > >> > >>y f = f . f > >> > >>y id > >>y head > >>y fst > >> > >>are all typeable? > > > >Using ghci: > > > >Prelude> let y f = f.f > >Prelude> :t y > >y :: forall c. (c -> c) -> c -> c > > > >So it admits principal type (a->a) -> a->a. From this you can see that > >(y head) and (y fst) cannot be typed, whereas (y id) can. > > I think the OP's point is that all three of his examples make sense, and > the resulting functions would have Haskell types, yet there doesn't seem > to be a Haskell type which permits all three uses of y. The problem is that the type system needs to be checkable, so has to throw some information away. if y f = f . f, the easiest way of losing information is to require that the output type of f be the same as the input. It certainly needs to be a type acceptable as input to f. if you put th f = f . f . f the examples still make sense, but should the type of th be different from the type of y? > but I can't find a type which permits more than one. Not in Haskell. If you allow quantification over higher kinds, you can do something like this: d f = f . f d:: âa::*, b::*â*.(b a â a) â b (b a)â a Now we can type d id id :: ât . t â t so id :: ât . (Ît.t) t â t ie b is (Ît.t) so d id :: (Ît.t)((Ît.t) t) â t :: ât . t â t and d head head:: ât.[t]ât so b is [] so d head :: ât . [[t]] â t and fst :: âx,y.(x,y)âx so b is Îx.(x,y) d fst :: ât,y . (Îx.(x,y))((Îx.(x,y)) t) â t :: ât,y . (Îx.(x,y))(t,y) â t :: ât,y . ((t,y),y) â t (oops, only one y) but you would be expecting a bit much of a compiler to infer any of this. -- JÃn Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] xemacs & haskell major mode
On 2005-01-24 at 16:32MST Surendra Singhi wrote: > Is there any ilisp or slime like package for haskell, which integrates > haskell with xemacs or emacs and provides a kind of integrated > development environment? > I am using Hugs 98. Does http://www.haskell.org/pipermail/haskell/2004-November/015015.html > help? -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Global Variables and IO initializers
On 2004-11-04 at 16:16+0100 Koen Claessen wrote: > Benjamin Franksen wrote: > > | 1) I strongly disagree with ideas to execute IO actions > | implicitly in whatever defined or undefined sequence > | before or during main for whatever reasons. > > I agree with the objections you make. Having full IO actions > as initialization actions might be a bit too much. I agree with that too. Let me propose what I think may be a simpler (though at present the dough is barely risen, let alone baked) alternative: external "constant" modules. First, I'd like to point out that having initialisation data that changes between runs of a programme is already possible: a programme could do IO to its own loadmodule. I mention this not as a serious suggestion, but to forestall objections about changing the content of a "constant" module. The idea is simply that we should provide a mechanism of saying to a compiler "this file (of data) is a module that exports only the variable v". Given the way IO and filesystems stand at the moment, this probably means that we'd have to restrict v to be a String (or [Word8]?), but the correct solution to that would be typed IO, and it's too early to talk about that. So we tell the compilation system that file /somewhere/contains-v contains the value of the variable v::String, and that it lives in the imaginary module Home.Of.V, and when the resulting programme is loaded, so is the content of /somewhere/contains-v, and v is bound to it. OS permitting the loading of the file should only be virtual. Now IO to /somewhere/contains-v should have no effect on the value of v, but next time the programme starts it can use the new value. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] looking for reference to wadler's (?) law of language design
On 2004-10-12 at 12:53+0200 Johannes Waldmann wrote: > this is slightly off topic - I am preparing for a lecture on domain > specific languages and I try to track down the source and original > version of (what I recall as) Wadler's "law" of language design, I think it first appeared here: http://www.informatik.uni-kiel.de/~mh/curry/listarchive/0017.html -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] different element
On 2004-10-06 at 10:37CDT "ldou" wrote: > In the random selection, it perhaps select the same element > of the string, how can I select two different elements? Consider the \\ operator. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] topology in Haskell
On 2004-06-10 at 10:39BST Martin Escardo wrote: > Dear Haskell-list members, > > This is to advertise the monograph > > Synthetic topology of data types and classical spaces, to appear in > ENTCS 87, 150pp, three parts, 6+5+2 chapters. Interesting. But why do you use Int rather than the Integer? In particular > This gives some surprising results, e.g. that the type > ((Int->Bool)->Int) has decidable equality (for total elements). is not at all surprising, since Int (and Bool) is finite, so there are only finitely many total elements of that type :-) For Integer it is surprising, but I haven't read that far yet... Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lifting functions to tuples?
On 2003-11-18 at 10:46EST "Abraham Egnor" wrote: > The classic way to write a lift function for tuples is, of course: > > liftTup f (a, b) = (f a, f b) > > which has a type of (a -> b) -> (a, a) -> (b, b). I've been wondering if > it would be possible to write a function that doesn't require the types in > the tuple to be the same, just that the types in the second tuple are the > result of applying the type transformation implied in the function to be > lifted to the types in the first tuple. Now, in Haskell98, this isn't > possible because of the monomorphism restriction; however, ghc > conveniently has a way to disable that. However, I'm still having > problems figuring out if it's even doable within the current constraints > of the glasgow-extended type system. One possibility I tried is: > > liftTup (f :: forall a b. a -> b) (p, q) = (f p, f q) Note that the type you are requiring for f is equivalent to forall a . a -> forall b . b which rather limits the possible values for f. Another possibility would be lifTup:: (forall a. a -> b) -> (c, d) -> (b,b) but that requires the f to be polymorphic and that the result has elements of the same type. What you want is that f be applicable to both b and c, giving results b' and c', but if b and c happen to be the same type then f need not be polymorphic. I don't think you can express this in ghc's type system. You'd have to have bounded quantification: lifTup :: forall c, a >= c, b >= c, d, a'<=d, b'<= d. (c -> d) -> (a,b)->(a',b') which is monstrous even if I've managed to get it right! Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
On 2003-08-29 at 17:39PDT Hal Daume III wrote: > Hi fellow Haskellers, > > I'm attempting to get a sense of the topology of the Haskell > community. Based on the Haskell Communities & Activities reports, it > seems that the large majority of people use Haskell for Haskell's sake. > > If you use Haskell for a purpose *other than* one of those listed below, > I'd love to hear. In addition to the things you exclude, I've written (and sold!) a custom web-server log-analysis programme. I use Haskell for managing some personal data, and also use it a great deal for what prof. Wilkes calls nonce programming. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Laziness
On 2003-08-02 at 14:36PDT "Dominic Steinitz" wrote: > Could someone explain to me why this doesn't work > > test l = >hs > where > hs = map (\x -> [x]) [0..abs(l `div` hLen)] > hLen = length $ head hs > > whereas this does > > test l = >hs > where > hs = map (\x -> [x]) (0:[1..abs(l `div` hLen)]) > hLen = length $ head hs > > I would have thought laziness would allow the compiler to > know that hs would contain at least one element and > therefore calculate hLen. Laziness isn't enough to tell it that. It would also have to know that abs never returns an answer less than zero ([0 .. -1] == []). All the compiler knows is that abs returns an integer. Jón PS I don't know the general policy, but I for one dislike getting emails in HTML unless it's /absolutely/ necessary for the content. Multipart/alternative doesn't help much either. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators, Re: Function composition and currying
On 2003-07-17 at 09:08+0200 Johannes Waldmann wrote: > On Wed, 16 Jul 2003, K. Fritz Ruehr wrote: > > > I think the cutest way to get what you want here is to define a new > ^^ > > operator as follows: > > > > (.<) = (.) . (.) > > Indeed this is cute - but let me add a general comment here: > in my code, I don't define any operators at all (only functions). > I do think that self-defined operators make a programm less readable. While I agree with that, I think that the language needs "user"-defined operators for libraries; it's a matter of defining them rarely and getting them widely accepted. I'm even tempted to suggest that the language ought to restrict their use to gurus. Someone mentioned multiplying by a scalar. I think this is a good application, but what we need is to agree (somehow) on the symbol used. I've used (*.) and (.*), with the dot being on the side the scalar is on (on the grounds that . is a scalar product elsewhere), but without wide agreement I agree that this sort of thing reduces readability, because while I can read these programmes, it's harder for everyone else. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: How overload operator in Haskell?
On 2003-07-12 at 20:20+1000 Andrew J Bromage wrote: > G'day all. > > On Fri, Jul 11, 2003 at 04:28:19PM -0400, Dylan Thurston wrote: > > > Don't be silly [...] > > Never! Or only sometimes. I'm surprised that no-one has yet answered the question "How overload operator in Haskell?" with "Overload operator in Haskell fine". (cf Cary Grant) -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Search by type (Re: In search of: [a->b] -> a -> [b])
On 2003-06-17 at 20:15EDT Derek Elkins wrote: > The closest function I see is ap :: Monad m => m (a -> b) -> m a -> m b > (so you could write your function as f fs a = ap fs (return a) not that > I would recommend it). Also you may want to check out the Haskell > reference at zvon.org, it's indexed by type as well. That's useful. It reminds me to ask whether anyone is working on adding a search by type facility to any of the haskell systems. I remember a talk by folk from York about how they did it (years ago), and being impressed, so it seems a shame that we don't have this now. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: for all quantifier
On 2003-06-08 at 18:03PDT Ashley Yakeley wrote: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Peter G. Hancock) wrote: > > Thanks! It made me wonder what colour the sky is on planet Haskell. > > From a Curry-Howard point of view, (I think) the quantifiers are > > currently the wrong way round. It is actually painful! > > Well don't forget the other one: > > data MyType1 = forall a. MkMyType1 a; > > data MyType2 = MkMyType2 (forall a. a); > > You can put anything in a MyType1, but only something of type (forall a. > a) such as "undefined" in a MyType2. I'm not sure I understand your implication. After the proposed change you'd have to write: > data MyType1 = exists a. MkMyType1 a; > > data MyType2 = MkMyType2 (forall a. a); to get the same effect, and we'd have that > data MyType1a = MkMyType1a (exists a . a) would be (bar alpha) equivalent to MyType1, and (after a suitable grace period) > data MyType2a = forall a . MkMyType2a a would be like MyType2, which all seems much more reasonable than the present notation. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: forall quantifier
On 2003-06-06 at 08:15BST "Simon Peyton-Jones" wrote: > > I forget whether I've aired this on the list, but I'm > seriously thinking that we should change 'forall' to > 'exists' in existential data constructors like this one. You did mention it, and there were several replies. I'd characterise them as mainly falling into two classes: "Yes, the change is sensible" and "No, it's all right as it is so long as you stand on your head when reading programmes". It doesn't seem so difficult to me. It's a matter of thinking in terms of expressions for types and functions that return types. If you define type F a = forall t . (a, t) and subsequently write e:: F Int this is equivalent to writing e:: forall t . (Int, t) Now, although we don't have type expressions that correspond to the RHSs of data declarations, it seems perfectly reasonable to expect things to work as if we did -- the chief problem being that we can't see from the context which constructors are data and which type. So data D a = forall t . MkD a t leads us to interpret e:: D Int as e:: forall t . MkD a t I don't think that the problem of type and constructor namespaces detracts from this argument -- if anything, it points up a problem with data constructors, not quantifiers. >From there it's easy to decide that to get an existential type we need to write data D a = exists t . MkD a t (and type F a = exists t . (a, t) looks quite reasonable too). > One has to explain 'forall' every time. But we'd lose a > keyword. Seems like a small price to pay. As Christian Maeder points out it is a loss only in the type variable namespace. As to omitting the quantifier, I say no, since the omission of quantifiers elsewhere corresponds uniformly to universal quantification. Jón PS that's one heck of an email address you have there, Simon! -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: class Function ?
On 2002-10-29 at 04:09PST Ashley Yakeley wrote: > At 2002-10-29 03:42, Jon Fairbairn wrote: > > >But we could just make $ the primitive instead of > >juxtaposition (and infix the primary form). > > > >Then f a is shorthand for f $ a and it stops there. > > But then how would you overload $? The class Function and it's first instance would have to be built in (not too onerous since function application is anyway). Not that I'm necessarily in favour of this, you understand. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: class Function ?
On 2002-10-29 at 03:21PST Ashley Yakeley wrote: > At 2002-10-29 02:43, Josef Svenningsson wrote: > > >> I'm pretty sure it's not possible... > >> > >You mean in H98? Sure no! What I meant was to implement overloading of > >function application as an extension of H98. > > See my earlier message. If function application is overloadable, then > there must be some operator "funapp" that corresponds to it. But > operators themselves need function application, > so you end up with: > > f a > reduces to > funapp f a > reduces to > funapp (funapp (funapp f)) a > reduces to > etc. But we could just make $ the primitive instead of juxtaposition (and infix the primary form). Then f a is shorthand for f $ a and it stops there. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Overloading and Literal Numerics
> Alain Cremieux wrote: > I am trying to build a functional firewall generator. The first part > describes the available protections (kernel, anti-address spoofing, etc.). > The second desribes every protocol, and the necessary rules if the > corresponding service is enabled (e.g. open the http port...). In the third > one, the user will choose the services he wants to use/open and the static > parameters (for instance the squid port number). > I wanted the user part to be "user-friendly", even if it is an Haskell > program. So the commands > definePort "squidPort" 3128 > Seemed more logical than > definePort "squidPort" "3128" > > The problem is that the numeric literal 3128 is considered as being a member > of Num class, and not as beeing an Int. > So I can't write a unique function which accepts 1) the string "3128" 2) the > literal numeric 3128 3) the string "3128:3129"(if the user wants to give a > port range, for instance) I understand the problem, but I still don't see why you want strings here. [Int] would do. They'd just have to type [3218..3130] for a range of port numbers, and you can define ordinary variables: type Port = [Int] http:: Port http = [80] You'd have to have them type definePort "squidPort" [3128] and that allows giving a range of ports where only one port is required, but at least they are going to be constrained to be numbers. With this, portRange [3128.3129] will give a compile time error, where portRange "3128.3129" would have to be a run-time error. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Overloading and Literal Numerics
> Jon Fairbairn <[EMAIL PROTECTED]> writes: > > > data Port = Tcpmux | Nbp | Echo_ddp | Rje | Zip | Echo_tcp | ... > > deriving Enum, ... > > instance Num Port where ... > > Or, alternatively, just use Strings, and have a portFromString first > check /etc/services for a match, then try to parse the string as a > positive integer, and finally generate an error if no valid port can > be determined? Possibly, if there's really no way of making sure the error happens at compile time. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Overloading and Literal Numerics
> Hi, > I am trying to create an overloaded function "à la Java" to be able to > call it either with a string or a number. > Ex : > definePort "http" > definePort 80 > but I have problem with restrictions in Haskell's type system > Is there a better solution ? If we knew /why/ you wanted to do this we might be able to help. I can't see why you want to allow Strings, which have far too wide a range of values, as arguments to something that takes a port designator as an argument. data Port = Tcpmux | Nbp | Echo_ddp | Rje | Zip | Echo_tcp | ... deriving Enum, ... instance Num Port where ... would seem like a better way to me. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Library report, monad zero laws
Apologies for responding to messages in reverse order . . . > * My reluctance to change the draft H98 report is rising sharply. Understood! > * I don't think the H98 report has ever had laws about mzero etc. No, they went on the transition from 1.4, I think. > * And the whole laws business is flaky because people can and do >make instances of Monad that don't obey the laws. That's what made me ask the question. Either it shouldn't say what it does about mzero being the zero, or it should explain more. So an alternative would be to remove the remark about the zero, but then we'd be left with no clues about the intentions. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Library report, monad zero laws
> On Fri, Jun 21, 2002 at 12:50:21PM +0100, Simon Peyton-Jones wrote: > > | From: Jon Fairbairn [mailto:[EMAIL PROTECTED]] > > | Sent: 20 June 2002 16:27 > > | To: Simon Peyton-Jones > > | Subject: Library report, monad zero laws > > | > > | The old report used to include > > | > > | m >> zero = zero > > | zero >>= m = zero > > | m ++ zero = m > > | zero ++ m = m > > | > > | after the other monad laws. Now mzero and mplus are in the > > | library, shouldn't there be some mention of these laws there? > > | I'd be particularly keen to see a remark about > > | > > | _|_ >> zero > > | > > | inevitably being _|_ > > Would you put that next to m >> zero = zero ? Well, that's rather the point. At the moment the library report just says "The class methods mzero and mplus are the zero and plus of the monad.", which implies m >> zero = zero, but it can't be. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: FW: Haskell accumulator
> Paul Graham is collecting canonical accumulator generators at
> http://www.paulgraham.com/accgen.html , and has Dylan, E, JavaScript,
> various dialects Lisp, Lua, Rebol, Ruby, Perl, Python and Smalltalk.
As others have implied, the only correct answer to this is
"it's the wrong question". One of the major advantages of
functional programming is that you do most things without
global variables, because they are a Bad Thing. So an
accumulator based on a variable is simply not the
appropriate abstraction in most cases.
Think about sum:
sum = foldl (+) 0
That works by using an accumulator, but Haskell is so
expressive you don't even need to mention the fact!
In addition the question is underspecified -- what happens,
for example if the argument isn't a number? This is not a
problem for Haskell, of course, but in allowing the lisp
version to throw an exeption he finesses away the advantage
of strong typing.
> Could the serious Haskellers comment on this attempt of mine?
>
> foo n = do
> n' <- newIORef n
> return (\i -> do { modifyIORef n' (i+); readIORef n' })
What strikes me about this, though, is that perhaps the
imperative primitives in Haskell aren't quite perfectly
designed. It seems to me that modifyIORef ought to return
either the IORef of its value. In Algol68 if n IS a REF INT,
(n +:= i) has the value a (which will now contain it's
previous contents plus i), so it's a time honoured form.
If we had such a version (call it modIORef) we could dazzle
the blighters with:
foo n = fmap (\n' i -> modIORef n' (+i) >>= readIORef)
$ newIORef n
and if we had one that returned the value (say modReadIORef)
foo n = fmap (\n' i -> modReadIORef n' (+i))
$ newIORef n
Now, it was the work of moments to define and test (helped
by the type system) the above new functions, which shows
what expressive power is really about.
Jón
PS It's perhaps a bit disappointing that one needs a type
signature to use
foo = fmap (\n' i->modReadIORef n'(+i)) . newIORef
--
Jón Fairbairn [EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: layout rule infelicity
I wrote:
> > Can someone remind me why the "A close brace is also inserted whenever
> > the syntactic category containing the layout list ends" part
> > of the rule is there?
Lennart wrote:
> It's so you can write
> let x = 2+2 in x*x
> (and similar things)
and Arjan van IJzendoorn wrote:
> x = (3, case True of
> True -> 4)
>
> The ')' ends the syntactic category 'tuple'
So we get all this misery just so that people can cram
things onto fewer lines?
> let x = 2+2 in x*x
could be
> let {x = 2+2} in x*x
or
> let x = 2+2
> in x*x
and
> x = (3, case True of
> True -> 4
> )
would be fine.
I'd like to see a "-fuse-simpler-layout-rule"¹ option on the
compilers. . .
Jón
1. Why "-f" anyway? It took me ages to work out what
"-fallow-overlapping-instances" meant -- I wondered how
"fallow" could apply to overlapping instances.
--
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: IO and fold (was Re: fold on Monad? )
> >Yes you can define it, > > And you can, as well. Man sollte sich nicht darauf verlassen, daß ein Englander "man" verwendet, wenn es angebraucht wäre¹. > That's how common idioms come into being; > there's no special magic about the folds already in existence. Well, my point is that there is -- indeed some ways of defining the type for lists use a fold as the starting point. I mentioned the lack here because I think there is some deeper structure that someone cleverer than me may be able to see. > > >It seems to me that there's something odd about the way the > >IO monad interacts with bulk operations on files. > > That may be more related to IO than to the monadic approach > to it Yes. Hence the change of subject line. > >In particular, it seems odd that getContents should ever be the > >easiest way of tackling something, > > Who says that? I did! I think getContents is a klugey hangover from stream based I/O, and the existence of "semi-closed handles" supports that, so I'm hoping that people might become interested in looking at the question. > >One of the great things about fold is that you don't have to > >code the test for the end: it's encapsulated in the > >higher-order function. Shouldn't there be the same for IO? > > Isn't it? > > getContents = foldX (++) "" -- we drop the newlines here.. > getLines = foldX (:) [] > > No eof-testing in sight. Sure, once we've defined foldX, but then we need to know whether it really is a fold &c. I should remember to make my messages to the list less indirect. > So we've mostly got a fold lifted into the io-monad, with getLine > delivering the "head" (and implicitly truncating further input to > the "tail"). What more do you want?-) Theory! That's what I want! Cheers, Jón 1. I had to get help with this; perhaps it would have been better to leave my numerous mistakes in it! -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: layout rule infelicity
> I like layout but I think the existing rules are too
> complicated. Unfortunat ely it's difficult to do anything
> with them without breaking vast swathes of existing code,
> so we'll just have to put up with them.
Well, there's two things to consider: Haskell 98, which
probably shouldn't change, and extended Haskell, which
probably should. Especially if we can make the rules both
simpler and better.
> The reason I think layout is better than using {'s and ,'s is that humans
> use the layout to group the structure anyway, which means you can have
> confusing situations where a structure looks alright to a human but not
> to a computer.
Which is exactly the problem with the programme I
posted. Having thought about it a bit, it strikes me that
the particular problem is the insertion of a closing brace.
From the human reader's point of view, there's no visual
equivalent of the closing brace in the example:
> possible_int = do skip_blanks
> fmap Just int
> +++ (literal "-" `as` Nothing)
What happens is that a semicolon is inserted because the
indentation is the same as the previous line -- that's fair
enough, subject to some quibbles about treating all
expressions the same -- but then the +++ is a syntax error
unless a closing brace is inserted.
Visually, the equivalent of a closing brace is when
indentation is less (to my eye it ought to be right down to
where the 'do' is and inbetween be an error). What's wrong
with the notion that closing braces should only be inserted
when the indentation is less (or the file ends)? This would
reject some programmes, but only ones where the appearance
is misleading.
So
> possible_int = do skip_blanks
> fmap Just int
>+++ (literal "-" `as` Nothing)
> whatever ...
parses as
> possible_int = do {skip_blanks
> ;fmap Just int
> +++ (literal "-" `as` Nothing)
> }
> whatever ...
and
> possible_int = do skip_blanks
> fmap Just int
> +++ (literal "-" `as` Nothing)
> whatever ...
parses as
> possible_int = do {skip_blanks
> ;fmap Just int
> ;+++ (literal "-" `as` Nothing)
> }
> whatever ...
and then gives a syntax error
but
> possible_int = do skip_blanks
> fmap Just int
> +++ (literal "-" `as` Nothing)
> whatever ...
parses as
> possible_int = do {skip_blanks
> ;fmap Just int
> }
> +++ (literal "-" `as` Nothing)
> whatever ...
Which is just about acceptable to me, because the +++ does
stick out, though I'd prefer that one to be rejected too.
I wasn't fit enough to follow the earlier discussions of the
layout rule, so I'm not sure how this interacts with
previous awkward cases. I'd be happiest if we could come up
with a rule that didn't involve sticking in braces and
semicolons because it won't parse otherwise. Can someone
remind me why the "A close brace is also inserted whenever
the syntactic category containing the layout list ends" part
of the rule is there?
Jón
--
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Fwd: F#]
> Hey Simon et al at Micro$oft, when will there be an H#? But H# is C! we don't want that, surely? :-) Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
layout rule infelicity
Two very similar programmmes:
> possible_int = do skip_blanks
> fmap Just int
>+++ (literal "-" `as` Nothing)
> possible_int = do skip_blanks
> fmap Just int
> +++ (literal "-" `as` Nothing)
I think this is extremely bad language design! In general I
like having layout rules, but I've often thought that they
ought to take note of expressions, not just things in {...}
and that there ought to be "dead zones" where no programme
text is allowed, so that everything starting with the second
example and ending with
> possible_int = do skip_blanks
> fmap Just int
> +++ (literal "-" `as` Nothing)
should be rejected.
This example clinches it for me. Can anyone more au fait
with the layout rule figure out how to do it?
(My past irritation was that
... if p
then q
else r
is acceptable in some circumstances, but one has to use
... if p
then q
else r
in others. Having programmes rejected I don't mind, but
having them accepted when they are too close to right but
still wrong, I really do mind)
--
Jón Fairbairn [EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
IO and fold (was Re: fold on Monad? )
> foldr, foldM, etc. derive a recursive computation from the > recursive structure of an input list, so you have to feed > one in. If you want to bypass the list, you could use > IO-observations (getLine, isEOF) instead of list > observations (head/tail, null): Yes you can define it, I should have been a bit more direct. It seems to me that there's something odd about the way the IO monad interacts with bulk operations on files. In particular, it seems odd that getContents should ever be the easiest way of tackling something, rather than some natural operation on Monads. Doing something to each line of a file is such a common kind of computation that it ought to be easy! It also seems wrong that end of file should be an exception -- after all, for most files other than a terminal or "special file", having an end is the norm. As a result, the definition you gave strikes me as awkward (no fault of yours!). It suggests to me that a Monad isn't quite enough. One of the great things about fold is that you don't have to code the test for the end: it's encapsulated in the higher-order function. Shouldn't there be the same for IO? > Whether that is a real fold, or what the real fold/unfold would > look like, I leave to others;-) I suppose that was part of my real question, aimed at the others who've got the mental processing power to answer such things. Cheers, Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
fold on Monad?
Suppose I have a task I want to do to each line of a file, accumulate a result and output it, I can write main = do stuff <- getContents print $ foldl process_line initial_value (lines stuff) ie, it's obviously a fold I can't see a way of doing the same thing directly on the IO: I'd like to write something similar to main = do res <- foldX process_line initial_value getLine print res foldM almost does it: main = do res <- foldM process initial_value (repeat getLine) print res process a g = do line <- g return (process_line a line) but that goes on forever (or some fixed amount if (replicate n/repeat)) I feel this ought to be straightforward -- the structure is obviously some sort of fold, but I shouldn't have to use a list -- so I must be missing something obvious. What is it? Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Dependent Types
"Dominic Steinitz" <[EMAIL PROTECTED]> wrote:
> I've managed to crack something that always annoyed me when I used to do
> network programming.
[. . .]
>
> Suppose I want to send an ICMP packet. The first byte is the type and the
> second byte is the code. Furthermore, the code depends on the type. Now you
> know at compile time that you can't use codes for one type with a different
> type. However, in Pascal (which is what I used to use) you only seemed to
> be
> able to carry out run time checks.
I'm not sure I understand your problem. I don't see what's
wrong with the following approach, which is Haskell 98. The
type byte is coded as the type of the packet. Excuse the
perhaps ideosyncratic style ... (in particular, I'm
expecting people to use import qualified with this).
module ICMP where
data Type = Redirect RedirectData
| TimeExceeded TimeData
{- so you get an alternative for each of the packet types -}
instance Enum Type where
fromEnum (Redirect _) = 5
fromEnum (TimeExceeded _) = 11
{- we can't derive Enum for ICMP.Type, because it has non-nullary
constructors. That just makes it a bit more tedious
One could provide a class "code" with code:: t -> Int
instead of fromEnum
-}
{- now we define individual record types for each of the different
ICMP types -}
data RedirectData = RedirectData {redirectCode:: RedirectCode,
ip_addr:: Int, -- whatever
redirectData:: [Int]} -- or whatever
data RedirectCode = RedirNet
| RedirHost
| RedirNetToS
| RedirHostToS
deriving Enum
data TimeData = TimeData {timeCode:: TimeExceededCode,
timeData:: [Int]} -- or whatever
data TimeExceededCode = ExcTTL
| ExcFragTime
deriving Enum
{- Since Haskell 98 doesn't have MPTCs, if we want to
encode packets as anything other than [Int] we'd have
to define more classes. Encode serves as an example. -}
class Encode t where
encode:: t -> [Int]
instance Encode Type where
encode p@(Redirect d) = fromEnum p: encode d
encode p@(TimeExceeded d) = fromEnum p: encode d
instance Encode RedirectData where
encode d = fromEnum (redirectCode d): ip_addr d: redirectData d
instance Encode TimeData where
encode d = fromEnum (timeCode d): 0: timeData d
so one can go
encode (Redirect (RedirectData RedirNet 0 [0]))
and get [5,0,0,0], but
encode (TimeExceeded (TimeData RedirNet 0 [0]))
gives an error, as one would hope. What am I missing?
Cheers,
Jón
--
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: ">>" and "do" notation
On Tue, 2 Apr 2002 10:00:37 +0200 (MET DST), John Hughes
<[EMAIL PROTECTED]> wrote:
> >If (as a human reader of a programme) I see
> >
> >do a <- thing1
> >
> >
> >and I notice (perhaps after some modifications) that a is
> >not present in , then I /really/ don't want a
> >change to
> >
> >do thing1
> >
> >
> >to change the meaning of the programme.
> I think the point that's being missed in this discussion
> is that a monad is a n *abstract* type, and sometimes the
> natural "equality" on the abstract type is not the same as
> equality on representations. Of course, we want the left
> and right hand sides of the monad laws to have the same
> "meaning", and we want >> to "mean" >>= \_ ->, but this
> meaning is really up to the abstract equality, not the
> concrete one. If we can give >> a more efficient
> implementation, whic h constructs a better representation
> than >>= does, that's fine, as long as the two
> representations "mean" the same thing.
Point taken, but I remain unconvinced. What comes out of the
monad /isn't/ abstract; there's nothing to ensure that
subsequent use respects the abstraction.
> To be specific, the application that kicked off this
> discussion was program generation. In this example, it's
> not important that >> and >>= generate the same *program
> text*, the important thing is that they generate
> equivalent programs. If >> can more easily generate a more
> efficient program, that's fine.
Is it fine though? Since it will be possible to inspect the
generated code, it's possible that a change from do {_ <- A;
B} to do {A; B} can radically alter the subsequent behaviour
of the programme.
> There's another example in QuickCheck, where we use a
> monad Gen for random value generation -- Gen a is a
> generator for random values of type a. Gen doe s not
> satisfy the monad laws: for example, g and g >>= return
> will usually generate different values. But viewed as
> *probability distributions* (which i s how we think of
> them), they are the same. "Morally", Gen is a monad.
Well, aren't there cases where generating the /same/
pseudo-random sequences is important? In such a case, making
what looks like a semantically neutral change to the
programme might invalidate years of stored results.
> This is all perfectly respectable, and has to do with the
> fact that Haskell i s a programming language, not
> mathematics -- so we represent equivalence classe s by
> values chosen from them. For the *language* to rule out
> constructing different representations for "equivalent"
> constructions, such as >> and >>=, would be unreasonable.
Here's the problem. Your argument sounds very similar to the
one against type checking. That /you/ can get it right
doesn't encourage me to believe that J Random Hacker isn't
going to abuse the facility. It's not as if you couldn't
define >!= and >! for something that's nearly a monad, it
would just stop you using the do notation, which is, I think
fair, since Haskell provides no way of selecting the correct
form of equality for do {_ <- A; B} == do {A; B}.
Jón
--
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: ">>" and "do" notation
Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote: > It shouldn't be syntactic suger but at most an operator which does not belong > to the monad class. One could define (>>) just as an ordinary function > instead of a class member. That sounds to me like the best idea so far. If (as a human reader of a programme) I see do a <- thing1 and I notice (perhaps after some modifications) that a is not present in , then I /really/ don't want a change to do thing1 to change the meaning of the programme. Jón ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: finding ....
> On Wed, Mar 20, 2002, Jon Fairbairn wrote: > > > Could someone post an example of the creation of a > > > temporary file where race conditions are important? > > > > /any/ programme that does this on a multi-process system. > > Occasionally, the presence or absence of a file (usually empty) of a > certain name in a certain directory is used for communication between > processes on a multi-process system. Hence the need for an atomic openNewFile. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: using less stack
> Thanks for all the advice. In the end, I couldn't make $! work for me > (it always seems to be harder than I think it will be to use it, and $! > and deepSeq makes my code run slowly). :-( > But a continuation passing style foldl worked wonderfully. As Jay Cox pointed out by email, my answer was rot because I had confused foldl and foldr > I now have: > > > cpsfold f a [] = a > > cpsfold f a (x:xs) = f x a (\y -> cpsfold f y xs) > > and f takes a continuation, Bob's my uncle, and I have a program that > runs quickly in constant space! Good. I'm curious to know from other readers whether continuations like this are the only way of solving it, though. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: finding ....
> Could someone post an example of the creation of a > temporary file where race conditions are important? /any/ programme that does this on a multi-process system. Between the test for existence and the creation, some other process could have created a file of the same name. Then the create fails because of insufficient permissions, so the programme has to deal with failure anyway, or it succeeds and stomps on the data belonging to the other process. do possible_handle <- try $ openFile "whatever" ReadMode case possible_handle of (Right handle) -> do_things_to handle (Left error) -> do whatever you would have done had the existence test returned false is no more complex than a version using an existence test, but to create a file for writing, surely we need an openNewFile primitive? Otherwise we might open on a file that already exists and hit the "stomp" error mentioned above. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: using less stack
> Apologies for the typo: that should have been 5 elements, not 500. > > Amanda Clare wrote: > > I have stack problems: my program uses too much stack. I suspect, from > > removing bits of code, that it's due to a foldr in my program. If I use > > foldr or foldl on a long list (eg >500 bulky elements for a 3M stack), > > is this likely to be filling the stack? The fold itself won't be filling the stack. Without seeing some of the code it's hard to tell, but the most common cause of this sort of problem is a lack of strictness. foldr (+) 0 [0..5000] doesn't use up stack for the fold, but it builds a suspension for all 5000 additions, and evaluating that /does/ use stack unless the compiler has spotted that (+) is strict. (What compiler/interpreter are you using?) > > What is it that gets stored on > > the stack? If so, is there an obvious refactoring of the fold to use? The solution is to stick in $! judiciously and use foldr' (which seems to have got dropped from the standard libraries at some point, so you'll have to write your own) that uses $!. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Standard Library report: List union
> There's a remark at the beginning of 7.2 that says: > > delete, (\\), union and intersect preserve the invariant=20 > that lists don't contain duplicates, provided that=20 > their first argument contains no duplicates. > > The same applies to unionBy etc. This design is one > you might reasonably disagree with. I'd have thought > it would be more sensible to have the invariant that > *both* arguments to union and intersect are assumed > to be sets (no dups). That's partly what I was alluding to, but either way I'd have thought that there were clearer definitions, for example: unionBy eq xs ys = xs ++ [y | y <- nubBy eq ys, not (any (eq y) xs)] Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Standard Library report: List union
The current library report defines unionBy like this: unionBy eq xs ys = xs ++ deleteFirstsBy eq (nubBy eq ys) xs why does it take the nub of ys, but not xs? I'd have expected unionBy eq xs ys = (nubBy eq xs) ++ deleteFirstsBy eq (nubBy eq ys) xs Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Why is this function type-correct
"Rijk J. C. van Haaften" <[EMAIL PROTECTED]> wrote: > Recently, I wrote a function similar to > > x :: a > x = x 42 > > which is type-correct (Hugs, Ghc, THIH). > Still, from the expression it is clear > that the type shoud have a function type. > The definition > > x :: a -> b > x = x 42 > > is equally well accepted, though I can't > see why this type would be correct. (I'd > expect it to be too general.) > > For what reasons are these types considered > correct? When you say x :: a you are asking that the compiler check that everything you say about x is consistent with x being acceptable where /any/ type is required. In the application x 42, it requires that x be a function, which is fine, because x has any type, and this includes functions. When you say x = x 42, this requires that the type returned from x 42 is the same as the type of x, again fine because if x::a, then x:: Integer -> a also, so x 42:: a. It works out in practise because x = x 42 gives x the value bottom, and bottom::a for all a. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: n+k patterns
> > I argued that (Num a, Ord a) makes most sense to me. > > You argued that (Integral a) was a conscious choice (something I > > don't remember but I'm sure you're right), and is the right one anyway. > > > > I'd be interested to know what others think. If there's any doubt, > > we'll stay with Integral. > > My view is that (n+k) patterns are evil, so it doesn't really matter > what we decide. :-) No, seriously, I'm a little worried about > widening the range of numeric types for which (n+k) patterns are > supposed to work. I can (just about) imagine wanting to use Rationals > in an (n+k) pattern, but Float and Double? I dimly remember that the justification for having n+k was to allow inductive definitions, which only applies to Integral. I'd vote for keeping it as it is, too. Jón ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Transmitting parameters
> At 2001-11-01 22:10, raul sierra alcocer wrote: > > >What mechanism of transmiting parameters does Haskell implement? > > By value. Yes, though one might equally say that they are passed by reference, since in g = let f x = x+x z = factorial 1000 in f z * z the 'first' instance of x forces z to be evaluated and updated, the second instance of x uses this updated value, and so does the final occurrence of z. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98 - Standard Prelude - Floating Class
> On Tuesday 16 October 2001 07:29, Fergus Henderson wrote: > > [...] > > The whole idea of letting you omit method definitions for methods with > > no default and having calls to such methods be run-time errors is IMHO > > exceedingly odd in a supposedly strongly typed language, and IMHO ought > > to be reconsidered in the next major revision of Haskell. > > This is exactly what I think. I agree too, but being able to omit method definitions is sometimes useful -- would it be possible to make calls to those methods a /static/ error? I suspect this would be hard to do. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: read-ing scientific notation
> > The lexical syntax says that > > 10e3 > > means > > 10 e3 > > (i.e. two lexemes). I don't like this choice, and it could be "fixed" > > in the Revised H98 report. > > What is the likelihood of anyone *intentionally* writing an integer > abutted directly with a varid, followed directly by another integer, > and no intervening whitespace? Nil, unless you are entering an > obfuscated code contest, I reckon. This looks like a good change > to me. Given that someone might well intend f 10 e3 and accidentally write f 10e3, if there's a change at all I'd be happier to make 10e3 erroneous. While that case is probably going eventually to be caught by the type checker, it's better to have mistakes pointed out as soon as possible. I already intensely dislike the fact that f [1..10] mistyped as f [1.10] can get through both syntax and type-checking, so I'd vote against making the syntax more permissive unless someone can prove that all the errors that get through as a result are going to be caught some other way at compile time. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: series
> > hello, i just want to ask a simple question: does > > somebody have or knowwhere to find a haskell program that > > calculates the number e, that is the list of infinite > > digits? > It's a nice problem, which I encountered many years > ago as one of the first examples I saw of lazy evaluation! Isn't it in one of David Turner's books? -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
foldl'
Unless I'm mistaken, foldl' (the strict version of foldl) doesn't appear in (the export list of) the standard prelude or the list library. Is there a good reason for this? New users quite quickly find that they need it. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Notation question
> and not just type systems but also other aspects of operational > semantics. What we have here is a single rule from a rule-based > inductive definition of a certain relation G |- s :: S between typing > environments G, expressions s and types S. It's probably worth mentioning here that this notation originated (I think) in mathematical logic, as a way of presenting formal systems. Try "Gentzen", "Natural Deduction" and "Sequent Calculus" as search terms. Jón ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Anomalous Class Fundep Inference
Ashley Yakeley <[EMAIL PROTECTED]> wrote > OK, I understand it a bit better now. This code does not compile: > -- > class X a > instance X Bool > instance (Num a) => X a > -- > Can someone explain why the two instances overlap, given that Bool is not > an instance of Num? > > Would it be possible for Haskell to figure out this sort of thing and not > complain about it, or would that lead to nasty problems? Think what would happen if someone had a module that did define Bool as an instance of Num and imported the class X. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Combinator library gets software prize
On Sun, 21 Jan 2001, David Bakin wrote: > This article is very good, and having read the conference paper earlier > in the year I finished it with only one question: What's a 'quant' ... > and is it good or bad to be one? > > "Ten years ago, Jean-Marc Eber, then a quant at Société > Générale, ..." The OED has: 1. A pole for propelling a barge, esp. one with a cap at the top and a prong at the bottom to prevent it from sinking in mud. Also attrib., as quant-pole. and 2. In a windmill: 1924 Trans. Newcomen Soc. III. 42 All the framing and gearing of these mills are of wood, the only important parts of iron being the wrought iron gudgeons upon which the shafts revolve, and perhaps the `quants' or spindles which drove the runner stones. So perhaps he was tall, thin and fond of wearing a cap? :-) -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road[EMAIL PROTECTED] Cambridge CB1 3SZ +44 1223 570179 (pm only, please) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: fixity for (\\)
On Wed, 17 Jan 2001, Koen Claessen wrote: > I propose that it gets the following fixity: > > infixl 5 \\ Unless the it's common usage outside of Haskell, I oppose! Getting List> [1,2,3]\\[2]\\[3] ERROR: Ambiguous use of operator "(\\)" with "(\\)" at compile time does no harm, but getting [1] instead of [1,3] _at run time_ does do harm. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road[EMAIL PROTECTED] Cambridge CB1 3SZ +44 1223 570179 (pm only, please) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: old easter egg
On Fri, 1 Dec 2000, Zhanyong Wan wrote: > > Ronald Kuwawi wrote: > > > > open text editor, type > > hash :: [Char] -> Int > > hash = (foldl (+) 0) . (map ord) > hash "HASKELL%98" hash "Haskell Ninety Eight !!" surely? -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Inferring types
> If you define `p' as a syntactic function, e.g. > > p x y = x + y > or > > p x = (+) x > > rather than via > > p = (+) > > then the monomorphism restriction does not apply, and so the type inferred > for `p' will be the correct polymorphic type `Num a => a -> a -> a'. May I just take the opportunity to say that this is horrid? -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH+44 1223 570179 (after 14:00 only, please!)
Re: Precision problem
> No, but they ARE, assuming IEEE arithmetic, which is what the Report says, isn't it. > discrete mathematical objects with an arithmetic as well > defined as that on the integers. To do constant folding > according to different rules is, IMHO, outrageous. yes > Surely this is obvious to Haskell programmers? to me, anyway. If two runs (with different flags) of the compiler produce programmes that give different results, then one of them isn't adhering to the standard, (and so should be noted as such). -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH+44 1223 570179 (after 14:00 only, please!)
Re: Library conventions
Lennart Augustsson wrote: > Frank Atanassow wrote: > > 2) The Prelude doesn't use it. > > Well, it doesn't for historical reasons. Am I alone in thinking that the prelude is desperately in need of restructuring? Has anyone got any proposals for nested modules (so we could have Prelude.List.head)? > > 3) Nobody else uses it either, except me (and Chris, apparently :). > > I do. I think many people do. I would if I needed it. > > 4) Qualified infix operators are ugly. > > Yes, I can't deny that. :) That seems like a presentation problem. One day an editor might be persuaded to display Prelude.+ as (till ex.) + in proper size and 'Prelude' in smaller type beneath it or as a subscript. Jón -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH+44 1223 570179 (after 14:00 only, please!)
Re: When is an occurrence an occurrence
> Me too, for (A)! (B) looks too ugly for me. A type declaration should > refer to the "most local" definition of the name. I go for A, though I'd say that type declarations are part of the definitions and the definitions in a module obviously are of names in that module. > Btw, why would one declare the type of a function defined outside the > current module? For documentation only? I would just use a comment if > that's the case. You might want to restrict the type of an imported function to something less polymorphic. But it seems to me that the logical place for such things is in the import list, since this is effectively defining the environment for the module. Jón -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH+44 1223 570179 (after 14:00 only, please!)
Re: more detailed explanation about forall in Haskell
I'm reluctant to get involved in this discussion, cheifly because it seems to me that Jan is attacking a position that has quite a long history with (inter alia) the argument that a different position has a longer history, which doesn't strike me as terribly likely to lead to insight. Also my present powers of concentration don't allow me to keep up with the argument, so I'll just drop in a couple of points and duck out again. > [Lars asked] > > What is a 'type' in your oppinion? [Jan replied] > I look at it as a set (either a variable set or a specific set). E.g. I look > at Bool as a specific set which itself contains > values True , False that are not sets. Next I interpret something like f > :: a -> Int as a family (indexed by a) of functions of " set" a into set > Int. [snippety] > It is up to someone else to say if such > an interpretation shall lead into misinterpretation. Interpreting types as sets is not straightforward: try "Types are not sets" by James H. Morris, JR. in POPL 1973 as one pointer into this area. > I think Haskell will not be attractive to mathematicians > if types MUST be read as formula's . If that is the case I > can only say that I find the term "functional programming" > a bit strange. I don't think anyone said that they must. They can be, and one useful way of interpreting a type is as a statement of limitations on the use and behaviour of a term. f :: A -> B can be read as "if x is of type A, then f x will be of type B" x :: forall a . E can be read as "for all types A, x :: E [A/a]" I think the major source of confusion is that Haskell started out using the convention that a type expression containing a free variable was understood as being universally quantified at the top level (a convention which, I might add, I argued against in the first Haskell committee, so nyaa...), but then added 'forall' as an extension later (I thought this was going to happen :-)) Apart from that, I think that (once they have had the conventions and notation described to them) most mathematicians are not going to be put off by the type system. Certainly mathematicians must be warned against interpreting types simply as sets, but they also need to be warned that a "function" is not a function in the mathematical sense either, being constrained by the limits of computation. > > > > Isn't a type a statement about pre- and post-conditions, i.e. a formula? I'd say that's another reasonable way of reading them. > I can't answer this since I have never read the definition of a type in say > typed lambda calculus. Go on then! It won't hurt! Cheers, Jón -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH+44 1223 570179 (after 14:00 only, please!)
Re: string to Integer
> Then, the question is why we write > result = function operand1 operand2 > instead of > operand1 operand2 function = result > > I actually think the latter is cooler. :) I think there may be cultural influences about word order and/ or writing direction creeping in here :-) -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH+44 1223 570179 (after 14:00 only, please!)
Re: fixing typos in Haskell-98
> > Take and drop > > [..] > > I can see three alternatives: > > > > (A) Make them defined for any n. If n < 0, do something reasonable: > > take: give empty list > > drop: give whole list > > > > (B) Make them defined for n > length xs, but fail for n < 0. > > > > (C) Status quo > > > > PROPOSAL: Use alternative (A) > > I vote for (B). Ditto, though I would say that the restriction is that the argument should be a natural number, and its simply a failing of the type system that it cannot express this. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: deleteBy type
> > Is not deleteBy :: (a->Bool) -> [a] -> [a] > more natural for the library than >deleteBy :: (a->a->Bool) -> a -> [a] -> [a] > ? I'd say so. In general the prelude seems rather weak on functions to manipulate predicates. Jón -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Idiomatic Haskell extension library (Re: Reverse composition)
On 9 Oct, Heribert Schuetz wrote: [(f <| g) x = f (g x); (f |> g) x = g (f x)] >"Use symmetric glyphs for commutative operations and asymmetric glyphs >for non-commutative operations. Reflect glyphs for flipped operations." That would make me happy. > which I would suggest as a general guideline. and I'd go along with that. > Similarly, I would prefer a pair of reflected symbols for normal and > reversed function application, e.g., <$ and $>. (Yes, these are not 100% > reflected, but almost.) and that. For the record, my taste isn't particularly bothered by multi-character symbols; what swayed me in the past was the argument that it was a problem for other folk. * * * Anyway -- I'd like to suggest that we put a library containing definitions of simple operators of general utility somewhere readily accessible. The precise choice of name for operator doesn't matter (though I think a certain amount of discussion is worthwhile). What matters is that for common functions such as the ones we have been discussing the Haskell community should in general use the same names. I'd include composition, function products (as in Joe English's message) and operations on boolean predicates: > (f &&& g) x = f x && g x > (f ||| g) x = f x || g x > notF f x = not (f x) (I'm not wedded to those names.) Where do we put it? -- Jón Fairbairn [EMAIL PROTECTED]
Re: Reverse composition
On 8 Oct, Jonathan King wrote: > I think you might see the point. (No pun back there, I promise...) I > understand where using "." to mean composition came from, and I know that > it's a long-standing tradition in at least the Haskell community, but I > don't think the visual correspondence of . to the typographic glyph > "raised open circle" is so close that you'd really like to explain why > you diverged from current usage so much as to choose "." to mean > "composition". Back in the early Haskell discussions we argued about various options, but I think Richard Bird and Phil Wadler were insistent that, because function composition is so important for functional programming, the symbol used should be something with very low visual weight. Nowadays we might actually think of using ° (which would suggest º or § for the reverse ;-). Not to mention using · for composition... Even though I disagreed with the use of . in the original case, I was persuaded, and still think it ought to be a single character. Unfortunately most of the other good candidates have been used elsewhere. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: [haskell] Reverse composition
On 8 Oct, Christopher Jeris wrote: > Personal taste in infix operators seems to be another good argument for a > camlp4-style preprocessor for Haskell. Please no! I want to be able to read other folks programmes and vice versa. The whole point of suggesting a particular glyph on this foram is so that we can swallow our personal pride and use a common language. > For instance I would like to use > 'o' for composition (since anybody who uses 'o' for a variable gets what > they deserve!) but I guess that would make the lexer not so nice. You could use `o` already. f `o` g looks no worse to me than f >.> g et al. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Reverse composition
On 8 Oct, Joe English wrote: > [I wrote]: > > Just now I thought of .~ from . for composition and ~ (tilde, but > > commonly called twiddle) for twiddling the order about. > I've also seen .| and |. used for this purpose (by > analogy with Unix pipes.) > John Hughes' Arrow library spells it ">>>", Oh well, I thought it might be cute enough to solve the argument, but obviously not... > Along the same lines, are there accepted conventional infix operators > for the functions with types: > > (a0 -> b0) -> (a1 -> b1) -> (a0,a1) -> (b0,b1) > (a -> b0) -> (a -> b1) -> a -> (b0,b1)) > > (a0 -> b0) -> (a1 -> b1) -> Either a0 a1 -> Either b0 b1 > (a0 -> b) -> (a1 -> b) -> Either a0 a1 -> b > > (the last one is called "either" in the standard Prelude). These were on my list to think of names as well. In ponder I had ` (like a raised comma) and >< (product of functions). > I personally like: > > (f <*> g) (x,y) = (f x, g y) > (f <&> g) x = (f x, g x) > (f <+> g) (Left x) = Left (f x) > (f <+> g) (Right y) = Right (g y) > (f <|> g) (Left x) = f x > (f <|> g) (Right y) = g y I'd go along with those -- if for no other reason than you being first to suggest them, and wishing for less argument. They look OK too. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Reverse composition
Some time ago there was a discussion about what to call reverse composition (I can't find it in the archive - needs a search option?) Just now I thought of .~ from . for composition and ~ (tilde, but commonly called twiddle) for twiddling the order about. Maybe we could adopt that as normal usage? -- Jón Fairbairn [EMAIL PROTECTED]
New mailing list (Was Re: Mailing lists down for a while, should be back up now)
On 27 Sep, Manuel M. T. Chakravarty wrote: > Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote, > > Please don't define lists by who'll use them. Define them by the topic > > of discussion. > > Good point. `haskell-help' or some such is definitely > better. 'haskell-questions'? Maybe this list ought to be renamed 'advanced-haskell' or 'haskell-design'? Whatever we call it I'd subscribe and try to be helpful. Jón -- Jón Fairbairn [EMAIL PROTECTED]
Re: tuple component functions
On 16 Sep, Keith Wansbrough wrote: > I suggest calling them "pi13" or "prj13" rather than "tuple31", though. pi1_3 or proj1_3 or select_1_3 or sel_1_3, even s_1_3 -- omitting the "_" means sel is ambiguous (!). We should choose a scheme that can cope with such things even if they are unlikely. I don't think pi_m_n looks right unless you replace pi with the greek letter (UNICODE, anyone?). -- Jón Fairbairn [EMAIL PROTECTED]
Re: Haskell Wish list: library documentation
On 9 Sep, Christian Sievers wrote:
> It's a good idea to use two different types in an example, but Char
> is not well chosen, because the canonical way to write the above
> result is ("abc",[1,2,3]).
Good point. String is best:
unzip [("a", 1), ("b", 2), ("c", 3)] = (["a", "b", "c"], [1, 2, 3])
--
Jón Fairbairn [EMAIL PROTECTED]
Re: Haskell Wish list: library documentation
On 9 Sep, George Russell wrote:
> Here is my revised version of the documentation.
my :-) (which incorporates some of the other suggestions.)
I've given reasons at the bottom.
Type:
> unzip :: [(a,b)] -> ([a],[b])
unzip takes a list of pairs and returns a pair of lists.
Definition:
> unzip l = (map fst l, map snd l)-- [1]
Description:
see zip; unzip is such that if
unzip l = (a, b)
then zip a b = l -- [2]
Examples:
unzip [(1, 4), (2, 5), (3, 6)] = ([1, 2, 3], [4, 5, 6])-- [3]
See Also: unzip3
Notes about the above:
[1] The prelude is supposed to give definitions that are semantically
correct but are not necessarily efficient (eg sort), and I think
this is clearer. There are other definitions in the prelude that
could be made easier to understand.
[2] the motivation for the name comes from zip, and it makes it harder
to describe unzip when it's only necessarily true that zip undoes
what unzip does, and not vice versa.
[3] I think this example is slightly easier, though on second thoughts
unzip [('a', 1), ('b', 2), ('c', 3)] = (['a', 'b', 'c'], [1, 2, 3])
is better still.
Unrelated whinge:
I missed the discussion that decided that show should omit the
syntactically unnecessary spaces when converting lists and tuples.
While this may save space in files, I don't see that we are
equipped to break with centuries of typographic tradition wrt
spaces and commas.
--
Jón Fairbairn [EMAIL PROTECTED]
Re: Haskell Wish list: library documentation
On 8 Sep, George Russell wrote: > Don't add more functions like concatSep to the standard library or prelude. Certainly not to the prelude, but I think there is a strong case for evolving the standard library based on what people use. I use ((concat .) intersperse) quite a lot, and having a standard name for it would be a good thing. concatWith would be another possible name. > Instead document what is there better. Both. > (1) document the IO functions in one place Hear hear. One might argue that the definitions ought to be in the same module, too. I'd prefer a structure where there was a prelude that contained next to nothing (just the stuff that the language itself depends on) and libraries, together with a 'standard library' that includes the stuff from each of these libraries that are at present in the prelude. Most beginners programmes might have to start with > import UsualStuff but that's a small price to pay. > (2) document all functions with some text hear hear. > (3) there should be an index of all functions, hear hear. > (4) Haskell implementors should be encouraged to modify the library report by adding > their own functions and comments directly into the main text. I'd rather see: (4) Haskell implementors should be encouraged to implement exactly the library report and confine deviations to separate (well documented) libraries. Jón -- Jón Fairbairn [EMAIL PROTECTED]
Student project: error messages (was RE: Question)?
On 19 Aug, Mark P Jones wrote: > [...] note that the error messages that prompted > Jon's comment didn't have anything to do with sophisticated type systems. > Dealing with those kinds of things requires some hard work, but it isn't > research, and so it's hard to justify, at least in an academic context. This was my thought exactly, but it occurs to me to wonder whether it might not form an interesting undergraduate (or early graduate) project. The idea would be to instrument hugs to record errors so that one could discover what were the most common errors, and then modify the parser to add error productions to cope with them. It's the sort of thing that could be added to year on year. -- Jón Fairbairn [EMAIL PROTECTED]
Re: Question
On 20 Aug, Bob Howard wrote: > data BTree Integer = Leaf Integer | Node Integer (BTree Integer) (BTree Integer) ^ this ought to be a type variable name, but you've put the name of a type. > mkTree :: Integer -> BTree ^ argument missing > mkTree 0 = Leaf 0 > mkTree int = Node int (mkTree (int - 1)) (mkTree (int -1)) Actually, I have fond memories of Algol compilers that gave error messages pretty much as comprehensible as those above. I guess the problem is that Haskell compilers are prepared by people who have more pressing tasks than repeating old work on user friendly error messages :-( Jón -- Jón Fairbairn [EMAIL PROTECTED]
Re: Deriving Enum
On 13 Jul, Wolfram Kahl wrote: > I confess guilty to have diverged from this simpler problem > > > (//) :: [a] -> [b] -> [(a,b)] > > to the more general problem ??? like > diagonalise:: [[a]] -> [a] > diagonalise l = d [] l > d [] [] = [] > d acc [] = -- d [] acc would do, but muddles the order; >heads acc ++ d (rests acc) [] > d ls (l1:rest) = heads (ls') ++ d (rests ls') rest > where ls' = l1: ls > heads l = [a | (a: _) <- l] > rests l = [as | (_: as) <- l] ? Incidentally, are there standard names for 'heads' and 'rests' as I have them above? I couldn't find them. Jón -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Deriving Enum
On 11 Jul, Wolfram Kahl wrote: > Koen Claessen <[EMAIL PROTECTED]> > proposes the following diagonalisation function: > > > > [ (a,b) | (a,b) <- [1..] // [1..] ] > > > > For a suitable definition of (//), for example: > > > > (//) :: [a] -> [b] -> [(a,b)] > > xs // ys = diagonalize 1 [[(x,y) | x <- xs] | y <- ys] > >where > > diagonalize n xss = > > xs ++ diagonalize (n+1) (xss1 ++ xss2) > > where > > (xs,xss1) = unzip [ (x,xs) | (x:xs) <- take n xss ] > > xss2 = drop n xss > > > > And it works for any type. > > The core function here is > > > (diagonalize (1 :: Integer)) :: [[a]] -> [a] > > This function diagonalises finite or infinite lists > with arbitrary finite or infinite element lists. > > > To me, it seems unsatisfactory to have a solution to this pure list problem > with auxiliary functions relying on integers. I got rather lost in the ensuing discussion, so I've composed this reply from back here. It seems to me that the core function is (//), which can be written like this: > module Diagonalise ((//)) where > import List A diagonalisation function that doesn't use numbers. > (//):: [a] -> [b] -> [(a,b)] > a // b = diag a b [] the third argument acc is an accumulator for the reversed initial segment of a ie reverse acc ++ a == a0 > diag [] b [] = [] > diag [] [] acc = [] > diag [] (b: bs) acc = zip acc bs ++ diag [] bs acc > diag (a: as) b acc = zip acc' b ++ diag as b acc' > where acc' = a: acc Or have I totally lost it? -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Language Feature Request: String Evaluation
On 8 Jun, Paul Hudak wrote: > show x should be a string that when printed looks like the value that > you would have to type to generate it directly. This example is most > instructive: [...] and this is just cute: main = putStr (quine q) quine s = s ++ show s q = "main = putStr (quine q)\nquine s = s ++ show s\nq = " -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
RE: Proposal: Substring library for Haskell
On 20 May, Frank A. Christoph wrote: > > > > I would welcome either. However, there is a huge body of code that > > > assumes strings are lists of chars. > > > > Yes, obviously... this is for new programs (which people aren't writing > > because of Haskell's inefficiency in dealing with strings). > > While I think Haskell should also support primitive random-access strings, > String as [Char] is not all that inefficient for many purposes, thanks to > laziness. After all, the world's most famous text-processing language, Perl, > represents strings as character lists too. I think the reall absence here is a standard string processing library for strings of any type whatever. The first step would be to put one together for [Char], surely? While it makes sense to think about alternative representations at the outset (and possibly use them internally), the absence of a full-featured string processing library is more of an obstacle than it's lack of efficiency. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: View on true ad-hoc overloading.
On 20 May, Kevin Atkinson wrote:
> Sorry typo. That should be optional.
Is this a job for overloading? I think it would be better to provide
some syntactig sugar and compile-time checks for something like this:
data Argtype = Arg {a::Int, b::Bool, c::Char}
arg = Arg {a = 1, b = True, c = error "c mandatory"}
f (Arg _ True c) = c
f (Arg n False c) = head (show n)
main = putStr (show (f $ arg {c = 'c'}))
> It should be.
>
> array (range 1 to 10) [(1,1), (1,2) ]
> array (range 1 to 10 skip 2) [(1,1), (3,2) ...]
> array (range 1 to 100 factor 2] [(1,1), (2,2), (4,3), (8,4) ...]
>
> Perhapes range is not a good word to use. Maybe indices instead.
I don't see what you are getting at here. 'array' takes a list as an
argument.
--
Jón Fairbairn [EMAIL PROTECTED]
18 Kimberley Road[EMAIL PROTECTED]
Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Type casting??
On 10 Mar, Steve Frampton wrote: > My function looks sort of like this: > >foo :: Int -> [a] >foo 0 = [] >foo x = ['1'] ++ foo(x - 1) Since Haskell can infer types most of the time, try >foo 0 = [] >foo x = ['1'] ++ foo(x - 1) with this loaded into hugs you can then try Main> :type foo foo :: Num a => a -> [Char] Main> which tells you the correct type. The type you declared is too general, because it means that foo would have to have the property that whatever type of list was wanted in a given context, (foo n) would have to return a list of that type. But your foo returns a list of characters, so clearly doesn't satisfy this. The "Num a =>" indicates that the argument has to be a number; this is inferred because you subtract one from it. you could write foo 0 = [] foo x = ['1'] ++ foo ((x::Int) - 1) which gives Main> :type foo foo :: Int -> [Char] Main> or write foo :: Int -> [Char] foo 0 = [] foo x = ['1'] ++ foo (x - 1) to declare it yourself. Note that type casting in the C sense is not available in Haskell, the only thing you can do is to restrict something to have fewer types than it otherwise would have. Jon -- Jon Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: type question
> > This is a distilled version of a problem that arose in a student's program: > > > f :: a -> a > > f x = g > >where > >g :: a > >g = x > > Reading file "[...]": > Type checking > ERROR "[...]" (line 5): Inferred type is not general enough > *** Expression: g > *** Expected type : a > *** Inferred type : _2 > > Is there a simple explanation for this phenomenon? The scope of the type variable in the first type declaration doesn't include the function definition, so the g :: a is saying that g has to have type all t. t. Wasn't there once some discussion of the question of making variables in type declarations for functions range over the body? -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: FW: Why I hate n+k
On 27 Nov, Simon Marlow wrote: > (((+) + 1) + 1) 1 = (+) I just read this out to a friend, whose response was "Show that sort of thing to hackers and you'll convert them to functional programming instantly!" -- Jon Fairbairn [EMAIL PROTECTED]
Re: Haskell 98 progress...
On 23 Nov, Graeme Moss wrote:
>
> So no one minds that `--(Nothing)' is a comment whereas `--?Nothing?'
> is not a comment?
I think that this highlights the fact that the top-bit-set characters
were put into the language with relatively few distinctions; ASCII
brackets (){}[] are not included in symbol, but those in the rest of
unicode are (ambiguously; "Any unicode symbol or punctuation" seems to
include ? to me). I don't think Haskell 98 should do anything about
this.
> And that `--Copyright 1998' is a comment whereas `--? 1998' is not a
> comment?
While I might regard the first of these as bad style, I don't have any
difficulty seeing that the second is not a comment. People used to
lisp might be irritated by the error messages they get from things like
tree-reduce f t = whatever
but given that Haskell allows symbols to be adjacent, I think the new
comment rule is correct.
> Or that sequences like `--?What' and `--!Wow' are not comments?
Grammatically and typographically nasty anyway!
> I had to consult the syntax report in order to determine whether these
> were comments or not... at least with the old system I could tell
> immediately.
I think that's just a matter of getting used to it. The new rule makes
the lexemes --, ---, , ... into comment introducers and treats -
the same as other characters otherwise (unless I'm mistaken!), so it's
easier for someone to see that
a --> b
is an expression now. The previous rule was visually confusing.
> Apologies if this is dragging up old arguments.
Likewise!
--
Jon Fairbairn [EMAIL PROTECTED]
Re: derive conflicts with multiply-defined and module level import
On 7 Nov, Erik Meijer wrote: > >Another reason is that allowing definitions to be split up > >without any special syntax indicating this would harm readability. [...] > > 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! Oh yes it is! * I think there is a strong case for making this (and some, but not all other similar issues) part of the language. In the first instance it reduces (ideally removes?) the need for local style-checking preprocessors. If I read a Haskell programme at the moment, I can be sure when I've seen the last clause. If this were changed I'd need a preprocessor to tell me that this sensible grouping had been preserved. (Conventions are typically flouted unless eforced by the compiler. In the second instance, there is cause to believe that (good) programming language designers _do_ know better than the typical programmer. At least we should! (Erik: remember that you aren't a typical programmer when you argue these things.) Typical programmers misinterpret the results of readability research: Me: "Why have you got _so_many_ blank lines in your programme? Prog: "Blank lines improve the readability of code." Me: "But there's so much space that you can't see a whole definition at a time." Prog: "Research has shown that the more blank lines there are, the more readable the code" Me: "!" > Erik "warrior against the Edith Bunkerizing of programming Who she? > languages" Meijer Jon * apologies to those not familiar with the British pantomime traditions. -- Jon Fairbairn [EMAIL PROTECTED]
RE: MonadZero (concluded?)
On 5 Nov, Simon Peyton-Jones wrote: > I don't like grabbing too many very generic names like zero, plus, fail > from the user (this is all in the Prelude, remember). I don't want > to grab 'raise' because we're going to want it for exceptions in Haskell > 2. I havn't been able to think of anything better than these monsters. um, monadZero, monadFail? People who can't type can always add their own renamings. -- Jon Fairbairn [EMAIL PROTECTED]
Re: Int vs Integer
On 4 Oct, Chris Dornan wrote: > As a plain, ordinary punter could I ask for one of two things: > >1) More or less kill Int as a general-purpose type and adopt unbounded > integers (Integer) as the standard integral type. If you do this then > please put > > type Int = Integer > > into the standard prelude. I don't understand this. For old programmes, the right thing to do would surely be to use the compiler to determine which modules require the addition of "import Int", and if the standard prelude has the above declaration, wouldn't it make it harder? Probably one would put an explicit "default (Int)" in all the modules, which doesn't seem too much of a hardship. > For those that need old-fasioned efficient, bounded integers these can be > provided in a separate library module. > > As has been said by others, would those that would like to see Int > knocked on the head make sure that the performance hit won't be too > severe. The above statements appear to be in conflict. The object of the change is to make sure that the default behaviour is safe rather even if less efficient. When the efficiency hit is significant and the programmer is sure that Int is safe, Int would be used. Am I missing the point here? Jon -- Jon Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Int vs Integer
On 15 Sep, Hans Aberg wrote: > The generalization of the Int type, as I see it, is a binary type, a > sequence of bit of fixed length, which has special operations such as > right/left shift with under/overflow, rotations, signed/unsigned arithmetic > and Boolean bit operations. agreed, though I think there is a strong case of providing most of those operations on Integer too (perhaps at a different type). -- Jon Fairbairn [EMAIL PROTECTED]
Fwd: Re: Int vs Integer
Bother! Sent this only to Simon... -- Forwarded message -- From: [EMAIL PROTECTED] Subject: Re: Int vs Integer Date: Tue, 15 Sep 1998 18:15:01 +0100 (BST) To: [EMAIL PROTECTED] On 15 Sep, Simon Peyton-Jones wrote: > I think there is one powerful argument for retaining the status quo, > but it is one no one has commented on: overloaded types can give > rise to strange error messages that bite beginners. I think that is mainly a question of designing good error messages. If there is only one alternative in scope, it should be possible to give helpful hint, for example. There is also nothing to stop a teacher providing a library where things are specialised if this is still a problem. Phil's remarks are also to the point. > After all, we have just *un-overloaded* map and friends for just > this reason. I think that was a mistake, given my above observations. > - generalise length, splitAt, drop, take, replicate > - generalise toEnum, fromEnum > - leave (!!) alone (arrays must fit in an address space) True, but worry about the knock-on effect of using a variable in an index to an array, causing other expressions to be typed at Int. Overload that too! Given that the report already mentions the 'specialize' pragma, I don't see any reason why the newly overloaded functions shouldn't be accompanied by specialisations for both Integer and Int, which should remove the efficiency drawback of making this change. Jon -- Jon Fairbairn [EMAIL PROTECTED]
Re: Int vs Integer
On 13 Sep, Simon Marlow wrote: > The common case of applying a dyadic operation to small Integers would > then be pretty close in performance to that of Int (a couple of > indirect jumps, and a test/branch for the overflow detection, to be > precise). Now that's more like what I had in mind. Isn't it also possible to reduce the number of checks for sequences of operations? -- Jon Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Int vs Integer
On 10 Sep, Will Partain wrote: > [EMAIL PROTECTED] writes: > >> As far as I know, none of the existing implementations >> takes the speed of Integer seriously (ghc certainly doesn't), ... > > The GHC implementation has always been a thin wrapper on top > of the GMP (GNU multi-precision arithmetic) library. So, > while we may not have taken Integer performance too > seriously, we made a point of hanging around with people who > did. (Hey, Lennart made much the same choice, and he's not > one to give away speed for nothing :-) The question is of performance for Int sized things in Integer, so the fact that you call a good library isn't relevant; what's important is what you do when you don't _need_ to use GMP to get the answer. My guess is that most of the real cost of doing Int sized arithmetic in Integers is the cost of detecting overflow. -- Jon Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Int vs Integer
On 9 Sep, John Launchbury wrote: > When we discussed this before I appealed for someone to try it out and > report on the results: > * What slowdowns (?speedups) can be expected in practice using Integer > rather than Int? > * Do existing programs break wildly with this more general type, or > do they work just as before? Or do they still work but now produce > different answers than before. > > Please can someone who feels strongly that we should make these changes > perform some experiments and report the results. Re speed: please don't! I don't see how knowing about the speed of existing implementations can affect the reasoning in deciding to make the change. As far as I know, none of the existing implementations takes the speed of Integer seriously (ghc certainly doesn't), so the data obtained would be thoroughly misleading. Furthermore, in a new programme it would not be hard to decide where to use Int if one is worried about speed. In an old programme discovering that it runs slowly in Haskell 1.5 would not occasion terribly much work either - you just have to change the import declarations to get hold of specially defined versions of the relevant functions. I'd agree that it might be useful to provide a compatibility prelude with implementations of 1.5. As to the second point, if old programmes produce different results, surely that's going to be because they were wrong in the first place! If they don't compile, it's harmless. So I don't think either of these experiments would be helpful. Changing to Integer improves the design of the language and increases the chance that programmes will give correct results. It's not as if we are asking for Int to be banned! Jon -- Jon Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: some Standard Haskell issues
On 7 Aug, [EMAIL PROTECTED] wrote:
> * maximal munch and comments
>
> Explicitly allowing operators such as --- and --> is not just
> a clarification; it is a change in the comment convention. (cf. p8 of
> the 1.4 report `The sequence -- immediately terminates a symbol ...')
right, and a positive change because it would remove this special case
from the report
> Though it is attractive to allow a wide range of operator symbols
it's not just convenient: try putting yourself in the mindset where
you want an arrow and have chosen --> so as not to clash with ->, and
then interpret the error messages you get. It's an ugly irregularity.
> --- comment
unambiguously not a comment
> --
likewise
> Any change putting in doubt (or even preventing) the commenthood of
> an unbroken line of 2 or more dashes would be a pain.
only a pain, and only briefly. I contend that it's easier to learn to
write
-- ---
than to learn not to try to define -->, |--, --| and so on. Oh, and what is
{-- comment --}
under the present rules?
Jon
--
Jon Fairbairn [EMAIL PROTECTED]
Re: Felleisen on Standard Haskell
On 4 Aug, Philip Wadler wrote: > I would be happy to find a name > that was less grand and final-sounding than 'Standard Haskell' though; > but more final sounding than 'Haskell 1.5'. > > Actually, Haskell 1.5 sounds exactly like what you want: halfway > between the first draft and the next edition. It also resonates > with those of use who remember Lisp 1.5, which was the `Standard > Lisp' for many years. -- P I think I agree; the other alternative would to be literal and call it Haskell 1 Final, or 1F for short. -- Jon Fairbairn [EMAIL PROTECTED]
