Hi Mateusz,
I don't think my post was out of order at all and I don't understand
why it sparked such an... energetic response - that wasn't my intent
at all.
A friendly response might contain the things you told John, but it could
also be a bit more empathic, otherwise its easy to perceive
Perhaps x is evaluated earlier than you think, i.e. before the trace
(due to some strictness analysis?). But this is a just a guess.
I usually use trace outermost in my expression, not within a let. I
never had a problem with it:
fA :: SomeInput - SomeResult
fA a = trace (Entering fA) $ f
-- Hi-- I am trying to show that a set of propositions and a conclusion the form a valid argument.-- I used two approaches; 1) using if-then-else, 2) using pattern matching.-- The version using if-then-else seems to be consistent with my knowledge of Haskell and logic (either of which could be
i don't understand what you're trying to do with that code, however you
seem to be asking about theorem proving in general
check out
http://www.haskell.org/haskellwiki/Libraries_and_tools/Theorem_provers
and
http://en.wikipedia.org/wiki/Automated_theorem_proving
hope it helps
On Wed, May
Not exactly what you ask, but it is noteworthy that the mind has different
logic processors. The fastest one work with IF THEN ELSE rules applied
specifically to deals. This is why your example (and most examples of
logic) involves a kind of deal expressed in the first person. This trigger
a fast
The relation to theorem proving is the main motivation for
my question.
In am trying to understand why some equations are ok and
others not.
I suspect that in Haskell equations are definitions rather
than assertions.
If approach 2 is a non-starter in Haskell, then can approach
1, using
You can stop suspecting: in Haskell, equations ARE definitions.
On May 15, 2013, at 9:15 PM, Patrick Browne patrick.bro...@dit.ie wrote:
The relation to theorem proving is the main motivation for my question.
In am trying to understand why some equations are ok and others not.
I suspect
Thank you very much to everyone who responded on java integration.
I have a lot of work to do before I can conclude, but I will give
a quick summary just in case there is some general interest.
The most common approach appears to be a network interface between
separate java and haskell
To have a single-process ghc --make -j you first of all need internal
thread-safety:
GHC internally keeps a number of global caches that need to be made thread-safe:
- table of interned strings (this is actually written in C and
accessed via FFI)
- cache of interface files loaded, these are
LinkedIn
Daniel Díaz Casanueva requested to add you as a connection on LinkedIn:
--
Minh Thu,
I'd like to add you to my professional network on LinkedIn.
- Daniel
Accept invitation from Daniel Díaz Casanueva
My apologies,
I don't know how this e-mail has reached the Haskell-Cafe.
Sincerely,
Daniel Díaz.
On Wed, May 15, 2013 at 11:44 PM, Daniel Díaz Casanueva mem...@linkedin.com
wrote:
[image: LinkedIn Logo] http://www.linkedin.com/
Minh Thu,
**
Daniel Díaz
Hi,
Dnia 2013-05-16, czw o godzinie 00:25 +0200, Daniel Díaz Casanueva
pisze:
My apologies,
I don't know how this e-mail has reached the Haskell-Cafe.
Sincerely,
Daniel Díaz.
Some time ago Badoo has send similar email but different mailing list
(I don;t have account on facebook
Welcome to issue 267 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers the
week of April 28 to May 11, 2013.
Quotes of the Week
* ciaranm: a category is just a category in the category of
categories
* cmccann: the
For a simple interchange format, you might also look at MSGPACK; the
bindings are nice and the format is simple.
I used it for call-haskell-from-anything
(https://github.com/nh2/call-haskell-from-anything), a concept with
which you can call Haskell code from any language that supports loading
Hello Thomas,
thanks for your detailed answer.
Could be worthwhile re-evaluating the patch.
Does your patch still apply somewhat cleanly?
And does it address all the caches in your list already or only some
subset of them?
To have a multi-process ghc --make you don't need thread-safety.
It's also useful to note that the disk cache might do a surprisingly good
job at caching those .hi files for you. That, and a lot of people (like
me!) use SSDs, where the parallel compilation takes the vast majority of
time.
I'd be really excited to see parallel ghc --make.
By the way, totally
On Wed, May 15, 2013 at 6:36 PM, Clark Gaebel cgae...@uwaterloo.ca wrote:
It's also useful to note that the disk cache might do a surprisingly good
job at caching those .hi files for you. That, and a lot of people (like me!)
use SSDs, where the parallel compilation takes the vast majority of
Oh! That works quite nicely.
It's not supported for install-deps. I assumed that it just wasn't
implemented.
I should open a ticket.
Thanks!
- Clark
On Wednesday, May 15, 2013, Clark Gaebel wrote:
It's also useful to note that the disk cache might do a surprisingly good
job at caching
Danny Gratzer danny.grat...@gmail.com writes:
But this still doesn't really work since it'll loop forever without
finding any solutions. Haskell's list comprehensions don't play very
nicely with multiple infinite lists. If you really want to use this
style of programming for your problem, have
Patrick Browne patrick.bro...@dit.ie writes:
-- Hi
By the way, this is unrelated to your actual question, but if you
haven't already, you might want to check out Bird-style Literate Haskell
so you don't have to put -- in front of all of your non-Haskell text
in a comment-heavy code-light file
20 matches
Mail list logo
