Andrew Coppin wrote:
apfelmus wrote:
Andrew Coppin wrote:
I see lots of *trees*, but no general graphs. (As in, *data* structures
having cycles in them. My *code* is often cyclic...)
So what does a compiler do to typecheck it? It represents your code as a
graph and calculates
If you are going to ban graphs you also need to ban web pages (the links for
a graph, both between pages and interanlly), computer networks, maps,
dictionaries, you name it, it has a graph structure.
On 6/26/07, apfelmus [EMAIL PROTECTED] wrote:
Andrew Coppin wrote:
apfelmus wrote:
Andrew
On Tuesday 26 June 2007 23:20:32 Lennart Augustsson wrote:
If you are going to ban graphs you also need to ban web pages (the links
for a graph, both between pages and interanlly), computer networks, maps,
dictionaries, you name it, it has a graph structure.
Layout and rendering of web pages
Andrew Coppin wrote:
Lennart Augustsson wrote:
If you don't run into graphs you are either solving very peculiar
problems, or you don't recognize them when you see them. They are
everywhere.
I see lots of *trees*, but no general graphs. (As in, *data* structures
having cycles in them. My
apfelmus wrote:
Andrew Coppin wrote:
I see lots of *trees*, but no general graphs. (As in, *data* structures
having cycles in them. My *code* is often cyclic...)
So what does a compiler do to typecheck it? It represents your code as a
graph and calculates strongly connected
Thomas Conway wrote:
On 6/22/07, Duncan Coutts [EMAIL PROTECTED] wrote:
You might find that lazy IO is helpful in this case. The primitive that
implements lazy IO is unsafeInterleaveIO :: IO a - IO a
Personally, unsafeInterleaveIO is so horribly evil, that even just
having typed the name,
On 6/22/07, apfelmus [EMAIL PROTECTED] wrote:
I guess you have considered Software Transactional Memory for atomic
operations?
http://research.microsoft.com/~simonpj/papers/stm/index.htm
Also, write-once-read-many data structures (like lazy evaluation uses
them all the time) are probably
apfelmus wrote:
:D :D
Finally someone who fully understands the true meaning of the prefix
unsafe ;)
Personally, I'm loving the whole concept of this puppy:
GHC.Prim.*reallyUnsafePtrEquality#
I have absolutely no idea what it does, but it must be something really
unsafe! ;-)
*
On Fri, 2007-06-22 at 15:34 +1000, Thomas Conway wrote:
On 6/22/07, Duncan Coutts [EMAIL PROTECTED] wrote:
You might find that lazy IO is helpful in this case. The primitive that
implements lazy IO is unsafeInterleaveIO :: IO a - IO a
Personally, unsafeInterleaveIO is so horribly evil,
On 6/20/07, apfelmus [EMAIL PROTECTED] wrote:
Eh, why not a simple mergesort that also deletes duplicates?
I had to sit down and think about this, and while for the simple case
that I showed, your equivalent code is definitely simpler, and
probably more efficient.
The actual case that I'm
On Fri, 2007-06-22 at 09:38 +1000, Thomas Conway wrote:
The actual case that I'm dealing with, where I believe Data.Map (or
similar, incl finger trees) has a benefit is one in which it's not
simply a case of lists of items, yielding a list of items. I'm
manipulating an on-disk inverted index,
On 6/22/07, Duncan Coutts [EMAIL PROTECTED] wrote:
You might find that lazy IO is helpful in this case. The primitive that
implements lazy IO is unsafeInterleaveIO :: IO a - IO a
Personally, unsafeInterleaveIO is so horribly evil, that even just
having typed the name, I'll have to put the
Thomas Conway wrote:
In particular, I find my self wanting to use a priority queue for
N-way sorted merge, which you can do with Data.Map: (compiles, so
clearly works even though I have not tested it. ;-) )
import Data.List as List
import Data.Map as Map
merge :: Ord t = [[t]] - [t]
13 matches
Mail list logo
