Thiago Negri wrote:
> Why type inference can't resolve this code?
> {-# LANGUAGE RankNTypes, ConstraintKinds #-}
>
> bar :: (Num a, Num b) => (forall c. Num c => c -> c) ->Either a b ->Either a b
> bar f (Left a) = Left (f a)
> bar f (Right b) = Right (f b)
>
> bar' = bar (+ 2) -- This compiles o
> I've been toying with using Data Types a la Carte to get type
> representations, a `Typeable` class and dynamic types parameterized by a
> possibly open universe:
If the universe is potentially open, and if we don't care about
exhaustive pattern-matching check (which is one of the principal
ben
[I too had the problem sending this e-mail to Haskell list.
I got a reply saying the message awaits moderator approval]
Evan Laforge wrote:
> I have a typeclass which is instantiated across a closed set of 3
> types. It has an ad-hoc set of methods, and I'm not too happy with
> them because bein
Evan Laforge wrote:
> I have a typeclass which is instantiated across a closed set of 3
> types. It has an ad-hoc set of methods, and I'm not too happy with
> them because being a typeclass forces them to all be defined in one
> place, breaking modularity. A sum type, of course, wouldn't have th
> 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 t
I must stress that OpenUnion1.hs described (briefly) in the paper
is only one implementation of open unions, out of many possible.
For example, I have two more implementations. A year-old version of
the code implemented open unions *WITHOUT* overlapping instances or
Typeable.
http://okmij.
Perhaps effect libraries (there are several to choose from) could be a
better answer to Fork effects than monad transformers. One lesson from
the recent research in effects is that we should start thinking what
effect we want to achieve rather than which monad transformer to
use. Using ReaderT or
Here is a snippet from a real code that could benefit from
non-recursive let. The example is notable because it incrementally
constructs not one but two structures (both maps), ast and headers.
The maps are constructed in a bit interleaved fashion, and stuffing
them into the same State would be un
ivan.chollet wrote:
> let's consider the following:
>
> let fd = Unix.open ...
> let fd = Unix.open ...
>
> At this point one file descriptor cannot be closed. Static analysis will
> have trouble catching these bugs, so do humans.
Both sentences express false propositions.
The given code, if Has
Here is one possible approach. First, convert the propositional
formula into the conjunctive normal form (disjunctive will work just
as well). Recall, the conjunctive normal form (CNF) is
type CNF = [Clause]
type Clause = [Literal]
data Literal = Pos PropLetter | Neg PropLetter
type PropL
I'd like to emphasize that there is a precedent to non-recursive let
in the world of (relatively pure) lazy functional programming.
The programming language Clean has such non-recursive let and uses
it and the shadowing extensively. They consider shadowing a virtue,
for uniquely typed data.
Richa
Alberto G. Corona wrote:
> I think that a non-non recursive let could be not compatible with the pure
> nature of Haskell.
I have seen this sentiment before. It is quite a mis-understanding. In
fact, the opposite is true. One may say that Haskell is not quite pure
_because_ it has recursive let.
> If you would like to write
>
> let (x,s) = foo 1 [] in
> let (y,s) = bar x s in
> let (z,s) = baz x y s in
>
> instead, use a state monad.
Incidentally I did write almost exactly this code once. Ironically, it
was meant as a lead-on to the State monad.
But there have been other ca
Jon Fairbairn wrote:
> It just changes forgetting to use different variable names because of
> recursion (which is currently uniform throughout the language) to
> forgetting to use non recursive let instead of let.
Let me bring to the record the message I just wrote on Haskell-cafe
http:/
Andreas wrote:
> The greater evil is that Haskell does not have a non-recursive let.
> This is source of many non-termination bugs, including this one here.
> let should be non-recursive by default, and for recursion we could have
> the good old "let rec".
Hear, hear! In OCaml, I can (and often
TP wrote:
> pr :: Name -> ExpQ
> pr n = [| putStrLn $ (nameBase n) ++ " = " ++ show $(varE n) |]
The example is indeed problematic. Let's consider a simpler one:
> foo :: Int -> ExpQ
> foo n = [|n + 1|]
The function f, when applied to an Int (some bit pattern in a machine
register), produces _c
> It seems very interesting, but I have not currently the time to make a
> detailed comparison with vector/tensor algebra. Moreover I have not
I would suggest the freely available
Oersted Medal Lecture 2002
by David Hestenes
http://geocalc.clas.asu.edu/pdf/OerstedMedalLe
Well, I guess you might be interested in geometric algebra then
http://dl.acm.org/citation.cfm?id=1173728
because Geometric Algebra is a quite more principled way of doing
component-free calculations. See also the web page of the author
http://staff.science.uva.nl/~fontijne/
Geige
I'm late to this discussion and must have missed the motivation for
it. Specifically, how is your goal, vector/tensor operations that are
statically assured well-dimensioned differs from general
well-dimensioned linear algebra, for which several solutions have been
already offered. For example, th
Type classes are the approach to constrain type variables, to bound
polymorphism and limit the set of types the variables can be
instantiated with. If we have two type variables to constrain,
multi-parameter type classes are the natural answer then. Let's take
this solution and see where it leads
> > I must say though that I'd rather prefer Adres solution because his
> > init
> > > init :: (forall a. Inotify a -> IO b) -> IO b
> >
> > ensures that Inotify does not leak, and so can be disposed of at the
> > end. So his init enforces the region discipline and could, after a
> It's probably
I'm a bit curious
> * be reliable in the presence of async exceptions (solved by conduit,
> pipes-safe),
>
> * hold on to resources only as long as necessary (solved by conduit
> and to some degree by pipes-safe),
Are you aware of
http://okmij.org/ftp/Streams.html#regions
wh
But Haskell (and GHC) have existential types, and your prototype code
works with GHC after a couple of trivial changes:
> main = do
> W nd0 <- init
> wd0 <- addWatch nd0 "foo"
> wd1 <- addWatch nd0 "bar"
> W nd1 <- init
> wd3 <- addWatch nd1 "baz"
> printInotifyDesc nd0
> printInoti
I guess you might like then
http://okmij.org/ftp/Haskell/types.html#Prepose
which discusses implicit parameters and their drawbacks (see Sec 6.2).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
Mateusz Kowalczyk wrote:
> Is there a way however to do something along the lines of:
> > class Eq a => Foo a where bar :: a -> a -> Bool bar = (==)
> >
> > class Num a => Foo a where bar :: a -> a -> Bool bar _ _ = False
> This would allow us to make an instance of Num be an instance of Foo
> or
> In your class Sum example,
>
> class Sum x y z | x y -> z, x z -> y
>
> your own solution has a bunch of helper classes
First of all, on the top of other issues, I haven't actually shown an
implementation in the message on Haskell'. I posed this as a general
issue.
In special cases lik
Wren Thornton wrote:
> So I'm processing a large XML file which is a database of about 170k
> entries, each of which is a reasonable enough size on its own, and I only
> need streaming access to the database (basically printing out summary data
> for each entry). Excellent, sounds like a job for S
Aleksandar Dimitrov wrote:
> I've been kicking around the idea of re-implementing HList on the basis of the
> new DataKinds [1] extension.
The current HList already uses DataKinds (and GADTs), to the extent
possible with GHC 7.4 (GHC 7.6 supports the kind polymorphism better, but
it had a critica
> One problem with such monad implementations is efficiency. Let's define
>
> step :: (MonadPlus m) => Int -> m Int
> step i = choose [i, i + 1]
>
> -- repeated application of step on 0:
> stepN :: (Monad m) => Int -> m (S.Set Int)
> stepN = runSet . f
> where
> f
> Lazy I/O *sounds* safe.
> And most of the alternatives (like conduits) hurt my head,
> so it is really *really* tempting to stay with lazy I/O and
> think I'm doing something safe.
Well, conduit was created for the sake of a web framework. I think all
web frameworks, in whatever language, are q
Timon Gehr wrote:
> I am not sure that the two statements are equivalent. Above you say that
> the context distinguishes x == y from y == x and below you say that it
> distinguishes them in one possible run.
I guess this is a terminological problem. The phrase `context
distinguishes e1 and e2' is
The question of Set monad comes up quite regularly, most recently at
http://www.ittc.ku.edu/csdlblog/?p=134
Indeed, we cannot make Data.Set.Set to be the instance of Monad type
class -- not immediately, that it. That does not mean that there is no
Set Monad, a non-determinism monad that r
One may read this message as proving True === False without resorting
to IO. In other words, referential transparency, or the substitution
of equals for equals, may fail even in expressions of type Bool.
This message is intended as an indirect stab at lazy IO.
Unfortunately, Lazy IO and even the
Henning Thielemann wrote:
> However the interesting part of a complete case analysis on type level
> peano numbers was only sketched in section "8.4 Closed type
> families". Thus I tried again and finally found a solution that works
> with existing GHC extensions:
You might like the following mes
Wren Thornton wrote:
> I had some similar issues recently. The trick is figuring out how to
> convince attoparsec to commit to a particular alternative. For example,
> consider the grammar: A (B A)* C; where if the B succeeds then we want to
> commit to parsing an A (and if it fails then return A'
Jeremy Shaw wrote:
> It would be pretty damn cool if you could create a data type for
> generically describing a monadic parser, and then use template haskell
> to generate a concrete parser from that data type. That would allow
> you to create your specification in a generic way and then target
>
Dmitry Kulagin wrote:
> I try to implement typed C-like structures in my little dsl.
HList essentially had those
http://code.haskell.org/HList/
> I was unable to implement required type function:
> type family Find (s :: Symbol) (xs :: [(Symbol,Ty)]) :: Ty
> Which just finds a type in a
Tom Ellis wrote:
> To avoid retaining a large lazy data structure in memory it is useful to
> hide it behind a function call. Below, "many" is used twice. It is hidden
> behind a function call so it can be garbage collected between uses.
As you discovered, it is quite challenging to ``go again
It is indeed true that a grammar with left-recursion can be
transformed to an equivalent grammar without left recursion --
equivalent in terms of the language recognized -- but _not_ in the
parse trees. Linguists in particular care about parses. Therefore, it was
linguists who developed the parser
> > That said, to express foldl via foldr, we need a higher-order
> > fold. There are various problems with higher-order folds, related to
> > the cost of building closures. The problems are especially severe
> > in strict languages or strict contexts. Indeed,
> >
> > foldl_via_foldr f z l = fol
As others have pointed out, _in principle_, foldr is not at all
deficient. We can, for example, express foldl via foldr. Moreover, we
can express head, tail, take, drop and even zipWith through
foldr. That is, the entire list processing library can be written in
terms of foldr:
http://okm
Dmitry Kulagin wrote:
> I try to implement little typed DSL with functions, but there is a problem:
> compiler is unable to infer type for my "functions".
One way to avoid the problem is to start with the tagless final
representation. It imposes fewer requirements on the type system, and
is a qu
Petr Pudlak wrote:
> could somebody recommend me study materials for learning Hindley-Milner
> type inference algorithm I could recommend to undergraduate students?
Perhaps you might like a two-lecture course for undergraduates, which
uses Haskell throughout
http://okmij.org/ftp/Haskell
Magiclouds asked how to build values of data types with many
components from a list of components. For example, suppose we have
data D3 = D3 Int Int Int deriving Show
v3 = [1::Int,2,3]
How can we build the value D3 1 2 3 using the list v3 as the source
for D3's fields? We can't u
Johan Tibell posed an interesting problem of incremental XML parsing
while still detecting and reporting ill-formedness errors.
> What you can't have (I think) is a function:
>
> decode :: FromJSON a => ByteString -> Maybe a
>
> and constant-memory parsing at the same time. The return type her
I am doing, for several months, constant-space processing of large XML
files using iteratees. The file contains many XML elements (which are
a bit complex than a number). An element can be processed
independently. After the parser finished with one element, and dumped
the related data, the process
Alex Stangl wrote:
> To make this concrete, here is the real solve function, which computes
> a border array (Knuth-Morris-Pratt failure function) for a specified
> string, before the broken memoization modification is made:
> solve :: String -> String
> solve w = let h = length w - 1
>
Alex Stangl posed a problem of trying to efficiently memoize a
function without causing divergence:
> solve = let a :: Array Int Int
> a = listArray (0, 3) (0 : f 0)
> f k = if k > 0
> then f (a!0)
> else 0 : f 1
> in (interca
Takayuki Muranushi wrote:
> Today, I encountered a strange trouble with higher-rank polymorphism. It
> was finally solved by nominal typing. Was it a bug in type checker? lack of
> power in type inference?
> runDB :: Lens NetworkState RIB
> runDB = lens (f::NetworkState -> RIB) (\x s -> s { _run
> I was playing with the classic example of a Foldable structure: Trees.
> So the code you can find both on Haskell Wiki and LYAH is the following:
>
> data Tree a = Empty | Node (Tree a) a (Tree a) deriving (Show, Eq)
>
> instance Foldable Tree where
> foldMap f Empty = mempty
> foldMap f
Andreas Abel wrote:
> I tell them that monads are for sequencing effects; and the
> sequencing is visible clearly in
>
>(>>) :: IO a -> IO b -> IO b
>(>>=) :: IO a -> (a -> IO b) -> IO b
>
> but not in
>
>fmap :: (a -> b) -> IO a -> IO b
>join :: IO (IO a) -> IO a
Indeed! I'd lik
> And HList paper left me with two questions. The first one is how much
> such an encoding costs both in terms of speed and space. And the
> second one is can I conveniently define a Storable instance for
> hlists. As I said before, I need all this machinery to parse a great
> number of serialized
First of all, MigMit has probably suggested the parameterization of
Like by the constraint, something like the following:
data Like ctx = forall a. (ctx a, Typeable a) => Like a
instance ALike (Like ALike) where
toA (Like x) = toA x
instance CLike (Like CLike) where
toC (Like x) = toC x
Sorry for a late reply.
> There are of course more total functions of type `[a]^n -> [a]` than of type
> `[a] -> [a]`, in the sense that any term of the latter type can be assigned
> the
> former type. But, on the other hand, any total function `f :: [a]^n -> [a]`
> has an "equivalent" total fun
> 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
> 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
Inducti
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 ex
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 ->
Florian Lorenzen wrote:
> Now, I'd like to have a function
> > typecheck :: Exp -> Maybe (Term t)
> > typecheck exp = <...>
> that returns the GADT value corresponding to `exp' if `exp' is type
> correct.
Let us examine that type:
typecheck :: forall t. Exp -> Maybe (Term t)
Do you rea
> I am currently trying to rewrite the Graphics.Pgm library from hackage
> to parse the PGM to a lazy array.
Laziness and IO really do not mix.
> The problem is that even using a lazy array structure, because the
> parser returns an Either structure it is only possible to know if the
> parser
Let me see if I understand. You have events of different sorts: events
about players, events about timeouts, events about various
messages. Associated with each sort of event is a (potentially open)
set of data types: messages can carry payload of various types. A
handler specifies behavior of a s
Corentin Dupon wrote about essentially the read-show problem:
> class (Typeable e) => Event e
>
> data Player = Player Int deriving (Typeable)
> data Message m = Message String deriving (Typeable)
>
> instance Event Player
>
> instance (Typeable m) => Event (Message m)
>
> viewEv
Matthew Steele asked why foo type-checks and bar doesn't:
> class FooClass a where ...
>
> foo :: (forall a. (FooClass a) => a -> Int) -> Bool
> foo fn = ...
>
> newtype IntFn a = IntFn (a -> Int)
>
> bar :: (forall a. (FooClass a) => IntFn a) -> Bool
> bar (IntFn fn) = foo fn
This
> Consider code, that takes input from handle until special substring matched:
>
> > matchInf a res s | a `isPrefixOf` s = reverse res
> > matchInf a res (c:cs) = matchInf a (c:res) cs
> > hTakeWhileNotFound str hdl = hGetContents hdl >>= return.matchInf str []
>
> It is simple,
> It's only a test case. The real thing is for a game and will be
> something like:
> class EntityT e where
>update :: e -> e
>render :: e -> IO ()
>handleEvent :: e -> Event -> e
>getBound:: e -> Maybe Bound
> data Entity = forall e. (EntityT e) => Entity e
> data
> data A = A deriving Show
> data B = B deriving Show
> data C = C deriving Show
>
> data Foo = forall a. Show a => MkFoo a (Int -> Bool)
>
> instance Show Foo where
>show (MkFoo a f) = show a
I'd like to point out that the only operation we can do on the first
argument of MkFoo is to show to
Timo von Holtz wrote:
> class Test a where
> foo :: Monad m => m a
>
> instance Num a => Test a where
> foo = return 1
>
> instance Test Int where
> foo = return 2
>
> test constr = fromConstrM foo constr
I'm afraid the type checker is right. From the type of fromConstrM
fromConstrM :: f
Anthony Clayden wrote:
> So three questions in light of the approach of abandoning FunDeps and
> therefore not getting interference with overlapping:
> A. Does TTypeable need to be so complicated?
> B. Is TTypeable needed at all?
> C. Does the 'simplistic' version of type equality testing suffer p
System/Posix/DynamicLinker/Module/ByteString.hsc and
System/Posix/DynamicLinker/Prim.hsc sources in unix-2.5.1.0 package
contains the following reference to GPL-2 c2hs package:
-- Derived from GModule.chs by M.Weber & M.Chakravarty which is part of
c2hs
-- I left the API more or less the same, m
> I think instead you should have:
> - abandoned FunDeps
> - embraced Overlapping more!
Well, using TypeCast to emulate all FunDeps was demonstrated three
years later after HList (or even sooner -- I don't remember when
exactly the code was written):
http://okmij.org/ftp/Haskell/TypeClass.html#H
> did you see this, and the discussion around that time?
> http://www.haskell.org/pipermail/haskell-prime/2012-May/003688.html
>
> I implemented hDeleteMany without FunDeps -- and it works in Hugs (using
> TypeCast -- but looks prettier in GHC with equality constraints).
I'm afraid I didn't see
Ryan Ingram wrote:
> I've been seeing this pattern in a surprising number of instance
> definitions lately:
>
> instance (a ~ ar, b ~ br) => Mcomp a ar b br [1]
> instance (b ~ c, CanFilterFunc b a) => CanFilter (b -> c) a [2]
And here are a few more earlier instances of the same occurrence:
> However, if your are using ExtendedDefaultRules then you are likely to
> know you are leaving the clean sound world of type inference.
First of all, ExtendedDefaultRules is enabled by default in
GHCi. Second, my example will work without ExtendedDefaultRules, in
pure Haskell98. It is even shor
> > Exercise: how does the approach in the code relate to the approaches
> > to sharing explained in
> > http://okmij.org/ftp/tagless-final/sharing/sharing.html
> >
> Chapter 3 introduces an implicit impure counter, and Chapter 4 uses a
> database that is passed around.
> let_ in Chapter
> http://en.pk.paraiso-lang.org/Haskell/Monad-Gaussian
> What do you think? Will this be a good approach or bad?
I don't think it is a Monad (or even restricted monad, see
below). Suppose G a is a `Gaussian' monad and n :: G Double is a
random number with the Gaussian (Normal distribution). Then
>1. Haskell's type inference is NON-COMPOSITIONAL!
Yes, it is -- and there are many examples of it. Here is an example
which has nothing to do with MonomorphismRestriction or numeric
literals
{-# LANGUAGE ExtendedDefaultRules #-}
class C a where
m :: a -> Int
instance C () where
m
The bad news is that indeed you don't seem to be able to do what you
want. The good news: yes, you can. The enclosed code does exactly what
you wanted:
> sunPerMars :: NonDet Double
> sunPerMars = (/) <$> sunMass <*> marsMass
>
> sunPerMars_run = runShare sunPerMars
> sunPerMars_run_len = length
Tillmann Rendel has correctly noted that the source of the problem is
the correlation among the random variables. Specifically, our
measurement of Sun's mass and of Mars mass used the same rather than
independently drawn samples of the Earth mass. Sharing (which
supports what Functional-Logic prog
> And yes to first order predicate calculus too!
Just two weeks ago Chung-chieh Shan and I were explaining at NASSLLI
the embedding in Haskell of the higher-order predicate logic with two
base types (so-called Ty2). The embedding supports type-safe
simplification of formulas (which was really nee
> Do you know why they switched over in GHC 6.6?
If I were to speculate, I'd say it is related to GADTs. Before GADTs,
we can keep conflating quantified type variables with schematic type
variables. GADTs seem to force us to make the distinction.
Consider this code:
data G a where
GI :: Int
Kangyuan Niu wrote:
> Aren't both Haskell and SML translatable into System F, from which
> type-lambda is directly taken?
The fact that both Haskell and SML are translatable to System F does
not imply that Haskell and SML are just as expressive as System
F. Although SML (and now OCaml) does have
Nicolas Trangez wrote
> The protocol I'd like to implement is different: it's long-running using
> repeated requests & responses on a single client connection. Basically,
> a client connects and sends some data to the server (where the length of
> this data is encoded in the header). Now the serv
Yves Pare`s wrote:
> So I'm trying to make a type level function to test if a type list contains
> a type. Unless I'm wrong, that calls to the use of a type family.
More crucially, list membership also calls for an equality
predicate. Recall, List.elem has the Eq constraint; so the type-level
mem
> i think what i will do is to instantiate all table types individually:
> | instance Show c => Show (SimpleTable c) where
> | showsPrec p t = showParen (p > 10) $ showString "FastTable " .
> | shows (toLists t)
I was going to propose this solution, as we
Victor Miller wrote:
> I was writing a Haskell program which builds a large labeled binary tree
> and then does some processing of it, which is fold-like. In the actual
> application that I have in mind the tree will be *huge*. If the whole tree
> is kept in memory it would probably take up 100'
> | instance (Table a c, Show c) => Show a where
> I would have thought that there is on overlap: the instance in my code
> above defines how to show a table if the cell is showable;
No, the instance defines how to show values of any type; that type
must be an instance of Table. There is no `if'
Ben wrote:
> - use Data.Unique to identify Refs, and use existential quantification
> or Data.Dynamic to create a heterogenous Map from uid to log. for
> example, to represent a log of compare-and-swaps we might do something
> like
> data Ref a = Ref (IORef a) Unique
> data OpaqueCAS = forall a
> I thoutgh on the use or ErrorT or something similar but the fact is
> that i need many bacPoints, not just one. That is, The user can go
> many pages back in the navigation pressing many times te back
> buttton.
The approach in the previous message extends to an arbitrary,
statically unknown nu
Alberto G. Corona wrote about a monad to set a checkpoint and be able
to repeatedly go to that checkpoint and re-execute the computations
following the checkpoint.
http://haskell-web.blogspot.com.es/2012/03/failback-monad.html
The typical example is as follows.
> test= runBackT $ do
>l
> At present we can easily express different flavors of conjunction, but
> expressing disjunction is hard.
Disjunction is not particularly difficult. See, for example,
http://okmij.org/ftp/Haskell/TTypeable/TTypeable.hs
and search for ORELSE. The code demonstrates higher-order type-lev
> How do I add type annotations to interior locations in an abstract
> syntax tree?
> i.e. the type it [algorithm] infers is the type of the whole
> program, I would also like the types of any internal let-rec
> definitions so I can label my AST.
I had exactly the same problem: type reconstr
hat file A is closed before file B is opened?
To which the user tibbe replied
> You can typically explicitly close the files as well.
and the user dobryak commented
> Regions that Oleg refers to started out with region-based memory allocation,
> which is effectively a stack allocation strate
First of all, ListT is not a monad transformer, since it breaks the
law of associativity of bind:
*Control.Monad.List> let one = (lift $ putStrLn "1") :: ListT IO ()
*Control.Monad.List> let two = (lift $ putStrLn "2") :: ListT IO ()
*Control.Monad.List> let choice = return 1 `mplus` return 2 ::
Regions is an automatic resource management technique that statically
ensures that all allocated resources are freed and a freed resource
cannot be used. Regions also promote efficiency by helping to structure
the computation so that resources will be freed soon, and en
masse. Therefore, regions a
One should keep in mind the distinction between schematic variables
(which participate in unification) and universally quantified
variables. Let's look at the forall-elimination rule
G |- e : forall a. A
E
G |- e : A[a := t]
If the term e has the typ
ACM SIGPLAN 2012 Workshop on Partial Evaluation and Program Manipulation
http://www.program-transformation.org/PEPM12
January 23-24, 2012. Philadelphia, PA, USA (co-located with POPL'12)
Second Call For Participation
Program is now available
http://www.program-transformation.or
Evan Laforge has defined
> data Thing {
> thing_id :: ThingId
> , thing_stuff :: Stuff
> }
> newtype ThingId = ThingId String
and wishes to statically preclude binary operations with things that
have different ThingIds. However, Things and their Ids can be loaded
from files and so cannot be
ACM SIGPLAN 2012 Workshop on Partial Evaluation and Program Manipulation
http://www.program-transformation.org/PEPM12
January 23-24, 2012. Philadelphia, PA, USA (co-located with POPL'12)
Call For Participation
Online registration is open at
https://regmaster3.com/2012conf/POPL12
I would recommend Ralf Hinze's ICFP00 Pearl
Deriving Backtracking Monad Transformers
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.4164
He starts with a monad transformer expressed as a free term algebra,
and shows step-by-step how to transform it to a more efficient
Multi-parameter type classes are more flexible. Here is how you can
write your old code:
> {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
>
> class (ClassA a, ClassB b) => ClassC a b where
> from :: a -> [b]
> to :: a -> [b]
>
> data H = H
>
> class ClassA a where toInt :: a -> I
1 - 100 of 429 matches
Mail list logo
