Vincent Manis scripsit:
> Please, please, don't ever write functions that return void as anything
> other than an indication that no value was returned.
If no value is returned, you should use (values), which genuinely returns
no values and is distinguishable by call-with-values or any of the macros
built over it. It's true that if you use (values) in a context where
there must be a value, Chicken coerces it to #<unspecified>, but they
are not the same concept.
> #;44> (car (db-fetch-row (db-query "select salary where empname='Bilbo
> Baggins'")))
> #;45>
>
> So now, (a) you get no output, which might be mystifying and (b) car
> is now returning void. Neither of these violates any language rule,
> but each violates the Law of Least Astonishment.
I grant (a) is surprising, but I deny that (b) is.
> For SQL nulls, one could use '(), as has been mentioned;
That works only because SQL has such an impoverished domain of values.
The same is not true for other languages that Chicken can interface with,
including languages for non-SQL database engines. Identifying the null
value with the zero-length list is really a data pun.
> alternatively, an object called the-SQL-null-object could be created
> (perhaps as a record type value).
That is a priori reasonable, but it won't work with eq?, whereas the
unspecified value will.
> Incidentally, there are several different meanings for null in SQL,
True but not immediately relevant.
> People have enough trouble understanding SQL null without further
> conflating it with `this function returns no values'.
As I explained above, they are actually not conflated.
--
XQuery Blueberry DOM John Cowan
Entity parser dot-com [EMAIL PROTECTED]
Abstract schemata http://www.ccil.org/~cowan
XPointer errata
Infoset Unicode BOM --Richard Tobin
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
