What's the deal with Clean?
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
 |
What's the deal with Clean?
by Deniz Dogan-3
::
Rate this Message:
Recently there has been a lot of discussion on this list about the
programming language Clean and converting Clean programs to Haskell. Reading the Wikipedia article on the language, I can't really see any major difference between that and Haskell, except for the monads vs. uniqueness types. So what's the deal with Clean? Why is it preferable to Haskell? Why is it not? -- Deniz Dogan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Andrew Coppin
::
Rate this Message:
Deniz Dogan wrote:
> Recently there has been a lot of discussion on this list about the > programming language Clean and converting Clean programs to Haskell. > Reading the Wikipedia article on the language, I can't really see any > major difference between that and Haskell, except for the monads vs. > uniqueness types. > > So what's the deal with Clean? Why is it preferable to Haskell? Why is it not? > As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is notionally very similar to Haskell, but with lots of added clutter, complexity and general ugliness - but it's probably somehow more machine-efficient as a result. (All of which makes the name "Clean" rather ironic, IMHO.) Of course, this is merely the opinion I formed after performing a cursory scan of some of the introductory documentation. I haven't actually seen any code written with it or anything, so my opinion probably doesn't mean a lot... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by David Leimbach
::
Rate this Message:
On Tue, Nov 3, 2009 at 1:37 PM, Andrew Coppin <andrewcoppin@...> wrote:
It's preferable to Haskell in situations where Haskell isn't the best choice. The criteria for that decision is different from problem to problem.
Example: I had to implement a ring buffer, and I wanted the code using it to be written in Haskell. I ended up implementing the buffer in C, and wrapping it in FFI from Haskell because implementing a destructive array in Haskell is kind of unwieldy to someone of my experience level. In Clean, it looks like the uniqueness typing allows for destructive updates in a very controlled manner.
Disciplined Disciple might be interesting to look at here too, but i'm not sure I'd deploy anything with DDC just yet :-) Dave
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
|
|
|
Re: What's the deal with Clean?
by Erik de Castro Lopo-34
::
Rate this Message:
David Leimbach wrote:
> Disciplined Disciple might be interesting to look at here too, but i'm not > sure I'd deploy anything with DDC just yet :-) Indeed. What DDC needs most at the moment is more people working on it. I've fixed a couple of bugs and I'm working on some others, but there are a large chunk of them in the bug tracker which are simply too deep for me with my current level of knowledge. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Stephen Tetley-2
::
Rate this Message:
2009/11/3 Andrew Coppin <andrewcoppin@...>:
> > As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is > notionally very similar to Haskell, but with lots of added clutter, > complexity and general ugliness - but it's probably somehow more > machine-efficient as a result. > > (All of which makes the name "Clean" rather ironic, IMHO.) Ouch - you really could put it the other way round. Clean has very little clutter, though I suppose some people might take offence to it having simple macros (:==), but wait so does GHC via -XCPP... I think Clean had generics before Haskell had Data.Generics, otherwise Haskell generally has more innovation, more people work on Haskell, Haskell's motivation was language research... Clean has far fewer libraries, more people use Haskell... Clean used to be considered faster than Haskell, though I don't know what the situation is now: http://www.haskell.org/pipermail/haskell-cafe/2007-October/033854.html Clean is a very fine language, if I wasn't using Haskell I know what my alternative choice would be. Best wishes Stephen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Evan Laforge
::
Rate this Message:
> So what's the deal with Clean? Why is it preferable to Haskell? Why is it not?
Purely from glancing through the language reference, two things that it looks like clean has that I would love to have in haskell are better records and better arrays. The records don't implement any of the fancy subtyping stuff that the various haskell proposals do, but they have the benefits of a nicer syntax and actually being implemented. Haskell arrays (by which I mean the IArray and MArray interfaces) are, to me at least, really hard to use. From little things like using closed ranges where the rest of the world uses half-open ones and opaque documentation and no consistency between IArray and MArray, to bigger things like how do you insert or delete something. My conclusion, after wrestling with ixmap for 15 minutes, was to convert to a list, concatMap across [(i, a)], convert back to an array, which has the bonus of runtime crashes if you forget an 'i'. Sorry if this turned into a rant about arrays, but it's bothered me for a while :) I think the clean guys got it right when they decided to make good array support an explicit goal. I suppose haskell has since gone a different way with the various array fusion libraries with listlike interfaces, and maybe that's better in the long term. Maybe type families can make a nice interface someday. Meanwhile it's a mess though. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Ben Lippmeier
::
Rate this Message:
David Leimbach wrote:
> Disciplined Disciple might be interesting to look at here too, but i'm > not sure I'd deploy anything with DDC just yet :-) :) Nor would I (and I wrote most of it). I think the approach is right, but the compiler itself is still in the "research prototype" stage. Ben. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by David Leimbach
::
Rate this Message:
On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh <tracy.wadleigh@...> wrote:
Someone suggested that to me on IRC once I'd already cranked out a C implementation with FFI bindings. It's just too easy to use the FFI in Haskell :-)
If we raise the barrier of FFI, more people will use ST! Dave
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by David Leimbach
::
Rate this Message:
On Tue, Nov 3, 2009 at 3:14 PM, Ben Lippmeier <Ben.Lippmeier@...> wrote:
I have to admit, the first time I hit the wiki page for DDC I said to myself "Self, this sounds crazy complicated". Then I read part of the PDF (your thesis I believe) about Region Types on the bus ride to work and thought. "Gee I think I scared myself off too quickly".
Uniqueness typing is quite interesting in Clean, but to control aliasing, like really *control* aliasing, that's just far out man. So I still have to wrap my head around "why this isn't going to get completely out of control" and see why it's all safer than just writing C code but I must say the attention I will be paying to DDC has just gone quite a bit up.
Dave _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Don Stewart-2
::
Rate this Message:
stephen.tetley:
> 2009/11/3 Andrew Coppin <andrewcoppin@...>: > > > > > As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is > > notionally very similar to Haskell, but with lots of added clutter, > > complexity and general ugliness - but it's probably somehow more > > machine-efficient as a result. > > > > (All of which makes the name "Clean" rather ironic, IMHO.) > > Clean used to be considered faster than Haskell, though I don't know > what the situation is now: > http://www.haskell.org/pipermail/haskell-cafe/2007-October/033854.html We've come a long way in 5 years. Haskell is almost always faster on the shootout now. And parallelism goes a long way to helping there: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=clean&box=1 Though this is also true on a single core: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=clean&box=1 It's just a lot closer. Clean continues to have a very small memory footprint. -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by brian denheyer
::
Rate this Message:
Really, arrays in Haskell are the most @#!$! confusing thing in the
world. There's a bunch of different array structures. I can't tell which one works best, and all I want to do is x[i] = value. I thought uvector was the answer, you know, fast unboxed ARRAYs. Imagine my surprise when I saw this indexU :: UA e => UArr e -> Int -> e O(n). indexU extracts an element out of an immutable unboxed array. An array implementation with an order N lookup. huh ?? That's not an array, that's a list. I was looking for an array. However, I then found in the same hackage: readMU :: MUArr e s -> Int -> ST s e O(1). readMU reads the element at the specified index of a mutable unboxed array. So O(1) for mutable, but O(n) for immutable ? See, confusing... I'm sure there's a really good, lofty type safety, something or other reason for that, that I'm sure I don't care about ;-) There's also ST. So why is there a uvector, when there's ST ?? etc, etc, etc... and then there's monads... other than that, having fun with haskell :-) Brian On Nov 3, 2009, at 3:42 PM, David Leimbach wrote: > > > On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh <tracy.wadleigh@... > > wrote: > > I had to implement a ring buffer, and I wanted the code using it to > be written in Haskell. I ended up implementing the buffer in C, and > wrapping it in FFI from Haskell because implementing a destructive > array in Haskell is kind of unwieldy to someone of my experience > level. In Clean, it looks like the uniqueness typing allows for > destructive updates in a very controlled manner. > > The ST monad provides this functionality. The never-instantiated-in- > a-visible-way state parameter of the ST monad provides the > "uniqueness" required for doing destructive updates in a pure way. > > Someone suggested that to me on IRC once I'd already cranked out a C > implementation with FFI bindings. It's just too easy to use the FFI > in Haskell :-) > > If we raise the barrier of FFI, more people will use ST! > > Dave > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Daniel Peebles
::
Rate this Message:
In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on what operations they are paired with. We need to think of a better way to express this behavior in the documentation though. On Tue, Nov 3, 2009 at 9:12 PM, brian <briand@...> wrote: > Really, arrays in Haskell are the most @#!$! confusing thing in the world. > > There's a bunch of different array structures. > > I can't tell which one works best, and all I want to do is x[i] = value. > > I thought uvector was the answer, you know, fast unboxed ARRAYs. Imagine my > surprise when I saw this > > indexU :: UA e => UArr e -> Int -> e > > O(n). indexU extracts an element out of an immutable unboxed array. > > An array implementation with an order N lookup. huh ?? That's not an > array, that's a list. I was looking for an array. > > However, I then found in the same hackage: > > readMU :: MUArr e s -> Int -> ST s e > > O(1). readMU reads the element at the specified index of a mutable unboxed > array. > > So O(1) for mutable, but O(n) for immutable ? See, confusing... I'm sure > there's a really good, lofty type safety, something > or other reason for that, that I'm sure I don't care about ;-) > > There's also ST. So why is there a uvector, when there's ST ?? > > etc, etc, etc... > > and then there's monads... > > other than that, having fun with haskell :-) > > Brian > > > On Nov 3, 2009, at 3:42 PM, David Leimbach wrote: > >> >> >> On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh <tracy.wadleigh@...> >> wrote: >> >> I had to implement a ring buffer, and I wanted the code using it to be >> written in Haskell. I ended up implementing the buffer in C, and wrapping >> it in FFI from Haskell because implementing a destructive array in Haskell >> is kind of unwieldy to someone of my experience level. In Clean, it looks >> like the uniqueness typing allows for destructive updates in a very >> controlled manner. >> >> The ST monad provides this functionality. The >> never-instantiated-in-a-visible-way state parameter of the ST monad provides >> the "uniqueness" required for doing destructive updates in a pure way. >> >> Someone suggested that to me on IRC once I'd already cranked out a C >> implementation with FFI bindings. It's just too easy to use the FFI in >> Haskell :-) >> >> If we raise the barrier of FFI, more people will use ST! >> >> Dave >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@... >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@... >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > http://www.haskell.org/mailman/listinfo/haskell-cafe > Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Roman Leshchinskiy
::
Rate this Message:
On 04/11/2009, at 13:12, brian wrote:
> indexU :: UA e => UArr e -> Int -> e > > O(n). indexU extracts an element out of an immutable unboxed array. This is a typo (unless Don inserted a nop loop into the original DPH code). Roman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by wren ng thornton
::
Rate this Message:
Stephen Tetley wrote:
> 2009/11/3 Andrew Coppin <andrewcoppin@...>: > >> As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is >> notionally very similar to Haskell, but with lots of added clutter, >> complexity and general ugliness - but it's probably somehow more >> machine-efficient as a result. >> >> (All of which makes the name "Clean" rather ironic, IMHO.) > > Ouch - you really could put it the other way round. Part of this really comes down to how one feels about the monads vs uniqueness types argument. It's a silly argument to have since the ideas are orthogonal and only really intersect at IO, but there's history there which lead to the current state of things. Sometimes in Haskell I've thought about how uniqueness typing would make something faster, but in general all the plumbing associated with it in Clean makes me feel like I'm writing systems-level code (i.e. C, asm) instead of using a high-level language. The extra plumbing really makes it feel dirtier to work with. That doesn't mean Clean is bad, but I think it does contribute to the "cluttered" feeling Haskellers get. But as I said, it's a silly argument and folks should use whichever gives them warm fuzzies. I also have a vague unnameable distaste whenever working with Python, and rather enjoy working with Perl. Nobody's perfect :) -- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Roman Leshchinskiy
::
Rate this Message:
On 04/11/2009, at 13:23, Daniel Peebles wrote:
> In the presence of fusion (as is the case in uvector), it's hard to > give meaningful time complexities for operations as they depend on > what operations they are paired with. We need to think of a better way > to express this behavior in the documentation though. I have to disagree here. Fusion never makes the complexity of operations worse. If it does, it's a bug. Roman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by wren ng thornton
::
Rate this Message:
Roman Leshchinskiy wrote:
> On 04/11/2009, at 13:23, Daniel Peebles wrote: > >> In the presence of fusion (as is the case in uvector), it's hard to >> give meaningful time complexities for operations as they depend on >> what operations they are paired with. We need to think of a better way >> to express this behavior in the documentation though. > > I have to disagree here. Fusion never makes the complexity of operations > worse. If it does, it's a bug. I think the point was more that the relevant complexity bound can change in the presence of fusion. For a poor example: the first map over a list is O(n) but all subsequent ones in a chain of maps are O(1) with fusion. I'm sure there are better examples than that, but you get the idea. Some people may care to know about that latter complexity rather than just the "independent" complexity. While this comes up with fusion, it's not a new problem. The same sort of thing is gotten at by distinguishing worst-case vs average-case complexity, or amortized worst-case vs non-amortized wost-case, etc. -- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Don Stewart-2
::
Rate this Message:
briand:
> Really, arrays in Haskell are the most @#!$! confusing thing in the > world. > > There's a bunch of different array structures. > > I can't tell which one works best, and all I want to do is x[i] = value. > > I thought uvector was the answer, you know, fast unboxed ARRAYs. > Imagine my surprise when I saw this > > indexU :: UA e => UArr e -> Int -> e > > O(n). indexU extracts an element out of an immutable unboxed array. Umm.... That's a typo in the docs. Thanks. -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by Gregory Crosswhite-2
::
Rate this Message:
Actually, it's not a typo. If you look at the source, what you'll see
is indexU arr n = indexS (streamU arr) n and then tracking down indexS, you'll see indexS (Stream next s0 _) n0 | n0 < 0 = error "Data.Array.Vector.Stream.indexS: negative index" | otherwise = loop_index n0 s0 where loop_index n s = case next s of Yield x s' | n == 0 -> x | otherwise -> s' `seq` loop_index (n-1) s' Skip s' -> s' `seq` loop_index n s' Done -> error "Data.Array.Vector.Stream.indexS: index too large" So in other words, indexU really does have O(n) complexity since it first converts the array into a stream and then walks down the stream in order to find the desired element. Cheers, Greg On Nov 3, 2009, at 6:25 PM, Roman Leshchinskiy wrote: > On 04/11/2009, at 13:12, brian wrote: > >> indexU :: UA e => UArr e -> Int -> e >> >> O(n). indexU extracts an element out of an immutable unboxed array. > > This is a typo (unless Don inserted a nop loop into the original DPH > code). > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: What's the deal with Clean?
by ajb-2
::
Rate this Message:
G'day all.
Quoting wren ng thornton <wren@...>: > Sometimes in Haskell I've thought about how uniqueness typing would > make something faster, but in general all the plumbing associated with > it in Clean makes me feel like I'm writing systems-level code (i.e. C, > asm) instead of using a high-level language. The extra plumbing really > makes it feel dirtier to work with. That doesn't mean Clean is bad, but > I think it does contribute to the "cluttered" feeling Haskellers get. I think you're right here. Haskell has developed something of an aversion to naming things that aren't important enough to have a name, such as variables whose only reason to exist is "plumbing". We'd far rather spend effort on more higher-order functions, monads, combinators and points-freeness than name something that's unimportant. And the funny thing about this is that it usually works, because in Haskell, abstraction is cheap. I believe that this is the main reason why Haskell programmers haven't embraced arrows, despite their theoretical advantages: Every notation that has been implemented so far requires names for things that shouldn't need names. > But as I said, it's a silly argument and folks should use whichever > gives them warm fuzzies. I'd like to think that professional developers are a bit more scientific than this. Cheers, Andrew Bromage _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
