Hi
I was just wondering what methods are best to design/model the software in
bigger projects when you are planning to use Haskell.
Is there no difference compared to other languages? Are there any Haskell
tools?
Cheers,
Jaco
PS.
"Software design in Haskell" didn't give relevant hits. :(
__
jaco.van.iterson:
> Hi
>
> I was just wondering what methods are best to design/model the software in
> bigger projects when you are planning to use Haskell.
> Is there no difference compared to other languages? Are there any Haskell
> tools?
>
I don't believe anyone has written a "Programming H
On Sun, May 2, 2010 at 4:10 PM, Don Stewart wrote:
> I don't believe anyone has written a "Programming Haskell in the Large"
> book (or any other similar functional language??), but there is lots of
> experience in this community working on big, long lived code bases.
>
> Some key points:
[...]
>
brad.larsen:
> On Sun, May 2, 2010 at 4:10 PM, Don Stewart wrote:
> > I don't believe anyone has written a "Programming Haskell in the Large"
> > book (or any other similar functional language??), but there is lots of
> > experience in this community working on big, long lived code bases.
> >
> >
On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:
> * Avoid partial functions
Why?
Edgar
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 3 May 2010, at 02:18, Edgar Z. Alvarenga wrote:
On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:
* Avoid partial functions
Why?
Tell you tomorrow.
Conor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/
On 3 May 2010 11:18, Edgar Z. Alvarenga wrote:
> On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:
>
>> * Avoid partial functions
>
> Why?
What does "head []" do again?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
_
On Sun, May 2, 2010 at 9:18 PM, Edgar Z. Alvarenga wrote:
> On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:
>
>> * Avoid partial functions
>
> Why?
>
> Edgar
Ever place you use a partial function, you need to verify that its
usage is in fact safe. Otherwise, you risk pattern match fai
I'm a little confused about this too. I've seen many functions defined like:
f x = (\s -> ...)
which is a partial function because it returns a function and is the same as:
f x s = ...
Off the top of my head the State monad makes extensive use if this
style. Is this bad?
- deech
On 5/2/10, B
On 3 May 2010 14:17, aditya siram wrote:
> I'm a little confused about this too. I've seen many functions defined like:
> f x = (\s -> ...)
> which is a partial function because it returns a function and is the same as:
> f x s = ...
No, that's a partially applied function.
A partial function is
Cool. That makes way more sense.
I thought that ghc -Wall picked these up. So at least this problem
would go away if warnings were turned on (and heeded) by default.
Besides that from my own experience I'd strongly encourage people to
use HLint [1] .
-deech
[1 ] http://hackage.haskell.org/packa
I missed the part where you talked about -Wall. Sorry.
On 5/3/10, aditya siram wrote:
> Cool. That makes way more sense.
>
> I thought that ghc -Wall picked these up. So at least this problem
> would go away if warnings were turned on (and heeded) by default.
>
> Besides that from my own experien
On Sun, May 2, 2010 at 9:24 PM, Ivan Miljenovic
wrote:
> On 3 May 2010 14:17, aditya siram wrote:
>> I'm a little confused about this too. I've seen many functions defined like:
>> f x = (\s -> ...)
>> which is a partial function because it returns a function and is the same as:
>> f x s = ...
>
On 3 May 2010 14:35, Alexander Dunlap wrote:
> Of course, there are situations where it is really awkward to not use
> partial functions, basically because you *know* that an invariant is
> satisfied and there is no sane course of action if it isn't.
True, like "map head . group".
--
Ivan Lazar
On May 3, 2010, at 6:35 AM, Alexander Dunlap wrote:
Of course, there are situations where it is really awkward to not use
partial functions, basically because you *know* that an invariant is
satisfied
That falls under Don's: "Use types to encode the design into a machine
checkable form"
O
G'day all.
Quoting aditya siram :
I'm a little confused about this too. I've seen many functions defined like:
f x = (\s -> ...)
which is a partial function because it returns a function and is the same as:
f x s = ...
Off the top of my head the State monad makes extensive use if this
style. I
On 03/05/2010, at 06:02, Jaco van Iterson wrote:
> I was just wondering what methods are best to design/model the software in
> bigger projects when you are planning to use Haskell.
> Is there no difference compared to other languages? Are there any Haskell
> tools?
In addition to what Don said
Ivan Miljenovic disse:
> On 3 May 2010 14:17, aditya siram wrote:
>> I'm a little confused about this too. I've seen many functions defined like:
>> f x = (\s -> ...)
>> which is a partial function because it returns a function and is the same as:
>> f x s = ...
>
> No, that's a partially applied
There are many ways to handle errors in Haskell.
The Maybe method is the simplest but it also comes with a little overhead,
since you always have to unpack the Maybe a value return, and finally I
often end up by doing something like :
maybe (error "Unexpected Nothing") id someSafeFunction
when you
Don Stewart writes:
> Some key points:
>
> * Avoid partial functions
As an important corollary to this one I would add: "never throw
exceptions from pure code". They often leak out from "catch" blocks and
ruin your day.
G
--
Gregory Collins
___
On Mon, 3 May 2010, Gregory Collins wrote:
Don Stewart writes:
Some key points:
* Avoid partial functions
As an important corollary to this one I would add: "never throw
exceptions from pure code". They often leak out from "catch" blocks and
ruin your day.
It's not possible to throw
Henning Thielemann writes:
> It's not possible to throw exceptions from pure code. You can only
> call 'error' and that's another name for 'undefined', i.e. you have a
> partial (non-total ?) function.
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#v%3
Gregory Collins schrieb:
> Henning Thielemann writes:
>
>> It's not possible to throw exceptions from pure code. You can only
>> call 'error' and that's another name for 'undefined', i.e. you have a
>> partial (non-total ?) function.
>
> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/bas
Henning Thielemann writes:
>> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#v%3Athrow
> I see. This should be forbidden, at all! :-)
Why is this worse than or different from 'error'? To me it looks like
'error', only with a non-string parameter.
-k
Ketil Malde schrieb:
> Henning Thielemann writes:
>
>>> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#v%3Athrow
>
>> I see. This should be forbidden, at all! :-)
>
> Why is this worse than or different from 'error'? To me it looks like
> 'error', onl
Ketil Malde writes:
> Henning Thielemann writes:
>
>>> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#v%3Athrow
>
>> I see. This should be forbidden, at all! :-)
>
> Why is this worse than or different from 'error'? To me it looks like
> 'error', only
Gregory Collins writes:
>> Henning Thielemann writes:
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#v%3Athrow
>>> I see. This should be forbidden, at all! :-)
>> Why is this worse than or different from 'error'? To me it looks like
>> 'error',
> From: Rafael Cunha de Almeida
>
> Ivan Miljenovic disse:
>> On 3 May 2010 14:17, aditya siram wrote:
>>> I'm a little confused about this too. I've seen many functions defined like:
>>> f x = (\s -> ...)
>>> which is a partial function because it returns a function and is the same
>>> as:
>>>
2010/5/4 John Lato
> "Crashing at the point of the error" isn't necessarily useful in
> Haskell due to lazy evaluation. The code will crash when the result
> of the partial function is evaluated, which may be quite far away (in
> terms of function calls) from where the programmer would expect.
>
On Tue, May 4, 2010 at 9:09 AM, Limestraël wrote:
> Are there other methods than Maybe or exceptions to handle the errors in
> Haskell? Is the monad Error(T) useful?
I believe the usual Error monad is just (Either e), with Left
indicating failure. It's the same idea as Maybe, only returning
infor
On Tue, May 4, 2010 at 2:09 PM, Limestraël wrote:
> 2010/5/4 John Lato
>>
>> "Crashing at the point of the error" isn't necessarily useful in
>> Haskell due to lazy evaluation. The code will crash when the result
>> of the partial function is evaluated, which may be quite far away (in
>> terms o
On May 4, 2010, at 5:22 AM, John Lato wrote:
> The reason people argue for safeSecondElement over secondElement is
> exactly the reason you argue against it. Calling safeSecondElement on
> a list with < 2 elements forces the programmer to handle the result
> immediately by returning a Maybe, whic
On Tue, May 4, 2010 at 5:31 PM, Gregory Crosswhite
wrote:
>
> Yes, but I think that it is also important to distinguish between cases where
> an error is expected to be able to occur at runtime, and cases where an error
> could only occur at runtime *if the programmer screwed up*. If you struct
This whole thing seems to be touching on something I saw recently and was
quite interested in. I found a site talking about static contract checking
in Haskell, unfortunately I can't seem to find it now, but this paper (
http://research.microsoft.com/en-us/um/people/simonpj/papers/verify/haskellcon
I definitely like that idea. :-) Is this similar to the notion of dependent
types?
Cheers,
Greg
On May 4, 2010, at 11:21 AM, Kyle Murphy wrote:
> This whole thing seems to be touching on something I saw recently and was
> quite interested in. I found a site talking about static contract che
On Tue, May 4, 2010 at 2:43 PM, Gregory Crosswhite
wrote:
> I definitely like that idea. :-) Is this similar to the notion of
> dependent types?
That's where things tend to wind up eventually, yes. Although, with
Haskell as it stands, a great deal of unused information is already
present outsid
The papers are available here: http://gallium.inria.fr/~naxu/pub.html
But in general you can say things like the following:
(Dana Xu uses a slightly different notation that I can never remember).
sorted :: Ord a => [a] -> Bool
> sorted [] = True
> sorted [x] = True
> sorted (x:xs) = x < head xs
This is awesome! GHC-devs , please mainline the CONTRACT pragma.
-deech
On 5/4/10, Edward Kmett wrote:
> The papers are available here: http://gallium.inria.fr/~naxu/pub.html
>
> But in general you can say things like the following:
>
> (Dana Xu uses a slightly different notation that I can never
> "aditya" == aditya siram writes:
aditya> This is awesome! GHC-devs , please mainline the CONTRACT
aditya> pragma.
I think it needs a LOT more work before it is usable. (I hope I'm wrong,
but Dana reckoned it needed about 7 more man-years of work.)
Dana sent me a copy of her ghc 6
* On Sunday, May 02 2010, Alexander Dunlap wrote:
>Of course, there are situations where it is really awkward to not use
>partial functions, basically because you *know* that an invariant is
>satisfied and there is no sane course of action if it isn't. To take a
>contrived example:
>
>f ys = let x
On May 3, 2010, at 12:14 , Henning Thielemann wrote:
Ketil Malde schrieb:
Henning Thielemann writes:
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#v%3Athrow
I see. This should be forbidden, at all! :-)
Why is this worse than or different from 'e
On May 4, 2010, at 12:31 , Gregory Crosswhite wrote:
On May 4, 2010, at 5:22 AM, John Lato wrote:
"Crashing at the point of the error" isn't necessarily useful in
Haskell due to lazy evaluation. The code will crash when the result
of the partial function is evaluated, which may be quite far awa
Rafael Cunha de Almeida wrote:
I don't think that safeSecondElement is worse than secondElement. I think it's
better for the program to crash right away when you try to do something that
doesn't make sense.
Getting the secondElement of a list with one or less elements doesn't make
sense, so you
Gregory Crosswhite wrote:
Yes, but I think that it is also important to distinguish between cases
where an error is expected to be able to occur at runtime, and cases
where an error could only occur at runtime *if the programmer screwed up*.
Well sure, but how can you demonstrate that you (the
On May 9, 2010, at 1:04 AM, wren ng thornton wrote:
> If you're structuring your code with that invariant, then why aren't you
> using the correct type?
I do try to use the type system as much as possible to enforce constraints.
However. it is not always so simple as making sure that a list a
45 matches
Mail list logo
