Re: Handling large ini files.
G'day all. On Sun, Jul 13, 2003 at 10:09:21AM +1000, Andrew Rock wrote: > I think that each being a customisation *is* sufficient for coherence > of one data structure to hold them all. I agree, though using different data structures for each set of configuration parameters which will be used together is also something to consider. Also, if you're using GHC, -funbox-strict-fields is one flag you may look into. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Handling large ini files.
On Sunday, July 13, 2003, at 06:54 AM, Thaddeus L. Olczyk wrote: A while ago I looked at Haskell. I got stuck on a problem which basically caused me to stop using Haskell. Realising that I never asked anyone else how they would approach the deal, I decided to ask before I put the final chapter on Haskell. I have a program that requires a lot of customisation. As a result there is an initialization file with many entries ( typically 30-80 entries ). Some of these entries need to be accessed quite often, so that opening the file and reading in on demand is not really an option. So the basic question is how do I handle access to these parameters? PS: I've thought of Hugh's approach to global variables, but even with compound data structures it really isn't practical for such a large number. Not even when creating compound structures to hold the data. Worse you wind up with data structures which are not coherent having only the fact that each is a customisation in common. I think that each being a customisation *is* sufficient for coherence of one data structure to hold them all. My approach was to define a data structure that stored a sequence of flags, bindings of property names to values, sets of those, and sequences of those. For this I wrote a parser and some accessor functions. See section 7 in http://www.cit.gu.edu.au/~arock/hlibs/ABRHLibs.pdf Cheers, Rock. -- Andrew Rock -- [EMAIL PROTECTED] -- http://www.cit.gu.edu.au/~arock/ School of Computing and Information Technology Griffith University -- Nathan, Brisbane, Queensland 4111, Australia ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Handling large ini files.
A while ago I looked at Haskell. I got stuck on a problem which basically caused me to stop using Haskell. Realising that I never asked anyone else how they would approach the deal, I decided to ask before I put the final chapter on Haskell. I have a program that requires a lot of customisation. As a result there is an initialization file with many entries ( typically 30-80 entries ). Some of these entries need to be accessed quite often, so that opening the file and reading in on demand is not really an option. So the basic question is how do I handle access to these parameters? PS: I've thought of Hugh's approach to global variables, but even with compound data structures it really isn't practical for such a large number. Not even when creating compound structures to hold the data. Worse you wind up with data structures which are not coherent having only the fact that each is a customisation in common. Thaddeus L. Olczyk --- Think twice, code once. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Multiple "pointers" to "objects"
On Sat, 12 Jul 2003 07:47:02 -0700 (PDT) Ron de Bruijn <[EMAIL PROTECTED]> wrote: > > It's ofcourse possible to put a list of Subjects that > a Teacher teaches in the data declaration of the > teacher. But then there is no way of saying > efficiently (O(1) Just a pointer or index):"Give me a > list of all teachers that give Physics", and that's > just what I need. Are you sure that your data structure shouldn't be expressed by a graph? In that case, there is a very recent thread (last post today) on functional graph algorithms. I think that the difficulties you are facing are from the fact that you are trying to express a purely functional "updatable" graph. V. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Representing cyclic data structures efficiently in Haskell
Sarah Thompson <[EMAIL PROTECTED]> writes: [...] > work that well for circuits because, for anything other than trivially > simple components, the connections between nodes need to be labelled. it's been a while since i used it, but i thought erwig's graph library had labels on edges. it's a really sweet piece of work (disclaimer: i used the ml version). andrew -- http://www.acooke.org ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: accessing Haskell-Cafe from oe
fwiw you can also use gnus to access email (via an imap server) as a newsgroup. andrew "Jeff Aimt" <[EMAIL PROTECTED]> writes: >I discovered recently (thanks google) that Haskell Cafe was also named >"fa.haskell", but can't find a news server which would let me access >it like any other newsgroup. If someone accesses haskell cafe using a >free news server, could he say me which one ? -- http://www.acooke.org ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Multiple "pointers" to "objects"
Hi there, I was almost certain that Haskell was a great language until I wanted to make a real usefull program and got the following problem. I have data Lesson = Lesson Teacher SomeOtherProperties deriving Show data Subject = Subject Name [Teacher] SomeOtherProperties deriving Show data Teacher = Teacher TimeTable SomeOtherProperties What I want is that when I put some lesson in my timetable, the resources needed for that lesson are used up, so for example the timetable of a teacher will fill with each lesson that it gives. The problem is that when I "model" it this way, the state of the teachers that can give a certain subject will not change (suppose I have some function that fills one timeslot of the timetable of a teacher). It makes it even harder, because of the fact that one teacher can teach multiple subjects. In an OO-language I would simply let each element of the list of TeacherObjects of Subjects point to some TeacherObject, so it remembers it state, but that's anti-Haskell. It's ofcourse possible to put a list of Subjects that a Teacher teaches in the data declaration of the teacher. But then there is no way of saying efficiently (O(1) Just a pointer or index):"Give me a list of all teachers that give Physics", and that's just what I need. I could use a hashtable which includes the teachersobjects as values and the subjects as keys, but that isn't a very beautiful solution. This would give me(building of Hashtable O(n) and getting all teachers of some subject O(1)), so it would do. I am almost sure there exist some nice way of doing this, because otherwise Haskell would be completely useless IMHO, but I don't know it. Do you have any idea? Greets Ron __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Arrow Classes
Alastair Reid <[EMAIL PROTECTED]> writes: >> I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty) >> for fine-grained hierarchies. > > One cost which doesn't seem to have been mentioned is the programmer cost. > > With the current Haskell Prelude, a matrix operation (say) might have type: > > invert :: Num a => Matrix a -> Matrix a > > but, if we had one operation per class, the type might be: > > invert :: (Add a, Subtract a, FromInteger a, Eq a, Multiply a) > => Matrix a -> Matrix a > > More flexible but quite unwieldy. IIRC, Clean essentially has this. Though it's more like invert :: (+ a, - a, FromInteger a, = a, * a) => Matrix a -> Matrix a (I may be wrong about the syntax and the specifics :-) - Hari -- Raja R Harinath -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Template Haskell question
In article <[EMAIL PROTECTED] .com>, "Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote: > Yes, sorry, as Ian says, type splices just aren't implemented at the > moment. The error message is uninformative. > > This is useful info though -- someone wants type splices! Ah, but what I really want is to be able to splice in several types that are all connected in the context. (C1 a b,C2 b c) => $(foo [t|a|] [t|b|] [t|c|]) Right now I'm using m4, the textual preprocessor. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Decimal Literals
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Ketil Z. Malde) wrote: > I.e. for 3.14, allow any rational number in [3.14,3.15), or > perhaps (3.135,3.145]? Specifically the simplest rational in the range (I prefer the second one, "round half even"). One rational is simpler than another if both its numerator and denominator are closer to zero. In any given range, there is one rational that is simpler than all the others. I have a function that finds this rational, because I had to implement it for HScheme, because there's a function specified in R5RS called "rationalize" that must do this. In this case it tells me the simplest rational is 22/7. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Arrow Classes
In article <[EMAIL PROTECTED]>, Alastair Reid <[EMAIL PROTECTED]> wrote: > One way to overcome part of this problem would be to generalize the idea of > 'type synonyms' to allow 'context synonyms'. For example, we have type > synonyms like: > > type Point = (Int,Int) > > we could have 'context synonyms' like: > > class Num a => (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) That would be quite unnecessary. Simply write this: class (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) => Num a; instance (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) => Num a; And now you can write this: invert :: Num a => Matrix a -> Matrix a I use this idiom quite frequently for "joining" classes together. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Arrow Classes
> I'm glad to hear there isn't a _serious_ cost (i.e. performance penalty) > for fine-grained hierarchies. One cost which doesn't seem to have been mentioned is the programmer cost. With the current Haskell Prelude, a matrix operation (say) might have type: invert :: Num a => Matrix a -> Matrix a but, if we had one operation per class, the type might be: invert :: (Add a, Subtract a, FromInteger a, Eq a, Multiply a) => Matrix a -> Matrix a More flexible but quite unwieldy. One way to overcome part of this problem would be to generalize the idea of 'type synonyms' to allow 'context synonyms'. For example, we have type synonyms like: type Point = (Int,Int) we could have 'context synonyms' like: class Num a => (Add a, Subtract a, FromInteger a, Eq a, Multiply a, ...) Adding context synonyms would make it possible to write types concisely when using fine-grained class hierarchies and would also be useful with extensions like Hugs' T-REX or implicit parameters. Adding context synonyms would not help with type error messages though. When using TREX to encode an abstract syntax tree for the C language, I once got an error message that was over two pages long (i.e., about 4000 characters long). The error message amounted to saying that one list of fields didn't match another list of fields but with two pages of field names to look at, it was impossible to say what the differences between the types were. Things would not be that bad with the example types above but they would certainly be harder than the current error messages. -- Alastair Reid ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
