RE: [Haskell-cafe] how to avoid overlapping instance error?
If you are not using them to prevent overlapping instances, then why require instance decls at all? For example, why does GHC require an instance decl here: instance (Ord x)=ToSet [] x where toSet = Set.fromList But not here: listToSet x = Set.fromList x Or I suppose, one could rephrase this question as why not simplify instance declarations to be: instance ToSet where toSet = Set.fromList And let the typechecker take care of figuring out what instance is being specified here? -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Mon, 28 Feb 2005, Simon Peyton-Jones wrote: Unfortunately, the context of an instance decl is not taken into account when matching instance decls. Yes, it would make sense to do so, but it'd make the system yet more complicated. So Show (table item) overlaps with Show ([] item) Overlap is checked lazily, so if you look for Show (MyTable t) you won't get overlap. Only if you ask for Show (table item), where the type checker still doesn't know what type 'table' is going to be, do you get a problem. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of S. | Alexander Jacobson | Sent: 25 February 2005 17:09 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] how to avoid overlapping instance error? | | | Currently, the HAppS.DBMS lib requires the user to provide a Show | instance for their table types. An example might be: | | instance (Show item) = Show (MyTable item) where | showsPrec d table = showsPrec d $ Set.toList $ myTableSet table | | But the Table class itself defines a toSet function so I think I | should be able to do this once for all Table instances: | | instance (Show item,Ord item, Table table item p) = Show (table item) where | showsPrec d table = showsPrec d $ Set.toList $ toSet table | | But I get an error telling me I am overlapping with Show [a]. | | Since [] is not an instance of Table, I don't see why there should be | an overlap. | | -Alex- | | __ | S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Numeric vs. relative precedences of infix operators
Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as (*) has precedence over (+)? The compiler could construct a topographically ordered graph from these relations. This way it would also be possible that from two infix operators none has precedence over the other (although the have not the _same_ precedence), thus the sub-expressions with these operators must be enclosed in parentheses. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numeric vs. relative precedences of infix operators
Henning Thielemann writes: Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as (*) has precedence over (+)? The compiler could construct a topographically ordered graph from these relations. Widely accepted is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc. Why not 10, 20, 30,... ?? When I taught compilation, I suggested to use pairs (lprec,rprec) to denote simultaneously the precedence and the associativity. The parsing becomes quite homogeneous. (This is a very old idea, not mine, obviously...) Of course, there is a necessity to define the non-associativity as well... Some partial ordering is needed. But in this style it is even possible to declare bracketing operators. If the lprec of the second is equal to lprec of the first, then *both* operators are reduced. Parentheses become operators as all others... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] postgresql foreign function call segfaults
Hi Group, i'm trying to complete an haskell pgsql interface. all compiles well when using ghc's generated executable but it segfaults when i do a pqexec. -- PGresult *PQexec(PGconn *conn, const char *query); foreign import ccall libpq-fe.h PQexec pqexec::X_PGconn-CString-IO X_PGresult here's the offending code: create conn=do putStrLn creating table products putStrLn (\t++screate) q- newCString screate -- segmentation fault here! rs- pqexec conn q stat- pqcmdstatus rs stats-peekCString stat putStrLn (\tstatus is: ++ show stats) ra- pqcmdtuples rs ras-peekCString ra putStrLn (\trows affected is: ++ show ras) screate= CREATE TABLE products ( ++ product_no integer, ++ name text, ++ price numeric ++) i'm using pgsql 7.4, gcc 3.3.4, ghc 6.2.2 i tried compiling with -fvia-C and it doesn't finish compiling. i'm asking this question in the fear that i have done something wrong. i have posted my code here: http://www.eyan.org/haskell/Postgresql.hsc the makefile i'm using is here: http://www.eyan.org/haskell/Makefile the generated hc file is here: http://www.eyan.org/haskell/POstgresql.hc -- kind regards, eyan http://www.eyan.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Bound threads
Simon Marlow [EMAIL PROTECTED] writes: Is it important which thread executes Haskell code (I bet no) and unsafe foreign calls (I don't know)? If not, couldn't the same OS thread execute code of both threads until a safe foreign call is made? Actually in a bound thread, *all* foreign calls must be made using the correct OS thread, not just the safe ones. So your scheme would involve a context switch at every foreign call, which would end up being rather expensive. Ok. As I understand this (and as I'm trying to implement a similar scheme for my language), when an unbound thread performs a safe C call, the current OS thread transforms from a worker to a bound thread, and another worker is spawn if needed for remaining Haskell threads. So I have another idea: Why is the main thread bound? Wouldn't it be sufficient that, in cases where it's important to have the main Haskell thread bound to the main OS thread, the programmer wraps the main computation in a function which calls C and then calls back Haskell? Such function, if executed before spawning other threads which perform safe C calls, would in effect bind the threads together. That way there would be no OS thread synchronization needed when the main Haskell thread synchronizes with unbound threads. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] how to avoid overlapping instance error?
| Or I suppose, one could rephrase this question as why not | simplify instance declarations to be: | |instance ToSet where | toSet = Set.fromList | | And let the typechecker take care of figuring out what instance is | being specified here? That might be possible, but Haskell forces you to be a bit more explicit, that's all. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Browser-like UI
Hi, I've seen some options for GUI programming in Haskell libraries page, but what I really would like is to define my user interface using HTML (or, maybe, SVG). What are the options to do that in Haskell? I've read that Gtk2Hs has a mozilla rendering engine, but unfortunatly that won't build on my 64Mb computer. What else can I use? How does that work, can I handle HTML events with Haskell code? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numeric vs. relative precedences of infix operators
G'day all. Quoting [EMAIL PROTECTED]: Widely accepted is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc. Why not 10, 20, 30,... ?? I _think_ we had this back around Haskell 1.1 (which I never used, but early Gofers also had it). Moreover, operators could also have arbitrary fixity (prefix, infix, postfix). I'm not sure why this feature was dropped, but it's probably to do with the fact that when you do this, the language no longer has a managable LR grammar. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
