Re: [Haskell-cafe] Comma in the front
On 2006-07-13 at 02:29BST Neil Mitchell wrote: Hi, Are cool kids supposed to put the comma in front like this? Some cool kids do, some cool kids don't. Some do both, depending on their mood. The advantage of a leading , is that now the comma's line up, and if you want to add an item on the end of a list [a ,b ,c ] It's just a one line change, whereas with the comma after, you'd have to change the previous line as well - which is more effort and gives more noise in the darcs copy. This is one of my pet hates. First, people find things easier to read if they are in a form that they have encountered lots of times before (in addition to psycho-visual factors). I'd like to think that Haskell programmers read a lot of literature (and since they should have started reading this long before they learnt to programme, and continue so to read, they're going to have read more literature than code). So for me (and anyone else moderately literate) a list written [a, b, c ] is easier to read and, (for folk who read from left to right) gives emphasis to the important parts rather than the punctuation. (Of course, a list with elements that short would just be written [a, b, c] anyway.) Now, you argue that it's more effort to add (or delete) items from lists in this form, and maybe you are right (I do it by dragging my mouse over stuff I want to remove, so start with the comma and go down; it doesn't seem too hard. If you want keystroke commands, you want something that respects the syntax). The thing is, making modifications that change the meaning /ought/ to be effortful. If you can delete things without thinking about it, you're probably going to delete something you shouldn't. Then the argument from darcs -- well, historically diff is line based, which was fine in the days of punch-cards, but makes much less sense nowadays. Ideally the diff darcs uses should be syntax driven -- a nice project for someone; we can save effort by only doing this for Haskell, and leave programmers in other languages stuck with line-by-line diffs. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why is there no splitBy in the list module?
On 2006-07-12 at 23:24BST Brian Hulley wrote: Christian Maeder wrote: Donald Bruce Stewart schrieb: Question over whether it should be: splitBy (=='a') aabbaca == [,,bb,c,] or splitBy (=='a') aabbaca == [bb,c] I argue the second form is what people usually want. Yes, the second form is needed for words, but the first form is needed for lines, where one final empty element needs to be removed from your version! Prelude lines a\nb\n [a,b] Prelude lines a\n\nb\n\n [a,,b,] Prelude.lines and Prelude.unlines treat '\n' as a terminator instead of a separator. I'd argue that this is poor design, since information is lost ie lines . unlines === id whereas unlines . lines =/= id whereas if '\n' had been properly conceived of as a separator, the identity would hold. Hooray! I've been waiting to ask Why aren't we asking what laws hold for these operations? but now you've saved me the effort. I've been bitten by unlines . lines /= id already; it's something we could gainfully change without wrecking too much code, methinks. So I vote for the first option ie: splitBy (=='a') aabbaca == [,,bb,c,] Seconded. As far as naming is concerned, since this is a declarative language, surely we shouldn't be using active verbs like this? (OK I lost that argument way back in the mists of Haskell 0.0 with take. Before then I called take first: first n some_list reads perfectly well). Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comma in the front
On 2006-07-13 at 11:15+0200 Henning Thielemann wrote: Optimal notation of lists, because of most easiest editing, is a: b: c: [] That made me smile. In Ponder I had used up : for types, and lists could be a:: b:: c:. but when I suggested this at a Haskell meeting, Simon PJ complained that it looks like hopscotch. I've never quite understood that complaint! Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comma in the front
On 2006-07-13 at 09:35EDT [EMAIL PROTECTED] (Mark T.B. Carroll) wrote: Jon Fairbairn [EMAIL PROTECTED] writes: a:: b:: c:. but when I suggested this at a Haskell meeting, Simon PJ complained that it looks like hopscotch. I've never quite understood that complaint! http://blogs.salon.com/0002296/myimages/hopscotch.jpg and http://www.northshield.org/officers/seneschal/moy/games/hopscotch.gif suggest to me that the pattern of : and . going up in a row is a bit like the squares along the linear 'course' (or list (-:) where sometimes you get one and sometimes two. Well, perhaps (the pattern I associate with hopscotch is the first, ie ·:·:·:·, which could never happen since :. is the end of the list), but that still leaves open the question What's bad about that? :-) Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional progr., images, laziness and all therest
On 2006-06-22 at 15:16BST Brian Hulley wrote: minh thu wrote: y and yq are infinite... But how does this change the fact that y still has 1 more element than yq? yq is after all, not a circular list. infinity+1 = infinity I don't see why induction can't just be applied infinitely to prove this. because (ordinary) induction won't go that far. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional progr., images, laziness and all therest
On 2006-06-22 at 15:45BST Brian Hulley wrote: Jon Fairbairn wrote: infinity+1 = infinity Surely this is just a mathematical convention, not reality! :-) I'm not sure how to answer that. The only equality worth talking about on numbers (and lists) is the mathematical one, and it's a mathematical truth, not a convention. I don't see why induction can't just be applied infinitely to prove this. because (ordinary) induction won't go that far. I wonder why? For any finite list yq, |y| == |yq| + 1 So considering any member yq (and corresponding y) of the set of all finite lists, |y| == |yq| + 1 But the infinite lists /aren't/ members of that set. For infinite lists the arithmetic is different. |y| == |yq| +1 == |yq| If you don't use the appropriate arithmetic, your logic will eventually blow up. Couldn't an infinite list just be regarded as the maximum element of the (infinite) set of all finite lists? It can be, but that doesn't get it into the set. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computing lazy and strict list operations at the same time
On 2006-06-19 at 15:24- C Rodrigues wrote: Here's a puzzle I haven't been able to solve. Is it possible to write the initlast function? There are functions init and last that take constant stack space and traverse the list at most once. You can think of traversing the list as deconstructing all the (:) [] constructors in list. init (x:xs) = init' x xs where init' x (y:ys) = x:init' y ys init' _ [] = [] last (x:xs) = last' x xs where last' _ (y:ys) = last' y ys last' x [] = x Now, is there a way to write initlast :: [a] - ([a], a) that returns the result of init and the result of last, takes constant stack space, and traverses the list only once? Calling reverse traverses the list again. I couldn't think of a way to do it, but I couldn't figure out why it would be impossible. il [] = error foo il [x] = ([], x) il (x:xs) = cof x (il xs) where cof x ~(a,b) = (x:a, b) -- ! Should do it, I think. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fibonacci numbers generator in Haskell
On 2006-06-15 at 17:33BST Vladimir Portnykh wrote:
Fibonacci numbers implementations in Haskell one of the classical examples.
An example I found is the following:
fibs :: [Int]
fibs = 0 : 1 : [ a + b | (a, b) - zip fibs (tail fibs)]
Can we do better?
Well, you've had various variously sensible responses, so
here's one with /worse/ space performance (but a degree of
cuteness):
module Main where
import InfiniteMap
fib = memo fib'
where fib' fib 0 = 0
fib' fib 1 = 1
fib' fib n = fib (n-1) + fib (n-2)
memo f = f memf
where memf n = locate n m
m = build $ f memf
---
module InfiniteMap where
data IM t = Node {entry:: t, if_even::IM t, if_odd:: IM t}
build f = Node (f 0)
(build $ f . (*2))
(build $ f . (+1) . (*2))
locate 0 (Node e _ _) = e
locate n (Node _ e o)
| even n = locate (n`div`2) e
| otherwise = locate ((n-1)`div`2) o
--
Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [GHC] #738: ghc can't load files with selinux Enforcing
On Wed, 31 May 2006 14:15:26 - you wrote: #738: ghc can't load files with selinux Enforcing ---+ Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: closed Priority: normal |Milestone: 6.4.3 Component: Runtime System | Version: 6.4.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Architecture: x86_64 (amd64) | Os: Linux ---+ Changes (by simonmar): * resolution: = fixed * status: new = closed Comment: Fixed in the HEAD and the 6.4 branch, but I haven't been able to test (don't have SE Linux on a local machine). Please download a snapshot and try it out, if possible. That does seem to mend it for me. Note that my report says it only seems to happen x86_64 while in fact the fault /is/ present on x86 in 6.4.1 -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] OT - lamba calculus definition - alpha reduction
On 2006-05-29 at 15:46+0200 =?UTF-8?B?RHXFoWFuIEtvbMOhxZk=?= wrote: OK. If we have these two expressions: 1) (\x.x b x) 2) (\x.x c x) The question is, are they equal? (They are not identical, of course.) For answer no, there is a strong argument - there is no reduction sequence that can make these identical. On the other hand, their meaning expresses the same operation. Well, what is the answer? I will be lucky with any link to WWW resource or your opinion. Nevertheless, the more formal and precise your answer will be the more I will be lucky. ;-) If b and c are free, then no, they can't be considered equal, and i don't see how you can find a common meaning in this case either. Those two are equivalent: (\b.\x.x b x) = (\c.\x.x c x). Yes, those of yours are equal of no doubt. Those of mine are not, that's even my opinion, on the other hand, I was not precise enough in my explanation. Those of mine have the same behavior unless you mean something else by variables b and c. Otherwise the behavior is the same, isn't it? If the behavior is the same, they can be interchanged and, thus, they are equal... OK, I agree this may be a more philosophical question. ;-) There's no sensible way of regarding (\x. x b x) and (\x. x c x) as equal, other than by specifying that b and c are bound to the same value. More formally, I think the usual way of dealing with free variables is to talk about contexts C[[ _ ]] that bind some variables, and then asking whether the expressions under consideration are equal in all contexts. So for your expressions, if we choose C1 [[ _ ]] = (\b c . _ (\x.x)) (\x y.x) (\x y. y), then we have that C1 [[(\x. x b x)]] = (\b c . (\x. x b x) (\x.x)) (\x y. x) (\x y. y) = \y . (\x.x) but C1 [[(\x. x c x)]] = (\b c . (\x. x c x) (\x.x)) (\x y. x) (\x y. y) = \y.y and those are clearly not equal (substitution into contexts is allowed to capture free variables, it's what they're for!). So you can say that your two expressions are equal in contexts that bind b and c to equal values, but otherwise not. Does that help? It's OK to ask philosophical questions about lambda calculus -- in a sense it's why it was invented. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] (.) . (.)
On 2006-05-29 at 19:03BST Brian Hulley wrote: Dominic Steinitz wrote: I think it's fascinating that already with ((.).(.)) there is something that can be used practically and proved equivalent to something easily comprehensible, Well, it is compose composed with compose, so you can start from the idea that it's going to do something to do with composition and twoness... Certainly it shows how much there is still to explore in terms of the inner landscape of lambda calculus. You've read http://www.amazon.co.uk/exec/obidos/ASIN/0444875085/qid=1148927765/sr=1-1/ref=sr_1_0_1/203-8973698-1827131 I presume? ;-) It's a bestseller... -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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] 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: Serious bug with ghc FC5
On 2006-04-13 at 20:18+0200 Alain Cremieux wrote: (resent after being indefinitely held in fedora-haskell validation queue) Hi, 1) I have installed FC5 on 2 different machines. On my Athlon1800+ everything works perfectly. My other machine is a Pentium IV with hyperthreading, considered by Linux as SMP (x86 32). This is where problems occur 2) I have installed GHC-6.4.1 from Fedora Extras When I compile 'Omega' with it, Omega (which has a read-eval system) produces a 'mallocBytesRWX: failed to protect 0x' message Is this an SELinux issue like the one I posted on Trac (#738)? Does it still occur if you do a setenforce Permissive? Cheers, Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: [Haskell] What's up with this Haskell runtime error message:
On 2006-04-06 at 11:25EDT Michael Goodrich wrote: Thanks so much for your help. I should have made clear that I was aware that the definitions were mutually dependent. What I was hoping was that Haskell could solve this for me without my having to resort to effectively finessing any sequencing considerations. Perhaps I am really asking it to do too much. I think so. Haskell doesn't do anything magic; it's a programming language rather than a mathematical amanuensis, so you have to say what the algorithm is. In the kind of thing you were attempting, ⊥ is a valid solution to the equations, as in f a = g a + 1 g b = f a - 1 where, while f x = x+x + 1, g x = (x+x+1) - 1 is a valid solution, so are many others, and in particular so is f x = ⊥, g x = ⊥, which also has the merit of being simpler. If you want an iteration over values to happen, you have to say where to start and how to get from one approximation to the next (if you don't, how would the compiler choose for you?), and Haskell is very good at this, as described in the paper by John Hughes that someone posted earlier. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] What's up with this Haskell runtime error message:
On 2006-04-05 at 12:35EDT Michael Goodrich wrote: Greetings All: GHC gives: Fail: loop Hugs gives: [(ERROR - C stack overflow Nowt's up wi' ' runtime error message. GHC's perfectly lucid. It says your programme went into an infinite loop. This sort of thing belongs on haskell-cafe, by the way. I've moved it there. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] What's up with this Haskell runtime error message:
On 2006-04-05 at 14:03EDT Michael Goodrich wrote: BTW, I can't seem to locate 'haskell-cafe'. http://www.haskell.org/mailman/listinfo/haskell-cafe The message responding to my sign-up said nothing about haskell-cafe. Perhaps it should. It's so long since I signed up to haskell that I've forgotten what the sign-up message says. Also, in my infinte-looping application, I am wrapping the calculation in a 'take 1000' function - shouldn't this guarantee termination? Not on its own loop = loop:: Char l = [1,2,3,loop,5,6] putStr $ show $ take 4 l will print 1 2 and 3 and then loop when trying to find the value for the fourth. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [GHC] #738: ghc can't load files with selinux Enforcing
On 2006-04-04 at 10:03- GHC wrote:
#738: ghc can't load files with selinux Enforcing
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System |Version: 6.4.1
Severity: major | Resolution:
Keywords: | Os: Linux
Difficulty: Unknown | Architecture: x86_64 (amd64)
-+--
Changes (by simonmar):
* component: Compiler = Runtime System
Comment:
Is this at all related to #703?
No idea.
I have no idea what SELinux enforcing mode does.
It enforces the policies... I think permissive mode just
logs things, but enforcing mode actually stops them.
It looks like SELinux doesn't like us using mprotect() to
make dynamically-allocated memory executable. This is
required for things like 'foreign import wrapper',
because we have to generate dynamic code.
The audit log entry in Enforcing mode is this:
type=AVC msg=audit(1144148747.937:6073): avc: denied { execheap } for
pid=18253 comm=ghc-6.4.1 scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
whereas in Permissive mode I find this:
type=AVC msg=audit(1144148449.336:5974): avc: denied { execheap } for
pid=18056 comm=ghc-6.4.1 scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
ie the same, except that ghci loads the file OK.
Can anyone shed any more light here?
Not much; I can't say I understand SELinux, but I think the
answer is probably in here:
http://people.redhat.com/drepper/selinux-mem.html
It's possible we could mmap() instead, I suppose.
It looks like you have to do that, and even so will need to
take steps to avaid getting an execmem denial.
--
Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input
On 2006-03-28 at 08:02+0200 Tomasz Zielonka wrote:
I wonder if it would be possible to remove the space-leak by running both
branches concurrently, and scheduling threads in a way that would
minimise the space-leak. I proposed this before
http://www.haskell.org/pipermail/haskell-cafe/2005-December/013428.html
I would like to hear opinions from some compiler gurus.
This is something I've been thinking about on and off for a
long time (probably since John Hughes mentioned the case of
average). I even kept Tomasz's original message in my
inbox until today in the hope that I'd get round to sending
a response, but my flaky health gets in the way. So here,
and I hope people will allow for the fact that I'm half
asleep as I write this, is an attempt.
There are some observations I'd like to make, and a
proposal. Since the proposal relates (in a small way) to
concurrency and is, I think worthwhile, I've cc'd this
message to haskell-prime.
1) choosing the optimal reduction strategy is undecidable
2) we shouldn't (in general) attempt to do undecidable
things automatically
3) Separation of concerns: Pragmatic decisions about
evaluation order should be kept separate from the
denotational aspect of the code. By this token, seq
shouldn't be a function (because it isn't one), but a
pragma. The fact that it's shorter to write seq a b than
{-# SEQ a #-} b is a matter of syntax, so shouldn't rate
highly in language design decisions. Perhaps we want a
different syntax for this kind of pragma, but that's a
side issue.
So, to take Tomasz's example of wc, we want to be able to
define it essentially this way:
wc cs = (ll, ww, cc) where ll = lines cs
ww = words cs
cc = length cs
but add [a] pragma[s] to the effect that evaluation should
be input driven, and that ll, ww, and cc are to be given
equal time. Something like {-# STEPPER cs; ROUND_ROBIN
ll,ww,cc #-} (please do not take this as a suggestion of
real syntax!).
The way I would implement this is to add a new primitive,
STEP, which is like seq except that it only evaluates its
argument until it encounters another STEP. (It really isn't
much different to seq).
So after the compiler understood the pragma, it would
replace wc with this (allowing the compiler to pretend step
is a function):
wc cs = (ll, ww, cc) where ll = lines cs'
ww = words cs'
cc = length cs'
cs' = foldr (\a - STEP ll . STEP ww . STEP cc .
(a:))
[]
cs
Evaluation would start as normal (a wrinkle here is that the
way I've written it, whichever element of the tuple is
evaluated first gets two goes at the start, but that's a
compiler detail). when it came to evaluating cs', it would
be looking at a thunk something like
STEP ll (STEP ww (STEP cc ('x': ...)))
update the thunk to
(STEP ww (STEP cc ('x': ...)))
evaluate ll until (and if) it hits the thunk again, update
it to
(STEP cc ('x': ...))
evaluate ww until it hits the thunk, update it to
'x' : (STEP ...)
evaluate cc, and so on.
It seems to me that this wouldn't take much effort to
implement, but it would provide a simple means of removing
space leaks from a whole bunch of programmes without
mangling the source code much.
Jón
--
Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Alternatives to . for composition
On 2006-03-25 at 09:41PST Jared Updike wrote: 2218 RING OPERATOR = composite function = APL jot 00B0 degree sign 25E6 white bullet I don't think any other Unicode character should be considered. That's great but 1) I have no idea how to type it. Can I easily and comfortably? In emacs? For emacs, just bind a key (C-. say) to (ucs-insert #X2218). ucs-insert comes from ucs-tables. 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)? Eventually. in everyone's mail readers (including Gmail)? Eventually, I should think. I'm using nmh, which has to be one of the least trendy MUAs about, and that can do it. What does this: â look like in your email reader? 3) What encoding do my textfiles need to be in Probably utf-8 (i.e. how many bytes per char)? a bit more than one on average. How do I do that? Depends on the OS you are using. I've got locale set to en_GB.UTF-8 and it all more or less works. Does Haskell even support everything related to Unicode that we'd need? Not now, but Haskell' jolly well ought to. If the answers are satisfactory to all these questions, then Unicode is a good idea (and that's the ideal character). Satisfactory is in the eye of the beholder. If not, we're sadly stuck in ASCII land. It's far worse than that. We are stuck in an idiotic land where the meaning of a file depends on the meaning of a user settable variable in the OS. This is one of the many unpleasant consequences of untyped filesystems¹. Oh, and Haskell claims already to have unicode source files, but the compilers can't handle it. Jared. P.S. Plus that opens a lot of cans of worms for writing programs with all those fancy symbols! APL here we come! It's a question of good style, isn't it? Using â instead of - might be nice, but stringing together lots of arcane symbols like ââ°Ⱐwouldn't be. For Haskell 98 I argued against unicode, preferring that we should stick with ASCII, but nowadays a language that doesn't handle unicode properly is going to look shabby in a few years. Jón [1] Something about which something should be done in Haskell... -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Alternatives to . for composition
Gah! I managed to send that without a content-type field (for bizarre reasons which I won't elaborate right now). Here it is again with what I hope is the right (utf-8) type, which ought to make it more legible in some email readers. On 2006-03-25 at 09:41PST Jared Updike wrote: 2218 RING OPERATOR = composite function = APL jot 00B0 degree sign 25E6 white bullet I don't think any other Unicode character should be considered. That's great but 1) I have no idea how to type it. Can I easily and comfortably? In emacs? For emacs, just bind a key (C-. say) to (ucs-insert #X2218). ucs-insert comes from ucs-tables. 2) Will it show up in PuTTY (and everyone else's terminals/IDEs)? Eventually. in everyone's mail readers (including Gmail)? Eventually, I should think. I'm using nmh, which has to be one of the least trendy MUAs about, and that can do it. What does this: ∘ look like in your email reader? 3) What encoding do my textfiles need to be in Probably utf-8 (i.e. how many bytes per char)? a bit more than one on average. How do I do that? Depends on the OS you are using. I've got locale set to en_GB.UTF-8 and it all more or less works. Does Haskell even support everything related to Unicode that we'd need? Not now, but Haskell' jolly well ought to. If the answers are satisfactory to all these questions, then Unicode is a good idea (and that's the ideal character). Satisfactory is in the eye of the beholder. If not, we're sadly stuck in ASCII land. It's far worse than that. We are stuck in an idiotic land where the meaning of a file depends on the meaning of a user settable variable in the OS. This is one of the many unpleasant consequences of untyped filesystems¹. Oh, and Haskell claims already to have unicode source files, but the compilers can't handle it. Jared. P.S. Plus that opens a lot of cans of worms for writing programs with all those fancy symbols! APL here we come! It's a question of good style, isn't it? Using → instead of - might be nice, but stringing together lots of arcane symbols like ₀∘°⁰ wouldn't be. For Haskell 98 I argued against unicode, preferring that we should stick with ASCII, but nowadays a language that doesn't handle unicode properly is going to look shabby in a few years. Jón [1] Something about which something should be done in Haskell... -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
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-cafe] Infinite loop?
On 2006-02-17 at 20:12GMT rgo wrote: Hi all, my program probably goes into infinite loop... But i cannot understand where and why. getDirectoryContents will include . and .., so if you follow those, you're bound to loop. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite loop?
On 2006-02-17 at 09:22PST Jared Updike wrote: Yep. change one line to: entry - if isdir name /= . name /= .. and it does in fact work. Only if no-one has been tricky with symbolic links. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Parallel list comprehensions
On 2006-02-04 at 16:08EST Cale Gibbard wrote: cartesian xs ys = map (\[x,y] - (x,y)) $ sequence [xs,ys] I'm lost. Isn't that just like cartesian xs ys = [(x,y)|x-xs, y-ys] ? Whereas... On 04/02/06, Jan-Willem Maessen [EMAIL PROTECTED] wrote: On Feb 4, 2006, at 1:31 PM, Jon Fairbairn wrote: ... There ought to be a list_product somewhere (I mean [1..] `list_product` [4..] == [(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there? Not that I know of, but here's one which handles finite lists correctly; it'd be a nice addition to Data.List: dzip :: [a] - [b] - [(a,b)] dzip = dzipWith (,) dzipWith :: (a - b - c) - [a] - [b] - [c] dzipWith f [] ys = [] dzipWith f as [] = [] dzipWith f as (y:ys) = dzipK ys [y] where dzipK (b:bs) rbs = zipWith f as rbs ++ dzipK bs (b : rbs) dzipK [] rbs = dzipT as where dzipT ys@(_:yt) = zipWith f ys rbs ++ dzipT yt dzipT [] = [] -Jan-Willem Maessen ...does seem to work for infinite lists! -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Why is $ right associative instead of leftassociative?
On 2006-02-04 at 21:15GMT Brian Hulley wrote: Stefan Holdermans wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian wrote: I think the mystery surrounding :: and : might have been that originally people thought type annotations would hardly ever be needed whereas list cons is often needed, but now that it is regarded as good practice to put a type annotation before every top level value binding, and as the type system becomes more and more complex (eg with GADTs etc), type annotations are now presumably far more common than list cons so it would be good if Haskell Prime would swap these operators back to their de facto universal inter-language standard of list cons and type annotation respectively. I don't think Haskell Prime should be about changing the look and feel of the language. Perhaps it is just a matter of aesthetics about :: and :, but I really feel these symbols have a de-facto meaning that should have been respected and that Haskell Prime would be a chance to correct this error. However no doubt I'm alone in this view so fair enough Not exactly alone; I've felt it was wrong ever since we argued about it for the first version of Haskell. : for typing is closer to common mathematical notation. But it's far too late to change it now. - it's just syntax after all It is indeed. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Parallel list comprehensions
On 2006-02-04 at 15:11+0100 John Hughes wrote: I noticed ticket #55--add parallel list comprehensions--which according to the ticket, will probably be adopted. I would argue against. I also agree. Firstly: because in its more general forms the notation is confusing. Try this example: [(i,j,k) | i-[1..3], j-[1..3] | k - [1..9]] In general it's hard to predict how the elements from each set of generators and filters will match up. and I always think it's going to do something cooler -- a fair list product (like , only working on infinite lists), not a zip, and then I'm disappointed when I remember it doesn't. So it just uses up some syntax (ie adds possible errors) without adding anything really useful. There ought to be a list_product somewhere (I mean [1..] `list_product` [4..] == [(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there? Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Splitting a string into chunks
On 2006-01-13 at 13:32PST Jared Updike wrote: That works except it loses single newline characters. let s = 1234\n5678\n\nabcdefghijklmnopq\n\n,,.,.,. Prelude blocks s [12345678,abcdefghijklmnopq,,,.,.,.] Also the argument to groupBy ought to be some sort of equivalence relation. blocks = map unlines . filter (all $ not . null) . groupBy (\a b - not (null b|| null a)) . lines ... but that suffers from the somewhat questionable properties of lines and unlines. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with square root...
On 2005-12-21 at 18:10GMT Daniel Carrera wrote: Daniel Carrera wrote: Hey, The sqrt function is not doing what I want. This is what I want: round sqrt(2) Sigh... never fails. Spend an hour trying to solve a problem, and a minute after you write to the list you find the solution. I need brackets around sqrt. I'm surprised though. I don't understand why it dosn't work without brackets. Elementary syntax. Function application needs no parentheses and associates left, so sqrt 2 is fine, and what you wrote means (round sqrt) 2 whereas what you want is round (sqrt 2) -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getCPUTime ??
On 2005-11-21 at 15:14EST Michael Benfield wrote: I'm new to Haskell. I'm apparently misunderstanding something here. When I run this program: - module Main where import System.Posix import System.CPUTime printTime = getCPUTime = putStrLn . show main = printTime sleep 5 printTime - It produces this output: 14300 14300 or similar. In any case, both the numbers are the same. Should the second number not reflect a time 5 seconds later than the first? I've tried this with both GHC and Hugs, and both give me the same thing. Should 'sleep 5' take any CPU time? -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 2005-11-17 at 13:21EST Cale Gibbard wrote: Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Hear hear. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Ought to be ∘, unicode 0x2218, but without defining some keyboard macros, that's even harder to type. On the other hand, I could define ctrl-. as (ucs-insert 2218), and then it would be no harder to type than . -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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] 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-cafe] Nice way to calculate character frequency in a string
On 2005-10-25 at 12:20+0200 Lemmih wrote: On 10/25/05, Charles SDudu [EMAIL PROTECTED] wrote: Hello, I need to calculate the frequency of each character in a String. And if I can do this really well in C, I dont find a nice (and fast) answer in haskell. I tried several functions, listed below, and even the fastest do a lot of unnecessary things : calc :: String - [ (Char, Int) ] calc = filter (\p - snd p 0) . assocs . foldl (\k c - unsafeReplace k [(fromEnum c, (unsafeAt k (fromEnum c))+1)] ) k where k = array (toEnum 0, toEnum 255) [(toEnum i, 0) | i - [0 .. 255]] :: UArray Char Int [snip even more disagreable code] Ugh! These are all horrid. If something on the lines of calc = accumArray (+) 0 (minBound, maxBound) . (map (\x-(x,1))) isn't fast enough, complain to the implementors! What's the point of functional programming if one has to twist into a shape that allows inspection of one's own fundament to get stuff to run in decent time? Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interest in helping w/ Haskell standard
On 2005-10-14 at 16:56+0200 Stephane Bortzmeyer wrote: On Fri, Oct 14, 2005 at 03:34:33PM +0100, Jon Fairbairn [EMAIL PROTECTED] wrote: Because the language used inside these strings is standard, multi-language, widely used and documented? 10,000 lemmings can't be wrong? Right, disregard ASCII and specify the lexemes of Haskell 2 in a new encoding scheme, much better than ASCII :-) Haskell 98 isn't ASCII, but Unicode (Report, 2.1), current compiler inadequacies notwithstanding. So we've done that already. (And incidentally I'm on record as having argued for ASCII rather than Unicode for Haskell source). Not even the syntax of such regexps is checked at compile time. Of course, from the compiler's PoV, they are just strings. That's what I'm complaining about. May be a new form of strings, like in Perl, to show that this is a regexp? That's what I'm suggesting. Since Unicode is increasingly adopted, we could just use «regexp» The Unicode standard for regexps, UTR #18 (http://www.unicode.org/reports/tr18/) uses the very same standard syntax that you criticize. So if we must have a short-form syntax, perhaps we should use that one as I already intimated. However, as I read that report, it's a standard way of adapting (any, standard or otherwise) REs to handle unicode, not a standardisation of regexps per se. Specifically Note: This is only a sample syntax for the purposes of examples in this document. (Regular expression syntax varies widely: the issues discussed here would need to be adapted to the syntax of the particular implementation. [...] So it's not a Unicode standard for the syntax of regexps. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Default name of target executable
On 2005-10-11 at 09:49BST Simon Marlow wrote: On 11 October 2005 06:29, Tomasz Zielonka wrote: It wasn't meant to be a bug report, only a feature request ;-) Actually, I was mostly interested if anyone would mind if GHC chose the name based on the top-level module. Would you accept the patch? I'm slightly inclined not to make this change, but I could be swayed if there was enough interest in it. What I'm seeing so far is not overwhelming support for the change. Simon PJ is in favour, though. a.out has always irriteted me. I /never/ want an executable called that, and from time to time I try to run top-level-module and then curse that I haven't used -o. Looking now I find I have an a.out in my haskell directory, and I haven't the faintest idea what it is, so the only thing to do with it is delete it. The name a.out is meaningless too. It flies in the face of Haskell's approach to giving things sensible names. On this system ghc produces ELF format executables, so it doesn't even signify whatever historical format a.out used to be. Just what are the advantages of keeping this? Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Memoization
On 2005-10-07 at 22:42- Gerd M wrote: As (memory) is a function, it cannot be memoized (the function can be, but not its result, which is what you're after). How can a funcion be memoized but not it's result (what does this mean)!? Since there are no side effects in Haskell why is it important that the array is a CAF? Or let's say it that way, why can't the results of a (pure) function be memoized since it always returns the same result for the same parameters? I'm a bit rusty on this, but here's an attempt at an explanation. This is an implementation issue; a matter of choice for the implementor. In a function like this: f x = factorial 100 + x factorial 100 doesn't depend on x -- is a CAF -- so it can be lifted out and computed only once. Note that since the value of f doesn't depend on whether this is done, there's no /requirement/ that the compiler do it. In this: g a = \ x - factorial a + x g 100 is equivalent to f, but here the factorial 100 isn't a constant (it depends on a), so the compiler would have to go to extra lengths (known as full laziness) to ensure that the factorial was kept for each application of g. It's certainly possible for a compiler to do this, but the problem is that if the subexpression that gets retained is infinite, it takes up a lot of space, and there's no way for the programmer to say that it's no longer needed. So compilers tend not to do this. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
Re: [Haskell-cafe] Can't explain this error
On 2005-07-12 at 12:39- Dinh Tien Tuan Anh wrote: i have just encountered another type error. This program tries to print out partitions of a positive integer (i guess) parts 0 = [[]] parts x = [concat (map (y:) parts(x-y) | y-[1..(x `div` 2)]] ^ suspicious spacing! That's the same as parts x = [concat (map (y:) parts (x-y) | y-[1..(x `div` 2)]] ie you are giving map three arguments when it expects two, which is what the type error says. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Deprecate an instance
Would it be possible to extend the DEPRECATED pragma to allow one to deprecate an instance of a class? I was thinking about the recent discussion of APIs on haskell-cafe, where Jérémy Bobbio complained about using Booleans as arguments to libaray functions, preferring instead sensibly named data constructors. It occurred to me that by defining a class one could allow both the old interface and a better one by using a class: module Main where -- suppose f used to be Bool - Int - Int, replace it -- with this: f :: Toggle t = t - Int - Int f t x = case enabled t of Invert - -x DontInvert - x data DoInvert = Invert | DontInvert class Toggle t where enabled :: t - DoInvert instance Toggle DoInvert where enabled = id instance Toggle Bool where enabled True = Invert enabled False = DontInvert but for this to be any real use, we'd have to be able to deprecate the /instance/ Toggle Bool. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[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). -- Jn 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. -- Jn 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 URL: 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-cafe] Ignorant begginer question
On 2004-12-23 at 15:09-0200 =?ISO-8859-1?Q?Maur=EDcio?= wrote:
Guys,
What is wrong with this code?
**
import Complex
roots :: (Complex, Complex, Complex) - (Complex, Complex);
roots (a,b,c) = (x1,x2) where { x1 = (b*b + (sqrt_delta))/(2*a); x2 =
(b*b - (sqrt_delta))/(2*a); sqrt_delta = sqrt 4*a*c}
**
I load it into GHCi and get:
**
Kind error: `Complex' is not applied to enough type arguments
That means what it says: Complex takes an argument, namely
the type for the real and imaginary parts. You need to
choose from Float, Double or some RealFloat.
Try this in ghci:
Prelude :m Complex
Prelude Complex :info Complex
-- Complex is a type constructor
data (RealFloat a) = Complex a = (:+) !a !a
and then
type Compl = Complex Double
roots :: (Compl, Compl, Compl) - (Compl, Compl)
--
Jón Fairbairn [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Scoped type variables
On 2004-12-17 at 17:51GMT Simon Peyton-Jones wrote: This message is about lexically scoped type variables. I've been trying to work out what I think about this since you sent out the first message in this thread. I'm not sure that I've come to a useful conclusion, so I'll summarise my thoughts and see if that makes anything pop out of someone else's head. First, I've never liked the fact that type variables in signatures aren't declared anywhere -- this was part of the motivation that drove me to use a non-Hindley-Milner type system in Ponder. There, you could put a quantifier on an expression, so instead of f :: [a] - [a] f x = body you could write (mangled to make it look more like Haskell) stuff like f = forall a.\(x::[a]) - body::[a] and the scope of a was completely clear. Of course, this doesn't work with the way variables are declared in Haskell. Would it help to stick the quantifier at the beginning of the type declaration? forall a b . g :: Foo a b = [a] - [a] g = ... That reads OK, and one can imagine that whenever you see a g = ... bit, you implicitly get the type variables that come at the front of the type declaration in scope as well. Doing this would mean that you keep the old behaviour for cases where there is no quantifier at the beginning of the type declaration, so things wouldn't break. So there it is. Any one have strong opinions? (This is in addition to the existing mechanism for bringing scoped type variables into scope via pattern type signatures, of course.) If I have a strong opinion about anything it's that the only thing that should bring type variables into scope is a(n implied) quantifier. Free variables are nasty. I don't hold out much hope of convincing anyone of this last, though. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Determining all rotations (Was: Haskell problem please help)
On 2004-12-16 at 17:00+0100 Henning Thielemann wrote: imranazad wrote: Hi, im not very good with haskell, i barely know the basics, my coursework requires me to genereate a vigenere square... well anyway at the moment im trying to define a functin all_rotations which for any list returns the list of all its rotations, so far i've made an attempt but it only rotates onceany ideas? i dont want the complete solution just help thats all, much appreciated. all_rotations :: [a] - [[a]] all_rotations [] = [] all_rotations (x:xs) = reverse (x:xs) : [] 'cycle' the list, then determine all of its suffixes with 'tails' and take the first elements of each list. playing with inits l `zip` tails l might also be edifying. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Processing File Dependencies
On 2004-12-11 at 16:00GMT chris beddoe wrote: Hey, please don't send mail in html I have been trying to program a simple Haskell program that allows me to input a list of Java files and their dependencies Judging from what appears below, you should probably start with something simpler. Take this, for example: getArray :: [String] - [File] getArray [a] | length[a] == 1 = [parseFile (head[a])] | otherwise = [parseFile (head[a])] (getArray (tail[a])) length [a] is always going to be 1, because [a] is a list containing just a. head[a] is a, tail [a] is []. You give no cases for getArray when the input is something other than a list of length 1. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Pure Haskell Printf
On 2004-11-16 at 11:42+0100 Peter Simons wrote: Henning Thielemann writes: One advantage is that you need to type fewer characters. I know memory is expensive, that's why only the last two digits of year numbers are stored. :-] I understand what you're getting at -- and I find it annoying, too, when people sacrifice robustness for comfort. I'm not sure, though, whether this is the case here, because vsnprintf in Haskell still is type-safe. Not statically, though, surely? vsprintf %d, your age is %s\n John (10::Integer) is type incorrect, but won't be reported at compile time. At least I can't see how it could be, given that the string can't be dissected at compile time. You can save even more characters: msg = verb i = . shows 12 . verb \tj = $ test Right! One more reason to use ShowS-style. :-) and that really is type safe. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie Question on type constructors
On 2004-11-01 at 23:01+0100 Benjamin Franksen wrote: On Monday 01 November 2004 21:51, Jon Fairbairn wrote: Put the data declaration in a module, export the type, but not the constructor you want to hide: module Shape (Shape(Square), circle) where Since we were talking about 'what can one do with a constructor as compared with a function', it should be mentioned that this also has a disadvantage: you loose pattern matching outside the module. I.e. no longer can say ... case x of Circle radius - ... Square edge - ... BTW, would it be possible (in principle) to allow constructor export 'read-only', so matching against a constructor is allowed but not constructing a value? I don't see why not. To add something to the debate about what Circle /is/, I'd like to mention that the declaration data Shape = Circle Double | Square Double is a convenience that declares three new names (Shape, Circle and Square), but five entities. There's Shape: a type, Circle, Square:: Double - Shape: constructor functions, and Circle, Square:: Shape - (Double - t) - t - t: destructor functions. The first three are available for general use by the programmer, but the last two are hidden in the works of pattern matching. I think this is what confuses things. In all contexts bar pattern matching and export lists, Circle and Square refer to the constructor functions (and they really are just functions in these contexts). In patterns they indirectly refer to the destructor functions, and in export lists to both. I'd like to see the separation made more accessible, and if this were done, one could export whatever combination of the entities one desired. I hesitate to raise the question of what syntax we might choose to represent this for fear of invoking Wadler's law. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hugs segmentation fault
On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote: Jon Fairbairn wrote: On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote: Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again. I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1 Well, here's a sample session I recorded just now: C:\\ghc\ghc-6.2.1\bin\ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude let p = 1 : [2 * x | x - p, x 1] in p [1*** Exception: loop Prelude 123 Fail: thread blocked indefinitely C:\ Does this only happen to me? I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd) -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: getUserEntryForName weirdness
On 2004-10-29 at 18:29+0200 Peter Simons wrote: Is anyone else seeing this on his system? getUserEntryForName [] = print . userName wasabi wasabi happens to be the last entry in the /etc/passwd file, and that is what I get every time I query for an user that doesn't exist. The source code promises an exception, but I don't get one. Same here with ghc 6.2.1. The haddocks don't say anything about what should happen. BTW, the relevant library is System.Posix.User and a similar effect is observed with getGroupEntryForName Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] hugs segmentation fault
On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote: Jon Fairbairn wrote: On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote: Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again. I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1 Well, here's a sample session I recorded just now: C:\\ghc\ghc-6.2.1\bin\ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude let p = 1 : [2 * x | x - p, x 1] in p [1*** Exception: loop Prelude 123 Fail: thread blocked indefinitely C:\ Does this only happen to me? I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd) -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hugs segmentation fault
On 2004-10-29 at 00:45+0200 Andrej Bauer wrote: Hi, I am new to haskell, but otherwise experienced in programming languages. My first attempt at Haskell was this (on a Linux Debian) session with hugs: Type :? for help Prelude :version -- Hugs Version November 2003 Prelude let p = 1 : [2 * x | x - p, x 1] in p [1Segmentation fault Is it the norm for hugs to dump core like this? Or was I just very lucky to discover a bug? UNlucky. There's a bug in your programme in that it goes into an infinite loop consuming something (stack probably), and it happens that hugs doesn't correctly check for its exhaustion. (I'd call that a bug too) In ghci you get: [1*** Exception: loop which is better. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hugs segmentation fault
On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote: Jon Fairbairn wrote: In ghci you get: [1*** Exception: loop which is better. Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again. I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1 Is it coincidence that both Hugs and GHCi have trouble handling dependency loops, or is it a very difficult problem that both have given up on solving? It's not difficult per se, but it may be difficult to do without performance implications, and compiler hackers are always terribly protective of their performance... Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Language extension idea (was Re: [Haskell-cafe] Re: OCaml list sees...)
On 2004-10-10 at 11:20BST Malcolm Wallace wrote: As an example, instead of the following list-only code, f :: List a - ... f []= ... f (h:t) = ... you could write this more general version, which assumes only some class Sequence with operations null, head, tail, etc. f :: Sequence s = s a - ... f list | null list = ... | h - head list, t - tail list = ... Although slightly more verbose, it still achieves something like the clarity of pattern-matching. Here's my take on this: module SQC where import Array Split the reading from the writing, and allow the avoidance of head and tail wherever possible: class Sequential f where examine :: f a - Maybe (a, f a) the next three aren't really necessary first :: f a - a rest :: f a - f a isEmpty:: f a - Bool The default method for first and rest typify the usage. I think this is slightly prettier than using head and tail: first l | Nothing - e = error ugh | Just (hd, tl) - e = hd where e = examine l rest l | Nothing - e = error agh | Just (hd, tl) - e = tl where e = examine l isEmpty l | Nothing - examine l = True | otherwise = False class Sequential s = Sequence s where cons :: a - s a - s a nils :: s a With the reading and writing separated, we can do things like map and filter without requiring the thing being read from to have all the properties of a list: mapS:: (Sequential s, Sequence t) = (a - b) - s a - t b mapS f l | Nothing - e = nils | Just (h, t) - e = cons (f h) (mapS f t) where e = examine l filterS:: (Sequential s, Sequence t) = (a - Bool) - s a - t a filterS p l | Nothing - e = nils | Just (h, t) - e, p h = cons h (filterS p t) | Just (h, t) - e = filterS p t where e = examine l The instances for [] are straightforward instance Sequential [] where first = head rest = tail examine [] = Nothing examine (a:b) = Just (a,b) instance Sequence [] where cons = (:) nils = [] Actually, in Ponder, the list type was just a (recursive) synonym for something similar to List t = Maybe (t, List t), so examine would just have been the identity -- which suggests that this ought to be cheap to implement. We can give a read-only instance for (part of) an array: data ArrayTail i e = AT i (Array i e) deriving Show instance (Enum i, Ix i) = Sequential (ArrayTail i) where examine (AT i a) | inRange (bounds a) i = Just (a!i, AT (succ i) a) | otherwise = Nothing so that filterS ((==0).(`rem`2)) (AT 1 (array (1,10) ([1..10]`zip`[20..30])))::[Int] = [20,22,24,26,28] which might be handy for selecting stuff from an array represented sequence without having to build an array for the result. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strict evaluation not working?
On 2004-10-12 at 18:07+0200 Christian Hofer wrote: Hi, having found a bit of time to play with Haskell, I am trying to figure out how to enforce strict evaluation. I wrote the following program: main = let x = zipWith (+) [5..] [6..] in putStrLn $ show $ x `seq` head x I expected this program not to terminate - because of the seq-Operator, but it happily returns 11 in ghc as well as in ghci. What do I make wrong? head is strict in its first argument, so x `seq` head x is equivalent to head x. seq only evaluates to (w?)hnf. To do more you would need deepSeq. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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-cafe] Re: Silly I/O question
On 2004-09-28 at 21:19- John Goerzen wrote: On 2004-09-28, Peter Simons [EMAIL PROTECTED] wrote: John Goerzen writes: FWIW, this is working for me: import IO main = disp 100 disp 0 = return () disp n = let copy x = do eof - isEOF if eof then return () else do line - getLine putStrLn line (copy 0) in do copy 0 hSeek stdin AbsoluteSeek 0 disp (n-1) but it seems wasteful to poll isEOF so much. Why do you say that? The condition has to be tested for, whether you do it by polling or waiting for an error to be thrown For my 2¢, I think I prefere this sort of thing to look like this: import IO number_of_copies = 100 main = mapM_ contentsToStdOut $ replicate number_of_copies stdin contentsToStdOut hdl = do line_by_line hdl hSeek hdl AbsoluteSeek 0 line_by_line hdl = foldIO (const putStrLn) () hGetLine hdl foldIO process_item initial_state io_operation handle = process initial_state where process state = do eof - hIsEOF handle if eof then return state else do item - io_operation handle new_item - process_item state item process $ new_item and some version of foldIO should probably be in a library somewhere. If you really don't like polling, you can write this: contentsToStdOut hdl = do t - try $ line_by_line hdl hSeek hdl AbsoluteSeek 0 case t of Right () - error this never happens Left e - if isEOFError e then return () else ioError e with line_by_line hdl = do line - hGetLine hdl putStrLn line line_by_line hdl Note that all of these are incorrect because hGetLine doesn't tell you whether there was a newline at the end of file. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Network, sClose
On 2004-08-11 at 14:19BST Glynn Clements wrote: Bayley, Alistair wrote: Is recvFrom meant to be a one-shot function i.e. the socket is only closed when the process exits? The implementation is: recvFrom host port = do ip - getHostByName host let ipHs = hostAddresses ip s - listenOn port let waiting = do ~(s', SockAddrInet _ haddr) - Socket.accept s he - getHostByAddr AF_INET haddr if not (any (`elem` ipHs) (hostAddresses he)) then do sClose s' waiting else do h - socketToHandle s' ReadMode msg - hGetContents h return msg message - waiting return message This is rather more powerful than recvFrom in C, isn't it? Perhaps it's misnamed: C's recvFrom deals with finite messages, but with the above I can receive an infinite list, which is the source of the problem, even if rather cool. Note that the listening socket s is passed to accept then forgotten about. If it was accessible, it would be possible to either accept further connections on it, or to close it. As it stands, it will remain open and unused for the duration of the calling process. So the problem is the same as with hGetContents in general, compounded by the calling programme not having access to the socket, so it can't close it even if it knows it's finished with the data. Right. If listenOn and accept are in Network, sClose should be in there too. That would at least provide an API which is usable for the simplest programs. Agreed, and recvFrom seems to need to be something else, though the problem could be ameliorated by making withSocketsDo close any leftover sockets. You'd then have to use it for both Linux and Windows. OTOH, the core problem with Network.recvFrom is essentially that it appears to be a misguided attempt to provide a symmetric counterpart to Network.sendTo. While the low-level sendTo/recvFrom functions may be roughly symmetric, at a higher level, the client and server ends of a connection aren't at all symmetric. Given that, recvFrom could :: HostName - Socket - IO String. We'd have to call listenOn to get the socket, but that seems a small hardship compared to losing the use of the port. [1] What's the Do doing there anyway? You end up writing withSocketsDo$do, and we could do without the Do$do. -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Network, sClose
I just got myself a copy of ghc-6.2.1 and was idly experimenting with Network in ghci. I tried Prelude System.Posix Network do r - recvFrom localhost$ PortNumber 9090; putStr r in one ghci and Prelude Network do sendTo localhost (PortNumber 9090) jellied eels\n in another and was pleased to see jellied eels pop out of the first. Unfortunately a second attempt is not so happy: Prelude System.Posix Network do r - recvFrom localhost$ PortNumber 9090; putStr r *** Exception: bind: resource busy (Address already in use) According to the documentation there's some mention of Address already in use on this mailing list, but I couldn't find it -- I thought there used to be searchable archives of the mailing lists, but I couldn't find those either and resorted to google. A little experimentation revealed that: do sock - listenOn$PortNumber 7607; (hdl,host,port)- accept sock; s-IO.hGetContents hdl; putStr$s; IO.hClose hdl; Network.Socket.sClose sock is nicely repeatable. The following questions arise: * Shouldn't recvFrom call sClose itself? * If not, how should one clean up after using recvFrom? * Shouldn't sClose be reexported from Network? * is there a general way to get ghci out of a state where it's got stuff open on inaccessible sockets? Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Beginner problems with 'triple' code
On 2004-07-26 at 18:10BST =?iso-8859-1?q?Stu=20White?= wrote:
Hi
I'm not especially experienced in using haskell, and I could use some help.
As part of a project, I'm trying to construct a data type
that can represent three values as a 'triple' (as opposed
to a 'tuple'),
you could just use triples: (a,b,c)
and then make a function so that I can sort these values
into ascending order.
I'm having a few problems with the code that I have at the minute (I suspect its
riddled with errors!)
type Triple = Triple {
type is essentially for renaming types, you want data here.
entry 1 :: a;
You can't have spaces in field names. Make those changes and
see what hugs or ghci says to it.
DIVHi/DIV
(and more html snipped) Please don't send html messages to the list!
Jón
--
Jón Fairbairn [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with types
On 2004-07-23 at 19:18+0300 Kari Pahula wrote: temp :: (Real a) = Object (Energy a) (HeatC a) - Temp a temp Object (Energy e) (HeatC c) = Temp e*c But this fails in hugs with: ERROR temp.hs:22 - Constructor Object must have exactly 2 arguments in pattern You've given temp three arguments: Object, (Energy e) and (HeatC c). You meant: temp (Object (Energy e) (HeatC c)) = Temp e*c HTH -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Modules and files
On 2004-06-14 at 15:59PDT Iavor S. Diatchki wrote: according to the report there should be no connection between modules and files, and one should be able to have multiple modules in a file, and even a single module in multiple files. however none of the implementations support that, so in effect there is 1-1 correspondence between modules and files. the reason for this is that it provides an easy way for the implementation to find the modules. But surely it's also a significant discouragement to those who would write small modules, and therefore a Bad Thing, at least until editing and displaying multiple files is made sufficiently easy? Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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: [Haskell-cafe] WildCard question
On 2004-04-13 at 18:52+0200 Ketil Malde wrote: Paul Cosby [EMAIL PROTECTED] writes: Every time I try to use [underscore] in an definition it says something like the symbol /017 is not recognised Could that be \017, i.e. octal 17 (defined in ASCII as SI, whatever that may be)? SI is Shift In, if I remember correctly, not that the operation of devices like Flexowriters is of any relevance. However, I'd guess that it's hexadecimal 17, because ord '_' `rem` 16 == 15 == 0x17. So for some reason it's talking about the botom four bits of '_'! Any help suggestions? Wild guess: Are your files using the same character set as your Haskell system is expecting? I know Windows pulls some occasional stunts with the character set (and occasionally lies about it), but I wasn't aware that it affected underscore. Windows is a mystery to me, however. My guess would be something translating from one page of a character table to another. What locale are you in? Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are Kind errors and how do you fix them?
On 2004-03-23 at 16:58EST S. Alexander Jacobson wrote: Implementing Reverse from before, I am running into this weird error: type ReverseType a string = (string -(string,a)) data Reverse a string = Reverse (ReverseType a string) instance Monad (Reverse a s) where return x = Reverse (\text - (text,x)) (Reverse p) = k = Reverse p3 where p3 s0 = p2 s1 where (Reverse p2) = k a (s1,a)=p s0 Produces the error: Kind error: Expecting kind `* - *', but `Reverse a s' has kind `*' When checking kinds in `Monad (Reverse a s)' In the instance declaration for `Monad (Reverse a s)' I have no clue what this error message means. Kinds are to types what types are to values. You've declared Reverse to have two arguments: it takes a type, then another type and returns a type, so its kind is * - * - *. (Reverse a) has kind * - * and (Reverse a s) has kind *. Now a monad is something that takes a type as an argument, so has kind * - *, for example IO has kind * - * -- you expect to see IO Something most places. So (Reverse a) could perhaps be a monad, but (Reverse a s) cannot be. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Perspectives on learning and using Haskell
On 2004-01-01 at 21:07EST [EMAIL PROTECTED] wrote: There is only one problem I've found with test-driven development in Haskell. In C++, it's possible to break the module abstraction (yes, I know, C++ doesn't have modules; it has classes, which are really instantiable modules) by using friend. In Haskell, I find myself occasionally having to expose parts of a module which I would prefer not to, in order for the unit tests suite to do their job effectively. I wonder if there might be a way to fix this, say, by allowing modules to selectively expose parts of their interface depending on who wants to use it. One of my unexplored ideas is to make tests part of the code of a module (probably best done with some sort of typed include mechanism for test data), linked in some way with the type of an entity. So one might write something like f :: Integer - Integer |? f 0 == 1 f 3 == 6 The compiler would then (optionally?) run the tests as part of the compilation. This would bind the tests more tightly to the programme than is now possible. As I say, I haven't explored this, so perhaps some of those agile minds out there could run with it? -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Type checking
On 2003-12-31 at 19:27GMT Lee Dixon wrote: Hi, Can anyone explain to me how hugs manages to derive that f x y z = y (y z) x is of type f :: a - ((a - b) - a - b) - (a - b) - b To begin with, f has three arguments, x y and z, so letting each of these have types Tx Ty and Tz, f has to have type Tx - Ty - Tz - R, for some R. We see that y is applied to z, so y must have type Tz - Ry: f:: Tx - (Tz - Ry) - Tz - R but y is also applied to (y z) and x. (y z):: Ry, so y must also have type Ry - Tx - R since R is the type of the body of f. so we need to find a type that has instances Tz - Ry and Ry - Tx - R putting Ry = (a - b), we want Tz - (a - b) to be the same as (a - b) - Tx - R, which it is if Tz = (a - b), Tx = a and R = b. ie Ty = (a - b) - a - b. So substitute all those in the first guess for the type of f we get a - ((a - b) - a - b) - (a - b) - b | ---|------|| |Tz Tz | |-|--| TxTy R You want to look up unification and Hindley-Milner type inference. Does that help? Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: To show or not to show french accents
On 2003-12-18 at 16:40+0100 [EMAIL PROTECTED] wrote: Good evening, OK. I don't know Haskell enough to argue. But I can't resist pointing out that reading a single byte having the value 233 (that is 'é') The problem is that if you are reading single bytes, 233 is not necessarily é. It might be 'shch' if you are in Russia, or iota if you are in Greece. While it's (almost) completely reasonable to expect 233 to display as é in Western Europe, it's completely unreasonable to hold that expectation across borders. is certainly simpler than reading the four characters \233, parse it, and translate it into a single byte but it isn't a single byte internally. Indeed, if you are in Russia you could reasonably expect reading a single byte 233 to be converted to the internal code 1257 (if I got the arithmetic right). Since Haskell specifies unicode, if you are operating in a Russian locale that's what ought to happen. What I don't understand is why you want show for this. As I mentioned earlier, to output strings and get accented characters, all you have to do is to output the string with putStr, and voilà, les signes diacritiques. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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: odd interactions (was: IO behaves oddly if used nested)
I'd just like to add a brief note to what Claus has said: On 2003-10-06 at 19:48BST C.Reinke wrote: [moved to haskell-cafe] The odd is in the conceptual explanation. If I give a description of some f x = y function in Haskell I expect that some program f x is reduced to y and the result is given back (possibly printed). A good story to sell to students. This is almost everywhere the case except for the IO monad. indeed. Although, for the benefit of your students, you'll want to separate printing and reduction, even in the first case. I think one of the causes of confusion here is that the interpreters (ghci and hugs) do something solely for the convenience of the user -- namely print out /values/ -- that has nothing to do with the execution of Haskell /programmes/. I don't think that the definition of the language has anything to say about the effect of evaluating an expression. You could imagine an interpreter that only permitted objects of type IO () (or IO t, but that would still be confusing) to be entered at the top level. It would be less useful, because it would respond to an input of 2+2 with a type error and you'd have to enter print $ 2+2 instead. Alternatively it might respond to 2+2 with it:: Integer and then you could enter print it. Either of these would be less convenient to use, but would avoid that (possibly printed) above. If you remove the (possibly printed) and tweak a bit you get [...] If I give a description of some f x = y function in Haskell I expect that some /expression/ f x is reduced to y and the result is given back. A good story to sell to students. And I'd agree completely, but you can't output a value to a terminal, you have to output a sequence of characters, and to do that you have to observe certain conventions that have nothing to do with the value itself. Cheers, Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Improvement on this function
On 2003-09-17 at 10:31EDT Gordon James Miller wrote: Something I think is more café than language: Hello all. I'd be interested in getting some feedback on how to do this linear interpolation function a little more cleanly. The normal way that this is taught is to find the set of indices in the x list that bracket the input value, then use the slope between these points to calculate the y value for the input value. I had a version working at one point using !! to access particular elements but I wasn't sure which one was the better solution. !! can be expensive. linterp :: [Double] - [Double] - Double - Double linterp (x1:x2:xs) (y1:y2:ys) x | x = x2 || xs == [] = linterpPair x1 x2 y1 y2 x | otherwise = linterp (x2:xs) (y2:ys) x where linterpPair x1 x2 y1 y2 x = x1 + (x - x1) * (y2 - y1) / (x2 - x1) It seems to me that you have too much going on in one function. It would be better to break it into the part that finds the point where the interpolation is supposed to happen and the function that does the interpolation. You sort-of do this, but don't go far enough for my taste. You don't say whether the xs are supposed to be in increasing order. Also it's not obvious that your version does the right thing in the case where x head xs, and linterpPair doesn't look right to me. Something like: linterp :: [Double] - [Double] - Double - Double linterp xs ys x = linterpPair (neighbours (zip xs ys)) where linterpPair ((x1,y1),(x2,y2)) = y1 + (x - x1) * (y2 - y1) / (x2 - x1) neighbours all@(p@(x1,y1):rest) | x = x1 = head (dropWhile ((x). fst . snd) (all `zip` rest)) would be more to my taste, though it would be better to handle the errors rather than leave them to the runtime system. I think I would also define the function as linterp :: [(Double, Double)] - Double - Double since that seems more natural as the data are connected that way, and it would eliminate a zip. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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: recursion
On 2003-08-23 at 20:14+0200 Wolfgang Jeltsch wrote: On Thursday, 2003-08-21, 13:32, CEST, Keith Wansbrough wrote: [...] BTW: please post in plain ASCII, not HTML [...] Or post both, plain text and HTML, in combination. Users of HTML-capable mail clients will be able to read your mails formatted nicely while others will still see your text without HTML tags. I for one would prefer plain text only. For one thing I access my email over a phone line, so the more than doubling of message size that multipart/alternative entails is unwelcome. For another, few (if any) of the html encoded emails I've seen are formatted nicely. Either they look pretty much as they do with plain text, or the have poor choices of fonts or other questionable typographic design. Most of the time I find myself looking at the plain text version in preference. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Numbers again
On 2003-08-22 at 18:39+0200 Konrad Hinsen wrote: I am getting a bit worried about the usability of Haskell for numerical work. The Haskell 98 report states that floating literals are represented as a conversion from Rational, which means that the literal is first converted to a Rational. I can't find anything in the Haskell report that states how this conversion should take place, and to what precision it should be correct. It could be made correct to any precision as Rationals are represented using Integers, but at least Hugs doesn't do that. By experimenting with some particular cases, I found that its internal Rational representation is even less accurate than the precision of Double permits, which means that it is impossible to specify literals to the full precision of Double. GHC behaved fine in my tests. But what can I safely assume from a Haskell implementation? You can safely assume that (as it says in its documentation) Hugs is not suitable for numeric work. proper¹ Haskell implementations ought to use conversions that give the best possible accuracy for the final type. Jón [1] not that Hugs isn't proper, but it's just not designed for that. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: strange behaviour
On 2003-08-11 at 11:44+0200 David Sabel wrote: module Main(main) where import System.IO.Unsafe main = case unsafePerformIO (print test) of () - main ok, probably I use unsafePerformIO in an unsafe way and so on, but executing the program prints infinitely often test on the screen, but I think it would be correct to do so one time? It's correct behaviour to print test any number of times. Haskell is non-strict, which only means that things aren't evaluated unless needed. It's not (defined to be) lazy, which would mean that named expressions would be evaluated at most once (though ghc meets this). It's also not defined to be fully lazy meaning that unnamed expressions would be evaluated at most once in any given closure. So GHC is entirely within its rights to evaluate unsafePerformIO (print test) any number of times, or possible even none, since it knows that that expression always returns the same value (). So you /have/ used it in an unsafe way, and the above discussion illustrates why unsafePerformIO really is completely unsafe. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
Re: Hugs Humor
On 2003-07-08 at 10:15+0200 Jerzy Karczmarczuk wrote: If it's a _Rational_, surely you want it to be exactly the same as you get for 31415926536%100? No. If 'you' means concretely me, then no. Simply no. Writing pi = 3.1415926536 :: Rational and expecting to continue the computations with an exact fraction 31415926536%100, with the well known explosion of Nums Dens seems pragmatically silly. Ah, well, I'd say that writing pi = 3.1415926536 :: Rational is just misleading -- we all know jolly well that pi isn't a rational, so anyone who writes that deserves what they get. Now, if you were to write pi = 3.1415926536 :: Real I'd be happy to argue over just what the conversion is supposed to do. Unfortunately we don't have Real (in libraries as far as I remember -- if you have a continued fraction implementation of it, it ought to go to the libraries list). 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-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Hugs Humor
On 2003-07-07 at 12:01+0200 Jerzy Karczmarczuk wrote: Jon Fairbairn comments //Steffen Mazanek//: Prelude 0.1::Rational 13421773 % 134217728 Prelude 13421773/134217728 0.1 I do not know how this fraction is calculated, but it does not fit my expectations :-) Remember that internally arithmetic is binary, and that 0.1 can't be expressed exactly as a floating point number. I think that's the explanation. I don't understand the remark that the internal arithmetic is binary. Sure, it is, so what? My comment was perhaps too brief. As far as I am concerned, a constant with a decimal point in it should go like this: C.DD...DD \__d__/ becomes fromRational (CDD...DD % 100...00) and there's no problem in getting an accurate Rational (what you say about conversions applies if the desired result is some kind of float). However, if the conversion goes via float, and I think doing that is a bug, the fact that 1/5 has an infinite expansion in binary explains the peculiar numbers that Hugs produces in its Rational. It's an explanation of what happens, not what should be! During the revision of the report I said something to the effect that Int, Float and Double do not belong in the language proper. The suggestion was rejected for (I think) sociological reasons, but I still stand by it. While they should of course be provided in the standard libraries, they only serve to confuse things as far as the language design is concerned. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Hugs Humor
On 2003-07-07 at 13:40+0200 Jerzy Karczmarczuk wrote: [...] I believe (still naïvely??) that those socio-psycho-pragmatisms which played some role in the definition of the language should be better tuned. If I were to write pi = 3.1415926536 :: Rational I suppose that I would like to see rather 355/113 or something close, than 3926990817/125000 or similar. If it's a _Rational_, surely you want it to be exactly the same as you get for 31415926536%100? GHCI doesn't make me happier than Hugs: 221069929751607/70368744177664. That doesn't happen for me: Prelude :m Ratio Prelude Ratio 31415926536%100 3926990817 % 125000 Prelude Ratio 3.1415926536::Rational 3926990817 % 125000 Prelude Ratio What did you do to get it? Thus, perhaps one day we might think about parametrizing the 'conversion' of *explicit* decimal numbers, and -- as some other language permit -- make it possible and practical to use any other base different from 10. What do you think? There might be a use for that, but one can already write 0x55%2^32 so I'm not sure that there would be much call for it, given what I say below Such parametrization (perhaps with some global default) would also help the user who permits himself to write x = 1.875987 :: Rational to assess the error introduced by the representation conversion. I think that decimal number :: Rational ought not to introduce any error at all! As to exact v inexact numbers, in a sense we already have that distinction. Integer and Rational are (in correct implementations!) exact, Int, Float and Double are inexact. One could express my objection to the design as: relegate all inexactitudes to libraries. Cheers, Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Hugs Humor
On 2003-07-05 at 19:43+0200 Steffen Mazanek wrote: Hello, a quit funny hugs session: Prelude 0.5::Rational 1 % 2 Prelude 0.1::Rational 13421773 % 134217728 Prelude 13421773/134217728 0.1 I do not know how this fraction is calculated, but it does not fit my expectations :-) Remember that internally arithmetic is binary, and that 0.1 can't be expressed exactly as a floating point number. I think that's the explanation. Ok, ok, it is no bug... No, I think it is a bug: 0.1 ought to be equivalent to fromRational (1%10), but Hugs isn't intended for numerical work. GHCi gets the right answer. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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: floating point literals
On 2003-03-18 at 12:44EST Dean Herington wrote: Simon Marlow wrote: On Mon, Mar 17, 2003 at 10:33:47AM +, Ross Paterson wrote: GHC doesn't recognize literals like 9e2, and nor does lex. Fixed GHC, I'll leave lex to someone more familiar with the code... Cheers, Simon Forgive me if I'm confused, but I thought 9e2 was supposed to be parsed as two lexemes, 9 and e2. Was, but is no more. The syntax changed during the revision of the standard. Had me confused for a while too. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
loop?
The following module takes an inordinately long time to compile in ghc[i] (5.04): module Y2 where -- define the Y combinator without using built in recursion data Y2 t = Recur (Y2 t - (t - t) - t) y f = y2 (Recur y2) f where y2:: Y2 t - (t - t) - t y2 (Recur y2') f = f (y2' (Recur y2') f) -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: List comprehensions
On 2003-01-30 at 11:08GMT Ross Paterson wrote: On Thu, Jan 30, 2003 at 11:41:49AM +0100, Rijk J. C. van Haaften wrote: Recently, I came accross this expression: [ x + y | x - xs | y - ys ] As far as I can see (Haskell Report), this is not allowed by the haskell 98 standard. So I assume it to be an ex- tension. Where can I find information about this? It's not Haskell 98, but is implemented in GHC and Hugs (with extensions turned on). As far as I can tell ghc 5.04 accepts this without complaint. Is this a bug, or should I pass some argument to turn extensions off? Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: how to debug?
On 2002-10-05 at 18:41EDT David Roundy wrote: How does one debug in haskell? One doesn't. One writes correct code in Haskell ;-b I have already isolated my bug within one function, but that function has somewhat funky recursion, and uses an array (which I'm none too familiar with in haskell), and there aren't any smaller parts that I can see to test. :( More seriously: It seems to me likely that this function is too complicated for your current level of understanding (which probably means it's simply too complicated, full stop). Often, a better approach than trying to debug a function is to break the function into smaller parts using higher levels of abstraction. For example, you say that it involves funky recursion: perhaps it can be rewritten in terms of a fold or similar? In other words, can you abstract out the steps performed at each level of recursion (there may be several different steps depending on conditions)? You say it uses an array: can you use accumArray or accum? If you can break it up like this, it becomes easier to determine whether the individual parts are correct without resorting to debugging. Giving us a skek at the function in question might educe improved advice, too. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Priority of % (Ratio)
If I load ratio and type 2^3%5 into Hugs I get 8 % 5 as I'd expect. If I do the same for ghci, I get an error message, because it's parsed it as 2^(3%5). Prelude Ratio ought to have infixl 7 % (or maybe it should be in GHC.Real), but I can't find it (in either) Which reminds me: please can we have links from http://cvs.haskell.org/ to the various repositories? I can never remember the string of guff (cgi-bin/cvsweb.cgi/) that gets me from there to fptools. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Infix expressions
Ken Shan [EMAIL PROTECTED] wrote: In Haskell, backquotes can be used to convert individual identifiers into infix operators, but not complex expressions. For example, [1,2,3] `zip` [4,5,6] is OK, but not [1,2,3] `zipWith (+)` [4,5,6] Is there any reason other than potential confusion when one of the two backquotes is accidentally omitted? I've often wondered about this myself, but it's difficult to make a pleasant distinction between what's allowed in between `` and an ordinary expression. They can't be the same because you can't nest them. Using a matched pair of quotation marks would work, but then you have the possibility of writing really horrid expressions. In any case, perhaps some people on this mailing list would appreciate the following implementation of infix expressions that Dylan Thurston and I came up with -- as algebraic and perverse as we could manage: infixr 0 -:, :- data Infix f y = f :- y x -:f:- y = x `f` y main = print $ [1,2,3] -: zipWith (+) :- [4,5,6] Yes, I appreciate that! It reminds me of how I got the syntax of Ponder -- which had no predefined operators, not even if -- to work. The trick is that there is no trick. Oh, I think it /is/ a trick :-) Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: weird ghci thing (exception in rdrNameModule)
Hal Daume III [EMAIL PROTECTED] wrote: I have no idea what I did to cause this, but ghci just crapped out on me :) *** Exception: basicTypes/RdrName.lhs:83: Non-exhaustive patterns in function rdrNameModule I've seen this too, but I was trying to pin it down before reporting it. It might be something to do with reloading some (not all) of the current modules and/or command line definitions of functions. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Writing a counter function
Mark Carroll [EMAIL PROTECTED] wrote: On Sun, 30 Jun 2002, Jon Fairbairn wrote: (snip) But there's the rub. It's not beautiful and it doesn't make much sense. I really wish we could get away from the How do I convert this imperative code snippet into Haskell questions into How do I solve this abstract problem? The question as originally posed didn't seem like it particularly needed something imperative though. That largely misses the point. My objection is to the mindset behind the question. the first bit is very similar to, say, counter a = (a, \to_add - counter (a + to_add)) Which looks to me like imperative programming. Indeed, the Monad answer that I posted is imperative programming, it just happens to be done in Haskell. Stepwise transformation of a state is, on some occasions, the right answer to a problem. Unfortunately in this thread we haven't been told what the problem is. The question is of the form how do I make a hammer? when a hammer is rarely the most appropriate tool. That's what I'd like to get away from. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Writing a counter function
Shlomi Fish wrote: No. But I want to generate an irregular series, which I determine the intervals between two consecutive numbers myself. E.g: let (num1, next1) = (counter 5) (num2, next2) = (next1 100) (num3, next3) = (next2 50) in [num1,num2,num3] Will have the numbers [5, 105, 155]. What do you mean by determine? You can write sequence = iterate step_counter 0 if the interval between successive numbers is determined by the current number, or sequence = map f [1..] if it's determined by the index in the sequence. or sequence = map snd $ iterate step_counter (0,-7) step_counter (a,b) = (a+1, f a b) if it depends on both. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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: 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: 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
