Re: ghc-pkg 6.2 incorrectly parses commas within quotes
Ashley Yakeley wrote: Any word on whether this has been/will be fixed? [...] Well, it's fixed in CVS for quite a while, but it's up to Simon^2 when a new GHC release comes out. Personally I'd favour tossing this feature altogether, [...] Me too... :-P * * * Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-pkg 6.2 incorrectly parses commas within quotes
Ashley Yakeley wrote: Any word on whether this has been/will be fixed? [...] Well, it's fixed in CVS for quite a while, but it's up to Simon^2 when a new GHC release comes out. Personally I'd favour tossing this feature altogether, [...] Me too... :-P * * * Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] 3d or Nd geometry library?
On Fri, Feb 13, 2004 at 11:31:39AM -0800, Abraham Egnor wrote: I was somewhat surprised to see that there's only one geometry library on the haskell libraries page, and further dismayed to find that it for the most part only does 2d. It seems like haskell should be a natural fit for higher-order geometric libraries - has anyone heard of such? What kind of geometry algorithms are you searching for? Perhaps the answer to you question is that computational geometry is hard to get right and thus deserves to be written in C or C++ for better accessiblity. In case you are interested in convex polyhedra then I can provide you with a Haskell binding to the Parma Polyhedra Library (search for Parma PPL). The binding is a bit still buggy, probably because I didn't manage to marshal Integers propperly. When I find the flaw, the binding will come with the library (like the O'Caml interface). But you're right, especially due to the built-in arbitrary precision integers and rationals, Haskell is ideal for computational geometry. I attach the Graham convex hull algorithm, just for the sake of it. Axel. module Graham where import List import Ratio --import Debug.Trace(trace) type Vertex = (Rational, Rational) -- Removes double elements in a sorted list. remDoubles :: Eq a = [a] - [a] remDoubles [] = [] remDoubles (x:xs) = x:rD x xs where rD _ [] = [] rD last (x:xs) | x==last = rD last xs | otherwise = x:rD x xs -- Extract the point with the smallest y and largest x coordinate. getHullVertex :: [Vertex] - Vertex getHullVertex [] = error getHullVertex: empty set of points getHullVertex ps = foldl1 maxVertex ps where maxVertex :: Vertex - Vertex - Vertex maxVertex p1@(x1, y1) p2@(x2, y2) | y1y2 = p1 | y2y1 = p2 | x1x2 = p1 | otherwise = p2 -- Test three points for being ordered clockwise. If the argument simple is -- false pair this test lexicographically with the distance of the second -- and the thirds point. isCW :: Vertex - Vertex - Vertex - Ordering isCW (a, b) (c, d) (e, f) = let dx21 = c-a dy21 = d-b dx31 = e-a dy31 = f-b in case compare (dy31*dx21) (dy21*dx31) of LT - LT GT - GT EQ - compare (dx21*dx21+dy21*dy21) (dx31*dx31+dy31*dy31) -- Sort the list of points according to one point on the hull. preprocess :: [Vertex] - [Vertex] preprocess [] = [] preprocess pts = mp:sortBy (isCW mp) (filter ((/=) mp) pts) where mp = getHullVertex pts -- Remove points in the interior. graham :: [Vertex] - [Vertex] graham = gh . remDoubles . preprocess where gh [EMAIL PROTECTED] = points gh [EMAIL PROTECTED] = points gh [EMAIL PROTECTED],_] = points gh (p:o:ints) = init $ walk [o,p] (ints++[p]) -- Unfortunately lists all grow to the left in Haskell. Imagine the -- first argument to be written in reverse order. We are traversing -- the point set clockwise, so that the result does not have to be -- reversed. walk :: [Vertex] - [Vertex] - [Vertex] walk ps [] = ps walk (pM:pL:out) (pF:inp) | isCW pL pM pF/=GT = walk (pF:pM:pL:out) inp | otherwise = walk (pL:out) (pF:inp) walk [EMAIL PROTECTED] (pF:inp) = walk (pF:point) inp walk ps ps' = error $ weird point sets: ++show (length ps)++ and ++ show (length ps')++ long. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] non-ASCII characters in Haddock documentation
Am Freitag, 13. Februar 2004 01:23 schrieben Sie:
wolfgang:
Hello,
how do I insert non-ASCII and maybe even non-Latin-1 characters in
Haddock documentation?
Wolfgang
Looks like it might be difficult. The haddock lexer src has:
$alphanum = [A-Za-z0-9]
So, non-ascii might not be lexed.
Hello,
I meant non-ASCII characters in source code comments like this:
{-|
The execution time of this function is /n³/.
-}
Currently, Haddock seems to copy the bytes making up the
non-ASCII character
verbatim to the HTML file. But since the HTML file doesn't contain a
character set specification, it is illformed and it depends
on the browser how this situation is handled.
It shouldn't be too hard to fix this, at least for Latin-1 (full Unicode would be
somewhat harder). I'll add it to the TODO list.
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: exists keyword and existential types
In article [EMAIL PROTECTED],
Ben Rudiak-Gould [EMAIL PROTECTED] wrote:
And it would be nice to be able to pass around values of type
(exists t. Interface t = t), which behave just like OOP interface
pointers.
A value of type (exists t. Interface t = t) consists of two values,
one of type t, and one dictionary value. For that reason a data type
is used to represent this (and a newtype type cannot be).
So what's the difference? Data provides another layer of thunkage. For
instance:
data D = MkD Int;
newtype N = MkN Int;
Then (MkN undefined) is the same as undefined, but (MkD undefined) is
not.
So how does this apply to (exists t. Interface t = t)? Well, you'd have
two different versions of undefined depending on whether calculation
of the dictionary was part of the undefinition.
I don't see how
openInputStream :: FilePath - IO (exists t. InputStream t = t)
Bear in mind you can't even write IO (forall t. whatever) in Haskell.
would cause any more problems than
data Foo = forall t. InputStream t = Foo t
openInputStream :: FilePath - IO Foo
What am I missing?
Simply that undefined is not the same as (Foo undefined).
Quite separately, if InputStream happens to look like this:
class InputStream t where
{
f1 :: t - something;
f2 :: t - something';
f3 :: t - something'';
-- etc.
};
where none of the somethings refer to t, you'd be better off with a
data-type:
data InputStream
{
f1 :: something;
f2 :: something';
f3 :: something'';
-- etc.
};
This is a much better way of doing semi-OOP. AFAIK you can't really do
proper OOP-style extensibility in Haskell at all (and exists wouldn't
help either).
--
Ashley Yakeley, Seattle WA
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] non-ASCII characters in Haddock documentation
On Mon, Feb 16, 2004 at 10:20:30AM -, Simon Marlow wrote:
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
I meant non-ASCII characters in source code comments like this:
{-|
The execution time of this function is /n³/.
-}
Currently, Haddock seems to copy the bytes making up the
non-ASCII character
verbatim to the HTML file. But since the HTML file doesn't contain a
character set specification, it is illformed and it depends
on the browser how this situation is handled.
It shouldn't be too hard to fix this, at least for Latin-1 (full
Unicode would be somewhat harder). I'll add it to the TODO list.
While Haskell's source charset is specified as Unicode, Haskell source
files don't specify the byte encoding they use, so any source file using
non-ASCII characters isn't portable. Entrenching Latin-1 would make the
move to Unicode more difficult.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] non-ASCII characters in Haddock documentation
Ross Paterson [EMAIL PROTECTED] writes: It shouldn't be too hard to fix this, at least for Latin-1 (full Unicode would be somewhat harder). I'll add it to the TODO list. While Haskell's source charset is specified as Unicode, Haskell source files don't specify the byte encoding they use, so any source file using non-ASCII characters isn't portable. Perhaps one could have an option/pragma to specify source encoding? Entrenching Latin-1 would make the move to Unicode more difficult. Defaulting to Latin-1 may be sensible, though? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] non-ASCII characters in Haddock documentation
On Mon, Feb 16, 2004 at 12:51:06PM +0100, Ketil Malde wrote: Ross Paterson [EMAIL PROTECTED] writes: While Haskell's source charset is specified as Unicode, Haskell source files don't specify the byte encoding they use, so any source file using non-ASCII characters isn't portable. Perhaps one could have an option/pragma to specify source encoding? That would be a flexible solution, but it might not be implemented for a while. I think this is what the old \u escapes (now dropped from Haskell 98) were for. You could use your favourite encoding locally, but convert to a portable form when sending to another locale. Entrenching Latin-1 would make the move to Unicode more difficult. Defaulting to Latin-1 may be sensible, though? It may seem so to western europeans, but others may differ. A case could be made for UTF-8. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] non-ASCII characters in Haddock documentation
On Mon, Feb 16, 2004 at 10:20:30AM -, Simon Marlow wrote:
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
I meant non-ASCII characters in source code comments like this:
{-|
The execution time of this function is /n³/.
-}
Currently, Haddock seems to copy the bytes making up the
non-ASCII character
verbatim to the HTML file. But since the HTML file
doesn't contain a
character set specification, it is illformed and it depends
on the browser how this situation is handled.
It shouldn't be too hard to fix this, at least for Latin-1 (full
Unicode would be somewhat harder). I'll add it to the TODO list.
While Haskell's source charset is specified as Unicode, Haskell source
files don't specify the byte encoding they use, so any source
file using non-ASCII characters isn't portable. Entrenching Latin-1
would make the move to Unicode more difficult.
True, but GHC currently assumes Latin-1 as the encoding for source files.I don't
see it as entrenching Latin-1, just that we only accept Latin-1 encoded source files;
at some point in the future we might accept other encodings. Making the same
simplifying assumption in Haddock doesn't seem that big a deal.
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Wiki manager change
Hi all... the Haskell Wiki http://haskell.org/hawiki/ is under new management. From now on, please contact Shae Erisson [EMAIL PROTECTED] with your requests, comments, or feedback on the Wiki site - or, of course, improve and extend the site yourself! Thanks all for your contributions - please keep them coming, and make this resource even more useful. Cheers, --KW 8-) Former Haskell Wiki manager -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] non-ASCII characters in Haddock documentation
At 11:29 16/02/04 +, Ross Paterson wrote: On Mon, Feb 16, 2004 at 10:20:30AM -, Simon Marlow wrote: ... It shouldn't be too hard to fix this, at least for Latin-1 (full Unicode would be somewhat harder). I'll add it to the TODO list. While Haskell's source charset is specified as Unicode, Haskell source files don't specify the byte encoding they use, so any source file using non-ASCII characters isn't portable. Entrenching Latin-1 would make the move to Unicode more difficult. Ah, yes. I was going to suggest that for generating XHTML, it should be easy enough to generate #; expansions, but that doesn't take account of not knowing the input encoding. Maybe the XML conventions for encoding designation (UTF-8, UTF-16 big-endian, UTF-16 little-endian) might be applicable? Also: Defaulting to Latin-1 may be sensible, though? It may seem so to western europeans, but others may differ. A case could be made for UTF-8. I tend to agree. Further, the choice of defaulting to Latin-1 seems a strange one when much of the rest of the world (well, the networking world) seems to be moving towards more universal character set encodings. For example, URIs, XML, and UTF-8 has been the IETF preferred option since early 1998: [[ Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text. Protocols MAY specify, in addition, how to use other charsets or other character encoding schemes for ISO 10646, such as UTF-16, but lack of an ability to use UTF-8 is a violation of this policy; such a violation would need a variance procedure ([BCP9] section 9) with clear and solid justification in the protocol specification document before being entered into or advanced upon the standards track. For existing protocols or protocols that move data from existing datastores, support of other charsets, or even using a default other than UTF-8, may be a requirement. This is acceptable, but UTF-8 support MUST be possible. When using other charsets than UTF-8, these MUST be registered in the IANA charset registry, if necessary by registering them when the protocol is published. ]] -- http://www.ietf.org/rfc/rfc2277.txt #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] updating graphs non-destructively
In imperative languages, updating an object in a graph is an O(1) operation. However, non-destructive update appears to be O(n) with the size of the graph. For example, suppose we were to implement an auction system like eBay: --Data structures data Bid = Bid BidId Auction User Price DateTime data Auction = Auction Seller Title Description [Bid] data User = User UserId Name [Auction] [Bid] --Top level database type Auctions = FiniteMap AuctionId Auction type Users = FiniteMap UserId User type Bids = FiniteMap BidId Bid type Database = (Auctions,Users,Bids) If I want to add a bid, it seems like I have to traverse the whole Database looking for objects that point to the bid. One alternative is to store pointers rather than values e.g. data Bid = Bid BidId AuctionId UserId Price DateTime data Auction = Auction SellerId Title Description [BidId] data User = User UserId Name [AuctionId] [BidId] But that makes graph traversal expensive as each edge traversal then costs O(log n). O(log n) may be okay for this app, but what if I was implementing Friendster/LinkedIn/Tribe/etc.? Is there a better way to think about this? -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Data.Set whishes
Am Montag, 16. Februar 2004 10:05 schrieb Ketil Malde: Wolfgang Jeltsch [EMAIL PROTECTED] writes: * subsetOf :: Ord element = Set element - Set element - Bool (Isn't isSubsetOf a better name?) So is isElementOf. I just said subsetOf to be consistent with elementOf. Well, the naming in the Data.* modules should generally undergo some changes. Would x `isSubsetOf` y = x `union` y == y do, or did you want something more efficient? It's unefficient if, e.g., the x sets are always very small but so are union, intersect etc. I think, at first a complexity of O(|x| + |y|) would be acceptable so that your definition would be fine. Maybe, the implementation of union, intersect etc. should be changed so that the complexity is more like O(min(|x|,|y|)). -kzm Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: exists keyword and existential types
On Mon, 16 Feb 2004, Ashley Yakeley wrote:
A value of type (exists t. Interface t = t) consists of two values,
one of type t, and one dictionary value. For that reason a data type
is used to represent this (and a newtype type cannot be).
This is an implementation detail, though. It's like a function with one
declared parameter actually having two parameters, the other one a
dictionary. We don't have to box the explicit parameter so that the
implicit one can be propagated along with it.
So what's the difference? Data provides another layer of thunkage. For
instance:
data D = MkD Int;
newtype N = MkN Int;
Then (MkN undefined) is the same as undefined, but (MkD undefined) is
not.
I think this is orthogonal to the issue at hand. If there really is more
than one kind of undefined for (exists t. Interface t = t) (which I don't
think there is -- see below), then boxing it would just add yet another
kind.
So how does this apply to (exists t. Interface t = t)? Well, you'd have
two different versions of undefined depending on whether calculation
of the dictionary was part of the undefinition.
Dictionary calculation can never diverge, can it? They only depend on the
type, so if the program type-checks then it's always possible to construct
every dictionary. If the dictionary is stored with the value in an
unlifted pair, then there's only one kind of undefined.
And in any case, if problems like this really existed, they would apply
equally to implicit dictionary arguments, which seem to work without a
hitch. I'm effectively just proposing that we add implicit dictionary
return values.
openInputStream :: FilePath - IO (exists t. InputStream t = t)
Bear in mind you can't even write IO (forall t. whatever) in Haskell.
True, but why is this? Is there a deep reason why we can use nested
foralls as the arguments to (-), but not as the arguments to any other
type constructor?
data InputStream
{
f1 :: something;
f2 :: something';
f3 :: something'';
-- etc.
};
This is a much better way of doing semi-OOP.
I agree that this is a useful technique, but I'd still like to explore the
other possibilities. This technique won't help with my implicit parameter
state-threading proposal, for one thing.
AFAIK you can't really do proper OOP-style extensibility in Haskell at
all (and exists wouldn't help either).
Probably true. But I tend to use abstract interfaces far more often than
subtype polymorphism when I program in C++; I'd hardly notice the
difference if C++ didn't support inheritance at all. I don't know how true
this is of other people.
-- Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] updating graphs non-destructively
S. Alexander Jacobson wrote: In imperative languages, updating an object in a graph is an O(1) operation. However, non-destructive update appears to be O(n) with the size of the graph. For example, suppose we were to implement an auction system like eBay: [snip] One alternative is to store pointers rather than values e.g. data Bid = Bid BidId AuctionId UserId Price DateTime data Auction = Auction SellerId Title Description [BidId] data User = User UserId Name [AuctionId] [BidId] But that makes graph traversal expensive as each edge traversal then costs O(log n). O(log n) may be okay for this app, but what if I was implementing Friendster/LinkedIn/Tribe/etc.? Is there a better way to think about this? If you use pointers, surely the update becomes destructive? Unless you keep track of multiple versions of the top level database... which would be quite an effort! With a non-destructive update, I think you're stuck with visiting all the parts of the structure which can see the part you're changing. For a destructive update, more like what you'd use in an imperative language, you could try data Bid = Bid (IORef (BidId, Auction, User, Price, DateTime)) data Auction = Auction (IORef (Seller, Title, Description, [Bid])) data User= User(IORef (UserId, Name, [Auction], [Bid])) to get the edge traversal down to O(1). Regards, Tom ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
