Ezra Cooper e...@ezrakilty.net wrote:
I believe this to be a general trait of things described as
calculi--that they have some form of name-binders, but I have never
seen that observation written down.
Combinator calculi are a counter-example.
Tony.
--
f.anthony.n.finch d...@dotat.at
KC kc1...@gmail.com wrote:
Lambda abstraction was probably chosen in case someone found better
abstractions; e.g. epsilon, delta, gamma, beta, alpha, ... :)
http://www-maths.swan.ac.uk/staff/jrh/papers/JRHHislamWeb.pdf
Page 7:
By the way, why did Church choose the notation λ? In [an
On Mon, 21 Jun 2010, Maurício CA wrote:
bitspeak is a small proof of concept application that allows
writing text using only two commands (yes/no, 1/2, top/down etc.).
There is a parallel between data compression algorithms and this sort of
task, expressing a sentence in the minimal
I note that in some jurisdictions there is no such thing as a real name.
You can change your name for legal purposes (on official documentation and
so forth) simply by asserting that this is the name you prefer to be known
by. Your legal name doesn't have to be the same as your everyday name
(mine
On Tue, 2 Feb 2010, Arne D Halvorsen wrote:
If I may butt in here: to get a scalable, fast Game of Life, you should look
into Hashlife (by Gosper?) as exemplified in the open source application
Golly. It gives an astonishing speedup, and it would be interesting to see it
expressed in Haskell.
On Tue, 2 Feb 2010, Serguey Zefirov wrote:
Creation of new Array is (without knowing some subtle details) is
O(max coordinates difference between live cells). Creation of new Set
(X,Y) is O(NlogN) (N = number of live objects). Most of the cells in
Life are empty, so the Set/Map approach is
On Tue, 2 Feb 2010, ed...@ymonad.com wrote:
http://dotat.at/prog/life/hslife.hs
Er, yes, I didn't link to that in my earlier message because it's a
half-completed attempt. I think I got to the stage of realising that I
needed to write a monad or a monad transformer to thread the hash cons
state
On 3 Feb 2010, at 02:04, Jon Harrop j...@ffconsultancy.com wrote:
On Tuesday 02 February 2010 23:54:58 Richard O'Keefe wrote:
One message in this thread has already pointed to a
solution (in C) that in effect uses a bit-packed sparse
representation
to achieve high speed. The point is that
On Tue, 26 May 2009, Richard O'Keefe wrote:
I have one of Brian Marick's (www.exampler.com) stickers on my door.
It reads
to be less wrong than yesterday
Two quotes I often give my students:
Brethren, I beseech you in the bowels of Christ,
consider it _possible_ that you
On Mon, 12 Jan 2009, ChrisK wrote:
Lennart is right that 1 picosecond accuracy is absurd compared to all
the jitters and drifts in anything but an actual atomic clock in your
room. But since CPUs tick faster than nanosecond the CPUTime needs
better than 1 nanosecond granularity. I agree
On Wed, 17 Sep 2008, Manlio Perillo wrote:
Jefferson Heard ha scritto:
the weight of a full unix process plus the weight of the python
interpreter in terms of memory,
With copy on write some memory can be saved (if you preload all the required
modules in the master process).
The kernel
On Thu, 14 Aug 2008, Brandon S. Allbery KF8NH wrote:
Actually, while I'm not sure how Linux does it, on the *BSDs pipes are
actually socketpairs.
Not any more. FreeBSD replaced the socketpair implementation with a faster
one in 1996 and OpenBSD imported it soon after. NetBSD imported it in
On Thu, 14 Feb 2008, [EMAIL PROTECTED] wrote:
As I understand the original problem had less to do with the number of
comparison but more to do with the cost of a single comparison. In an
impure language, we can use constant-time physical equality. It is
usually provided natively as pointer
I've been thinking about hashlife recently. I've written part of a fairly
didactic C implementation http://dotat.at/prog/misc/hashlife.c but I
there are more interesting things that can be done with it.
In particular, the core calc2() function is essentially implementing lazy
evaluation, so it
On Sun, 11 Nov 2007, [EMAIL PROTECTED] wrote:
To be a true COBOL replacement, I think that one very important feature
is that it is link-compatible with existing COBOL code. You're never
going to be able to replace a 6MLOC COBOL monster in any manner other
than piecemeal.
AFAIK people are
On Thu, 27 Sep 2007, Ross Paterson wrote:
Combining characters are not an issue here, just the surrogate pairs,
because we're discussing representations of sequences of Chars (Unicode
code points).
I dislike referring to unicode code points as characters because that
tends to imply a lot of
On Wed, 26 Sep 2007, Aaron Denney wrote:
It's true that time-wise there are definite issues in finding character
boundaries.
UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
pairs and combining characters. Code points, characters, and glyphs are
all different things,
On Wed, 22 Aug 2007, Lutz Donnerhacke wrote:
* Tony Finch wrote:
http://erlang.org/doc/programming_examples/bit_syntax.html#4
The IP header example in the latter is a brilliant real-world example.
Unfortunly this example does not handle bit and byte order.
Take a look at Ada's
On Sun, 19 Aug 2007, Peter Cai wrote:
My duty is writing a network server which talks to another server through a
binary based private protocol.
Haskell needs something like Erlang's bit syntax.
http://erlang.org/doc/reference_manual/expressions.html#6.16
I've recently been wondering (in a more general context than just haskell)
about optimisations along the lines of
foo x y z = if complicated thing then Cons1 a b c
else if other complicated thing then Cons2 d e
else Cons3 f
bar some args = case foo perhaps different args
On Wed, 27 Jun 2007, Jeremy Shaw wrote:
Currently I am difficulty dealing with headers that could appear more
than once.
I recommend that you treat the header fields as an ordered list. Do not
use the latitude that the specification gives you to re-order headers, and
do not assume that
On Mon, 18 Jun 2007, Creighton Hogg wrote:
Okay, but these don't seem to really be design flaws so much as the
inevitable results of age and the need for backwards compatibility. I'm
looking more for technical problems that you would want to see fixed in our
magical UberOS.
I don't think
Another point worth noting is that the usual lambda calculus
representations of false and zero are equivalent. (However true
is not the same as one.)
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
MALIN: EAST OR SOUTHEAST 4 OR 5. MODERATE. FAIR. MODERATE OR GOOD.
On Fri, 26 Jan 2007, Neil Davies wrote:
existing ecoding system - both the BER (Basic Encoding Rules) and the
PER (Packed Encoding Rules). If you are looking to target a well
supported standard - this would be the one.
I'd say that ASN.1 encoding rules are badly, but widely supported. A
On Sun, 31 Dec 2006, Michael T. Richter wrote:
So what is the right approach (and, for that matter, what is the wider
problem)?
I thought that was clear from the other replies.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
HEBRIDES: CYCLONIC BECOMING WEST 6 TO GALE 8,
On Fri, 4 Aug 2006, Martin Percossi wrote:
I agree that naming can be abused. But I think it should be *me*, the
programmer, or in the limit ghc, the glorious compiler (but only because of
unresolvable ambiguities), who decides it -- not *you*, the language
implementor!!! ;-)
The ML
On Mon, 24 Jul 2006, Brian Hulley wrote:
[...] it seems to me that what's really needed is a compiler that can do
whole program optimization [...]
Has anyone done work on an equivalent of MLton for Haskell?
http://repetae.net/john/computer/jhc/
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
On Tue, 13 Dec 2005, Joel Reymont wrote:
It looks like 'ulimit -n' on FreeBSD lets you have 10k+ file descriptors open
per process. FD_SETSIZE is 1024 in the system headers, though. GHC relies on
this value (see ghc/rts/Select.c).
FD_SETSIZE is actually dynamic on FreeBSD (at least from the
On Tue, 13 Dec 2005, Joel Reymont wrote:
So it's just a matter of recompiling GHC and have it pick up new values?
Yes.
(It's a pity that the FD_SET macros aren't run-time configurable.)
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4.
29 matches
Mail list logo
