hello, > I'm not convinced that the binary library should "natively" support > cyclic data. I think that if saying: > > print x > > would not terminate, then there's no reason that > > puts bh x > > should terminate. I like to think of "puts" as a binary version of > print. (That is, of course, unless the instance writer for the > Binary/Show instances of the type of x is smart enough to not keep > writing the same thing over and over again.) I would challenge the > interested party to write a Show instance of String which wouldn't loop > indefinitely on "repeat 'x'". well, it is your choice to think of it as you like, but this is not what my original mail was about. i think the ability to make data persistant is a useful one and it should be as transperant to the programmer as possible. when i write something like: ones = 1 : ones
i don't think of "printing infinately many ones in memory" and i don't see why i should start thinking of it that way just because i want to make the object persistant. after all, one can think of the disk as a verys low memory. > If the user has some cyclic data structure and they want to be able to > write it in binary form, it should be on their shoulders to do it > correctly, not on the library's. why is that? i thought the whole point of having nice tools is that you don't need to write mindless stuff and concentrate on the important bits of your program. i don't have to worry much about sharing and cyclic data when i program in Haskell (i.e. it just happens), why should i suddenly start to worry about that if i want to make something persistant across executions of my program. > So essentially, I believe 'deriving Binary' should work identically to > 'deriving Show', except using a binary rep instead of a string rep. something like that could be useful, but with drift and the atrem library one can already do some of that. and the aterm library is a reasonably portable way to represent terms. this is definately not what i had in mind in my original post. >> it in Haskell, as presumbably sharing is not observable from within >> the language. this is why the "deriving" bit seems essential - the >> compiler can perform some magic. > > I assume you mean something like: > > let x = ...some really large structure... > y = [x,x] > in puts bh y > > then the size of what is written is |x+c| not |2x| for some small c? If > so, then I don't believe this can be implemented in the language; it > would have to be in the compiler. this is what i meant by compiler magic. > I see this as unlikely of happening > because it would mean that all compilers would have to implement this > identically and some might not handle sharing the same manner. different implementations do not need to implement sharing in the same way. they need to understand a common format. i am not saying designing such a format is easy, in fact things like: nats = 0 : map (+1) nats seem tricky as they involve functions. but persitance is useful. in fact as a beginning i was hoping for something that works in say GHC, and won't be too hard to implement. actually i thought it might already exist, but i guess not. bye iavor _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
