[Haskell-cafe] Re: ANN: Bookshelf
Emil Axelsson e...@chalmers.se writes: This is the first release of Bookshelf, a simple document organizer with some wiki functionality. Documents in a directory tree are displayed as a set of HTML pages. Documents in Markdown format are converted to HTML automatically using Pandoc. The manual http://www.cs.chalmers.se/~emax/bookshelf/Manual.shelf.html describes the full functionality. It would probably be a good idea to include the markdown functionality in your demonstration, since it's one of the more interesting features. This looks pretty neat though, good work! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: runhaskell CLI parameters
Vasili I. Galchin vigalc...@gmail.com writes: Hello, I have forgotten the runhaskell CLI parameters ... sigh. In particular I want to a local build of a set of of package: runhaskell Setup.hs configure --user??? I just did a runhaskell -? which didn't tell me a lot! Try runhaskell Setup.hs --help. runhaskell's help isn't very useful here, because the program you're interested in is actually Setup.hs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Indentation Question.
Ramaswamy, Vivek vivek.ramasw...@fmr.com writes:
Hello All~
I have been reading the book ?Haskell for real programmers? and am presently
on
chapter 03.
There was a small program demonstrated by the author on ?let?. The problem is
that when I cut and paste authors code into eclipse, the program works fine,
where as when I write my own copy of the program I am getting an error. I
figured out that when I remove the function any one function lend or bend, the
file compiles and runs fine.
My question is why does the Haskell compiler complains, in the case 2
functions
with the same signature and logic, even though their names are different.
module Lending where
{-- snippet lend --}
lend amount balance = let reserve= 100
newBalance = balance - amount
in if balance reserve
then Nothing
else Just newBalance
{-- /snippet lend --}
bend amount balance = let reserver = 100
newBalance=balance-amount
The problem is here
each element in a let clause should be indented to the same level, that
is
let foo = bar
baz = qux
is legal. foo and baz are both defined. But
let foo = bar
baz = qux
is not legal, the compiler thinks baz = qux is part of the statement
`foo = bar`, like `foo = bar baz = qux`. Also
let foo = bar
baz = qux
is not legal, since the compiler thinks the let clause is over and
expects the keyword `in`
in if balance reserver
then Nothing
else Just newBalance
Regards
-Vivek Ramaswamy-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Control.Arrow being icky
Louis Wasserman wasserman.lo...@gmail.com writes: In GHCi, I import Control.Arrow, and Kliesli doesn't appear: Prelude Control.Arrow :t Kliesli interactive:1:0: Not in scope: data constructor `Kliesli' It's spelled `Kleisli' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: evaluation semantics of bind
Gregg Reynolds d...@mobileink.com writes: I think I've just about got monads figured out, but there's one detail that still escapes me. As I understand it, a monad is a kind of programming trick the uses data dependency to force evaluation order. x = f means apply f to x; since the value of f x depends on the value of x, the evaluator must evaluate x before f x. However, consider: getChar = \x - getChar x = f does not mean apply f to x, it means do x, and then do f with the result of x. Bind is a sequencing operator rather than an application operator. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: evaluation semantics of bind
Oops, sent this off list the first time, here it is again. Jake McArthur j...@pikewerks.com writes: m...@justinbogner.com wrote: | Bind is a sequencing operator rather than an application operator. In my opinion, this is a common misconception. I think that bind would be nicer if its arguments were reversed. If this is a misconception, why does thinking of it this way work so well? This idea is reinforced by the do notation syntactic sugar: bind can be represented by going into imperative land and doing one thing before another. The fact that `x' may not actually have to happen before `f' is merely the typical sort of optimization we do in compilers for imperative languages: instructions that do not modify non-local state can be re-ordered, but IO cannot because it jumps elsewhere, no? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind)
Jake McArthur j...@pikewerks.com writes: m...@justinbogner.com wrote: | Oops, sent this off list the first time, here it is again. | | Jake McArthur j...@pikewerks.com writes: | m...@justinbogner.com wrote: | | Bind is a sequencing operator rather than an application operator. | | In my opinion, this is a common misconception. I think that bind would | be nicer if its arguments were reversed. | | If this is a misconception, why does thinking of it this way work so | well? This idea is reinforced by the do notation syntactic sugar: bind | can be represented by going into imperative land and doing one thing | before another. An imperative-looking notation does not make something imperative. Thinking of bind as sequencing really *doesn't* work very well. What does bind have to do with sequencing at all in the list monad, for example? What about the reader monad? - Jake What doesn't bind have to do with sequencing in the list monad? Consider: [1..2] = ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind)
Jake McArthur j...@pikewerks.com writes: m...@justinbogner.com wrote: | Oops, sent this off list the first time, here it is again. | | Jake McArthur j...@pikewerks.com writes: | m...@justinbogner.com wrote: | | Bind is a sequencing operator rather than an application operator. | | In my opinion, this is a common misconception. I think that bind would | be nicer if its arguments were reversed. | | If this is a misconception, why does thinking of it this way work so | well? This idea is reinforced by the do notation syntactic sugar: bind | can be represented by going into imperative land and doing one thing | before another. An imperative-looking notation does not make something imperative. Thinking of bind as sequencing really *doesn't* work very well. What does bind have to do with sequencing at all in the list monad, for example? What about the reader monad? - Jake What doesn't bind have to do with sequencing in the list monad? Consider: [1..2] = return . (^2) This says generate the list [1..2] and then use it to generate a list of squares. It's more than just application, it's a description of a sequence of actions. The whole point of list comprehensions (which is the only reason to have a list monad, as far as I know) is to think of it this way rather than as an application of concatMap. As for Reader, I don't know enough about it to say anything. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Bind as a sequencing operator
Jake McArthur j...@pikewerks.com writes: The problem with your description is that you said and then. The result will be generated lazily. There is no sequencing here. Consider: ~do x - [0..] ~ y - [0..9] ~ return (x, y) Which list is generated first? This is an implementation detail, since y has no dependency on x the compiler's free to reorder instructions, as it would be an imperative language. Semantically this means do x and then y, since if y is changed to depend on x, this is still valid, but if x is changed to depend on y, this sequence is not valid. Just because the compiler is allowed (and even encouraged) to change the sequence where that won't change the results, considering this a sequence is still valid and meaningful. | As for Reader, I don't know enough about it to say anything. Reader provides an immutable value that can be retrieved at any point in the monad. There are no monadic side effects, so it doesn't really mean much to say that anything happens in any particular order. It still needs to be retrieved (logically, not necessarily temporally) before it's used, doesn't it? - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Bind as a sequencing operator
Jake McArthur j...@pikewerks.com writes: | Just because the compiler is allowed (and even encouraged) to change the | sequence where that won't change the results, considering this a | sequence is still valid and meaningful. It can be helpful sometimes, but I don't think it should be the standard way to think of bind. There are too many cases when it makes little sense as a sequencing operator. Fair enough, thanks for your thoughts! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
John Goerzen jgoer...@complete.org writes: Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in any other programming language. Instead of Wikipedia, why not try a dictionary? Looking up monoid using dictionary.com: An operator * and a value x form a monoid if * is associative and x is its left and right identity. On the other hand, appendable doesn't seem to be a word, and while you can infer that it means something that can be appended to, that's only half of the story... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Ross Mellgren rmm-hask...@z.odi.ac writes: Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. I second this, many of the docs are sorely lacking examples (and there are of course docs that simply reference a paper, which is usually too long to be helpful in the short term...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Lennart Augustsson lenn...@augustsson.net writes: By no means do I suggest that Wikipedia should replace Haskell library documentation. I think the libraries should be documented in a mostly stand-alone way (i.e., no references to old papers etc.). In the case of Monoid, a few lines of text is enough to convey the meaning of it and gives an example. I don't think references to old papers are a bad thing (they might be good papers), but such references should certainly not be a replacement for a brief explanation and helpful example! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Logos of Other Languages
Ashley Yakeley ash...@semantic.org writes: All of these get one thing right that the current and most of the proposed Haskell logos do not: they don't make any reference to the syntax of the language itself. Doing so seems to miss the point of a logo: it's supposed to appeal visually, rather than semantically. So I'd like to see some submissions that don't use lambdas. All of these, in fact, make absolutely no reference to any part of the language itself, other than the title. Should we then use a portrait of Haskell Curry as the logo? I have no problem with a logo that doesn't have a lambda, but I don't think the fact that using a lambda is (almost) putting syntax in a logo should be considered a problem. An homage to syntax at least gives an easily recognizable icon, far more iconic than a camel or a grid of colours, and I would consider several of the lambda based ideas on the wiki simple, elegant and visually appealing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Time for a new logo?
Darrin Thompson darri...@gmail.com writes: \\ \\ \\ \\ \| \\ \\ --- \\ \\ // / \ // / \ \| // / /\\ --- // / / \\ +1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Time for a new logo?
George Pollard por...@porg.es writes: On Wed, 2008-12-17 at 02:47 +, Jeff Wheeler wrote: I love this ASCII-art version. I tried to make a vector version of it in Photoshop, and I came up with this [1] and [2]. Any critiques/suggestions? I'm thinking about a second version that more obviously defines the second '' with color from the bottom-right part of the lambda. Jeff Wheeler [1]: http://media.nokrev.com/junk/haskell-logos/logo1.png [2]: http://media.nokrev.com/junk/haskell-logos/logo2.png I like the first version better. :) I'd suggest making the lambda/arrow a bit straighter and beefing up the size of the equals in relation to the rest of the symbol :) I also like the first better. If the equals was ever so slightly wider, it would be absolutely perfect. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cabal
Don Stewart [EMAIL PROTECTED] writes: I'm a fan of gitit, and its 46 dependencies, that install via cabal-install. Pretty awesome. gitit's 46 dependencies convinced me to install cabal-install, and now I couldn't be happier! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: '#' in literate haskell
sam lee [EMAIL PROTECTED] writes: # is significant because it can be sh-bang line or pre-processor. This seems like it should be a bug, sha-bangs are unambiguous and the problem still occurs if compiled via `ghc -XNoCPP`. Regardless, I personally prefer the other sort of title in pandoc anyways, like A Title --- -- BOFH excuse #51: Cosmic ray particles crashed through the hard disk platter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to translate Haskell to other languages?
Jason Dagit [EMAIL PROTECTED] writes: I don't recall if I mentioned this in my original email. My goal is to do automatic translations. So, no you can't partially apply zipWith, but then that's because Python doesn't support partial application. On the other hand, you can easily use a lambda to get around this. So in an automatic translation I would replace partial application with lambdas. This shouldn't be a problem right? Partial application can be done in python, though somewhat awkwardly. Take a look at functools.partial. -- Green's Law of Debate: Anything is possible if you don't know what you're talking about. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] mailman issue
Sent: Friday, December 09, 2005 3:59 PM On Fri, Dec 09, 2005 at 05:49:15AM +0100, [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 09:59:25PM +0100, [EMAIL PROTECTED] wrote: p.s.: Strangely, Tomasz's reply again appears as being sent from my address in the archive. Anyone knows why? Maybe mailman is somehow confused by this weird address: xoxy = haskell-cafe [EMAIL PROTECTED] ? Relevant headers of this message: [...] Looks like gourmet.spamgourmet.com resends to haskell-cafe@haskell.org messages addressed to [EMAIL PROTECTED] as if they were send from [EMAIL PROTECTED] That is right. Apparently, there is something going wrong with carbon copies at the forwarding service. I couldn't reach the provider yet, so for the time being, I won't use the Cc field here anymore. To avoid further confusion, please, refrain from using the forwarding address (i. e. the lengthy one, containing many funny signs and numbers) as destination of your posts, be it in the To or in the Cc field. My address to reply or send a Cc to is just [EMAIL PROTECTED] . Thanks, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- Original Message - From: Wolfgang Jeltsch - [EMAIL PROTECTED] Sent: Thursday, December 08, 2005 6:13 PM I thought that the original question was about using some kind of uniqueness type system at an intermediate stage during compiling. Haskell would still have no uniqueness types but the compiler would infer uniqueness types internally and use the uniqueness information it gets from this. Right, that's what I was having in mind. See also http://www.haskell.org/pipermail/haskell-cafe/2005-December/012625.html Regards, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- Original Message - From: Tomasz Zielonka - [EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 8:53 PM Clean-like _explicit_ uniqueness typing is not what I'm asking for in Haskell. So you want implicit, automatically inferred uniqueness typing - something that would be even more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) Maybe it's just my lacking insight, but why should uniqueness inferring be all that fragile? A uniqueness checker can be rather robust, as is demonstrated by the Clean one, so all we'd have to worry about is how to find a good set of supposedly unique node candidates to suggest to the checker. (It certainly would not work well the dumb way, like, trying every single combination out of n^2 possibilities, where n is the total node count.) Whatever suggestion gets through the uniqueness checker, the resulting code can't be consuming more space, slower, or otherwise worse than the one without reusing unique nodes, can it? On the other hand, performance gains thereby seem likely to me. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! errr..., could you give me some clue how you'd expect automatically uniqueness detection to deteriorate your coding style? I, for one, don't define elegance in terms of not running too fast. ;) I don't feel very comfortable either with the impact _explicit_ uniqueness attributing has on the ease of coding. Anyway, I am not arguing pro Clean but pro compile time sharing analysis here. To be honest, your reply feels like a counterpart to the likewise questionable monad avoidance in Clean. Regards, zooloo p. s.: Anyone knows what makes your cited mail appear in the list archive as beeing sent from my address? The copy I got to my mailbox is ok. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- Original Message - From: Tomasz Zielonka - [EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 8:53 PM Clean-like _explicit_ uniqueness typing is not what I'm asking for in Haskell. So you want implicit, automatically inferred uniqueness typing - something that would be even more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) Why should inferring uniqueness be all that fragile? A uniqueness checker can be rather robust, as is demonstrated by the Clean one. Maybe I'm lacking insight, but to me it seems that all we'd have to worry about is how to find a good set of supposedly unique node candidates to suggest to the checker. (It certainly would not work well the dumb way, like, trying every single combination out of n^2 possibilities, where n is the total node count.) Whatever suggestion gets through the uniqueness checker, the resulting code can't be consuming more space, slower, or otherwise worse than the one without reusing unique nodes, can it? On the other hand, performance gains thereby seem likely to me. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! errr..., could you give me some clue how you'd expect automatically uniqueness detection to deteriorate your coding style? I, for one, don't define elegance in terms of not running too fast. ;) I don't feel very comfortable either with the impact _explicit_ uniqueness attributing has on the ease of coding. Anyway, I am not arguing pro Clean but pro compile time sharing analysis here. To be honest, your reply feels like a counterpart to the likewise questionable monad avoidance in Clean. Regards, zooloo p.s.: Anyone knows what makes your (Tomasz's) cited mail appear in the list archive as beeing sent from my address? The copy I got to my mailbox correctly shows you as the sender. p.p.s.: I've sent this mail a second time because the first one got lost somehow - hopefully, it doesn't show up again. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
On Thu, Dec 08, 2005 at 06:38:53PM +0100, [EMAIL PROTECTED] wrote: - Original Message - From: Tomasz Zielonka - [EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 8:53 PM Clean-like _explicit_ uniqueness typing is not what I'm asking for in Haskell. So you want implicit, automatically inferred uniqueness typing - something that would be even more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) Why should inferring uniqueness be all that fragile? It's just that I automatically thought about how uniqueness typing is used in Clean, expecially as a way to achieve O(1) array update. It would be nice if Haskell could infer that an *immutable* array given as parameter to an update operation (like. //) can be reused to create the result effectively. But if you wrote code with such an optimisation in mind, you could be very disappointed with performance if the compiler didn't perform the optimisation. I think that in the case of arrays I would still prefer to use mutable arrays to be sure that my program has the desired asymptotic complexity. Maybe you didn't intend to propose it for arrays? It would be fine to use your idea for smaller, constant-size things, like records, etc, just to reduce the constant factor. A uniqueness checker can be rather robust, as is demonstrated by the Clean one. In Clean there is no surprise, because this optimisation is part of the type system, it's part of the language definition. Whatever suggestion gets through the uniqueness checker, the resulting code can't be consuming more space, slower, or otherwise worse than the one without reusing unique nodes, can it? It can be slower than the programmer expects, in terms of asymptotic complexity. So this feature could be difficult to use to create reliable, efficient code. Of course, unpredictabile efficiency of Haskell programs is not a new problem. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! errr..., could you give me some clue how you'd expect automatically uniqueness detection to deteriorate your coding style? I, for one, don't define elegance in terms of not running too fast. ;) I was referring to UT as in Clean, not to automatic UT you propose. You said Clean sort of gives it for granted, with it = extremely fast code. I don't yet know a language which _grants_ extremely fast code without being more low-level. OK, I am nitpicking ;-) To be honest, your reply feels like a counterpart to the likewise questionable monad avoidance in Clean. My english understanding skills failed me here. Could you expand this sentence using simpler words? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- Original Message - From: Duncan Coutts - [EMAIL PROTECTED] Sent: Thursday, December 08, 2005 9:09 PM On Thu, 2005-12-08 at 11:29 -0800, Jeremy Shaw wrote: The only case it is a benefit is when it accidentally happens and it's just a bonus, but in that case you never needed the optimisation it in the first place. If you prefer consistently slower code to accidentilly faster one, you can still turn off the optimisations of your choice. :) We already have this issue in Haskell with strictness. This holds for nearly every automatical optimisation, doesn't it? So if it were easy to find out the uniqueness that the compiler was inferring then it might actually be useful to people that it did such an inference. Since in that case they would be able to check that it was actually kicking in and modify their code if it were not. You would also want to be able to ask the questions why is it not unique here when I expect it to be, just like the compiler currently answers our question of why the type is not what we expect it to be at some place in the program. Duncan I couldn't agree more. Regards, zooloo p.s.: Strangely, Tomasz's reply again appears as being sent from my address in the archive. Anyone knows why? p.p.s: At least as weirdly, the first version of my duplicated mail unexpectedly _has_ shown up again (after more than 5 hours), whilst another, later message of mine was posted within minutes! Sorry everyone for the inconvenience. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- Original Message - From: Jan-Willem Maessen - [EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 2:21 PM Wearing my Fortress language designer hat, we've given serious thought to these techniques for very large arrays. Copying such structures is terribly expensive, or even impossible (imagine copying a 1PB array). That's slightly beyond the size of arrays I am currently dealing with. ;) I can see that in-place updating is of utmost importance in such cases. However, I was actually thinking of something the Clean people call garbage collection at compile time, which, as far as I can see, involves no runtime overhead at all (Clean Language Report 2.1, section 9.1. - ftp://ftp.cs.kun.nl/pub/Clean/Clean20/doc/CleanLangRep.2.1.pdf). I don't quite see why it should be necessary to specify uniqueness attributes explicitely (as it mostly is in Clean), if the type checker knows the coercion laws better than me, anyway. Hence, my question about automatically deriving uniqueness properties of tokens, to the greatest extent safely feasible at compile time. (Sorry, if this is all trivial and already implemented in ghc. As indicated, I am merely learning Haskell, and I haven't spent any mentionable time yet to understand compiler intestines.) Regards, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- Original Message - From: Tomasz Zielonka - [EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 9:18 PM We can get similar performance from Haskell using various features of GHC (unboxed arrays, mutable arrays, ST monad, soon SMP, etc) and one can argue that they are even nicer. I liked the concept of UT in Clean, but I haven't ever got comfortable with using it to write real programs. Clean-like _explicit_ uniqueness typing is not what I'm asking for in Haskell. I think the biggest obstacle is that almost nobody asks for it. Well, you asked, but how much Haskell code did you write to be sure that you really need it? Indeed, my own experience is too limited to really compare. However, the latest ghc survey, http://haskell.org/ghc/survey2005-summary.html suggests that Performance of compiled code is a top issue to others, too. OC, this involves various aspects, with memory usage being only one of them. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). In the debian shootout, http://shootout.alioth.debian.org/benchmark.php?test=alllang=ghclang2=clean, programs generated by ghc generally need multiples of time and space of the Clean version, even though the latter is, in many cases, a nearly literal translation from Haskell. I know, all this is not representative. Anyway, it may serve as motivation for my question (or suggestion). Regards, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
On Wed, Dec 07, 2005 at 05:59:55PM +0100, [EMAIL PROTECTED] wrote: I liked the concept of UT in Clean, but I haven't ever got comfortable with using it to write real programs. Clean-like _explicit_ uniqueness typing is not what I'm asking for in Haskell. So you want implicit, automatically inferred uniqueness typing - something that would be even more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
Hi all, being occupied with learning both languages, I'm getting curious if Haskell couldn't achieve most of the performance gains resulting from uniqueness typing in Clean by *automatically* determining the reference count of arguments wherever possible and subsequently allowing them to be physically replaced immediately by (the corresponding part of) the function's result. Are there any principal obstacles, or *could* this be done, or *is* this even done already, e. g. in ghc? Regards, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch upwith Clean's uniqueness typing?
From: Shae Matijs Erisson - [EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 6:16 PM [EMAIL PROTECTED] writes: being occupied with learning both languages, I'm getting curious if Haskell couldn't achieve most of the performance gains resulting from uniqueness typing in Clean by *automatically* determining the reference count of arguments wherever possible and subsequently allowing them to be physically replaced immediately by (the corresponding part of) the function's result. Are there any principal obstacles, or *could* this be done, or *is* this even done already, e. g. in ghc? Maybe you're describing speculative evaluation? Optimistic Evaluation: An Adaptive Evaluation Strategy for Non-Strict Programs http://citeseer.ist.psu.edu/ennals03optimistic.html -- Thanks for the pointer - I have heard a little about optimistic evaluation already, but don't know much of the details (yet). Anyway, from what I know, I think it's a different thing. In Clean, you can (and often are required to) assign uniqueness attributes to some parts of a function's type signature. The extended type checker ensures that none of those parts is referred to more than once during a single run of the program. Based on this guarantee, a function does not have to allocate new memory at all to store a unique result but can overwrite the unique arguments in place. Apparently, the uniqueness assignments have to comply with very tight laws - getting a program through the Clean type checker can be tough, once it reports an uniqueness coercion error. I suppose, no explicit uniqueness attributing is going to be implemented in Haskell, anyway. My question is - and this might better suit to Haskell -, can't uniqueness be inferred (and exploited) automatically in many cases? Regards, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
