On Fri, Feb 29, 2008 at 7:57 AM, felix winkelmann <[EMAIL PROTECTED]> wrote: > On Fri, Feb 29, 2008 at 1:41 PM, Tobia Conforto <[EMAIL PROTECTED]> wrote: > > felix winkelmann wrote: > Would a db interface include symbols as output?
Would it? I honestly don't know. I haven't seen it in practice, and can't think of a deal-breaking use-case. Enum types come to mind, but that could be handled (perhaps less naturally) with strings. Could it? I'm looking at Postgres, and wondering how to come up with a consistent approach for handling user-defined datatypes. There's no right solution, and the best compromise is to let the user register in/out translation functions. An out-function could translate a value in a custom type into anything, including a symbol (unless we *specify* that this should be illegal). Should it? If we are approaching a common dbi, we should decide now. But it feels premature to rule out an entire datatype for lack of a good "null" type. For representing sql-null, the special immediate-type solution is best because it's unambiguous. If that were ruled out, simply using the symbol 'null -- and forbidding database layers from returning symbols as output-values other than 'null -- would be my second choice, but it's an inferior solution, and I have a feeling I'd regret it later. But please not '(), for the same reason not #f, 0, or an empty string. > cheers, > felix (who would like to keep the number of immediate types small) I don't want to see a circus of immediate types either, but one more isn't horrible. I thought (void) was perfect for this, but I respect the concerns that have been raised. So, (void) needs a brother who has no semantic baggage. Best, Graham _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
