[ ghc-Bugs-608378 ] Unicode bug in toUpper/toLower
Bugs item #608378, was opened at 2002-09-12 13:44 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=608378group_id=8032 Category: Prelude Group: 5.04 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Norbäck (norpan) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode bug in toUpper/toLower Initial Comment: Since GHC now does full unicode, toUpper ought to be full Unicode also. According to the Haskell 98 Library Report, section 9: Function toUpper converts a letter to the corresponding upper-case letter, leaving any other character unchanged. Any Unicode letter which has an upper-case equivalent is transformed. I take as my example the character ÿ (which is the only one I can write in iso-8859-1 by the way). toUpper 'ÿ' ought to be unicode 0178 (hexadecimal). But it's not toUpper 'ÿ' gives 'ÿ' toLower (toEnum 0x178) gives toEnum 0x178 I understand that this may cause more trouble than it's worth, but either the report needs to be rewritten or the implementation changed. -- Comment By: Simon Marlow (simonmar) Date: 2003-08-20 10:08 Message: Logged In: YES user_id=48280 This is now fixed in the HEAD. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-12 14:31 Message: Logged In: YES user_id=48280 GHC doesn't support Unicode in any real sense. The Char type is 32 bits, but the rest of the system really only works with the ISO 8859 character set. Nonetheless, I'll leave the bug report here as a reminder :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=608378group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Hash functions
Many thanks for Data.HashTable, which I am about to use. Unfortunately I seem to need an unseemly hack because the key I want, namely ThreadId's, don't have a hash function defined, and defining one requires me to muck around with GHC internal functions. Could some more hash functions be provided? The logical method would be to have class HashKey key where hash :: key - Int32 and define it for as many types as possible. I think the reason I didn't do this was because the choice of a hash function usually depends on more than just the type of the data you want to hash. For example, there are lots of hash functions over Int, but you'll want to pick one that works well for the distribution of values you have. There really ought to be a way to get an Int from a ThreadId, though. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fast CString - IO PackedString fuction
is there a way to go from a CString to a PackedString w/o going through a normal String in the middle? or should i write my own? -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: let vs. where [was: Re: more unsafePerformIO questions (is it safe to use with ReadMode Handles)?]
G'day all. On Wed, Aug 20, 2003 at 07:42:59AM +0200, Jan Scheffczyk wrote: I always thought that there is a tiny difference between let and where: They're semantically equivalent. See, for example: http://haskell.org/onlinereport/decls.html#sect4.4.3.2 Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
'Forest inversion'?
Hi all, Recently I've discovered an inversion operation on forests that transforms 'wide' forests into 'deep' onces and vice versa. I'm sure that this operation is already known, however, I could not find any information on it. (Largely because I don't know under what name to look for it.) You Haskell guys know about data structures, so you should know more. :-) Example (use a fixed with font to view): the single-tree forest A /|\ B C D | | |\ E F G H | | I J | K is inverted to the forest A BE /| |\ C F I K / \ D G / \ H J and vice versa. In an implementation where every node has two pointers, one to its first child and one to its right-hand sibling, the inversion means that in every node those two pointers are swapped. In Haskell the algorithm looks like this: data Forest a = Forest {trees :: [(a, Forest a)]} deriving (Show, Eq) inv :: Forest a - Forest a inv (Forest []) = Forest [] inv (Forest ((a,f) : g)) = Forest ((a, inv (Forest g)) : trees (inv f)) and it is easy to prove that for every f :: Forest a, inv (inv f) = f. What would I want to do with it? Well, deep trees are difficult to navigate using existing tree controls. Example: Suppose I want to let the user play a text adventure, but I allow 'undo'. Then I can show him the tree of moves that he already tried, and let him backup to a previous state, and try something else at that point. This results often in a deep tree. So showing a wide tree instead (using the above inversion) might help the user. Especially if the children of a node are 'ordered' in the sense that the first child node is most important. So: is this 'forest inversion' known, under which name, what are the known uses, etc.? Thanks in advance! Groetjes, Marnix -- Marnix Klooster [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
container for different types, avoiding boiler plate
I think similar things have been asked before, but I couldn't find anything specific. I have a data type with attributes. These attributes have different types. Right now I'm using a lot of boilerplate like that: data Gender = Masc | Fem | Neutr ... data Attr= Gender Gender | Cat Cat | Graph Graph | ... data Type= TypeCat | TypeGender | ... deriving Eq myTypeOf (Gender _) = TypeGender myTypeOf (Cat_) = TypeCat ... myTypeOf _ = TypeError data Segment = Seg { attrs :: [Attr] } attr f seg = seg { attrs = f (attrs seg) } gattr :: Type - [Attr] - Maybe Attr gattr theType [] = fail attribute not found gattr theType (a:as) = if myTypeOf a == theType then return a else gattr theType as cat :: Cat - Segment - Segment cat c = attr ((Cat c):) -- set value gcat :: Segment - Maybe Cat-- get value gcat = deCat . gattr TypeCat . attrs where deCat (Just (Cat c)) = c deCat x = x ... Does anyone have some suggestions for making this more concise? Generic Haskell? Tricky type classes? Thanks, Markus -- Markus Schnell Infineon Technologies AG, CPR ET Tel +49 (89) 234-20875 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Weighted Automata: Workshop Announcement
[apologies if you receive multiple copies of this message] --- Weighted Automata: Theory and Applications Dresden University of Technology, June 1 - 5, 2004 The workshop will cover all aspects of weighted automata, ranging from the theory of formal power series to max-plus- algebra and applications as e.g. in digital image processing or algebraic optimization of networks. The aim is to present tutorials and survey lectures by outstanding scientists in this area. Moreover, we encourage everybody to participate in this workshop and present their own technical contribution in this area. Tutorials: P. Butkovic (Birmingham) U. Montanari (Pisa) J. Kari (Iowa City)J. Sakarovitch (Paris) Survey lectures: J. Albert (Wuerzburg) F. Katritzke (Siegen) S. Bozapalidis (Thessaloniki) W. Kuich (Wien) Z. Esik (Szeged) M. Mohri (ATT, New Jersey) P. Gastin (Paris) L. Staiger (Halle) All lecturers are asked to give a survey on their field of interest followed by recent research results. Submission: If you wish to present a technical contribution, please send us an abstract (preferably of at most one page) before February 15, 2004. Authors will be informed about acceptance of their submission before March 15, 2004. There will be a special issue of the Journal of Automata, Languages, and Combinatorics (JALC) on the topic of this workshop. The deadline for submission of papers is July 15, 2004. All submissions will be refereed according to the usual journal standards. Registration: Interested participants are most welcome. There are no conference fees. Participants from central/eastern european countries can apply for financial support. Important Dates: deadline for submission of abstractsFebruary 15, 2004 notification of acceptance March 15, 2004 registrationApril 1, 2004 submission of papersJuly 15, 2004 Further Information: http://www.orchid.inf.tu-dresden.de/gk-spezifikation/wata4.html --- Manfred Droste Heiko Vogler Dresden University of TechnologyDresden University of Technology Institute of AlgebraInst. of Theor. Computer Science D-01062 Dresden, GermanyD-01062 Dresden, Germany Tel.: +49-351-463-33908 Tel.: +49-351-463-38232 Fax: +49-351-463-34235 Fax: +49-351-463-37959 E-Mail: [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GPCE 03 Call for Participation
GPCE'03: 2nd International Conference on Generative Programming and Component Engineering In Cooperation with ACM SIGPLAN and SIGSOFT and co-located at NetObjectDays'03 September 22-25, 2003, Erfurt, Germany http://gpce.org/GPCE03 GPCE is the premier forum for dissemination and discussion of ideas on domain-specific languages, generative programming, model-based development, and component engineering. It brings together software engineering and programming language researchers and practitioners interested in key technologies for automating program development. This second conference will be co-located with NetObjectDays'03, one of the largest main-stream software development conferences in Germany. GPCE'03 program features 2 invited talks, by Olivier Danvy and Peri Tarr 21 papers featuring latest research in - Domain-Specific Languages - Staged Programming - Modeling-Based Development - Aspect-Orientation - Meta-Programming and Language Extension - Domain-Specific Code Generation 4 workshops - Reflectively Extensible Programming Languages and Systems - Product Line Engineering - The early steps: Planning, Managing, and Modeling - Component Engineering Methodology - GPCE Young Researchers Workshop 6 tutorials - Executable UML - Domain-Specific Languages - Multi-Staged Programming - Generatrive Programming - Model-Driven Development - Model-Driven Architecture 6 tool demonstrations of tools for - Metamodeling - Model-Driven Architecture - Generative development GPCE'03 attendees will have access to all NetObjectDays'03 events including Keynote Addresses by Steve Mellor, Jim Odell, and Dave Weiss. Poster submissions and submissions to the Product Line Engineering Workshop are still being solicited. For details of the conference program please refer to http://gpce.org/GPCE03. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: container for different types, avoiding boiler plate
I use my 'DynamicMap' type to handle this sort of thing. However, I don't really recommend this approach unless you're very careful. You basically lose out on all nice type checking properties and enter a world of dynamic typing (more or less). Anyway, you can find it at: http://www.isi.edu/~hdaume/DynamicMap.hs it uses NLP.FiniteMap, but you can replace this with Data.FiniteMap. You can then do things like: data Gender = Masc | Fem | Neutr deriving Typeable data Number = First | Second | Third deriving Typeable let dm = addToDM (addToDM emptyDM Masc) Second case lookupDM dm of Just Masc - is a guy Just _- is not a guy _ - i don't know gender case lookupDM dm of Just First - is first Just Second - is second _ - either i don't know or is third of course 'deriving Typeable' means you need GHC6; otherwise you can write the instances by hand. -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 5:01 AM To: [EMAIL PROTECTED] Subject: container for different types, avoiding boiler plate I think similar things have been asked before, but I couldn't find anything specific. I have a data type with attributes. These attributes have different types. Right now I'm using a lot of boilerplate like that: data Gender = Masc | Fem | Neutr ... data Attr= Gender Gender | Cat Cat | Graph Graph | ... data Type= TypeCat | TypeGender | ... deriving Eq myTypeOf (Gender _) = TypeGender myTypeOf (Cat_) = TypeCat ... myTypeOf _ = TypeError data Segment = Seg { attrs :: [Attr] } attr f seg = seg { attrs = f (attrs seg) } gattr :: Type - [Attr] - Maybe Attr gattr theType [] = fail attribute not found gattr theType (a:as) = if myTypeOf a == theType then return a else gattr theType as cat :: Cat - Segment - Segment cat c = attr ((Cat c):) -- set value gcat :: Segment - Maybe Cat-- get value gcat = deCat . gattr TypeCat . attrs where deCat (Just (Cat c)) = c deCat x = x ... Does anyone have some suggestions for making this more concise? Generic Haskell? Tricky type classes? Thanks, Markus -- Markus Schnell Infineon Technologies AG, CPR ET Tel +49 (89) 234-20875 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: 'Forest inversion'?
Dear Marnix, your transformation can be rewritten as the composition of three functions: one that converts the forest into a binary tree (this is based on the natural correspondence between forests and binary trees (*), see Knuth TAOCP, Vol 1), one that mirrors a binary tree swapping left and right subtrees, and one that transforms the resulting binary tree back into a forest. Each of these transformations is quite well-known, but alas I know of no name for the composition. Cheers, Ralf (*) The binary tree representation of forest is sometimes called left-child, right-sibling representation. But you probably already know that. Recently I've discovered an inversion operation on forests that transforms 'wide' forests into 'deep' onces and vice versa. I'm sure that this operation is already known, however, I could not find any information on it. (Largely because I don't know under what name to look for it.) You Haskell guys know about data structures, so you should know more. :-) Example (use a fixed with font to view): the single-tree forest A /|\ B C D | | |\ E F G H I J K is inverted to the forest A BE /| |\ C F I K / \ D G / \ H J and vice versa. In an implementation where every node has two pointers, one to its first child and one to its right-hand sibling, the inversion means that in every node those two pointers are swapped. In Haskell the algorithm looks like this: data Forest a = Forest {trees :: [(a, Forest a)]} deriving (Show, Eq) inv :: Forest a - Forest a inv (Forest []) = Forest [] inv (Forest ((a,f) : g)) = Forest ((a, inv (Forest g)) : trees (inv f)) and it is easy to prove that for every f :: Forest a, inv (inv f) = f. What would I want to do with it? Well, deep trees are difficult to navigate using existing tree controls. Example: Suppose I want to let the user play a text adventure, but I allow 'undo'. Then I can show him the tree of moves that he already tried, and let him backup to a previous state, and try something else at that point. This results often in a deep tree. So showing a wide tree instead (using the above inversion) might help the user. Especially if the children of a node are 'ordered' in the sense that the first child node is most important. So: is this 'forest inversion' known, under which name, what are the known uses, etc.? Thanks in advance! Groetjes, Marnix -- Marnix Klooster [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: container for different types, avoiding boiler plate
On Wed, 20 Aug 2003 08:25:39 -0700 Hal Daume [EMAIL PROTECTED] wrote: I use my 'DynamicMap' type to handle this sort of thing. However, I don't really recommend this approach unless you're very careful. You basically lose out on all nice type checking properties and enter a world of dynamic typing (more or less). Anyway, you can find it at: http://www.isi.edu/~hdaume/DynamicMap.hs it uses NLP.FiniteMap, but you can replace this with Data.FiniteMap. You can then do things like: data Gender = Masc | Fem | Neutr deriving Typeable data Number = First | Second | Third deriving Typeable let dm = addToDM (addToDM emptyDM Masc) Second case lookupDM dm of Just Masc - is a guy Just _- is not a guy _ - i don't know gender case lookupDM dm of Just First - is first Just Second - is second _ - either i don't know or is third of course 'deriving Typeable' means you need GHC6; otherwise you can write the instances by hand. One useful thing I've found when using Dynamics is that pattern guards can be used as a relatively compact typecase. E.g. foo dyn | Just b - fromDynamic dyn = if b then T else F | Just (s :: String) - fromDynamic dyn = show s | otherwise = show dyn The only other way I could think of getting typecase like behavior at another time before I knew about pattern guards was through a horrendous set of nested case statements. Another trick for debugging is it is fairly easy to get Haskell to know the expected type, so that you can have error messages, in a generic error handling routine, like, expected Int but got FooBar. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: overlapping instances and functional dependencies
Wolfgang Jeltsch has observed: I have this code: class C a b c | a b - c where f :: a - b - c instance C a b c = C a (x,y,b) c where f a (_,_,b) = f a b instance C a (a,c,b) c where f _ (_,c,_) = c ghci -fglasgow-exts -fallow-overlapping-instances compiles it without complaint but hugs -98 +o says: ERROR ClassProblem.hs:7 - Instances are not consistent with dependencies *** This instance: C a (a,b,c) b *** Conflicts with : C a (b,c,d) e *** For class: C a b c *** Under dependency : a b - c Can anyone tell me what the reason for this is and, maybe, how to avoid these problems with Hugs? I believe it's helpful to think about this problem in terms of logical programming, and proceed in phases. Phase 1. The compiler sees the instances of a class C and compiles them into a database of instances. In Prolog terms, given the instances instance C a b c = C a (x,y,b) c instance C a (a,c,b) c the compiler asserts c(A,tuple(A,C,B),C,dict2). c(A,tuple(X,Y,B),C,dict1) :- c(A,B,C,_). In Haskell, lower-case type identifiers are variables and upper-case one are type constants. In Prolog, it's the other way around: lower-cased identifiers are constants and upper-cased are variables. I hope that won't cause too much confusion. I happen to have SWI-Prolog handy, in which I assert the above two facts. Phase 2. Suppose the compiler sees a type with a class constraint ``C Int (Int,Char,Bool) t'' The compiler can determine the appropriate instance by issuing a query: ?- bagof(Dict,c(int,tuple(int,char,bool),T,Dict),Dicts). Dict = _G158 T = char Dicts = [dict2] Yes In our case, only one instance matched, and we found the corresponding dictionary. If Dicts were a list of two or more dictionaries, we would have needed to choose the most specific, if any. Phase 1a. Before we get to Phase 2 however, we have to take care of one more problem. The class declaration specified a dependency: class C a b c | a b - c which all members of that class must satisfy. The instances (which define the membership) must be consistent with the dependency a b - c. The consistency would be violated if there were two types C a b c1 and C a b c2 such that c1 /== c2. Thus we can check the consistency of the instances by searching for a counter-example: ?- c(A,B,C1,_), c(A,B,C2,_), \+ C1 == C2. A = _G151 B = tuple(_G151, _G153, tuple(_G151, _G158, _G302)) C1 = _G153 C2 = _G158 Yes Alas, in this case we found a counter-example: types C a (a,c,(a,c',d)) c C a (a,c,(a,c',d)) c' with c' /= c match some instance but contradict the functional dependency. Therefore, the compiler complaints. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: let vs. where
At 7:42 AM +0200 8/20/03, Jan Scheffczyk wrote: Hi Andrew, let x = expensiveComputation foo in x + x I would certainly hope that expensiveComputation wasn't called twice, and even though the language doesn't guarantee it, I have already written code that assumed it. I always thought that there is a tiny difference between let and where: Using let expensiveComputation foo might be computed twice (depending on the compiler?). But using: x + x where x = expensiveComputation foo should compute the value for x only once. Therefore, I always try to use where for common subexpressions. Please correct me if I'm wrong here. The reserved word let introduces an expression (a let-expression), but there's no such thing as a where-expression. The reserved word where can be used only in definitions. For example, 3 + ((x + x) where x = expensiveComputation foo) is invalid syntax, whereas 3 + let x = expensiveComputation foo in x + x is OK. And here's a use of where in a definition: let z = x + x where x = 2 in z*5 That could have been written using only let: let z = let x = 2 in x + x where x = 2 in z*5 Watch out for the Hugs 98 command line-- it allows z*5 where z = x + x where x = 2 but that's not a truly valid expression, because you can't embed it in a larger expression: 2 + (z*5 where z = x + x where x = 2) is properly identified as a syntax error. Regards, --Ham -- -- Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138Austin, Texas 78712-1188 [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: sequencing data structures
I want to sequence data structures in an efficient manner, to store them to files and to send them over the network. Ideally, I want to be able to write an infinite data structure (at least one containing loops). If that is not possible I want to be able to read as lazily as possible, this means traversing the data structure in breadth first order, so that a cons form can be reached quickly. Does anyone have any thoughts/pointers on this subject? It would surprise me if nobody has had this problem before. Hi Martin, If you can live with supporting only one compiler then you can get a lot of this done via the FFI. In buddha, my debugger for Haskell, I have to print pretty versions of arbitrary data structures, which is in many ways similar to what you want to do. I recently extracted the relevent code into a library for reifying: http://www.cs.mu.oz.au/~bjpop/code.html It gives: data Graph = ... reify :: a - IO Graph prettyGraph :: Graph - String Its not what you want but it might give you some ideas. GHC has quite a nice API for its runtime environment, and it is straightforward to write some C code that crawls over the heap. If you are careful not to cause any garbage collection then you can find cycles without much problem. Some issues are what to do about thunks? You could force them but they might diverge, so it would have to be incremental. Also your data structure might have functions inside it, which are going to be hard no matter what you do. Cheers, Bernie. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Monads and Maybe
On Tue, 19 Aug 2003 14:09:16 +0100 (BST) C T McBride [EMAIL PROTECTED] wrote: Hi As an example, I'll use the Maybe monad. Suppose I want to write code to handle experimental data, in which there might be missing values. I might then decide to represent measurements by data of type Maybe Double, with missing values represented by Nothing. I could then go on to define functions on missing values, which would return Nothing when their argument is Nothing, and I could string these functions together via the monad mechanism. Fine. But how would I handle e.g. addition of two such values? The result should be Nothing when either of its arguments isNothing. Is there any mechanism to handle that? Yes, liftM2. Defined in module Monad (or Data.Monad resp.). Konrad. Wolfgang Or, more generally, infixl 9 $ ($) :: Monad m = m (s - t) - m s - m t mf $ ms = do f - mf s - ms return (f s) or just liftM2 ($) or just ap ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: sequencing data structures
On Wednesday 20 August 2003 9:16 am, Bernard James POPE wrote: If you can live with supporting only one compiler then you can get a lot of this done via the FFI. In buddha, my debugger for Haskell, I have to print pretty versions of arbitrary data structures, which is in many ways similar to what you want to do. [details omitted] This interface looks pretty similar to the interfacein Hugs The module is hugs98/libraries/Hugs/Internals.hs: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/libraries/Hugs/Internals.hs?rev=1.2content-type=text/x-cvsweb-markupsortby=log It seems to me that, with a little tweaking of the Buddha and Hugs.Internals interfaces, we could provide the same interface on both Hugs and GHC. (It's also pretty simple to implement so it could potentially be added to NHC98 as well.) The major difference between the interfaces is that Buddha's thunk representation is a recursive datatype so the reify operation relies on lazyness to handle cycles and large substructures. Instead, Hugs.Internals thunk representation is a non-recursive datatype and 'classifyCell' (the equivalent of Buddha's reify) is an operation to classify a single thunk as an Int, Float, application, etc. and the program must explicitly traverse function arguments to examine them. This is a pretty small difference - the Buddha-style of interface is easily implemented in terms of the Hugs.Internals interface. Another potential difference is in the semantics. The semantics of the Hugs.Internals operations is difficult because they allow you to examine unevaluated thunks in the heap. For example, you might look at a thunk for: 1+2 and see any of the following: addInt (fromInteger dictionary 1) (fromInteger dictionary 2) addInt 1 (fromInteger dictionary 2) addInt 1 2 3 in fact, a legal (but bizarre) Haskell compiler could also return 4-1 1 + (1+1) id 3 or anything else whose value is 3. To reflect this in the semantics, we use the same trick that we use in the semantics of exception handling and use non-determinism. That is, a thunk is viewed as a set of all possible representations of the same _value_ and classifyCell merely selects one of those representations (which is why classifyCell is in the IO monad). Sadly, the resulting semantics isn't compositional since the semantics of an application e1 e2 contains both 'good' meanings based on the semantics of e1 and e2 [ x y | x - [[e1]], y - [[e2]] ] but also many expressions that have nothing to do with the semantics of e1 or of e2 but which just happen to evaluate to the same value (like the legal but bizarre reifications of 1+2 given above). Not having a compositional semantics is frequently regarded as a Bad Thing. -- Alastair Reid ps Hugs.GenericPrint in the same directory contains a generic printing function based on Hugs.Internal that produces output identical to the old Hugs printing mechanism. There's also code (Hugs.CVHAssert) to write assert functions where the assertions are about the size of the arguments (based on an idea by Cordelia Hall) and there's even some code to disassemble bytecode functions. pps I doubt that these modules have been tested in several years - minor bitrot may well have set in. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: sequencing data structures
I want to sequence data structures in an efficient manner, to store them to files and to send them over the network. Simply deriving Show and Read is not very good, because it's space inefficient and read cannot give any output until the whole data structure is parsed. So I thought I should store them in some space efficient format. First problem: how to make them derivable (so that I don't have to write boilerplate class instances for all my data structures). I read the derivable type classes paper, but it's not implemented in ghc (only Unit and :+: and :*: are, which is not enough). So how to go about it? Using DrIFT? Template Haskell? [Shameless plug]: This is typically the kind of thing Generic Haskell was designed for: http://www.generic-haskell.org/ For more information you can also consult your local Generic Programming expert Patrik Jansson. -- Johan Jeuring ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Database interface
Tim Docker writes: : | The list being folded over | is implied by the DB query, is accessible through the IO monad. | Hence a parameter is not required. It would really be: | | doquery :: Process - String - b - (b - IO (b,Bool)) - IO b : | One thing that I am unsure about is whether the column value | accessing functions that I specified before | |stringv :: Process - CInt - IO String |doublev :: Process - CInt - IO Double |intv:: Process - CInt - IO Int | | should return actions in the IO monad as above, or instead should | be in some other DBQuery monad, that trivially extends the IO monad, | but is only valid inside the doquery call. This would have the benefit | of restricting the column access functions to inside a query via the | type system. How about introducing a Cursor abstract data type? doquery :: Process - String - b - (Cursor - b - IO (b, Bool)) - IO b stringv :: Cursor - CInt - IO String doublev :: Cursor - CInt - IO Double intv:: Cursor - CInt - IO Int This achieves the restriction you're after, because doquery is the only exported producer of Cursor, and stringv etc. are the only exported consumers of Cursor. It also has the benefit that the function you pass to doquery can make other calls to doquery, without mucking up the 'current row' state. There would be one current row per Cursor, not one per Process. | I'd also probably use a typeclass to specify a single colv function. | ie: | |class DBCol a where |colv :: DBQuery a | |instance DBCol String where... |instance DBCol Double where... Good idea. The user can always use explicit type signatures to resolve ambiguity, and even then the code size will be about the same as with stringv etc. - Tom ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
haskell reify, was sequencing data structures
Hi, Alistair writes: This interface looks pretty similar to the interfacein Hugs The module is hugs98/libraries/Hugs/Internals.hs: Yes. You may recall that I had something even closer to the Hugs interface previously which I called GhcInternals. I modelled that on what Hugs provides. I even think that you suggested that we unify their designs. I agree, but I don't think I replied, sorry about that. I think I got tangled up in other problems and never got back to it. Noone else said anything about that version, so I assumed that there was very little interest in it - which is probably true. It seems to me that, with a little tweaking of the Buddha and Hugs.Internals interfaces, we could provide the same interface on both Hugs and GHC. (It's also pretty simple to implement so it could potentially be added to NHC98 as well.) I'm all for making a consistent interface. But I wonder what kind of interface people would like and what they would want to do with it, besides writing universal printers (which are very useful nonetheless). Things that seem important (to me) are: - Do you want to observe cycles and or sharing? Of course this is very hard to do because of garbage collection. In buddha I observe cycles but not other forms of sharing. To do this I have to be very careful not to cause garbage collection when I'm traversing the heap. I don't remember now whether you can observe cycles using the Hugs internals interface. I _think_ that it was possible but I don't remember. - Do you want the ability to force thunks or just stop when you see them? The incremental approach of the Hugs interface is nice, but I'm worried that it will make the detection of cycles harder - that's the reason I moved to reify in buddha away from Hugs style. (In buddha I just want to print things up to the extent that they are evaluated when reify is called, I stop when I see a thunk, cycle, nullary constructor). - There needs to be some support from the compilers/interpreters. Hugs already has this. Ghc has some of it, but I abuse the profiling system in order to get the names of constructors to be present on the heap. I'm not happy with this. Under normal compilation GHC doesn't keep constructor names around, as far as I know. However, the new debugger in GHC must do something to get names of things, so perhaps the -prof hack is no longer needed? GHC's heap representation is already quite intricate, and I wonder if the implementors/maintainers would not want to introduce more complexity for the sake of a library that few people might use? I don't know what the case is with NHC, though I seem to recall Malcolm or Olaf saying that such a thing would be possible, but I might be making that up. Cheers, Bernie. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: let vs. where
At 7:42 AM +0200 8/20/03, Jan Scheffczyk wrote: Hi Andrew, let x = expensiveComputation foo in x + x I would certainly hope that expensiveComputation wasn't called twice, and even though the language doesn't guarantee it, I have already written code that assumed it. I always thought that there is a tiny difference between let and where: Using let expensiveComputation foo might be computed twice (depending on the compiler?). But using: x + x where x = expensiveComputation foo should compute the value for x only once. Therefore, I always try to use where for common subexpressions. Please correct me if I'm wrong here. The reserved word let introduces an expression (a let-expression), but there's no such thing as a where-expression. The reserved word where can be used only in definitions. For example, 3 + ((x + x) where x = expensiveComputation foo) is invalid syntax, whereas 3 + let x = expensiveComputation foo in x + x is OK. And here's a use of where in a definition: let z = x + x where x = 2 in z*5 That could have been written using only let: let z = let x = 2 in x + x where x = 2 in z*5 Watch out for the Hugs 98 command line-- it allows z*5 where z = x + x where x = 2 but that's not a truly valid expression, because you can't embed it in a larger expression: 2 + (z*5 where z = x + x where x = 2) is properly identified as a syntax error. Regards, --Ham -- -- Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138Austin, Texas 78712-1188 [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe