Re: [Haskell-cafe] why the name lambda calculus?
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 http://dotat.at/ Biscay, FitzRoy: Mainly westerly or southwesterly 4 or 5, occasionally 6 in Fitzroy, becoming variable 3 at times in south. Slight or moderate, becoming rough or very rough in northwest Fitzroy. Rain or showers, thundery at times. Good, occasionally poor. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why the name lambda calculus?
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 unpublished letter to Harald Dickson, Church] stated clearly that it came from the notation x̂ used for class-abstraction by Whitehead and Russell, by first modifying x̂ to ∧ x to distinguish functionabstraction from class-abstraction, and then changing ∧ to λ for ease of printing. This origin was also reported in [Rosser. Highlights of the history of the lambda calculus. Annals of the History of Computing]. On the other hand, in his later years Church told two enquirers that the choice was more accidental: a symbol was needed and λ just happened to be chosen.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Tyne, Dogger: Northwest becoming variable then east, 3 or 4, increasing 5 or 6 later. Slight or moderate. Showers, thundery later. Moderate or good.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: RFC: migrating to git
On Wed, 12 Jan 2011, Claus Reinke wrote: What happens after the merges? Does one maintain the branches somehow, or does one lose the (in-)dependency information? Remember that a branch in git is just a name for a point in the revision graph. When you commit to a branch the name is updated to point to the new commit. Names are local to a particular repository. When you do a merge, you do it on a particular branch which is updated to point to the merge commit. The other branches that were merged in (there's usually one but you can create octopus merges if you want) remain as they were. The merge commit contains un-named pointers to its parent commits for use by git, and conventionally records the names of the brances that were merged in the commit message for the convenience of humans. You can commit to the other branches to extend them, or delete and reconstruct them differently, without affecting the state represented by the merge. Have a look the way topic branches are used in the maintenance of git itself as an example of how to deal with a collection of independent patches. http://git.kernel.org/?p=git/git.git;a=blob;f=MaintNotes;hb=refs/heads/todo Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Wed, 12 Jan 2011, Claus Reinke wrote: In my understanding, the unorderedness of patch history in darcs is there to make distributed repos easier (fewer constraints: same set of patches, but not same order; can mix local commits and pulls from various repos, no need for a central repo), Apart from variable patch ordering all of that is true of all DVCSs. and because darcs has a causal rather than a temporal view of patch history (which patch depends on which other patches, instead of which patch came first). You can emulate darcs's patch re-ordering in git if you put each independent sequence of patches on a separate branch. Then you can re-merge the branches in whatever order you want. This is a fairly common git workflow. In other words, always keep a branch/repo that only pulls from the central repos (no other source of patches). It is normal in git to keep a pristine branch for each remote repository that you pull from - git sets these branches up by default. There can be many remotes in a git repository. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Mon, 10 Jan 2011, Roman Leshchinskiy wrote: It also seems to make finding buggy patches rather hard. Have a look at `git bisect`. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: ANN: bitspeak 0.0.1
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 number of bits via compression also minimized the number of yes/no questions that need to be asked. In particular, a Huffman coding: Sure, Huffman was actually my first tought. But I couldn't think of a pratical display for the result of Huffman encoding that could be easily followed by a human looking at the screen. http://www.inference.phy.cam.ac.uk/dasher/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ SOUTH BISCAY: EASTERLY OR NORTHEASTERLY 4 OR 5, OCCASIONALLY 6 IN SOUTHWEST. SLIGHT OR MODERATE. FAIR. GOOD.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage accounts and real names
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 isn't). What matters is continuity of identity and the ability to link your identities across the places you participate. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Game of life in haskell.
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. I played around with implementing hashlife a few years ago. It is a truly beautiful algorithm, and mind-expanding if all you know is representing Life as an array of booleans. The problem with implementing it in Haskell is it relies on persistent object identities (of the branches of a quadtree) that it hashes in order to memoize quadtree creation. This makes what ought to be a beautifully quasi-functional algorithm look ugly and imperative. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Game of life 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 faster. Also it leads to very concise code. I have a small and relatively quick Life algorithm that's based on lists, so it should translato to Haskell quite nicely. The basic representation of the Life universe is a sorted list of the co-ordinates of live cells. You can compute a new generation in one scan of the list, or rather a kind of zip3 that scans a 3x3 box along three adjacent rows, skipping empty space. It's much faster if, instead of storing one live cell in each list element, you store a small word-sized bitmap. You can then use SIMD-within-a-register to combine the three rows of cells and emit a new bitmap if it is non-zero. Have a look at http://dotat.at/prog/life/life.html for the story of how I developed the algorithm, including C source (about 40 lines of code). I've written a couple of other articles about SWAR techniques for Life: http://fanf.livejournal.com/81169.html http://fanf.livejournal.com/93032.html Getting the bits onto the screen quickly is the hardest part :-) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Game of life in haskell.
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 through the code without it getting in the way. For those interested in Hash Life whether or not it's written in Haskell, there's a description of how it works in http://dotat.at/prog/life/hashlife.c though that code is also incomplete. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Game of life in haskell.
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 that approach takes time (and space) per generation proportional to the number of occupied cells, not the size of the space, and that is the basis of the scaling claim. A simple Haskell analogue, which has the right asymptotic cost, would be to represent a Life generation by a list of (row_number, [col_no, ..., col_no]) pairs in strictly ascending order of row number, where each pair contains a list of the numbers of the occupied columns in strictly ascending order. The space is (number of occupied cells * a constant) + (number of occupied rows * another constant). Computing the next generation then amounts to a bunch of 3-way merges. That will be a lot faster than using Map or Set but you're still paying a lot for the indirections between cons cells. Mutating an array in-place would be significantly faster and no more difficult to code correctly because this is such a trivial algorithm. Richard's description is pretty much exactly what I had in mind for a Haskell version of my C code. The C translates to Haskell so well because its data structure is immutable: the new generation is written to fresh memory then the old generation becomes garbage. The old generation is scanned in the order it is written (albeit by three pointers with a row between each one) which is inconvenient for linked lists. However the algorithm is symmetrical so it doesn't mind processing the universe in alternating directions, so long as the rendering code can cope :-) The indirections are less bad than they might be because the code will always be following a pointer to an adjacent memory location, because of the algorithm's simple allocation behaviour. But it'll be about twice as slow as the C equivalent because it uses twice the memory. Efficient mutate-in-place Life algorithms become disgustingly complicated before they can beat listlife. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: nntp 0.0.1
On Sat, 13 Jun 2009, Maciej Piechotka wrote: Nntp is a library to connect to nntp (i.e. mainly USENET) servers. Currently RFC977 is being implemented. You should be referring to RFC 3977, published in October 2006. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] the problem of design by negation
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 _may_ be wrong. Oliver Cromwell Fear most of all to _remain_ in error. Me, deliberately misquoting Kierkegaard, quoting Socrates. I changed 'be' to 'remain'. Along similar lines, Esther Dyson's .sig says Always make new mistakes! Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: System.CPUTime and picoseconds
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 with Lennart — I also want an Integral type; it keeps the granularity constant and avoids all the pitfalls of doing math with a Double. Out of simplicity I can see why the granularity was set to 1 picosecond as it is slightly easier to specify than 100 picosecond or 10 picosecond or 1/60 nanosecond (hmmm... arcnanosecond?). The FreeBSD kernel uses a 64+64 bit fixed point type to represent time, where the integer part is a normal Unix time_t. The fractional part is 64 bits wide in order to be able to represent multi-GHz frequencies precisely. http://phk.freebsd.dk/pubs/timecounter.pdf Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ TYNE DOGGER FISHER GERMAN BIGHT HUMBER: SOUTHWEST 7 TO SEVERE GALE 9 DECREASING 5 OR 6 LATER. MODERATE TO VERY ROUGH, DECREASING SLIGHT TO ROUGH LATER. OCCASIONAL RAIN. MODERATE OR GOOD.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode's greek lambda
On Wed, 19 Nov 2008, Simon Marlow wrote: Tue Jan 16 16:11:00 GMT 2007 Simon Marlow [EMAIL PROTECTED] * Remove special lambda unicode character, it didn't work anyway Since lambda is a lower-case letter, it's debatable whether we want to steal it to mean lambda in Haskell source. However if we did, then we would probably want to make it a special symbol, not just a reserved symbol, otherwise writing \x-... (using unicode characters of course) wouldn't work, because \x would be treated as a single identifier, you'd need a space. There are a number of mathematical lambdas in Unicode (distinct from teh Greek lambdas), but they are not in the basic multilingual plane and they are presumably not very easy to type :-) Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: NORTHWESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN VIKING AND SOUTH UTSIRE. VERY ROUGH, OCCASIONALLY HIGH. RAIN THEN SHOWERS, WINTRY LATER IN VIKING AND NORTH UTSIRE. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Python's big challenges, Haskell's big advantages?
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 data structures and writable pages supporting an OS-level process add up to dozens of KB whereas a language-level concurrent context should require about 1KB. context switching times, That's probabily the same as thread switching time. Competent language-level concurrency support (as in Haskell and Erlang) makes a context switch about as expensive as a function call, thousands of times faster than an OS-level process switch. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH: EAST 3 OR 4, INCREASING 5 AT TIMES. SLIGHT. SHOWERS. GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whatever happened to sendFile?
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 2001 and Mac OS X in 10.4 (2005). Dragonfly BSD forked from FreeBSD after the new pipe code was introduced. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTHEAST ICELAND: SOUTHWESTERLY BACKING SOUTHEASTERLY 4 OR 5, OCCASIONALLY 6 IN NORTH. MODERATE. SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me]
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 comparison, and can be trivially emulated via mutation. In Haskell you can (with care) use System.Mem.StableName. http://research.microsoft.com/~simonpj/Papers/weak.htm Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING NORTH UTSIRE: SOUTHERLY 5 OR 6, OCCASIONALLY 7 LATER IN NORTH. MODERATE OR ROUGH. FAIR. GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hash-cons
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 ought to be possible to write it even more nicely in Haskell. However it relies crucially on a hash-cons aka intern aka memoized constructor find(). How can one implement this in Haskell? Google doesn't turn up anything very helpful. If I can solve the hash cons problem, then it ought to be fairly straightforward to use Parallel Haskell to speed up the algorithm on multicore machines. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ PORTLAND: SOUTH 7 TO SEVERE GALE 9 VEERING SOUTHWEST 5 TO 7. ROUGH OR VERY ROUGH. RAIN AT FIRST, THEN SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Somewhat random history question - chicken and egg
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 replacing code by writing other applications that manipulate the same data as the legacy code but do not link with it. I should ask my wife more about the structure of Peoplesoft. I know it's a mixture of COBOL, PL/SQL, and Peoplecode on the server, and Java on the client... No Haskell in it, though. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ WEST FAIR ISLE FAEROES SOUTHEAST ICELAND: SOUTHERLY VEERING NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN FAEROES AND SOUTHEAST ICELAND. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
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 invalid simplifications. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
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, and it's very difficult to represent the latter two as anything other than a string of code points. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing binary data.
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 representation clauses for such topics. Erlang has support for byte endianness but not (it seems) bit endianness. I'm currently kicking up a fuss about this on the erlang-questions list, since while Erlang's bitwise big-endian layout works OK for network protocols, it fails for typical little-endian C structures with bit fields. Thanks for the pointer to Ada. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing binary data.
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 http://erlang.org/doc/programming_examples/bit_syntax.html#4 The IP header example in the latter is a brilliant real-world example. It has recently been upgraded to support arbitrary bit streams. See http://www.it.uu.se/research/group/hipe/papers/padl07.pdf Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS versus Pattern Matching performance
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 of Cons1 a b c - code for case one Cons2 a b - code for case two Cons3 a - code for case three into foo x y z k1 k2 k3 = if complicated thing then k1 a b c else if other complicated thing then k2 d e else k3 f bar some args = foo perhaps different args (\ a b c - code for case one) (\ a b - code for case two) (\ a - code for case three) Such that you save a cons (unless the compiler can return the value in registers or on the stack) and a case analysis branch, but a normal function return (predictable by the CPU) is replaced by a less-predictable indirect jump. Does anyone have references to a paper that discusses an optimisation like this for any language, not just Haskell? Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SHANNON ROCKALL: VARIABLE 3, BECOMING SOUTH OR SOUTHEAST 4 OR 5, OCCASIONALLY 6, VEERING WEST LATER. MODERATE OR ROUGH. RAIN WITH FOG PATCHES, SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY VERY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of MIME Strike Force
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 messages you have to process will be within the minimum and maximum count requirements for each field. (This rules out encoding those requirements in the type system.) Postmasters will hate your software if you do either of these things :-) You need to support appending new fields to the top as well as the bottom of the header. Although it's traditional in most situations to add a new field to the bottom of the header, Received: fields must be added to the start. For any application that does message processing on an MTA, it's a *really* good idea to add new fields to the top of the header, so that they appear interspersed amongst the Received: lines in a way that indicates where and when the processing happened. Doing this also means your program will play nicely with DKIM. Ignore the strict syntax in RFC 2822 that prevents arbitrary trace header fields: this is a bug that will be fixed in the next version of the spec, and in practice software doesn't mind unexpected trace fields. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FAIR ISLE FAEROES: VARIABLE 3 OR 4, BUT NORTHERLY 5 OR 6 IN WEST FAEROES. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
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 I'll have much to say about Haskell or FP in general here, so this is way off-topic. In particular, I'm skeptical about relying on language guarantees as the basis of OS security, because that tends to limit the scope of your platform - you still want to support legacy C applications. Perhaps you can use typed assembly language techniques to check machine code before running it... dunno. Anyway: (1) Security partitioning. Current OSs are based on timesharing security, where users are protected from each other, but any process owned by a user can do ANYTHING to any other process owned by that user. This makes you utterly vulnerable to viruses, since if an attacker has compromised the user of a single user machine, they've effectively compromised the machine, whether or not they have got root. Furthermore, users don't have enough privilege to create new security partitions (i.e. new users), which would allow them protect themselves against untrusted code. As others have mentioned, a capability-based system is the ideal to aim for. (2) Unix has an assumption that disks are fast and the network is slow, in that you can't do something else while waiting for data from the disk, but you can with data from the network (using select() etc.) There are some AIO APIs that fix this problem, but they are disgusting and don't fit in with the network APIs. There's also the problem of paging which means that memory can unexpectedly take 10ms instead of 10ns to access. (3) The network APIs assume that memory bandwidth is cheap and that it makes sense to copy data from userland buffers to kernel buffers. It would be faster if buffers were sharable. There are some zero-copy APIs (e.g. sendfile), but they are not general. Cunning tricks to retro-fit zero copy onto the existing API depend on page table hacks and often have unexpectedly bad performance in some situations. (4) The system-call-as-function-call model assumes that system calls take negligible time. This is not true for filesystem calls, e.g. stat, open, etc. especially ones that aren't supported by an AIO API. Even fast system calls uncur the cost of two context switches. A better model is system-api-as-network-protocol, in which userland can send a bunch of requests to the kernel in one system call, and get the results back as and when they are available. There are some APIs like this already in the event-handling area, e.g. kqueue and epoll, but they are not general. The Linux syslets idea is heading in this direction. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ HEBRIDES BAILEY FAIR ISLE: EAST OR NORTHEAST 4 OR 5, OCCASIONALLY 6. SLIGHT TO MODERATE, OCCASIONALLY ROUGH. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What puts False before True?
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: binary: high performance, pure binary serialisation
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 surprisingly large number of security problems have been caused by ASN.1 code, and similar bugs have turned up in independent implementations so it isn't just one widespread shoddy implementation. OTOH ASN.1 is used by TLS, LDAP, Kerberos, SNMP, S/MIME, H.323, etc. etc. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: NORTHWEST 3 OR 4, OCCASIONALLY 5 AT FIRST. SLIGHT OR MODERATE. SHOWERS. GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Literate Haskell source files. How do I turn them into something I can read?
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, OCCASIONALLY SEVERE GALE 9. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
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 constructor/variable ambiguity introduces a nasty maintenance headache: what if you upgrade to a new version of a library which introduces a new constructor which happens to be the same as a variable you have been using? Suddenly the meaning of your functions changes! Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Haskell?
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] http://dotat.at/ PORTPATRICK: STRONG WINDS ARE EXPECTED TO DEVELOP AROUND A LOW THAT WILL REACH ROCKALL ON THURSDAY AND WHERE IT WILL BE SLOW MOVING THROUGH FRIDAY. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Re[2]: FFI: number of worker threads?
On Wed, 21 Jun 2006, Simon Peyton-Jones wrote: New worker threads are spawned on as needed. You'll need as many of them as you have simultaneously-blocked foreign calls. If you have 2000 simultaneously-blocked foreign calls, you'll need 2000 OS threads to support them, which probably won't work. Does the RTS use select() to multiplex network IO instead of spawning threads? Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: NORTHWESTERLY 7 TO SEVERE GALE 9 DECREASING 5 OR 6. RAIN OR SHOWERS. MODERATE OR GOOD, BECOMING POOR AT TIMES. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] FreeBSD: Max # of sockets opened
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 kernel's point of view - the macros are less so). You can re-set it to whatever value you like at compile time (e.g. gcc -DFD_SETSIZE=10240). Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FreeBSD: Max # of sockets opened
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. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Optimizations for mutable structures?
The following paper seems relevant to this thread. Although it's written in the context of C and C++, it's relevant to any language that combines pre-emptive threads and imperative features. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
On Wed, 7 Dec 2005, Robert Dockins wrote: What exactly are the semantics of C programs and why do we believe that C compilers are correct? With regards to threading, the semantics are undefined and the compilers are subtly broken :-) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: jhc vs ghc and the surprising result involving ghc generated assembly.
On Wed, 2 Nov 2005, skaller wrote: On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote: BTW, you shouldn't generate identifiers with leading underscores because they are reserved for the implementation. I AM the implementation :) You are not the C implementation. Generated Identifiers start with underscores, so they don't clash with arbitrary C code. You should prefix them with something else, e.g. felix_. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: Existing Haskell IPv6 Code
On Thu, 12 May 2005, Marcin 'Qrczak' Kowalczyk wrote: But they don't differ in addressing. In BSD sockets the difference between streams and packets lies in socket type, while addresses are split into address families which bijectively correspond to protocol families. I believe there are some obscure protocol families that have more than one address family, which is why the two concepts exist in the API. However there's an enormous amount of code that muddles them up, but this doesn't matter for the Internet protocols. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: The jhc Haskell compiler.
On Tue, 26 Apr 2005, Ashley Yakeley wrote: Does that mean my program will be GPL if I compile it with jhc? No; cf. gcc. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: How can I make a counter without Monad?
On Wed, 16 Mar 2005, Peter Davis wrote: On 2005-03-16 02:52:39 -0800, Nicolas Oury [EMAIL PROTECTED] said: instance Splittable Integer where split n = (2*n,2*n+1) I haven't played much with the Splittable class yet, but what would be wrong with instance Splittable Integer where split n = (n,n+1) If you recursively split the left-hand result then that overlaps with the right-hand result. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN HUMBER, BECOMING VARIABLE 3. OCCASIONAL RAIN OR DRIZZLE. MODERATE OR POOR WITH FOG BANKS. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Preprocessor question
Simon Marlow writes: We also like to get as clean a cpp as possible - if you go through gcc -E you get a whole bunch of symbols defined, The -undef option gets rid of most of those. and cpp gets passed the -lang-c flag (whatever that means, but it looks pretty scary). The other possibilities are -lang-c++, -lang-objc, etc. It's to do with things like comment syntax and Objective C's #import directive. It's not as scary as it looks, I think :-) Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998
Re: GHC licence
[EMAIL PROTECTED] wrote: I do think that the GNU license would be a mistake -- as I understand, it would prevent the use of GHC in commercial projects, and I'm pretty sure that's something Simon wants to *encourage*. The GPL explicitly allows commercial use. The commercially problematic aspect of the GPL is that derived versions of GPLed software must be distributed with source (and all the intellectual property exposed). This does not propagate to works created using GPLed software. Tony. -- F.A.N.Finch [EMAIL PROTECTED] [EMAIL PROTECTED] +44-7970-401-426 "Plenty more letters in the alphabet"
