Shae Matijs Erisson wrote:
> Do you have a version of HXML + (any) namespace support online or otherwise
> available for playing with? I'd like to try it.
Not yet, but stay tuned.
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing
Graham Klyne wrote:
> Joe English wrote:
> >What are you looking for in an XML toolkit?
>
> Hi, thanks for responding. My desiderata:
>
> 1. Works with HUGS and GHC (I'm currently developing with HUGS, but
> anticipate using GHC for "production" code).
H
implementing XMLNS is not hard, but implementing
it in a sane way requires some ingenuity.)
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
e Just Plain Wrong --
they're subject to horribly bad roundoff errors --
and I'm not even close to being a numerical analyst.
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
s not true
on all platforms. The slogan is "All the world is not a VAX."
Java attempts platform independence by declaring that all
the world *is*, in fact, a VAX [*].
[*] More precisely, a 32-bit platform with IEEE 754 floating point.
--Joe English
[EMAIL PROTECTED]
__
d it's very convenient.
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
The haskell mailing list is getting an increasing amount of
spam, viruses, and virus warnings. Would it be possible
to change the list policy to only allow submissions from
subscribed members? Please?
--Joe English
[EMAIL PROTECTED
tterns and OO patterns.
OO patterns tend to be informal, intuitive guidelines; and
though some FP patterns are like this (e.g., "combinator library",
"embedded domain-specific language"), the majority can be
described rigorously. This gives t
YPE declarations)
+ Several data structures and public functions have been renamed
+ Space fault in comment parsing fixed
Please contact Joe English <[EMAIL PROTECTED]> with
any questions, comments, or bug reports.
--Joe English
[EMAIL
Simon Peyton-Jones wrote:
> There should really be a strict accumArray, just as there
> should be a strict foldl.
Yes, please!
Is there a way to write a strict version of accumArray in
Haskell 98, or does this need to be done by the implementation?
--Joe English
[EMAIL PRO
kElem and cat finally fixes the problem.
I'm still not sure *why* this does the trick --
hopefully somebody smarter can explain that --
but the modified program runs in bounded space,
no matter how large the input file is.
(It even works in Hugs, which I found surprising, since
version is 0.1, and is slightly post-alpha quality.
Tested with GHC 5.02, NHC98 1.10, and various recent versions of Hugs.
Please contact Joe English <[EMAIL PROTECTED]> with
any questions, comments, or bug reports.
--Joe English
[E
ese "datafied"
| XML documents. Many of the HaXml techniques are far more elegant, compact,
| and powerful than the ones found in familiar techniques like DOM, SAX, or
| XSLT. Code samples demonstrate the techniques.
http://www-106.ibm.com/developerworks/xml/library/x-matters14.
ng about them goes, I don't think I really "got"
monads until reading Wadler's aptly-titled "Comprehending Monads",
which approaches them from this perspective.
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
;Comprehending Monads" gives a very good presentation
using the fmap/return/join formulation (called map/unit/join
in that paper). "The Essense of Functional Programming"
is another very good presentation using the return/>>=
formulation (there called "unitM/bindM"). See
http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html >
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
ine
| f # m = m >>= (return . f)
and add an appropriate fixity declaration for '#'.
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
ve to do with the way hugs98 implements and Int to Bool array?
Most likely yes. Hugs is optimized for interactive use and quick
compilation, not for space usage. Try it with GHC or HBC and
see how it does.
--Joe English
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
t ([1..102400] :: [Integer])'
has type 'IO [()]', perhaps the result of the IO operation --
a list of 100K empty tuples -- is the culprit, even though
the result is never used.
Does 'mapM_ print ... ' (:: IO ()) perform any better?
--Joe English
[EMAIL PROTECTED]
a combination of the HaXML combinators
and Ketil Malde's parser would give the best of both worlds.
--Joe English
[EMAIL PROTECTED]
Marcin 'Qrczak' Kowalczyk wrote:
> Joe English pisze:
> > According to the ISO C standard, the meaning of wchar_t
> > is implementation-defined.
>
> I know. How to convert between the default multibyte locale and
> Unicode on such systems?
As far as I ca
erpreted as such. It appears
to depend on the current locale.
--Joe English
[EMAIL PROTECTED]
--
also runs without a space problem under STG Hugs.
--Joe English
[EMAIL PROTECTED]
and sum',
where:
length' :: [a] -> Integer
sum':: [Integer] -> Integer
length' = foldl_strict (\n _ -> n + 1) 0
sum'= foldl_strict (+) 0
foldl_strict:: (a -> b -> a) -> a -> [b] -> a
foldl_strict f a [] = a
foldl_strict f a (x:xs) = (foldl_strict f $! f a x) xs
fixed these as well.
Thanks!
--Joe English
[EMAIL PROTECTED]
t case, plus ~10K
words to spare.
After fixing the *other* space leak that Malcolm Wallace noted,
(too much laziness in 'length' and 'sum') all the tests ran without
a problem. That was using breadth=12 and depth=6, which makes Hugs98
run out of room even with the default heap size.
Problem solved! Thanks!
--Joe English
[EMAIL PROTECTED]
In my
real program though there's much more data stored at each
node and it fails on modestly-sized inputs.
Thanks in advance for any advice...
--Joe English
[EMAIL PROTECTED]
--
module SpaceLeak where
data Tree a = Tree a [Tree a]
deriving (Show, Eq)
--
-- a few of the usual polyt
cumulation (validation, namespace processing,
many simple translations to other document types, etc.),
all of which should run in space bounded by the depth of the tree.
--Joe English
[EMAIL PROTECTED]
;unfoldr' which -- again according
to my unreliable intuition -- should behave nicely space-wise).
Thanks for any advice,
--Joe English
[EMAIL PROTECTED]
'filter/filter' version, so the former
may be preferable if the two are in fact semantically
equivalent.
--Joe English
[EMAIL PROTECTED]
arrows), but those don't look as nice typeset IMHO.
I also like:
apfst :: (a -> c) -> (a,b) -> (c,b)
apsnd :: (b -> c) -> (a,b) -> (a,c)
apl :: (a -> c) -> Either a b -> Either c b
apr :: (b -> c) -> Either a b -> Either a c
These are called "first", "second", "left", and "right"
in the Arrow library.
--Joe English
[EMAIL PROTECTED]
p = (==)) l1 l2
> ...
> where
> union l1 l2
> means
> union (==) l1 l2
I don't quite see what algorithm you're using
to decide how many arguments are passed
to the function.
What would you get if you typed:
foo = foldr union []
for example?
--Joe English
[EMAIL PROTECTED]
he built-in functions enough to follow
> it. (Monads are Haskell's way of making imperative and mutative programming
> harder to do so that programmers are less likely to do it, right? :))
Actually, quite the opposite... you should see how difficult
it was to do I/O in Haskell *befor
luated
until it's requested, so the space behaviour of "array" is
particularly bad. The second rule of thumb, then, is
"avoid Haskell Arrays unless you really, really need
constant-time random access."
In this particular problem, 'scprod' consumes elements in
sequential order, so it may be better to use lists instead
of arrays. (In fact "scprod a a where a = produce n 1.0"
has a closed-form, O(1) solution, but I assume that's not
the problem you're really trying to solve :-)
Hope this helps,
--Joe English
[EMAIL PROTECTED]
I wrote:
> Operationally I expect that in "let x = f y in ... x ... x",
> 'f y' is only evaluated once, no matter what type it is.
Which, of course, is not how Haskell actually works,
if x :: (SomeClass a) => SomeType a. DOH!
Please disregard my earlier remarks
Alex Ferguson <[EMAIL PROTECTED]> wrote:
> Joe English:
> > How about leaving the 'a = b' binding form as it is,
> > (monomorphism restriction and all) and using 'a = ~ b'
> > to indicate call-by-name. [...]
> I like that much less [...] becaus
till signal an error if the programmer accidentally
bumps into the MR. If this happens you only need to
twiddle the code to fix it. For people reading the code,
a ~ on the RHS of a binding is a signal that something
out-of-the-ordinary is going on operationally, the same as
when it appears on the LHS.
--Joe English
[EMAIL PROTECTED]
s. IIRC,
the main reason comprehensions et al. were de-overloaded
is because ambiguities led to error messages that
bewildered novices. If it were possible to declare
default Monad ([])
this problem could be alleviated.
That's my $.02...
--Joe English
[EMAIL PROTECTED]
P.S., than
36 matches
Mail list logo
