[See comments at bottom]
Bulat Ziganshin wrote:
Finally i've implemented the following (you then would use
'withForeignPtr' to work with contents of ForeignPtr):
-- -
-- Encode/decode contents of memory buffer
You would need to define a type class
(Binary a) = EncodedPtr a b
where the 'a' is as you have it currently, and the b would be an
enumerated type which tracks the memory representation.
I agree they are different concepts - that is why an EncodedPtr would
require 2 type parameters. Of
I have no problems with marshalling/unmarshalling (and even with the
implicit casting going on). What I dislike is having a bunch of
functions which are the same but with different names, where the
difference boils down to enumerated types that end up being encoded in
the function name.
Bulat Ziganshin wrote:
i'm not against your idea, you absolutely right that this will be more
Haskell way, but can this be implemented without additional
complications for library users?
C is a language which pushes the boundaries of no complications (ie
convenience) quite far (and yet
Bulat Ziganshin wrote:
malloc :: Storable a = IO (Ptr a)
malloc = doMalloc undefined
where
doMalloc :: Storable b = b - IO (Ptr b)
doMalloc dummy = mallocBytes (sizeOf dummy)
Is there any reason to not code this as
malloc :: Storable a = IO (Ptr a)
malloc = mallocBytes $
Bertram Felgenhauer wrote:
Jacques Carette wrote:
Bulat Ziganshin wrote:
malloc :: Storable a = IO (Ptr a)
malloc = doMalloc undefined
where
doMalloc :: Storable b = b - IO (Ptr b)
doMalloc dummy = mallocBytes (sizeOf dummy)
Is there any reason to not code
Andrew U. Frank wrote:
should * always be
commutative or is its use for non-commutative types acceptable?
This very question caused much agony in many design meetings for the CAS
Maple. The list of pros and cons on each side is quite large!
There are too many really nice optimizations
Robert Dockins wrote:
The behaviour of NaN actually makes perfect sense when you realise that
it is Not a Number. Things that are not numbers are incomparable with
things that are.
Yes, NaN can be of type Float. But it's not a Float.
If you take that tack, then you have to concede that
Robert Dockins wrote:
On Apr 7, 2006, at 9:43 AM, Jacques Carette wrote:
[Lots of stuff about IEEE 754]
Is this an H' worthy item?
It is worth taking a serious look in conjunction with completely redoing
the Num class. Minor tweaking of the behaviour on NaNs (which requires
a large amount
I believe you might be able to use (commutative) anti-unification, also
known as generalization for this task.
Jacques
Harry Chesley wrote:
This is more of an algorithm question than a language question, but
any insights would be much appreciated.
The problem is to input a series of programs
Max Vasin wrote:
Pupeno wrote:
What about this
runDaytimeServer :: DaytimeServer - IO DaytimeServer
runDaytimeServer dts = do
dts' - runStreamDaytimeServer dts
dts' - runDgramDaytimeServer dts'
return dts'
runDaytimeServer dts
= runStreamDaytimeServer dts = runDgramDaytimeServer
Glynn Clements wrote:
Every other language (including Haskell) tends to have the problem
that eventually you will encounter a situation where the language's
own worldview gets in the way.
Or, to put it another way: if Haskell is so flexible, why do we need
Template Haskell? I can't imagine a
Bulat Ziganshin wrote:
Language.Haskell.TH.Lib is full of definitions like this:
infixP p1 n p2 = do p1' - p1
p2' - p2
return (InfixP p1' n p2')
btw, such definitions can be simplified by using liftM/ap operations:
instance (Monad m, MyNum v) = MyNum (m
David Roundy and Henning Thielemann have been arguing about the nature
of vectors and matrices, in particular saying:
On Thu, Jun 30, 2005 at 02:20:16PM +0200, Henning Thielemann wrote:
On Thu, 30 Jun 2005, David Roundy wrote:
Matrices _and_ vectors! Because matrices represent
Henning Thielemann wrote:
I'm uncertain about how who want to put the different kinds of
multiplication into one method, even with multi-parameter type classes.
You need instances
(*) :: Matrix - Matrix - Matrix
(*) :: RowVector - Matrix - RowVector
[many other instances removed.]
Henning Thielemann wrote:
Data Orientation = Row | Column
Data Vector a = Vector Orientation [a]
In the first mail you wrote
9. There are row vectors and column vectors, and these are different
types. You get type errors if you mix them incorrectly.
I interpreted that you want to
I would recommend that you look very closely at the design of the
LinearAlgebra package, the Matrix and Vector constructors, and the
underlying implementation data-structure rtable() for Maple's
implementation of all these ideas. About 250 person-days were spent on
just the high-level design,
Henning Thielemann wrote:
On Wed, 29 Jun 2005, Jacques Carette wrote:
9. There are row vectors and column vectors, and these are different
types. You get type errors if you mix them incorrectly.
What do you mean with row vectors and column vectors are different
types? Do you mean
Henning Thielemann wrote:
Mathematical notation has the problem that it doesn't distinguish between
things that are different but in turn discriminates things which are
essentially the same.
I used to think that too. And while that is sometimes true, it is
actually quite rare! When common
[EMAIL PROTECTED] wrote:
One of the things I appreciate and I hate simultaneously in your postings
is that you are so categorical.
'tis indeed simultaneously one of my strengths and one of my weaknesses
;-) I also like to play Devil's Advocate, to draw out the interesting
arguments.
Henning Thielemann wrote:
I'm also aware of that I mean different objects when I write
uniformly '1'. But I know that they are somehow different.
Since '1' can safely be used to denote the unit of any monoid, it does
indeed have a lot of applications. And of course the syntactic artifact
I was under the impression that, in ghc 6.4 at least, GADTs did just that: use information gained by matching on the
type constructor to refine types. I sort-of expected that the extension to pattern matching would follow.
Or is that a nice paper waiting to be written?
Jacques
Lennart
Lennart Augustsson [EMAIL PROTECTED] wrote:
Jacques Carette wrote:
Such people have the nasty habit of also thinking that ALL
functions are continuous! You might think they were constructivists or
something.
Why would a constructivist think that all functions are continuous?
It makes
[EMAIL PROTECTED] wrote:
Why do you think that constructivists are against +0 /= -0?
Because they can't prove it - either way.
Or that they think that all functions are continuous?
[See previous email] Because all constructible functions are provably
continuous.
Do you think that Per Martin-Lf
Wonderful post! I just want to throw a minor wrench in:
[EMAIL PROTECTED] wrote:
Eq is not merely a function of type a - a - Bool. It's a concept
with semantics. It must be an equivalence relation, and it also must
mean semantic equality. Functions that respect semantic equality have
the
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
Jacques Carette [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Eq is not merely a function of type a - a - Bool. It's a concept
with semantics. It must be an equivalence relation, and it also must
mean semantic equality. Functions
Jerzy Karczmarczuk [EMAIL PROTECTED] wrote:
Syntax for 3D arrays?
Give me one single language where this is natural and immediate.
I can think of 3: Mathematica, Maple and APL.
But I hope you don't
try to convince us that Mathematica is good at number crunching...
For linear algebra, Maple,
[EMAIL PROTECTED] wrote:
Jacques Carette writes:
Jerzy Karczmarczuk wrote:
Syntax for 3D arrays?
Give me one single language where this is natural and immediate.
I can think of 3: Mathematica, Maple and APL.
I can't see how Maple makes things more *natural and
immediate* than Matlab
Duncan Coutts wrote:
On Wed, 2005-05-04 at 18:29 -0400, Jacques Carette wrote:
There is also Template Haskell vs MetaOCaml.
For the life of me, I still cannot fathom why Template Haskell is untyped, while MetaOCaml is fully typed. Which is
the main reason I write meta-program
There is also Template Haskell vs MetaOCaml.
For the life of me, I still cannot fathom why Template Haskell is untyped, while MetaOCaml is fully typed. Which is
the main reason I write meta-program in MetaOCaml and 'other' programs in Haskell.
There is the additional aspect that my
Philippa Cowderoy [EMAIL PROTECTED] wrote:
On Fri, 29 Apr 2005, Simon Peyton-Jones wrote:
2. Use sub-typing, so that a value (Left x) is *both* in type Either
and in type NEither. This opens a very large and complicated design
space, as Ben mentioned.
I've been playing with this design space
I tried to implement symbolic differentation using GHC's simplification
rules. I assume that someone has already thought about this, right?
You are trying to do 'intensional programming' via GHC's simplification
rules, ouch! You are likely to hit limits very very quickly.
However, if you
Were I to write the same code as
Terrence Brannon [EMAIL PROTECTED] wrote:
module Crypt_Discordian
where
import List
vowel_list = aeiouAEIOU
is_vowel c = c `elem` vowel_list
move_vowels lis = move_vowels' lis [] []
move_vowels' [] c v = v ++ c
move_vowels' (x:xs) c v
| is_vowel x =
Josef Svenningsson [EMAIL PROTECTED] wrote:
You claimed that monad transformers break the
mzero-is-right-identity-for-bind law because they can be applied to
IO. I say, it's not the monad transformers fault. They cannot possibly
be expected to repair the law if they are given a faulty monad.
Thomas Jäger [EMAIL PROTECTED] wrote:
On Mon, 14 Feb 2005 11:07:48 +0100, Daniel Fischer And could one define
\f g h x y - f (g x) (h y)
point-free?
sure,
((flip . ((.) .)) .) . (.)
That occurence of flip cannot (AFAIK) be removed, indicating that as far as natural composition is concerned,
The recent post of Graham Klyne (below) reminds me that I have meant to ask:
is there a ``top 20'' things a serious programmer should know when writing
code in Haskell? Of course there is a lot of programming language theory
that would be great to know, but I mean really down-to-earth things like
[My apologies for not seeing the related discussion yesterday on haskell-cafe,
I was not subscribed until just now]
Iavor Diatchki [EMAIL PROTECTED] wrote:
On Fri, 28 Jan 2005 10:01:33 -0500, Jacques Carette [EMAIL PROTECTED] wrote:
The previous post on record syntax reminded me of some
[I have now subscribed to haskell-cafe]
Henning Thielemann [EMAIL PROTECTED] wrote:
This seems to be related to what I wrote yesterday
http://www.haskell.org/pipermail/haskell-cafe/2005-January/008893.html
Yes, very much. Except that rather than trying to tell mathematicians that they are
101 - 138 of 138 matches
Mail list logo