Could someone please explain what the difference (if any!), in semantics
is between
class Foo f = Bar f g where
method1 :: f a - g a
and
class Bar' g where
method2 :: Foo f = f a - g a
? Maybe the translation of the above to something lower level might
help. [Note: f a - g a is just
* Jacques Carette care...@mcmaster.ca [2013-09-18 08:21:51-0400]
Could someone please explain what the difference (if any!), in
semantics is between
class Foo f = Bar f g where
method1 :: f a - g a
and
class Bar' g where
method2 :: Foo f = f a - g a
Bar is more flexible than
On 13-09-18 08:54 AM, Roman Cheplyaka wrote:
* Jacques Carette care...@mcmaster.ca [2013-09-18 08:21:51-0400]
Could someone please explain what the difference (if any!), in
semantics is between
class Foo f = Bar f g where
method1 :: f a - g a
and
class Bar' g where
method2 :: Foo f = f
On 3/09/2013, at 5:17 PM, damodar kulkarni wrote:
I didn't want to clutter that thread so I am asking a question here.
Where do I find foundational and/or other good references on the topic of
stream interface vs string interface to convert objects to text? I tried
google but failed
.
Where do I find foundational and/or other good references on the topic
of stream interface vs string interface to convert objects to text? I
tried google but failed.
It has to do with the cost of string concatenation.
Let's take a simple thing.
A Set of Strings.
Smalltalk has
String
For lazy I/O, using shows in Haskell is a good analogue of using
#printOn: in Smalltalk. The basic form is include this as PART of
a stream, with convert this to a whole string as a derived form.
What the equivalent of this would be for Iteratees I don't yet
understand.
Why not to try
want to clutter that thread so I am asking a question here.
Where do I find foundational and/or other good references on the topic of
stream interface vs string interface to convert objects to text? I tried
google but failed.
I am looking for pointers that explain the rational behind the above claim
Hi,
Hoogle is definitely not deprecated. The reason you can't yet search
all packages simultaneously is that it consumes too many resources -
the number of Haskell packages exploded at a time when I wasn't able
to spend enough time to allow Hoogle to keep up. It's definitely
something on the todo
Mateusz Kowalczyk fuuzetsu at fuuzetsu.co.uk writes:
I always thought [hayoo] was just Hoogle with more indexed docs.
Wait - there's a semantic difference:
hoogle does understand type signatures
(e.g., it can specialize them, or flip arguments of functions)
while hayoo just treats signatures
On Thu, Aug 22, 2013 at 9:23 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.uk wrote:
On 22/08/13 19:30, jabolo...@google.com wrote:
Hi,
I noticed Hayoo appears as a link in the toolbox of
http://hackage.haskell.org and also that Hayoo seems to display better
results than Hoogle. For example,
On Fri, Aug 23, 2013 at 10:12:27AM +0200, Erik Hesselink wrote:
Note that the 'normal' hoogle indexes all (?) of hackage. But by
default it only searches the haskell platform. You can add a package
with '+' to search in that package. E.g. PublicKey +crypto-api.
If the idea behind this, that
It's a bit pointless, if I have to know the package, where I want to
search in.
Yeah! It does sound a bit pointless. Hoogle should search everything
by default, and then you can refine your search by clicking on the '+'
or '-' on the packages that appear on the left menu.
Jose
--
Jose
On 23/08/13 14:57, jabolo...@google.com wrote:
It's a bit pointless, if I have to know the package, where I want to
search in.
Yeah! It does sound a bit pointless. Hoogle should search everything
by default, and then you can refine your search by clicking on the '+'
or '-' on the packages
Hi,
I noticed Hayoo appears as a link in the toolbox of
http://hackage.haskell.org and also that Hayoo seems to display better
results than Hoogle. For example, if you search for 'PublicKey' in
Hayoo, you will get several results from Hackage libraries, such as,
'crypto-pubkey' and 'crypto-api'.
On 22/08/13 19:30, jabolo...@google.com wrote:
Hi,
I noticed Hayoo appears as a link in the toolbox of
http://hackage.haskell.org and also that Hayoo seems to display better
results than Hoogle. For example, if you search for 'PublicKey' in
Hayoo, you will get several results from Hackage
So is there a high-level comparison of HSpec and tasty? The only
difference I've glimpsed so far was that HSpec has a syntactic sugar for
describing tests which, honestly, I haven't found very useful.
So, could someone write up a quick comparison of the two for the benefit
of the folks like me
When I was writing
http://www.vex.net/~trebla/haskell/crossroad.xhtml
I wanted to write: branching on predicates and then using selectors is
less efficient than pattern matching, since selectors repeat the tests
already done by predicates.
It is only ethical to verify this claim before
Note that, unfortunately, GHC's exhaustiveness checker is *not* good
enough to figure out that your predicates are covering. :o) Perhaps
there is an improvement to be had here.
Edward
Excerpts from Albert Y. C. Lai's message of Mon Apr 22 00:51:46 -0700 2013:
When I was writing
What is the relationship between these two modules? Do we really need
both?
(Data.Vector.Storable is part of vector, Data.StorableVector is from a
separate package, storablevector.)
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 25 March 2013 05:04, Roman Cheplyaka r...@ro-che.info wrote:
What is the relationship between these two modules? Do we really need
both?
There doesn't seem to be any relationship at all between them...
(Data.Vector.Storable is part of vector, Data.StorableVector is from a
separate
for Haskell libraries. It is a simple
one:
functional object data structures encapsulating mutable state VS type
classes encapsulating mutable state
Here is a simple example. I present an API: using a type class `FooC`,
and aso as a data structure `FooT`. Both are stateful, in the form of
an MVar
What is the advance of using type classes? A function of the form
f :: Show a = ...
really has an implicit argument
f :: Show__Dict a - ...
that the compiler infers for us. So, the advantage of type classes is one
of convenience: we don't have to pass dictionaries around, or even figure
On Mon, Mar 4, 2013 at 5:50 PM, Rob Stewart robstewar...@gmail.com wrote:
...
-
import Control.Concurrent
-- API approach 1: Using type classes
class FooC a where
mkFooC :: IO a
readFooC :: a - IO Int
incrFooC :: a - IO ()
I recommend taking 'mkFooC' out of the typeclass. It
Hi,
I have a question about API design for Haskell libraries. It is a simple one:
functional object data structures encapsulating mutable state VS type
classes encapsulating mutable state
Here is a simple example. I present an API: using a type class `FooC`,
and aso as a data structure `FooT
Of course that is fine. But keep in mind that all parser combinator based
libraries are based on a top-down parsing strategy which in most places,
BUT NOT ALL, fits Haskell's syntax. Try to use the chaining combinators
where-ever possible. In case of doubt you can always spy on how things are
On 2 February 2013 20:08, Sean Cormican seancormic...@gmail.com wrote:
Can anybody provide me with some guidance on whether to try and create the
parser using Parsec or if haskell-src is a better option.
In the case that haskell-src is a better option, are there any tutorials or
documents
Dnia niedziela, 3 lutego 2013, Doaitse Swierstra napisał:
Use the uu-parsinglib library, which provides error messages, repairs your
errors and using its idioms definition you can even write:
inParens c = iI '(' c ')' Ii
I think you cannot get it shorter and with more functionality.
On 2/3/13 12:27 AM, Stephen Tetley wrote:
Haskell-src-exts parses real Haskell - including most (if not all?)
GHC extensions. If you were wanting to analyze 'in the wild' Haskell
projects you might also want to use CPPHS as many Haskell projects use
the CPP preprocessor.
That was something
* Patrick Pelletier c...@funwithsoftware.org [2013-02-03 10:57:14-0800]
On 2/3/13 12:27 AM, Stephen Tetley wrote:
Haskell-src-exts parses real Haskell - including most (if not all?)
GHC extensions. If you were wanting to analyze 'in the wild' Haskell
projects you might also want to use CPPHS
Hi,
I've been spending a bit of time looking into using Parsec as a parser for
a subset of the syntax of the Haskell language, a high level description of
what I'm looking to create is a parser which confirms whether a given
Haskell code file is valid or in the case that it isn't returns some
Hi Sean,
1. Please do not confuse haskell-src and haskell-src-exts. You should
definitely use the latter. I also find it relatively well documented.
2. If your goal is to write a tool and not to write a Haskell parser as
an exercise, then I would recommend haskell-src-exts. Another option
On Jan 31, 2013, at 10:47 , Jan Stolarek jan.stola...@p.lodz.pl wrote:
Thanks for replies guys. I indeed didn't notice that there are monads and
applicatives used in
this parser. My thought that monadic parsers are more verbose came from
Hutton's paper where the
code is definitely less
Thanks for replies guys. I indeed didn't notice that there are monads and
applicatives used in
this parser. My thought that monadic parsers are more verbose came from
Hutton's paper where the
code is definitely less readable than in example I provided.
There is one more thing that bothers me.
Jan Stolarek jan.stola...@p.lodz.pl wrote:
Thanks for replies guys. I indeed didn't notice that there are monads
and applicatives used in this parser. My thought that monadic parsers
are more verbose came from Hutton's paper where the code is definitely
less readable than in example I
On Wed, Jan 30, 2013 at 1:21 PM, Jan Stolarek wrote:
I will be writing a parser in Haskell and I wonder how to approach the
problem.
Utrecht University has a course that covers this, among other things. You
might find the slides and lecture notes useful:
Dnia czwartek, 31 stycznia 2013, Ertugrul Söylemez napisał:
Remember that 'Either e' is also a monad. =)
I remember - this makes the change from Maybe to Either very easy :) Still I
found that adding
error message to every combinator and function ads a lot of boilerplate. Also,
I experince
On 1/30/13 7:21 AM, Jan Stolarek wrote:
I will be writing a parser in Haskell and I wonder how to approach the problem.
My first thought
was to use monadic parser, e.g. like the one described by Hutton and Meijer in
Monadic Parsing
in Haskell functional pearl. But then I stumbled upon this:
I will be writing a parser in Haskell and I wonder how to approach the problem.
My first thought
was to use monadic parser, e.g. like the one described by Hutton and Meijer in
Monadic Parsing
in Haskell functional pearl. But then I stumbled upon this:
Jan Stolarek jan.stola...@p.lodz.pl wrote:
I will be writing a parser in Haskell and I wonder how to approach the
problem. My first thought was to use monadic parser, e.g. like the one
described by Hutton and Meijer in Monadic Parsing in Haskell
functional pearl. But then I stumbled upon
On 30 January 2013 12:38, Ertugrul Söylemez e...@ertes.de wrote:
A monadic parser /is/ a combinator parser. The code you linked just
doesn't go as far as wrapping it up with a newtype and providing a monad
instance.
Further, (+) in the linked example is monadic bind and `result` is
2013/1/17 Kazu Yamamoto k...@iij.ad.jp:
The following blog post by Joyent is worth reading:
http://joyent.com/blog/diy-vs-as-a-service-with-memcachier
We don't really believe in Node.js (Go Haskell are our
choices), so that is a small concern to us, but everyone has
2013/1/17 Jason Dusek jason.du...@gmail.com:
2013/1/17 Kazu Yamamoto k...@iij.ad.jp:
The following blog post by Joyent is worth reading:
http://joyent.com/blog/diy-vs-as-a-service-with-memcachier
We don't really believe in Node.js (Go Haskell are our
choices), so
Hello,
The following blog post by Joyent is worth reading:
http://joyent.com/blog/diy-vs-as-a-service-with-memcachier
We don't really believe in Node.js (Go Haskell are our
choices), so that is a small concern to us, but everyone has
their failings.
--Kazu
On 11/21/12 4:59 PM, Artyom Kazak wrote:
I saw a question on StackOverflow about the difference between isAlpha
and isLetter today. One of the answers stated that the two functions are
interchangeable, even though they are implemented differently.
I decided to find out whether the difference in
Hello!
I saw a question on StackOverflow about the difference between isAlpha and
isLetter today. One of the answers stated that the two functions are
interchangeable, even though they are implemented differently.
I decided to find out whether the difference in implementation influences
Hello Haskellers!
I wonder if you know of benchmarks that attempt to compare,
empirically, lazy vs. eager evaluation. Pointers to papers and/or
code would be most appreciated.
Our group (at UMD) is working on a paper that develops some technology
for lazy programs, and we would like to choose
Hi Mark,
Thank you for the clarification.
I think, then, that we should indeed provide a link to a notice about
native libraries - like, if you're using native libraries, make sure
their architecture is 32-bit or universal as well; in case of
MacPorts you can achieve this by doing port install
I've filed a bug report: http://hackage.haskell.org/trac/ghc/ticket/7314
My only problem is that I don't have OS X 10.8 installed on my machine.
I'm running OS X 10.6, and am not inclined to upgrade.
So providing feedback on the questions related to the bug report will be hard
and/or take some
Hi,
I finally found another OS X mountain lion install and can confirm the
behaviour I described earlier:
32-bit: compiled code works, interpreted code works
64-bit: compiled code works, interpreted code fails
Here's the test case:
- cabal install gloss --flags-GLUT GLFW
- cabal unpack
On Monday, 8 October 2012 at 06:28, Christiaan Baaij wrote:
ghci: segfault
ghci from gdb: everything works
This makes me suspect something that gets disabled when debugging, such as
address space randomization and the like. I did not think ML handled that any
differently from Lion, though.
On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij
christiaan.ba...@gmail.com wrote:
Hi,
I finally found another OS X mountain lion install and can confirm the
behaviour I described earlier:
32-bit: compiled code works, interpreted code works
64-bit: compiled code works, interpreted code
Johan, should I also file the bugreport remove the suggestion to
install 32-bit platform there, or is there a different place for bugs
of the platform website?
On Mon, Oct 8, 2012 at 7:25 AM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Oct 8, 2012 at 3:28 AM, Christiaan Baaij
Eugene: I think thats a bug / ticket for the haskell platform trac, rather
than ghc's trac.
look forward to seeing how to reproduce those problems / helping fix em!
On Mon, Oct 8, 2012 at 3:08 PM, Eugene Kirpichov ekirpic...@gmail.comwrote:
Johan, should I also file the bugreport remove the
I'm the source of the 32-bit recommendation, and the HP Mac distribution
builder
To summarize what I read in this thread:
1. 32-bit GHC/HP didn't work with 64-bit Cario libs
2. Some libs available via brew were 64-bit, and 32-bit ones would have
to be compiled
3. There is still some
Carter:
Not yet.
I'll get round to it once I'm done with with an Agda presentation I'm
working on. Until then I can't afford to break my environment.
On Fri, Sep 28, 2012 at 1:56 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
do these problems also happen if your'e using the glut
The GLUT-backend calls system.exit when the window is closed, because
'exitMainLoop' is only defined within freeglut, which is not by default
installed on non-linux platforms.
There is hence no real point in running gloss applications with the
GLUT-backend from GHCi.
I'll try to find a
The behaviour seems to differ between versions of OS X.
A student has OS X 10.8 installed and is observing the described behaviour:
32-bit: interpreted and compiled work correctly
64-bit: only compiled code works correctly
However, I have OS X 10.6, and I'm observing the following behaviour:
I'm experiencing the same issues with compiled 64 bit working
correctly, but interpreted causing all sorts of issues with Scotty.
On Thu, Sep 27, 2012 at 3:45 PM, Christiaan Baaij
christiaan.ba...@gmail.com wrote:
The behaviour seems to differ between versions of OS X.
A student has OS X 10.8
do these problems also happen if your'e using the glut backend? (because if
its only glfw that has problems, then its something wrong in the ffi code,
but if its both, that suggests there may be some sort of systematic
problem?)
@Lyndon, that sounds like a bug... especially since scotty seems to
Hi,
On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald
carter.schonw...@gmail.com wrote:
To the best of my knowledge there is absolutely no reason to use the 32bit
haskell on OS X (aside from memory usage optimization cases which likely do
not matter to the *typical* user), and the community
On Wed, Sep 26, 2012 at 10:58 AM, Johan Tibell johan.tib...@gmail.com wrote:
On Wed, Sep 26, 2012 at 7:44 AM, Carter Schonwald
carter.schonw...@gmail.com wrote:
To the best of my knowledge there is absolutely no reason to use the 32bit
haskell on OS X (aside from memory usage optimization
On 2012-09-26, at 1:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote:
what can we (the community ) do to address the fact that the haskell platform
installer suggestions for os x are sadly completely backwards? (or am I
completely wrong in my personal stance on this matter)
I'd
Adding Mark who's the release manager for the platform (and also the
maintainer of the OS X builds).
On Wed, Sep 26, 2012 at 11:57 AM, Erik Hesselink hessel...@gmail.com wrote:
On Wed, Sep 26, 2012 at 10:58 AM, Johan Tibell johan.tib...@gmail.com wrote:
On Wed, Sep 26, 2012 at 7:44 AM, Carter
Both are excellent points, thank you.
Your mention of general recursion prompts the following: in 1995, ten years
after publication of Boehm-Berarducci, Launchbury and Sheard investigated
transformation of programs written in general recursive form into
build-foldr form, with an eye towards the
Running gloss [1] programs from GHCi only works with the 32bit version of the
latest Haskell Platform.
The 64-bit version just shows a black window and GHCi becomes unresponsive.
I use gloss to display trees and graphs in the functional programming course
given at our university.
The ability to
really? does the 64 bit code work correctly when compiled?
if the compiled version works correctly, could you post a repo of some
example codlets that *should work* on ghc 7.6 so i can sort out if its
fixable. There were some similar problems with gtk / cairo for a while on
OS X, and i was able
Hi,
I installed Haskell Platform 32-bit on a fresh 64-bit mac, because the
page http://www.haskell.org/platform/mac.html says: Pick the 32-bit
vesion, unless you have a specific reason to use the 64-bit version.
The 32-bit one is slightly faster for most programs.
Then, during the installation
Wouldn't you say then that Church encoding is still the more appropriate
reference given that Boehm-Berarducci's algorithm is rarely used?
When I need to encode pattern matching it's goodbye Church and hello Scott.
Aside from your projects, where else is the B-B procedure used?
First of
On Wed, Sep 26, 2012 at 12:41 AM, o...@okmij.org wrote:
First of all, the Boehm-Berarducci encoding is inefficient only when
doing an operation that is not easily representable as a fold. Quite
many problems can be efficiently tackled by a fold.
Indeed. Some operations are even more efficient
Hi Eugene,
To the best of my knowledge there is absolutely no reason to use the 32bit
haskell on OS X (aside from memory usage optimization cases which likely do
not matter to the *typical* user), and the community should probably update
the recommendation to reflect this.
I can certainly attest
On Thu, Sep 20, 2012 at 3:15 PM,o...@okmij.org wrote:
Incidentally, there is more than one way to build a predecessor of Church
numerals. Kleene's solution is not the only one.
Wouldn't you say then that Church encoding is still the more appropriate
reference given that Boehm-Berarducci's
do you have any references for the extension of lambda-encoding of
data into dependently typed systems?
Is there a way out of this quagmire? Or are we stuck defining actual
datatypes if we want dependent types?
Although not directly answering your question, the following paper
Inductive
Dan Doel wrote:
P.S. It is actually possible to write zip function using Boehm-Berarducci
encoding:
http://okmij.org/ftp/Algorithms.html#zip-folds
If you do, you might want to consider not using the above method, as I
seem to recall it doing an undesirable amount of extra work
On Thu, 20 Sep 2012, o...@okmij.org wrote:
Dan Doel wrote:
P.S. It is actually possible to write zip function using Boehm-Berarducci
encoding:
http://okmij.org/ftp/Algorithms.html#zip-folds
If you do, you might want to consider not using the above method, as I
seem to recall it
is actually meaningful). Not only they are faster; one
can _syntactically_ prove that PRED . SUCC is the identity.
What is the setup that, here, gives the distinction between a
syntactic proof and some other kind of proof?
oo--JS.
Ah, I have just read the for-any vs for-all part of
http://okmij.org
cata vs para, left folds
do not appear to be strictly more powerful. Right folds can capture
algorithms that left folds (apparently) can't; e.g., folds over infinite
structures. I say apparently because once you add scanl/r to the
discussion instead of just foldl/r, things get a lot murkier
On 9/18/12 4:27 AM, o...@okmij.org wrote:
There has been a recent discussion of ``Church encoding'' of lists and
the comparison with Scott encoding.
I'd like to point out that what is often called Church encoding is
actually Boehm-Berarducci encoding. That is, often seen
newtype ChurchList a
On Wed, Sep 19, 2012 at 8:36 PM, wren ng thornton w...@freegeek.org wrote:
P.S. It is actually possible to write zip function using Boehm-Berarducci
encoding:
http://okmij.org/ftp/ftp/Algorithms.html#zip-folds
Of course it is; I just never got around to doing it :)
If you do, you
There has been a recent discussion of ``Church encoding'' of lists and
the comparison with Scott encoding.
I'd like to point out that what is often called Church encoding is
actually Boehm-Berarducci encoding. That is, often seen
newtype ChurchList a =
CL { cataCL :: forall r. (a - r - r)
On 18 September 2012 18:27, o...@okmij.org wrote:
There has been a recent discussion of ``Church encoding'' of lists and
the comparison with Scott encoding.
I'd like to point out that what is often called Church encoding is
actually Boehm-Berarducci encoding. That is, often seen
newtype
Oleg,
Let me try to understand what you're saying here:
(1) Church encoding was discovered and investigated in an untyped setting.
I understand your tightness criterion to mean surjectivity, the absence of
which means having to deal with junk.
(2) Church didn't give an encoding for
Hi list,
I have yet another question about folds. Reading here and there I encountered
statements that
foldr is more important than foldl, e.g. in this post on the list:
http://www.haskell.org/pipermail/haskell-cafe/2012-May/101338.html
I want to know are such statements correct and, if so,
Hi Jan!
foldl always traverses the list to the end; in particular, if there is no end,
it would hang forever (unless the compiler is smart enough to detect an
infinite loop, in which case it can throw an error). On the other hand, if the
first argument is lazy enough, foldr would stop before
18.09.2012, 16:32, Jan Stolarek jan.stola...@p.lodz.pl:
Hi list,
I have yet another question about folds. Reading here and there I
encountered statements that
foldr is more important than foldl, e.g. in this post on the list:
Oleg, do you have any references for the extension of lambda-encoding of
data into dependently typed systems?
In particular, consider Nat:
nat_elim :: forall P:(Nat - *). P 0 - (forall n:Nat. P n - P (succ
n)) - (n:Nat) - P n
The naive lambda-encoding of 'nat' in the untyped lambda-calculus
This paper:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.957
Induction is Not Derivable in Second Order Dependent Type Theory,
shows, well, that you can't encode naturals with a strong induction
principle in said theory. At all, no matter what tricks you try.
However, A Logic
Fascinating!
But it looks like you still 'cheat' in your induction principles...
×-induction : ∀{A B} {P : A × B → Set}
→ ((x : A) → (y : B) → P (x , y))
→ (p : A × B) → P p
×-induction {A} {B} {P} f p rewrite sym (×-η p) = f (fst p) (snd p)
Can you somehow define
On Tue, Sep 18, 2012 at 11:19 PM, Ryan Ingram ryani.s...@gmail.com wrote:
Fascinating!
But it looks like you still 'cheat' in your induction principles...
×-induction : ∀{A B} {P : A × B → Set}
→ ((x : A) → (y : B) → P (x , y))
→ (p : A × B) → P p
×-induction {A}
On Tue, Sep 18, 2012 at 8:39 PM, Dan Doel dan.d...@gmail.com wrote:
On Tue, Sep 18, 2012 at 11:19 PM, Ryan Ingram ryani.s...@gmail.com
wrote:
Fascinating!
But it looks like you still 'cheat' in your induction principles...
×-induction : ∀{A B} {P : A × B → Set}
→ ((x :
Hi. Just a brief question. System.IO functions are defined in IO monad
and have signatures like Foo - IO Bar.
Would it be better to have all of them defined as (MonadIO m) = Foo
- m Bar? What are the problems that would arise?
Sergey
___
Haskell-Cafe
On 12 September 2012 18:24, Sergey Mironov ier...@gmail.com wrote:
Hi. Just a brief question. System.IO functions are defined in IO monad
and have signatures like Foo - IO Bar.
Would it be better to have all of them defined as (MonadIO m) = Foo
- m Bar? What are the problems that would arise?
On 12 September 2012 19:55, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 12 September 2012 18:24, Sergey Mironov ier...@gmail.com wrote:
Hi. Just a brief question. System.IO functions are defined in IO monad
and have signatures like Foo - IO Bar.
Would it be better to have all of
Hi there,
I am writing a toy compiler in Haskell to further my skills in
functional programming. One of the functions I wrote is to determine the
iteration count of a loop. I have a number of different test that I want
to do and I find myself now testing some of these using pattern matching
On Sun, Aug 12, 2012 at 1:30 PM, Maarten Faddegon
haskell-c...@maartenfaddegon.nl wrote:
= if-- All stmts use the same lcv
test_lcv == init_lcv
test_lcv == update_lcv
test_lcv == update_lcv'
-- And the lcv is not updated in the body
This
I'm a somewhat experienced coder but I am relatively new to Haskell.
I've got a question about whether a usage of do notation is idiomatic,
or whether it's better to use pattern matching.
I've got two functions which take an input and return Maybe SomeType.
If either returns Nothing, I also want
The do notation in this instance yields a nice advantage: if you want to
switch to a different monad to encapsulate failure you will meely need to
swap out the type signature and your function will need no further work.
On Aug 4, 2012 7:35 AM, Matthew wonderzom...@gmail.com wrote:
I'm a somewhat
Also if you don't need foo and bar you can write:
callFoo callBar return baz
//Johan
On Aug 4, 2012 8:36 AM, Matthew wonderzom...@gmail.com wrote:
I'm a somewhat experienced coder but I am relatively new to Haskell.
I've got a question about whether a usage of do notation is idiomatic,
or
On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote:
I'm a somewhat experienced coder but I am relatively new to Haskell.
I've got a question about whether a usage of do notation is idiomatic,
or whether it's better to use pattern matching.
I've got two functions which take
On Sat, Aug 4, 2012 at 7:05 AM, Alexander Solla alex.so...@gmail.com wrote:
On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote:
I'm a somewhat experienced coder but I am relatively new to Haskell.
I've got a question about whether a usage of do notation is idiomatic,
or
On Sat, Aug 4, 2012 at 7:05 AM, Alexander Solla alex.so...@gmail.com wrote:
On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote:
...
With do notation, I can write something like this:
do
foo - callFoo x
bar - callBar x
return (baz)
1 - 100 of 1606 matches
Mail list logo
