This is a "Related Work" section of the previous message. We compare
three main methods of achieving safe casts. It seems that the method
proposed in the earlier message is quite different -- especially in
terms of extensibility. In this message, we compare the extensibility
of four techniques. St
I admire the elegancy of your code which makes the changes to add new data
types minimum. There is one question I want to ask: Does this technique
extend to polymophic types?
Let's say we have the following type:
> data D a = C | D a
Is it possible to index the type D a? Or there is some fundmen
On Fri, Aug 01, 2003 at 05:00:55PM +0100, Keith Wansbrough wrote:
> [stuff about GUIDs]
>
> Careful! There are two things one might tie GUIDs to.
>
> You could compute a hash of (or associate a GUID with) the *interface*,
> or the *implementation*. These are different things. Until we know
>
[stuff about GUIDs]
Careful! There are two things one might tie GUIDs to.
You could compute a hash of (or associate a GUID with) the *interface*,
or the *implementation*. These are different things. Until we know
which we want, we should support both.
Why?
One might reasonably say "this pr
> "Derek" == Derek Elkins <[EMAIL PROTECTED]> writes:
Derek>
Derek> Except that I would probably mapM_ over a list of chunks, I don't
Derek> see what the problem is with your second version of the code is.
The second version allocates memory like crazy, so much that the
poke
confluence! Inspired by some posts the other day I implemented an
immutable GUID naming scheme for interfaces with Haskell. I thought it
would require compiler support, but it turns out a good 90% solution can
be done as a separate program quite nicely and there are not too tough
workarounds for th
8th European Conference on Software
Maintenance and Reengineering
March 24 - 26, 2004
Tampere, Finland
Call for Papers
The European Conference on Software Maintenance is the premier European conference on
the theory and practice of evolution, maintenance and reengineering of software
system
==
CALL FOR PAPERS
Fourth International Conference on
Software Engineering, Artificial Intelligence,
Networking, and Parallel/Distributed Computing (SNPD03)
October 16-18, 2003
Luebeck, Germany
http://www.isp.uni-luebeck.de/snpd03/inde
On Fri, 1 Aug 2003 12:02:00 +0200
Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2003 at 05:15:33PM -0400, Derek Elkins wrote:
> > On Thu, 31 Jul 2003 13:18:40 -0700
> > "Hal Daume" <[EMAIL PROTECTED]> wrote:
> >
> > > so, my questions are: does this exist in some other form I'm not
On Thu, Jul 31, 2003 at 05:15:33PM -0400, Derek Elkins wrote:
> On Thu, 31 Jul 2003 13:18:40 -0700
> "Hal Daume" <[EMAIL PROTECTED]> wrote:
>
> > so, my questions are: does this exist in some other form I'm not aware
> > of? is there something fundamentally broken about this (sorry for the
> > pu
[EMAIL PROTECTED] wrote:
>
> ... loads of cunning stuff omitted
>
Software-engineering-wise your approach suffers
from an important weakness: a closed world assumption.
The programmer has to maintain your "TI" and pass it
on in all kinds of contexts for the array of types to
be handled. I also h
On 01 Aug 2003 09:44:14 +0200
Peter Thiemann <[EMAIL PROTECTED]> wrote:
> I recently had my first exposure to Haskell's FFI when I was trying to
> compute MD5 and SHA1 hashes using the existing C implementations. In
> each case, the idea is to make the hash function available as function
>
> > md
Peter Thiemann wrote:
md5 :: String -> String
Hmmm, this should probably be:
> md5 :: [Word8] -> [Word8]
unless you really want the MD5 of the Unicode characters...
Cheers,
S.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman
I recently had my first exposure to Haskell's FFI when I was trying to
compute MD5 and SHA1 hashes using the existing C implementations. In
each case, the idea is to make the hash function available as function
> md5 :: String -> String
However, the naive implementation
> md5_init md5_state
14 matches
Mail list logo
