On Dec 23, 2007 1:44 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> parseHeader3 :: BS.ByteString -> Maybe (Int, Int)
> parseHeader3 bs = do
>(x, rest) <- BS.readInt $ BS.dropWhile (not . isDigit) bs
>(y, _) <- BS.readInt $ BS.dropWhile (not . isDigit) rest
>return (x, y)
But that versi
On Dec 26, 2007 12:42 PM, Benja Fallenstein <[EMAIL PROTECTED]> wrote:
> parseHeader :: BS.ByteString -> Maybe (Int,Int)
> parseHeader = evalStateT $ liftM2 (,) parseInt parseInt where
> parseInt = StateT $ BS.readInt . BS.dropWhile (not . isDigit)
(oh, I missed Conal's mail which says the sam
On Tue, 25 Dec 2007 13:49:21 +0200, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
Hi Cristian,
Cristian Baboi wrote:
...I finished reading the Haskell Language Report and I noticed that the
class Show and Read are "toys".
Actually, they are not toys at all. They are very useful, and they
do th
Hi,
Are CAF's specified in the Haskell report? I couldn't find them mentioned.
If not, why do all Haskell compilers support them? Is there some paper
which persuaded everyone they were a good idea, or some reference I
could look up?
Thanks
Neil
___
Ha
Hi
> > Are CAF's specified in the Haskell report? I couldn't find them mentioned.
>
> CAF is a term of art. If you define
>
> fred = 2 + 2
>
> that's a CAF.
I should have been more precise with my question. Given the code:
fred = 2 + 2
bob = fred + fred
In a Haskell implementation fred would b
On Wed, 26 Dec 2007 17:16:22 +0200, Neil Mitchell <[EMAIL PROTECTED]>
wrote:
Hi,
Are CAF's specified in the Haskell report? I couldn't find them
mentioned.
If not, why do all Haskell compilers support them? Is there some paper
which persuaded everyone they were a good idea, or some refere
"Neil Mitchell" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Are CAF's specified in the Haskell report? I couldn't find them mentioned.
CAF is a term of art. If you define
fred = 2 + 2
that's a CAF.
> If not, why do all Haskell compilers support them?
How could they not? I'm not sure I understand y
Well I certainly hope the standard defines that both fred and bob will only
be evaluated once, because my programs depend on that :)
Peter
Neil wrote:
> fred = 2 + 2
> bob = fred + fred
> In a Haskell implementation fred would be evaluated once to 4, then
> used twice. The 2+2 would only happen
Steve Lihn gmail.com> writes:
> I do come aross a question while reading the DSL page on Wikipedia.
>
> http://en.wikipedia.org/wiki/Domain-specific_programming_language
>
> In the Disadvantage section (near the end), there is an item -- hard
> or impossible to debug. Can anybody explain why or
Hi Neil,
On Dec 26, 2007 7:16 PM, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Given the code:
>
> fred = 2 + 2
>
> bob = fred + fred
>
> In a Haskell implementation fred would be evaluated once to 4, then
> used twice. The 2+2 would only happen once (ignore defaulting and
> overloaded numerics for
On 12/26/07, Cristian Baboi <[EMAIL PROTECTED]> wrote:
>
> The reason I want to build functions of type String -> (a -> b) is because
> I want to see how far I can get with "functions are first class citizens"
> in Haskell. I thought that if I read the function from an external source,
> there is n
The (extremely enlightening) discussion so far has focused on the
inconsistent (arguably buggy) behavior of [a,b..c] enumeration sugar.
I think it's worth pointing out that the code could also be made to
run by making the drop function strict. I got to thinking, in a
"strictness" debugging scenari
dbenbenn:
> Since it's possible to support laziness for Integer (while still
> avoiding any stack overflow), I think it makes sense to do so. What
> if you have some big complicated program like the following:
>
> x = some big slow computation
> y = [x..]
>
> lots of code
>
> z = length $ take
On 26 Dec 2007, at 12:30 PM, Peter Verswyvelen wrote:
Well I certainly hope the standard defines that both fred and bob
will only
be evaluated once, because my programs depend on that :)
If your programs depend on lazy evaluation, they can't be Haskell
98. Any complete reduction method is
On 12/26/07, Don Stewart <[EMAIL PROTECTED]> wrote:
> Depending on laziness if fine, but depending on undefined strictness semantics
> for particular types is more fragile. Whether Int or Bool or whatever
> type has a strict or lazy accumulator in enumFromTo is entirely
> unspecified -- you can't
Just curious -- how can this be done in Arrows instead of Manad/T? Or can it?
On Dec 26, 2007 6:42 AM, Benja Fallenstein <[EMAIL PROTECTED]> wrote:
> On Dec 23, 2007 1:44 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> > parseHeader3 :: BS.ByteString -> Maybe (Int, Int)
> > parseHeader3 bs = do
> >
>arising from use of `/' at DSLTest.hs:11:14-28
Thanks for the example. I am particularly amazed GHC is complaining at
'/', not '+'. The type mismatch occurs (is reported) at much lower
level. It would be nice if there is a way to bump it up a couple
levels...
On Dec 26, 2007 12:56 PM, B
* Steve Lihn wrote:
> Thanks for the example. I am particularly amazed GHC is complaining at
> '/', not '+'. The type mismatch occurs (is reported) at much lower
> level. It would be nice if there is a way to bump it up a couple
> levels...
Add type signatures for mu and dont_try_this.
___
http://en.wikipedia.org/wiki/First-class_object
The term was coined by Christopher Strachey in the context of “functions
as first-class citizens” in the mid-1960's.[1]
Depending on the language, this can imply:
1. being expressible as an anonymous literal value
2. being storable in variabl
19 matches
Mail list logo
