Re: [Chicken-users] New immediate values (was: DBI)

[Graham Fawcett]

On Fri, Feb 29, 2008 at 7:57 AM, felix winkelmann <address@hidden> wrote:
> On Fri, Feb 29, 2008 at 1:41 PM, Tobia Conforto <address@hidden> 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