On 1/24/12 5:51 PM, Vincent Hanquez wrote:
On 01/24/2012 07:33 AM, Gregory Crosswhite wrote:
On 1/24/12 9:43 AM, Felipe Almeida Lessa wrote:
Use cereal [1], usually it's fast and easy enough.
Out of curiosity, is binary no longer the recommended standard for
such things?
binary got
On 1/24/12 9:43 AM, Felipe Almeida Lessa wrote:
Use cereal [1], usually it's fast and easy enough.
Out of curiosity, is binary no longer the recommended standard for such
things?
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 01/20/12 14:52, Michael Snoyman wrote:
> Essentially, I would want:
>
> SomeConstr args <- someAction
>
> to be interpreted as:
>
> temp <- someAction
> case temp of
> SomeConstr args ->
I completely agree; perhaps what we really want though is something
more akin to a language extension -
On 01/20/12 13:23, Edward Z. Yang wrote:
> In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable
> (it can't fail to match). But the Haskell 1.4 story is unattractive
> becuase
> a) we have to introduce the (new) concept of unfailable
> b) if you a
Today I learned (tldr; TIL) that the "fail" in the Monad class was added
as a hack to deal with the consequences of the decision to remove
"unfailable" patterns from the language. I will attempt to describe the
story as I have picked it up from reading around, but please feel free
to correct me on
On 01/12/12 16:58, Magicloud Magiclouds wrote:
> Yes, that is a problem. But consider my PS in original mail, I have no
> idea what exception should I catch. Where could I get that
> information?
In my experience, exceptions fall into three categories.
First, when performing IO, some functions th
On 01/12/12 17:23, Gregory Crosswhite wrote:
> Indeed, and in fact this situation is a very natural occurrence whenever
> you are writing code that takes an arbitrary IO action, executes it, and
> then returns either the result or the exception that it threw. The code
> that I last u
On 01/12/12 17:07, Simon Hengel wrote:
> I think there are situation when it is justified to catch almost all
> exceptions. And people do that a lot, which often leads to ctrl-c not
> properly working (e.g. we had this in HUnit before 1.2.4.2).
Indeed, and in fact this situation is a very natura
On 01/12/12 16:49, Ivan Lazar Miljenovic wrote:
> But it is usually recommended that you *don't* do this, as it even
> captures Ctrl-c invocations:
Is that true in all threads, or just in the main thread?
Cheers,
Greg
___
Haskell-Cafe mailing list
Haske
On 01/12/12 13:03, Magicloud Magiclouds wrote:
> Hi,
> With Prelude.catch, I could write "catch () $ \_ -> return Nothing".
> But with Control.Exception.catch, I must specify a type for the "_".
> What should I do?
Use SomeException for the type, as it is the base of the exception
hierarchy.
(A
On Dec 24, 2011, at 6:47 PM, Murray Campbell wrote:
> It's too late to avoid success at all costs but please don't banish our
> precious pedantry!
>
> Scare on!
Please don't misunderstand, I have absolutely no problems at all with people
arguing voraciously and pedantically over ideas, as long
On Dec 24, 2011, at 6:22 PM, Tony Morris wrote:
> Wait what?
>
> I find it intriguing, helpful, provocative and potentially helpful toward the
> common goal of helping others. I am interested in further commentary. I'm not
> scared and you shouldn't be either.
Asking honest questions is immin
On Dec 22, 2011, at 12:40 PM, Alexander Solla wrote:
>
> fst _|_ = _|_
>
> This expression is basically non-sense.
This is only "nonsense" because you refuse to accept that there are valid
formalisms other than your own that contain _|_ as a perfectly valid entity.
:-)
> Should we a
On Dec 22, 2011, at 12:25 PM, Alexander Solla wrote:
> It is not "limiting" to make distinctions that capture real differences. An
> overly broad generalization limits what can be proved. Can we prove that
> every vehicle with wheels has a motor? Of course not -- bicycles exist. Can
> we p
On Dec 20, 2011, at 11:18 PM, Heinrich Apfelmus wrote:
> Tillmann Rendel wrote:
>> Hi,
>> Robert Clausecker wrote:
>>> Image you would create your own language with a paradigm similar to
>>> Haskell or have to chance to change Haskell without the need to keep any
>>> compatibility. What stuff wou
On Dec 21, 2011, at 6:52 PM, Fedor Gogolev wrote:
> Hello. I'm trying to get some threads that I can stop and get last
> values that was computed (and that values are IO values, in fact).
> Here is my first approach:
> [...]
> tick :: Int -> IO Int
> tick v = return $ v + 1
> [...]
> The problem
On Dec 21, 2011, at 8:52 AM, Jesse Schalken wrote:
> I don't have experience with proof assistants, but maybe my answer to this
> thread can be summed up as giving Haskell that kind of capability. ;)
Okay, then suffice it to say that most of what you said *is* implemented in
real languages li
On Dec 21, 2011, at 2:24 PM, Alexander Solla wrote:
> I would rather have an incomplete semantic, and have all the incomplete parts
> collapsed into something we call "bottom". We can then be smart and stay
> within a total fragment of the language (where bottom is guaranteed to not
> occur).
On Dec 21, 2011, at 2:14 PM, scooter@gmail.com wrote:
> I'd suggest, in addition to the symbols, renaming some of the fundamental
> types and concepts, like Monad. I would violently agree that Monad is the
> correct term, but try to communicate with a commodity software developer
> sometim
On Dec 20, 2011, at 11:21 PM, Jesse Schalken wrote:
> On Tue, Dec 20, 2011 at 10:43 PM, Gregory Crosswhite
> wrote:
>
> On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:
>
>> Why do you have to solve the halting problem?
>
> You have to solve the halting pro
On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:
> Why do you have to solve the halting problem?
You have to solve the halting problem if you want to replace every place where
_|_ could occur with an Error monad (or something similar), because _|_
includes occasions when functions will never
On Dec 20, 2011, at 8:38 PM, Ben Lippmeier wrote:
> Some would say that non-termination is a computational effect, and I can
> argue either way depending on the day of the week.
*shrug* I figure that whether you call _|_ a value is like whether you accept
the Axiom of Choice: it is a situati
On Dec 20, 2011, at 8:40 PM, Jesse Schalken wrote:
> If you think a value might not reduce, return an error in an error monad.
Okay, I'm completely convinced! Now all that we have to do is to solve the
halting problem to make your solution work... :-)
Cheers,
Greg
On Dec 20, 2011, at 8:30 PM, Jesse Schalken wrote:
>
>
> On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier wrote:
>
> On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:
>
> > In denotational semantics, every well-formed term in the language must
> > have a value. So, what is a value of "fix id"?
On Dec 20, 2011, at 8:05 PM, Tillmann Rendel wrote:
> Hi,
>
> Robert Clausecker wrote:
>> Image you would create your own language with a paradigm similar to
>> Haskell or have to chance to change Haskell without the need to keep any
>> compatibility. What stuff would you add to your language, w
On Dec 20, 2011, at 5:20 AM, Robert Clausecker wrote:
> What stuff would you add to your language
Gratuitous use of parentheses.
Cheers,
Greg___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Dec 19, 2011, at 4:45 PM, Gregory Crosswhite wrote:
> First, there needs to be lots of [STRUCTURE] that makes it easy for people to
> skim through and pick out the specific information that they want to find out
> about [...]
Grr! I have no idea why that word got dropped out, sin
On Dec 19, 2011, at 3:49 PM, Richard O'Keefe wrote:
> On 19/12/2011, at 5:46 PM, Gregory Crosswhite wrote:
> [improved Monoid documentation]
Thank you. :-)
> I would go so far as to point out that "mappend is a generalisation of
> Data.List.sum, Data.List.produ
On Dec 19, 2011, at 1:01 PM, Richard O'Keefe wrote:
> Documentation for a library module needs to start by telling people what
> it is for. For a particular function, someone needs to know very quickly
> "is this what I am looking for? is this the kind of thing I _should_ have
> been looking for
On Dec 19, 2011, at 1:01 PM, Richard O'Keefe wrote:
>
> On 19/12/2011, at 3:44 PM, Gregory Crosswhite wrote:
>> So what do you all think about my own suggestion for the documentation?
>
> It is an improvement.
>
> Documentation for a library module needs to star
On Dec 19, 2011, at 1:03 PM, Alexander Solla wrote:
> The "incidental" comment is significantly more clear than an English
> description.
That is only true for someone who has already seen a sentence like that one
before and so can immediately pick up what it is getting at. :-) In
particula
On Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:
> On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe wrote:
> No. Not by a country mile.
> It's better than "non-existent".
> It's better than "misleading".
> But it's not even on the same *continent* as "adequate".
>
> +1
So what do you all t
On Dec 17, 2011, at 9:58 AM, Thomas Schilling wrote:
> Wll... I've gotten a little bit of a different perspective on this
> since working at a company with very high code quality standards (at
> least for new code). There is practically no observable code review
> happening. I'm sure Dimitr
On Dec 17, 2011, at 2:57 PM, Gregory Crosswhite wrote:
> +1 for this idea, because it follows the principle of least surprise.
Sorry about the double-post! I was foolish enough not only to use
unsafePerformIO to send my e-mail, but to forgot to mark the sending routine
with NOINLINE pra
On Dec 17, 2011, at 12:51 PM, Matthew Farkas-Dyck wrote:
> By my reason, the instance (Monoid a => Monoid (Maybe a)) is
> appropriate, since we have another class for inner-type-agnostic
> choice -- Alternative! (and MonadPlus, but that's essentially the
> same, and would be if (Functor m => Appl
On Dec 17, 2011, at 1:26 AM, Yves Parès wrote:
> "1) What about the First type? Do we {-# DEPRECATE #-} it?"
>
> Personnaly, I'm in favor of following the same logic than Int:
> Int itself is not a monoid. You have to be specific: it's either Sum or Mult.
>
> It should be the same for Maybe: we
On Dec 17, 2011, at 1:26 AM, Yves Parès wrote:
> "1) What about the First type? Do we {-# DEPRECATE #-} it?"
>
> Personnaly, I'm in favor of following the same logic than Int:
> Int itself is not a monoid. You have to be specific: it's either Sum or Mult.
>
> It should be the same for Maybe: we
On Dec 17, 2011, at 12:35 PM, Matthew Farkas-Dyck wrote:
> (1) If we do (4), then the documentation ought to be adequate as-is.
I see your point that if we do (4) then some and many are no longer problematic
for Maybe and [], and thus we don't need warnings for those types. However,
nonethele
On Dec 16, 2011, at 3:59 AM, Carl Howells wrote:
> Monoid and Alternative are not the same. There is a very important
> difference between them:
>
> class Alternative f where
>(<|>) :: f a -> f a -> f a
>...
>
> class Monoid a where
>mappend :: a -> a -> a
>...
>
> The equival
On Dec 16, 2011, at 3:34 AM, Bryan O'Sullivan wrote:
> This is both confusing and incorrect. It's entirely possible for an action in
> the Maybe type to fail.
Okay, so inserting the phrases "that either fail eventually or" and "that
succeed forever if they do not immediately fail" so that that
On Dec 15, 2011, at 9:31 PM, malcolm.wallace wrote:
> I do not regard that as a change in their semantics - it is perfectly allowed
> already Indeed, the instances of some/many that I write are already
> lazily-unfolding, wherever possible. It all depends simply on whether your
> instance of
Hey everyone,
First, thank you all for this great discussion! I unfortunately have been home
due to health concerns which gets really boring after a while, so being able to
participate in such a fun intellectual exercise like has really been making my
day. :-D Sorry that this has resulted in
On Dec 15, 2011, at 6:19 PM, Gregory Crosswhite wrote:
> After all, we already have the Monad typeclass which gives them essentially
> the same functionality.
Make that the *Monoid* typeclass. :-)
Cheers,
Greg___
Haskell-Cafe mailing list
H
On Dec 15, 2011, at 5:40 PM, Antoine Latter wrote:
> I said 'combinators', not 'instances'.
Oh! Okay, that was my bad then.
> A lot of popular parsers
> combinators can be written exclusively from (<|>) and empty, but make
> little sense for List and Maybe, and may not even function properly.
Hey everyone!
First of all, it sounds like we all agree that the documentation for
Alternative needs to be improved; that alone would clear a lot of the
confusion up.
I think that a fairly convincing case has also been made that removing
many/some from the typeclass doesn't help too much sinc
On Dec 15, 2011, at 4:29 PM, Chris Wong wrote:
>> Okay, so how about the following as a user narrative for some and many?
>>
>> ...
>
> I was in the middle of writing my own version of Applicative when I
> stumbled on this intense debate. Here's what I wrote for the
> documentation:
>
> class
On Dec 15, 2011, at 3:36 PM, Antoine Latter wrote:
> That's the interesting thing about type-classes like Alternative and
> Functor - they mean very little, and are used in widely varying
> contexts.
So... your point is that in the Haskell community we don't tend to care about
whether our types
On Dec 15, 2011, at 2:13 PM, Antoine Latter wrote:
> Isn't this what Ross previously suggested? I think his suggested
> instance methods for Maybe return the elements of the lists
> incrementally.
Yes and no. Yes, his excellent suggestion is one of my favorite ideas for what
we should do with
Hey everyone,
This is even more out there than my previous posts, but the following just
occurred to me: is it absolutely necessary that some/many have produced the
entire list of results before returning? Couldn't we change their semantics so
that the list of results is computed and/or extra
Okay, so how about the following as a user narrative for some and many?
many v = repeatedly execute the action v and save each obtained result
until v fails; at that point, *succeed* and return a list with all of the
results that had been collected
some v = like many v, but if v
On Dec 15, 2011, at 12:52 PM, Brandon Allbery wrote:
> These statements are not mutually logically consistent, and leave me
> wondering if Applicative and/or Alternative have been fully thought out.
Oh, that particular question is *super*-easy to answer: based on what I've
been reading, they
On Dec 15, 2011, at 12:36 PM, Antoine Latter wrote:
> Although I'm still not sure why I would be using these operations in
> maybe or list.
You probably wouldn't use these operations directly on Maybe or List, but the
whole point is that when you are using a typeclass you have cannot assume tha
On Dec 15, 2011, at 12:03 PM, Ross Paterson wrote:
> The current definition says that some and many should be the least
> solutions of the equations
>
>some v = (:) <$> v <*> many v
>many v = some v <|> pure []
>
> We could relax that to just requiring that they satisfy these equations
On Dec 15, 2011, at 3:37 AM, Bryan O'Sullivan wrote:
> But that's precisely what the Alternative class is already for! If you are
> writing an Alternative instance at all, then you are asserting that it must
> be possible and reasonable to replicate the existing behaviour of some and
> many.
On Dec 14, 2011, at 4:40 PM, Ivan Lazar Miljenovic wrote:
> [...] Apart from some
> basic combinators in Control.Monad or the definitions of monad
> transformers, how much of what you write in do-blocks is applicable to
> some generic Monad instance as opposed to a specific Monad?
Well, if my *o
On Dec 13, 2011, at 3:32 AM, Bryan O'Sullivan wrote:
> Don't be silly. The purpose of some and many is to be used with combinators
> that are expected to fail sometimes. If you use them with combinators that
> always succeed, of course you're going to get an infinite loop.
Yes, but how can som
On Dec 14, 2011, at 8:38 AM, Thomas Schilling wrote:
> On 12 December 2011 22:39, Antoine Latter wrote:
>> But now they look as if they are of equal importance with the other
>> class methods, which is not really true.
>
> Maybe, but something like this is best fixed by improving
> documentatio
On Dec 13, 2011, at 5:09 AM, Bryan O'Sullivan wrote:
> Correct. And your example of "some (Just 1)" inflooping was not a
> counterargument, but rather an illustration that perhaps some people (and I'm
> not trying to imply you here, don't worry) don't understand what some and
> many are suppos
On Dec 13, 2011, at 5:09 AM, Bryan O'Sullivan wrote:
> Correct. And your example of "some (Just 1)" inflooping was not a
> counterargument, but rather an illustration that perhaps some people (and I'm
> not trying to imply you here, don't worry) don't understand what some and
> many are suppos
On Dec 13, 2011, at 3:06 AM, Bryan O'Sullivan wrote:
> There is absolutely no implication of consuming anything in the definitions
> of many or some. This is how they happen to behave when used in the context
> of some parsing libraries, but that's all. If many or some always go into an
> infi
Hey everyone!
So, I was on LtU reading about F*
http://lambda-the-ultimate.org/node/4318
and an idea just occurred to me which *must* have occurred to someone smarter
than me, so I would love your feedback on the following question:
Could Haskell be extended to support linear/affine ty
Hey everyone,
I am sure that it is too late to do more than idly speculate about this, but
could we split the some/many methods out from Alternative? They simply don't
make sense except in a subset of possible Alternatives --- in most cases they
just result in an infinite loop. That is to say
Purely out of curiosity, would it be more efficient for GHC to use the new
built-in exception handling instructions in LLVM?
http://blog.llvm.org/2011/11/llvm-30-exception-handling-redesign.html
Cheers,
Greg___
Haskell-Cafe mailing list
Haskell
Hey everyone,
I have uploaded a number of small packages to Hackage that I no longer actively
use so that I don't find out immediately when a new version of GHC has broken
them. Since Hackage is going to the trouble of finding out when a package no
longer builds anyway, could it have a feature
Hey everyone,
What is the difference between MonadPlus and Alternative? In my mind, it would
make sense for the difference to be that the former provides "and" semantics
(i.e., x `mplus` y means do both x and y) whereas the latter provides "or"
semantics (i.e., x <|> y means do x or y but not
On 7/11/11 11:18 AM, Yitzchak Gale wrote:
The standard way to create a Typeable instance is
just to derive it. If you do that, you will not be affected
by this change.
This is only the "standard way" if one is willing to sacrifice Haskell98
or Haskell2010 compatibility by using the non-standa
On 5/31/11 12:49 PM, Scott Lawrence wrote:
I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy.
Whether they are lazy or not depends entirely on the definition of the
monad. For example, if you look up the ST and State monads you will
find th
On 5/28/11 10:11 AM, Alex Rozenshteyn wrote:
Since no-one has yet mentioned it, and I think it might be relevant,
http://types.bu.edu/seminar-modularity/first-class-modules-for-haskell.pdf
I haven't read it with any degree of understanding, but I don't think
it's tractable to remove modules fr
Hey everyone,
Okay, this will sound silly, but I ventured into the Scala mailing list
recently and asked an ignorant question on it, and I was shocked when
people reacted not by enlightening me but by jumping on me and reacting
with hostility. I bring this up not to badmouth the Scala communi
On 05/23/2011 12:08 PM, Brent Yorgey wrote:
Just a minor quibble: note that
> filter (not . isNothing)
is slightly preferable since it does not introduce a frivolous
equality constraint on the type wrapped by the Maybe.
Or even better,
filter isJust
:-)
Cheers,
Greg
-> [a]"
Click on first result.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 5/23/11 9:25 AM, Gregory Crosswhite wrote:
On 5/23/11 9:20 AM, michael rice wrote:
What's the best
On 5/23/11 9:20 AM, michael rice wrote:
What's the best way to end up with a list composed of only the Just
values,
no Nothings?
Try catMaybes in Data.Maybe.
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.o
On 5/20/11 8:35 AM, Jeremy O'Donoghue wrote:
I would like to suggest, quite seriously, that the Haskell community
try to come to a consensus about supporting a single Haskell GUI, with
a view to distribution in the HP. Obviously my vote is for wxHaskell,
but I'm quite prepared to loose the vote
o much
trouble. I use it in a mixed Haskell, C++, Scala and Python build. If
there is interest I could conceivably clean up the ghc waf tool and
release it.
On Sat, May 14, 2011 at 5:32 PM, Gregory Crosswhite
mailto:gcr...@phys.washington.edu>> wrote:
On 5/14/11 1:25 PM, Maciej M
On 5/14/11 1:25 PM, Maciej Marcin Piechotka wrote:
(to mention
one which is often neglected - parallel build).
While I do appreciate you stepping in to defend autotools (if for no
other reason then because someone has to so that the discussion is
balanced :-) ), I think that you are wrong to
On 5/11/11 3:11 PM, Bryan O'Sullivan wrote:
It's a fairly terrible piece of software.
My experience is that it is the only cross-platform build system I have
used to date that hasn't made my eyes bleed, though I only use it for
C/C++/Fortran. I suppose that counts as a personal testimonial in
On 2/11/11 1:25 PM, Luke Palmer wrote:
I would like to see a language
that allowed optional verification, but that is a hard balance to make
because of the interaction of non-termination and the evaluation that
needs to happen when verifying a proof.
I believe that ATS (short for Advanced Type
On 1/12/11 5:05 AM, Ketil Malde wrote:
Of course, ideally you should design your types so that all possible
values are meaningful:-)
Sadly we cannot all program in Agda. :-)
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http:/
On 12/24/10 4:08 PM, Andrew Coppin wrote:
Gotta love the way that this is THE MOST COMMON USE CASE for kill, and
yet kill itself doesn't support doing this.
The problem with killing processes by name is that names aren't unique,
so you might unintentionally end up killing other processes that
Take a look at the monad-loops package.
Cheers,
Greg
On 12/13/2010 06:15 AM, Jacek Generowicz wrote:
-- Is it possible to rewrite code written in this style
untilQuit = do
text <- getLine
report text
if text == "quit"
then return ()
else untilQuit
-- in a style using higher o
On 11/21/10 10:48 PM, Magicloud Magiclouds wrote:
Hi,
For example, I have a data A defined. Then I want to add (+) and (-)
operators to it, as a sugar (compared to addA/minusA). But * or other
stuff defined in class Num is meanless to A. So I just do:
(+) :: A -> A -> A
(+) a b =
A (elem1
On 11/19/10 12:22 PM, Andrew Coppin wrote:
Use the Force
I tried, but I'm not yet strong enough in the Force to read citations
with my eyes closed. :-(
(PS: Thanks for pointing me to the paper, Simon!)
Cheers,
Greg
___
Haskell-Cafe mailing list
Ha
27;ll help motivate me to do the remaining work!
Thanks
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org]
| On Behalf Of Gregory Crosswhite
| Sent: 19 November 2010 19:23
| To: Haskell Cafe
| Subject: [Haskell-cafe] Impredica
Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw
in the documentation that Impredicative Types are still supported. Is
this true? I thought that they were on their way out because they
overcomplicated type checking; has this plan been changed?
Cheers,
Greg
__
On 11/11/10 12:07 PM, C. McCann wrote:
To retain sanity, either "types
that can be serialized" must be marked explicitly (perhaps in the
context, similar to having a Data.Typeable constraint) to indicate
potential non-parametric shenanigans
You mean, like Data.Binary?
Cheers,
Greg
On 11/6/10 6:38 AM, C K Kashyap wrote:
Thanks a lot Gregory and Daniel,
I think I'll go with the "mapM_ (putWord8 . fromIntegral . ord)" approach.
If your string has any chance of containing Unicode characters then you
will want to use the "encode" function in the module
"Codec.Binary.UTF8.
On 11/04/2010 03:06 PM, Dan Doel wrote:
Implementing type inference can be very easy in a logic language, because most
of the work in a non-logic language is implementing unification:
http://muaddibspace.blogspot.com/2008/01/type-inference-for-simply-typed-
lambda.html
3 lines of Prolog to
On 11/04/2010 03:30 PM, Lennart Augustsson wrote:
KRC, Miranda, and LML all predate Haskell and have list comprehensions.
Just because those languages predate Haskell and have list
comprehensions doesn't mean that they still couldn't have gotten the
idea from Haskel!. After all, I fully ant
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 give me or point me towards a good example
of such a case? I've been trying to
On 11/2/10 8:37 PM, wren ng thornton wrote:
Though I would suggest you look at the LogicT library instead of using
actual lists... Also, you may be interested in reading the LogicT
paper[2] or this paper[3] about search combinators in Haskell. Both
offer a number of optimizations you should be
I haven't ever used it myself, but I've heard good things about Lua,
which was designed to be an embedded scripting language for applications:
http://www.lua.org/
If you believe the Programming Language Shootout
(http://shootout.alioth.debian.org/) it is pretty fast for a dynamic
interpre
On 11/01/2010 06:19 PM, Richard O'Keefe wrote:
On 2/11/2010, at 1:27 PM, Gregory Crosswhite wrote:
Hey everyone,
This is a little off-topic, but I just ran into a problem which might benefit
from being attacked by a logic language,
Why not describe the problem?
My goal
Hey everyone,
This is a little off-topic, but I just ran into a problem which might
benefit from being attacked by a logic language, so I've been looking
for a good one to try out --- and hopefully one that has a very
efficient implementation since I want to iterate through billions and
poss
The expression
sequence [a,b,c,...]
is roughly equivalent to
do
r_a <- a
r_b <- b
r_c <- c
...
return [r_a,r_b,r_c,...]
The expression
sequence_ [a,b,c,...]
is roughly equivalent to
do
a
b
c
...
Also, this is a complete aside but what the heck. :-)
Has anyone else been driven crazy by the way that Java code and
libraries are documented? It seems like whenever I try to figure out
how to use a piece of Java code, the functionality is spread out over a
huge collection of classes and me
Or if you want to keep the advantages of a powerful type system, you can
use Scala.
Cheers,
Greg
On 10/28/10 9:53 PM, aditya siram wrote:
I understand your frustration at not having free tested libs
ready-to-go, Java/any-other-mainstream-language programmers tend to
expect this and usually ge
On 10/28/10 12:34 PM, Andrew Coppin wrote:
More specifically, I copied the Cabal description from another package
and then updated all the fields. Except that I forgot to update one.
And now I have a package which I've erroneously placed in completely
the wrong category.
I am glad to hear that
On 10/23/10 12:57 PM, Claude Heiland-Allen wrote:
On 23/10/10 17:42, Gregory Crosswhite wrote:
On 10/23/10 7:54 AM, John Lato wrote:
On Fri, Oct 22, 2010 at 6:16 PM, Bulat Ziganshin
This doesn't work, which was why the OP asked in the first place. When
a thread calls an unsafe fo
On 10/23/10 7:54 AM, John Lato wrote:
On Fri, Oct 22, 2010 at 6:16 PM, Bulat Ziganshin
mailto:bulat.zigans...@gmail.com>> wrote:
Hello John,
Monday, October 18, 2010, 8:15:42 PM, you wrote:
> If anyone is listening, I would very much like for there to be a
> mechanism by which
On 10/20/10 4:09 AM, Simon Peyton-Jones wrote:
No, this isn't optimised. The trouble is that you write (map Foo xs), but GHC
doesn't know about 'map'. We could add a special case for map, but then you'd
soon want (mapTree Foo my_tree).
How about a special case for fmap? That seems like it
1 - 100 of 299 matches
Mail list logo
