Thanks for the patch. I've revised the writer function a bit -- there was some useless cruft in it, and you misspelled floating as foating -- and added a switch to turn off the raising of errors,
thanks for the cleanup, it was just a quick'n'dirty result of a longer debugging session...
*silently-truncate-literals*, which defaults to T, since I suspect not everyone is happy with errors like that popping up. You can set it to NIL and get the behaviour you're after.
...but i really don't like the default of that special.
rationale: 1) you start using the lib, do some calculations involving db storage, some time later realize that they are somewhat off, start digging where the hell it goes wrong, waste a lot of time looking at too many things until you finally realize that 7/10 written to the database silently comes back as something else than 7/10.
imho, that special should default to NIL for the least surprises and for bringing the symptoms of the error *much* closer to their cause.
then: 2) user stars using lib, stores ratios in db, at some point faces a descriptive error message which includes a hint about the above mentioned special, reads up on the issue if necessary, based on necessary understanding of the issue decides to add required coercions to his code or to set/bind the special to T.
summing up all the time people would spend with the use-case 1) is a lot more than people would spend with 2).
now, i don't care much, because i've been through 1) already... :) but i suggest these changes for everyone's good.
i've pushed what i think to my repo, but i will not stick to it. if you decide to keep things as they are, i'll eventually unpull my patch to enjoy the benefit of the zero distance from the official repo.
hth,
rationale: 1) you start using the lib, do some calculations involving db storage, some time later realize that they are somewhat off, start digging where the hell it goes wrong, waste a lot of time looking at too many things until you finally realize that 7/10 written to the database silently comes back as something else than 7/10.
But.... 7/10 will be written as 0.7 just fine. Of course, this holds for 1/3, but there's no way to do that right, so in effect we'd be disallowing the writing of rationals to the db (except in cases where the divisor is guaranteed to be something like 10 or 4).
then: 2) user stars using lib, stores ratios in db, at some point faces a descriptive error message which includes a hint about the above mentioned special, reads up on the issue if necessary, based on necessary understanding of the issue decides to add required coercions to his code or to set/bind the special to T.
Well, what I'm afraid of is 3) the user has been happily running a system on top of CL-Postgres, upgrades, and suddenly finds his system crashing. That's a bad thing, no?
Cheers, Marijn
But.... 7/10 will be written as 0.7 just fine. Of course, this holds for 1/3, but there's no way to do that right, so in effect we'd be disallowing the writing of rationals to the db (except in cases where the divisor is guaranteed to be something like 10 or 4).
yes, by default disallowing the writing of ratios to the db on which a store/load operation is not an #'identity. (btw, cl-perec enforces this philosophy on an even more fine-grained level for all the data types (or at least it should). it has the actual type information of the receiving column, not just the type of the value that is to be written, and errors *at storing* if the value is going to be distorted by the db).
which is along the line with my thinking: by default report potentially surprising behavior as early as possible (but leave some ways to acknowledge the issue, once the decision has been made). iow, fail early.
Well, what I'm afraid of is 3) the user has been happily running a system on top of CL-Postgres, upgrades, and suddenly finds his system crashing. That's a bad thing, no?
not in my world. i know i'm radical with this way of thinking, but if user (who is a programmer here!) is not ready for an upgrade, then they simply shouldn't upgrade. i have countless repos subscribed in my feed reader, so i get notified of the changes even before pulling them. incompatible changes are inevitable and DVCS' make it as easy to deal with them as never before. i had some patches even in postmodern itself that i didn't pull to the live system for quite a while.
and what you call "crashing" in my reading means that after the upgrade running the test suite stops with a descriptive error message, even showing the context... now, if people have no test suites at all, then no form of backward compatibility can save them.
this kind of "crashing" is a lot much better than getting a mail half a year later, which, after a few days investigation, leads to the realization that your government transferred the wrong amount of money to 3200 municipalities for half a year... :)
it didn't happen, because we catch it in the test phase of a new project (or we didn't get that mail yet... :) but still, you get the point.
anyways, this is just one opinion, but i hope gives some insight why i argue for this behavior.
postmodern-devel@common-lisp.net
-
Attila Lendvai -
Marijn Haverbeke