At 11:00 AM -0500 11/13/06, Mark J. Reed wrote:
On 11/13/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
- There are no Undef or NaN etc values or variables.
A RDBMS language with no "null" would seem to be problematic..
although i guess you could just use 1-tuples where the empty tuple is
treated as null.
In SQL, the "null" is used for multiple distinct meanings, including
'unknown' and 'not applicable', and having to deal with it makes an
RDBMS more complicated to implement and use by an order of magnitude.
In practice, there are multiple better ways that users can indicate
"unknown" or "not applicable" etc, and that can be done using the
other features.
At 5:35 PM +0000 11/13/06, [EMAIL PROTECTED] wrote:
And you may be forced to deal with NaN and Inf values if you are
storing raw binary float values as they are built into the bit
patterns.
All data types in my RDBMS are boxed types that hide their
implementation from the user, so details about bit patterns used by
numbers are abstracted away; as particular implementations define it,
numbers may not even be floats at all; they could be rationals or
strings or whatever the implementer wants to use, but the user
doesn't have to care.
The only place raw bit patterns appear is in the Blob type, but those
are undifferentiated so the bits don't mean anything but to the user.
If users have a NaN or Inf they want to store, they can't do it as a
database native finite integer or number; but like with nulls, there
are other ways to record what users want to know.
In any event, I'm interested in knowing what people think about
having named sub-expressions supported in Perl 6 and/or giving it
stronger pure functional syntax or paradigm support; pure functional
means there are no variables or assignment, as far as users are
concerned.
-- Darren Duncan
