This is already a separate extension: PatternSignatures. However, that
extension is deprecated for some reason.
On Tue, Aug 6, 2013 at 2:46 PM, Evan Laforge wrote:
> Occasionally I have to explicitly add a type annotation, either for
> clarity or to help choose a typeclass instance. Usually to
variable of p be *needed* to compute the
> value of the guard? My conjecture is that it cannot, so it does not make
> sense to consider variables of g bound by p. Maybe you can cook up some
> counterexample.
>
> I think the pattern variables of p should not be in scope in g, and
&g
The definition
Just x | x > 0 = Just 1
is recursive. It conditionally defines Just x as Just 1 when x > 0 (and as
bottom otherwise). So it must know the result before it can test the guard,
but it cannot know the result until the guard is tested. Consider an
augmented definition:
Just x
There is a package that implements an Int that throws an exception on
overflow:
http://hackage.haskell.org/package/safeint
Since Int's existence is pretty much all about trading for performance, I
wouldn't recommend holding your breath on the above becoming the default.
If you want things to
On Mon, Apr 29, 2013 at 10:05 AM, Duncan Coutts <
duncan.cou...@googlemail.com> wrote:
> On Thu, 2013-04-25 at 00:52 +0200, Gábor Lehel wrote:
> > On Wed, Apr 24, 2013 at 7:56 PM, Bryan O'Sullivan >wrote:
> >
> > > On Wed, Apr 24, 2013 at 10:47 AM, Duncan Coutts <
> > > duncan.cou...@googlemail.c
really think they're worth saving in general, though. I haven't
missed them, at least.
-- Dan
On Thu, Apr 25, 2013 at 3:19 PM, Gábor Lehel wrote:
> Good point, again. Is that the only problem with it?
>
>
> On Thu, Apr 25, 2013 at 5:57 PM, Dan Doel wrote:
>
>> It
It is not completely backwards compatible, because (for instance) the
declaration:
newtype C a => Foo a = Foo a
was allowed, but:
newtype Foo a where
Foo :: C a => a -> Foo a
is an illegal definition. It can only be translated to a non-newtype data
declaration, which changes the s
Presumably concat also has to use skip, for the same reason as filter.
Otherwise it has to recursively process the outer stream until it gets to a
non-empty inner stream, which breaks the rule that only the final consumer
is recursive.
concat [[1,2,3],[4,5],[],[6,7]]
probably looks something
Do note that deepSeq alone won't (I think) change anything in your
current code. bug will deepSeq the file contents. And the cons will
seq bug. But nothing is evaluating the cons. And further, the cons
isn't seqing the tail, so none of that will collapse, either. So the
file descriptors will still
One thing that typically isn't mentioned in these situations is that
you can add more laziness. I'm unsure if it would work from just your
snippet, but it might.
The core problem is that something like:
mapM readFile names
will open all the files at once. Applying any processing to the file
Just because you can't use the 'magic primitive' in question to
produce an element of the empty type doesn't mean the system is sound
(nor does type soundness have anything to do with proving 'false').
The question is what the primitive is supposed to do. If it's supposed
to work as a witness of e
do block ending in a return
>
> Even that last one is slightly questionable, I feel, but probably works
> for almost all cases. Are there any others?
>
> On Mon, Mar 04, 2013 at 12:20:12PM -0500, Dan Doel wrote:
>> I hadn't seen this before, but I tried it out, and the p
I hadn't seen this before, but I tried it out, and the parts I'm interested
in are nice. The indenting is less flaky than what I was using before
(comments had issues).
If you're rewriting things, though, it'd be nice to be able to customize
indentation a little more. For instance, I like laying o
with a higher-rank type (whether because it inferred it
separately, or you gave it), and that does trigger the alternate code path.
If that's still too vague, you'll have to refer to the paper.
-- Dan
*
http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/jfp-outsidei
On Wed, Jan 2, 2013 at 11:20 AM, Dan Doel wrote:
> Note that even left-to-right behavior covers all cases, as you might have:
>
> f x y
>
> such that y requires x to be checked polymorphically in the same way.
> There are algorithms that can get this right in general,
Your example doesn't work for the same reason the following doesn't work:
id runST ()
It requires the inferencer to instantiate certain variables of id's type to
polymorphic types based on runST (or flip's based on one), and then use
that information to check (id in your example) as a
polymo
Lists! The finite kind.
This could mean Seq for instance.
On Nov 30, 2012 9:53 AM, "Brent Yorgey" wrote:
> On Fri, Nov 30, 2012 at 02:33:54AM +0100, Ben Franksen wrote:
> > Brent Yorgey wrote:
> > > On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote:
> > >> Tony Morris wrote:
> > >> >
On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric wrote:
> join IS the most important from the categorical point of view.
> In a way it is natural to define 'bind' from 'join', but in Haskell, it
> is not always possible (see the Monad/Functor problem).
>
> As I said, from the mathematical point of v
On Mon, Oct 15, 2012 at 10:05 PM, damodar kulkarni
wrote:
> @Jake
>
>
>> In my opinion, this is not as nice as the do-notation version, but at
>> least it's compositional:
>
>
> That's an important point you have made, as Haskellers value code
> composition so much.
> If code composition is the "h
On Wed, Sep 26, 2012 at 12:41 AM, 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 than usuall
On Wed, Sep 19, 2012 at 8:36 PM, wren ng thornton 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 might want
t paper (that's
impossible). But parametricity can be used to prove statements _about_
the encodings that imply the induction principle.
> On Tue, Sep 18, 2012 at 4:09 PM, Dan Doel wrote:
>>
>> This paper:
>>
>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=1
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 f
Copying the mailing list, because I forgot.
On Thu, Sep 13, 2012 at 5:18 AM, satvik chauhan wrote:
> Consider the code below :
>
> {-# LANGUAGE
> MultiParamTypeClasses,FlexibleInstances,FunctionalDependencies,UndecidableInstances,FlexibleContexts
> #-}
> class Foo a c | a -> c
> instance Foo Int
On Thu, Apr 5, 2012 at 10:14 AM, Grigory Sarnitskiy wrote:
> First, what are 'functions' we are interested at? It can't be the usual
> set-theoretic definition, since it is not constructive. The constructive
> definition should imply functions that can be constructed, computed. Thus
> these are
On Wed, Feb 22, 2012 at 1:40 AM, wren ng thornton wrote:
> It's a category-theoretic product, but not for the category of domains. Let
> Set be the category of sets and set-theoretic functions. And let pDCPO be
> the category of (pointed) domains and their homomorphisms.
>
> The (domain-theoretic)
On Tue, Feb 21, 2012 at 10:44 AM, wren ng thornton wrote:
> That's a similar sort of issue, just about whether undefined ==
> (undefined,undefined) or not. If the equality holds then tuples would be
> domain products[1], but domain products do not form domains!
> ...
> [1] Also a category-theoreti
On Thu, Jan 19, 2012 at 11:11 PM, Dan Doel wrote:
> No, this is not correct. Unfailable patterns were specified in Haskell
> 1.4 (or, they were called "failure-free" there; they likely existed
> earlier, too, but I'll leave the research to people who are
> interest
On Thu, Jan 19, 2012 at 10:43 PM, Gregory Crosswhite
wrote:
> first, that the notion of "unfailable" was not removed from the language
> so much as not added in the first place
No, this is not correct. Unfailable patterns were specified in Haskell
1.4 (or, they were called "failure-free" there; t
A is a retract of B.
http://nlab.mathforge.org/nlab/show/retract
g is the section, f is the rectraction. You seem to have it already.
The definition needn't be biased toward one of the functions.
On Thu, Jan 19, 2012 at 4:24 PM, Sean Leather wrote:
> I have two types A and B, and I want to
On Sun, Jan 1, 2012 at 3:26 PM, Ketil Malde wrote:
> Chris Smith writes:
>
>>> I wonder: can writing to memory be called a “computational effect”? If
>>> yes, then every computation is impure.
>
> I wonder if not the important bit is that pure computations are unaffected by
> other computations (
On Sun, Dec 25, 2011 at 12:14 AM, Eugene Kirpichov wrote:
> On Sat, Dec 24, 2011 at 10:49 PM, Dan Doel wrote:
>> I think it's good to be clear on all these specifics, and people could
>> do with a better recognition of the difference between (non-)strict
>> and (lazy)ea
On Sat, Dec 24, 2011 at 2:31 AM, Albert Y. C. Lai wrote:
> 1. a function f is strict if f ⊥ = ⊥
> 2. ⊥ represents any computation which does not terminate, i.e. an exception
> or an infinite loop
> 3. "strict" describes the denotational semantics
All three of these statements are true. The only
On Thu, Dec 22, 2011 at 4:19 AM, Heinrich Apfelmus
wrote:
> Alexander Solla wrote:
>>>
>>> And denotational semantics is not just nice. It is useful. It's the best
>>> way to understand why the program we just wrote doesn't terminate.
>>
>>
>> Denotational semantics is unrealistic. It is a Platon
On Wed, Dec 7, 2011 at 5:48 AM, Dmitry Kulagin wrote:
> I am still pretty new in Haskell, but this problem annoys me already.
>
> If I define certain monad as a type synonym:
>
> type StateA a = StateT SomeState SomeMonad a
>
> Then I can't declare new monad based on the synonym:
>
> type St
Greetings,
In the process of working on a Haskell-alike language recently, Ed
Kmett and I realized that we had (without really thinking about it)
implemented type synonyms that are a bit more liberal than GHC's. With
LiberalTypeSynonyms enabled, GHC allows:
type Foo a b = b -> a
type Bar
On Sun, Sep 4, 2011 at 12:24 AM, Ivan Lazar Miljenovic
wrote:
> On 4 September 2011 12:34, Daniel Peebles wrote:
>> Hi all,
>> For example, if I write in a do block:
>> x <- action1
>> y <- action2
>> z <- action3
>> return (f x y z)
>> that doesn't require any of the context-sensitivty that Mona
Greetings,
Following some work at hac-phi, I've finally put together a new
release of vector-algorithms. It should now be available via hackage,
or you can pull from code.haskell.org if you prefer:
hackage: http://hackage.haskell.org/package/vector-algorithms/
latest: darcs get http://code.ha
On Fri, Jul 22, 2011 at 4:11 PM, Serguey Zefirov wrote:
> But "cpu" variable is the same in all places. If we don't dive into
> CPUFunc reduction (to Int or whatever) we can safely match funcVars
> argument and unify cpu.
>
> This is the case when we write generic functions over type family applic
On Fri, Jul 22, 2011 at 11:12 AM, Serguey Zefirov wrote:
> -
> {-# LANGUAGE GADTs, TypeFamilies #-}
>
> class CPU cpu where
> type CPUFunc cpu
>
> data Expr cpu where
>
On Wed, May 18, 2011 at 2:04 AM, Ryan Ingram wrote:
> Yes, the goal isn't so much to improve complexity (both are O(1)) but to
> reduce the constant factor on that O(1).
>
> In an inner loop like that, allocator/gc calls by far dominate the cost of
> the program. If you can remove them, you've im
On Tue, May 3, 2011 at 2:26 AM, Dominique Devriese
wrote:
> What I find interesting is that he considers (non-)termination an
> effect, which Haskell does not manage to control like it does other
> types of effects. Dependently typed purely functional languages like
> Coq (or Agda if you prefer ;)
(Sorry if you get this twice, Ertugrul; and if I reply to top. I'm
stuck with the gmail interface and I'm not used to it.)
On Thu, Apr 28, 2011 at 11:27 AM, Ertugrul Soeylemez wrote:
> I don't see any problem with this. Although I usually have a bottom-up
> approach, so I don't do this too often
On Tuesday 12 April 2011 11:27:31 AM Leon Smith wrote:
> I think impredicative polymorphism is actually needed here; if I write
> ...
> Then I get a type error
> ...
I'm not going to worry about the type error, because that wasn't what I had in
mind for the types. The type for loop I had in mind
On Monday 11 April 2011 8:31:54 PM Leon Smith wrote:
> I have a type constructor (Iterator i o m a) of kind (* -> * -> (* ->
> *) -> *), which is a monad transformer, and I'd like to use the type
> system to express the fact that some computations must be "pure", by
> writing the impredicative t
On Thursday 17 March 2011 6:41:33 PM wren ng thornton wrote:
> How about "pragmatically efficacious"?
Well...
> (3) Use type hackery to disallow performing subtraction when the result
> would drop below zero, e.g. by requiring a proof that the left argument
> is not less than the right.
As far a
On Tuesday 22 February 2011 3:13:32 PM Vasili I. Galchin wrote:
>What is the category that is used to interpret linear logic in
> a categorical logic sense?
This is rather a guess on my part, but I'd wager that symmetric monoidal
closed categories, or something close, would be to linear l
On Saturday 19 February 2011 1:11:23 AM Vasili I. Galchin wrote:
> BTW I was thinking of http://www.ats.org when I asked this question.
Technically speaking, if one considers ATS to be dependently typed, then one
might as well also consider GHC to be dependently typed (with the right
extensions
On Thursday 03 February 2011 5:12:54 PM Tim Chevalier wrote:
> On Thu, Feb 3, 2011 at 2:03 PM, Luke Palmer wrote:
> > This is probably a result of strictness analysis. error is
> > technically strict, so it is reasonable to optimize to:
> >
> >let e = error "foo" in e `seq` error e
>
> Yes,
On Monday 03 January 2011 9:23:17 pm David Sankel wrote:
> The following is a dependent type example where equality of open terms
> comes up.
>
> z : (x : A) → B
> z = ...
>
> w : (y : A) → C
> w = z
>
> Here the compiler needs to show that the type B, with x free,
> is equivalent to C, with y f
On Thursday 23 December 2010 12:52:07 pm Daniel Peebles wrote:
> Fair enough :) that'll teach me to hypothesize something without thinking
> about it! I guess I could amend my coinductive proof:
>
> http://hpaste.org/paste/42516/mirrormirror_with_bottom#p42517
>
> does that cover bottom-ness adeq
On Thursday 02 December 2010 7:54:18 pm Larry Evans wrote:
> [snip]
> *Maybe* the computer science people are trying to minimize the concepts.
> In this case, the one concept common to both the sum and product ( in
> the math peoples viewpoint) is there's a function:
>
>field2type: field_name
On Thursday 02 December 2010 10:13:32 am Petr Pudlak wrote:
> Hi,
>
> recently, I was studying how cartesian closed categories can be used to
> describe typed functional languages. Types are objects and morphisms are
> functions from one type to another.
>
> Since I'm also interested in systems
It took me a bit to decide whether this was an adequate counter to my
objection, but ultimately, I don't think it is. I'll try to explain as well as
possible.
On Friday 12 November 2010 1:40:10 pm rocon...@theorem.ca wrote:
> As you are well aware in Coq, and in Agda we don't have an extensional
On Thursday 11 November 2010 9:23:13 pm Luke Palmer wrote:
> Admittedly, the class of reasoning I usually use in my Haskell
> programs, and the one that you talked about using earlier this
> message, is essentially "seq doesn't exist". However, I prefer to use
> this class of reasoning because I w
On Thursday 11 November 2010 11:54:56 am Sjoerd Visscher wrote:
> Yes, but it would not break any existing code. It would only break code
> that knowingly did the wrong thing.
Well, if we added a function that randomly scrambled GHC's heap memory, it
wouldn't break any existing code, because none
On Thursday 11 November 2010 12:34:21 pm John Lato wrote:
> I think the only way this would work would be if you consider functions to
> be equal only to themselves, i.e. "x+x" and "2*x" are not equal. That's
> not a trade-off I would be willing to make.
In general, it doesn't even have to be bas
qual representations then we could we could decide
> whether two pure functions were equal, which (if not done in the IO
> monad) would(?) break purity; and (b) per Dan Doel, if we wanted to
> implement our serialization in a way so that equal functions get equal
> representations, we coul
On Thursday 11 November 2010 4:25:46 am Thomas Davie wrote:
> I don't think I agree, I didn't see a rule f == g => serialise f ==
> serialise g anywhere.
That equal things can be substituted for one another is one of the fundamental
ideas of equality (the other is that anything is equal to itself
On Wednesday 10 November 2010 1:42:00 pm Petr Pudlak wrote:
> I was reading the paper "Total Functional Programming" [1]. I
> encountered an interesting note on p. 759 that primitive recursion in a
> higher-order language allows defining much larger set of function than
> classical primitive recurs
On Wednesday 10 November 2010 1:37:41 pm Stephen Tetley wrote:
> Is it just me or does this bit in the proposal:
>
> m .lookup key
> .snd
> .reverse
>
> Which translates to this:
>
> reverse . snd . (\m -> lookup m key) $ m
>
> make no sense and refuse to type check - i.e lookup is p
On Wednesday 10 November 2010 2:08:56 pm Lauri Alanko wrote:
> So the proposal seems to be tailored specifically to fix some
> inconveniences with records. I'd much rather see a true record system
> for Haskell, since that would fix the namespace conflict problem in a
> more robust way.
I certainl
On Saturday 06 November 2010 2:09:13 am Sebastian Fischer wrote:
> Is there a deeper reason why people use "morphism" and not
> "homomorphism" or is it just because it's shorter?
I don't really know. But that's (one) standard terminology in category theory.
Objects and morphisms.
It may be due t
On Thursday 04 November 2010 5:13:23 pm Gregory Crosswhite wrote:
> On 11/02/2010 08:37 PM, wren ng thornton wrote:
> > Indeed. If your program requires unification or constraint solving
> > then logic programming or constraint programming[1] is the way to go.
>
> Would you be kind enough to giv
On Thursday 04 November 2010 12:12:51 pm Jeremy O'Donoghue wrote:
> Best laugh I've had in ages. Personal favourites are:
The Forth one got me. I also like:
OCaml: "OCaml is an attempt to implement object-oriented syntax in Caml. It is
related to SML."
No mention of what Caml is, by the way. H
On Tuesday 02 November 2010 3:11:22 pm Brandon Moore wrote:
> That's surprising, I think LogicT gains significant performance from that
> sort of CPS conversion.
It's probably not that surprising.
LogicT is an encoding of a recursive type, so there's potentially more causes
for the gain. For ins
On Tuesday 02 November 2010 4:01:33 pm Brandon Moore wrote:
> >instance C Int b where
> >
> > update _ n = n
This instance violates the fundep. The fundep says that the first parameter
determines the second. However, this instance is a scheme for declaring
infinitely many monomorphic instances
On Monday 01 November 2010 6:40:30 pm Jeremy Shaw wrote:
> Looks a lot like Church encoding to me:
>
> http://en.wikipedia.org/wiki/Church_encoding
>
> It was first discovered by the guy who invented lambda calculus :p
Also, if you're interested in this, you can read Proofs and Types by Girard
On Friday 22 October 2010 7:24:37 am Max Bolingbroke wrote:
> Ah yes, pattern synonyms. This solution is somewhat unsatisfying
> because you will also need some smart constructors:
>
> """
> nil = Roll NilF
> cons x xs = Roll (ConsF x xs)
> """
>
> Now the names of the smart constructors for buil
On Friday 22 October 2010 6:37:49 am Max Bolingbroke wrote:
> This is all well and good, but it means when working with data types
> defined in this manner you have to write Roll and unroll everywhere.
> This is tedious :-(
Your discovery is interesting (and I haven't seen it before).
Another sol
On Friday 22 October 2010 5:48:28 am Max Bolingbroke wrote:
> I think evaluating dictionaries strictly is more of a "want to have"
> rather than "actually implemented". In particular, GHC supports
> building value-recursive dictionaries - and making dictionary
> arguments strict indiscriminately wo
On Tuesday 19 October 2010 6:16:16 am Max Bolingbroke wrote:
> Thanks - your definitions are similar to Roman's suggestion.
> Unfortunately my criteria 3) is not quite what I actually wanted - I
> really wanted something "GHC-optimisable" - (so non-recursive
> definitions are a necessary but not s
On Saturday 16 October 2010 7:04:23 pm Ben Millwood wrote:
> On Fri, Oct 15, 2010 at 9:28 PM, Andrew Coppin
>
> wrote:
> > I'm still quite
> > surprised that there's no tool anywhere which will trivially print out
> > the reduction sequence for executing an expression. You'd think this
> > would
On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote:
> Hughes himself said that when your arrow is an instance of ArrowApply,
> you are better off just sticking with monads.
Well, this is not necessarily good advice. It is true that ArrowApply will
preclude some sort of static analysi
On Sunday 10 October 2010 5:32:16 pm Johannes Waldmann wrote:
> I mean instead of h . g . f $ x
> I'd sometimes prefer x ? f ? g ? h
> but what are the "?"
Note, before anyone gets too excited about this, there are some built-in
things about the language that make forward chaining less nic
On Wednesday 29 September 2010 2:52:21 pm Christopher Done wrote:
> LiberalTypeSynonyms lets you partially apply type synonyms.
Not in general. LiberalTypeSynonyms only allows synonyms to be partially
applied when expansions of other type synonyms will eventually cause them to
become fully appli
On Saturday 18 September 2010 6:03:39 pm wren ng thornton wrote:
> pointed objects, pointed sets/groups/topospaces, pointed categories,
> pointed functors, etc aren't all the same though.
The definition of pointed objects could be massaged to yield pointed functors,
though.
Instead of a categor
On Saturday 18 September 2010 8:27:45 am Gábor Lehel wrote:
> Hmm. I had a similar thought, but dismissed it because I was under the
> impression that you needed to use all the parameters of the class as
> parameters of its associated types. But apparently that was mistaken
> -- or, at least, your
On Friday 17 September 2010 4:04:26 pm Gábor Lehel wrote:
> What I would *want* to write is this:
>
> class (Mutable (Thawed a), Frozen (Thawed a) ~ a) => Immutable a where
> type Thawed a :: *
> thaw :: a -> Thawed a
>
> class (Immutable (Frozen a), Thawed (Frozen a) ~ a) => Mutable a wh
On Friday 10 September 2010 11:13:50 pm michael rice wrote:
> Which of these would be more costly for a long list?
>
> f :: [Int] -> [Int]
> f [x] = [x]
> f (x:xs) = x + (head xs) : f xs
>
> f :: [Int] -> [Int]
>
> f [x] = [x]
> f (x:y:xs) = x + y : f (y:xs)
Another option would be:
f [x] =
On Wednesday 08 September 2010 11:17:43 pm wren ng thornton wrote:
> -- | Proof that impure is not p...@e
> fmap f (impure a)
> == fmap f (E a a)
> == E (f a) a
> /= E (f a) (f a)
> == impure (f a)
I don't believe your proof. The type of E is as follows:
E :: a ->
On Wednesday 25 August 2010 5:05:11 pm DavidA wrote:
> Hi,
>
> The code below defines a type synonym family:
>
> {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-}
> {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
>
> data Vect k b = V [(b,k)] deriving (Eq,Show)
>
> data TensorBasis
On Wednesday 18 August 2010 2:50:00 pm Gregory Crosswhite wrote:
> On 08/18/10 11:30, Dan Doel wrote:
> > Now, moving to the two loops:
> > loop = loop
> > loop' = \w0 -> let (w1, ()) = putStr "c" w0 in loop' w1
> >
> > How are we to
On Wednesday 18 August 2010 11:14:06 am Ertugrul Soeylemez wrote:
> > loop, loop' :: IO ()
> > loop = loop
> > loop' = putStr "c" >> loop'
>
> Huh?! Let's translate them. 'loop' becomes:
>
> undefined
>
> But 'loop\'' becomes:
>
> \w0 -> let (w1, ()) = putStr "c" w0
>
On Friday 13 August 2010 8:51:46 pm Evan Laforge wrote:
> I have an app that is using Data.Text, however I'm thinking of
> switching to UTF8 bytestrings. The reasons are that there are two
> main things I do with text: pass it to a C API to display, and parse
> it. The C API expects UTF8, and the
On Thursday 12 August 2010 7:59:09 pm wren ng thornton wrote:
> Not quite. Strong-sigma is a dependent pair where you can project both
> elements. Weak-sigma is a dependent pair where you can only project the
> first element (because the second is erased). Existentials are dependent
> pairs where y
On Wednesday 11 August 2010 3:13:56 pm Tillmann Rendel wrote:
> I understand your argument to be the following: Functional languages are
> built upon the lambda calculus, so a *pure* functional language has to
> preserve the equational theory of the lambda calculus, including, for
> example, beta r
On Wednesday 11 August 2010 9:49:07 am mo...@deepbondi.net wrote:
> The mixture is not as free as some would like; the fact that Haskell has
> this distinction between monadic actions and pure values (and the fact
> that the former can be manipulated as an instance of the latter) means
> that the p
> I remember the first lambdacat said something like "why can't u curry
> this funkshun". I don't see it in this list. :-(
Simon cat and Oleg cat are also missing, unfortunately.
Also the 'catamorphism' picture with the banana peel (there may be others I
can't recall, too).
_
On Sunday 01 August 2010 10:52:48 am Felipe Lessa wrote:
> On Sun, Aug 1, 2010 at 11:29 AM, Nicolas Pouillard
>
> wrote:
> > Finally maybe we can simply forbidden the forcing of function (as we do
> > with Eq). The few cases where it does matter will rescue to
> > unsafeSeqFunction.
>
> What's t
On Saturday 31 July 2010 8:13:37 am Ertugrul Soeylemez wrote:
> I agree to some extent, but only to some. Mostly the problem of people
> is that they are trying to understand "monads" as opposed to specific
> instances. It's better to learn "the IO monad", "state monads", "the
> list monad", "the
On Tuesday 27 July 2010 8:50:56 am Henning Thielemann wrote:
> I always assumed that 'm a' would be a monoid for 'm' being an
> applicative functor, but I never tried to prove it. Now you made me
> performing a proof. However the applicative functor laws from
> http://www.haskell.org/ghc/docs/6.12.
On Sunday 04 July 2010 5:41:07 am Yves Parès wrote:
> Okay, I understand better, now.
> But I could never have guessed it just from the GHC error message.
>
> Another question on the same code:
>
> import Control.Monad.Identity
>
> newtype SomeMonad s a = SomeMonad { unSome :: Identity a }
> d
On Saturday 03 July 2010 10:52:31 pm Felipe Lessa wrote:
> I understood your explanation. However, is this an implementation
> detail/bug or is it an intended feature?
Well, I wouldn't call it a bug. Perhaps it could be called a lack of a
feature, because one can imagine such pattern matches bei
On Saturday 03 July 2010 7:24:17 pm Yves Parès wrote:
> I'm trying to implement the type protection used by ST to prevent a monad
> from returning a certain type.
> There's my code:
>
> import Control.Monad.Identity
>
> newtype SomeMonad s a = SomeMonad { unSome :: Identity a }
> deriving (Mona
On Saturday 03 July 2010 4:01:12 pm Kevin Quick wrote:
> As a side note, although I agree it abuses the fundeps intent, it was handy
> for the specific purpose I was implementing to have a "no-op/passthrough"
> instance of op. In general I like the typedef approach better, but it
> looks like I mu
On Saturday 03 July 2010 3:57:34 pm Thomas Hartman wrote:
> When I load up Control.Applicative in ghci and try, eg
>
> many [1,2] or many (Just 1) or some [1,2] or some (Just 1)
>
> this never returns.
>
> What are the practical uses of these combinators, or for using the
> Alternative class in
On Saturday 03 July 2010 2:11:37 pm David Menendez wrote:
> > {-# LANGUAGE MultiParamTypeClasses #-}
> > {-# LANGUAGE FunctionalDependencies #-}
> > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
> >
> > class C a b c | a -> b, a -> c where
> >op :: a -> b -> c
> >
> > instance C Bo
On Friday 02 July 2010 6:23:53 pm Claus Reinke wrote:
> -- second, while trying the piece with classic, non-equality constraints
> Prelude> (id :: (forall b. Eq b=>b->b) -> (forall b. Eq b=>b->b))
>
> :1:0:
> No instance for (Show ((forall b1. (Eq b1) => b1 -> b1) -> b -> b))
> arising f
On Sunday 20 June 2010 9:24:54 pm Alexander Solla wrote:
> Why can't you just use let notation do deal with the recursion? I
> thought "lets" in do blocks were just a little bit of syntactic sugar
> for "regular" let expressions, which do allow mutual recursion. I
> could be totally wrong though.
1 - 100 of 262 matches
Mail list logo
