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 only
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
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/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 add
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 --- say,
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.
(Although
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
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 natural
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 used for this took
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
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
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 as
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 is that
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 would you add to
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 prove
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 accept
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, what
On Dec 20, 2011, at 8:30 PM, Jesse Schalken wrote:
On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier b...@ouroborus.net 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
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,
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
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 11:21 PM, Jesse Schalken wrote:
On Tue, Dec 20, 2011 at 10:43 PM, Gregory Crosswhite gcrosswh...@gmail.com
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 problem if you want
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
sometime
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 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
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 12:39 PM, Brandon Allbery wrote:
On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe o...@cs.otago.ac.nz 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
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
particular,
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 start by telling people what
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 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.product, Data.List.and, and Data.List.or
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, since
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,
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 remove
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 remove
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 =
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 pragma
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 Dimitrios
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
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.
The
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
Haskell
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
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
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 the
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 equivalent to
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
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 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
(which I
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 that
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
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
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
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
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 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 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
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 supposed to
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 supposed to
On Dec 14, 2011, at 8:38 AM, Thomas Schilling wrote:
On 12 December 2011 22:39, Antoine Latter aslat...@gmail.com 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
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
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
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
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
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
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
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
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
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
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 way to end up
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
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
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
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
. 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
gcr...@phys.washington.edu mailto:gcr...@phys.washington.edu wrote:
On 5/14/11 1:25 PM, Maciej
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
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
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
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
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] Impredicative Types
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
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
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/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
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
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
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
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
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
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
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
...
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
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
On 10/23/10 7:54 AM, John Lato wrote:
On Fri, Oct 22, 2010 at 6:16 PM, Bulat Ziganshin
bulat.zigans...@gmail.com 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
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 foreign
Since you are proposing creating an abstract type TExp that can't be
created manually in contrast to Exp, I have a question that might simply
be a reflection of ignorance on my part on how TH works now.
As far as I can tell by looking through the documentation, when I want
to create an
1 - 100 of 295 matches
Mail list logo
