On 29. Februar 2008 21:40:40 -0500 John Cowan [EMAIL PROTECTED] wrote:
Thomas Chust scripsit:
[...]
Of course I don't want to have the same typing mess as in Java in
CHICKEN and I do think the whole practice of having nullable reference
types (by default) is questionable. I just don't think
On Fri, Feb 29, 2008 at 4:02 PM, Ozzi Lee [EMAIL PROTECTED] wrote:
I don't see that anyone's mentioned the existing sql-null egg yet. Is
there anything wrong with it?
http://chicken.wiki.br/sql-null
I didn't know that existed. Thanks Ozzi. There are just too many damn
eggs these days...
On Fri, Feb 29, 2008 at 1:31 AM, Tobia Conforto [EMAIL PROTECTED] wrote:
Graham Fawcett wrote:
There does seem to be a good case for an immediate value that *can*
be tested this way, though. John et. al. wouldn't have used (void)
in eggs if there weren't.
What about providing a
On 29 Feb 2008, at 12:31 am, Tobia Conforto wrote:
What about providing a utility to create new immediate values,
disjoint from anything else?
It's called gensym :-)
ABS
--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog:
On Fri, Feb 29, 2008 at 1:41 PM, Tobia Conforto [EMAIL PROTECTED] wrote:
felix winkelmann wrote:
(define sql-null (new-immediate-value))
(define (sql-null? x) (eq? x sql-null))
With the certainty that sql-null won't be eq? to anything else at
all, won't be a list, a record, nothing
On 29 Feb 2008, at 1:14 pm, John Cowan wrote:
Alaric Snell-Pym scripsit:
What about providing a utility to create new immediate values,
disjoint from anything else?
It's called gensym :-)
Gensym values aren't disjoint *in type* from anything else.
Ah, but disjointness in value is all
Alaric Snell-Pym scripsit:
Gensym values aren't disjoint *in type* from anything else.
Ah, but disjointness in value is all that's required...
Technically yes, but most of us find predicates like number?, string?,
and symbol? rather handy all the same, and don't want NULL mixed up
with them.
On Fri, Feb 29, 2008 at 3:59 PM, John Cowan [EMAIL PROTECTED] wrote:
Alaric Snell-Pym scripsit:
So do we make the bold move of not defining (token? x)?
No, we realize that just as we need only one empty list (unlike Java, where
any list can have zero elements without losing its
On 29. Februar 2008 09:24:07 -0500 John Cowan [EMAIL PROTECTED] wrote:
Alaric Snell-Pym scripsit:
Gensym values aren't disjoint *in type* from anything else.
Ah, but disjointness in value is all that's required...
Technically yes, but most of us find predicates like number?, string?,
and
Alaric Snell-Pym scripsit:
So do we make the bold move of not defining (token? x)?
No, we realize that just as we need only one empty list (unlike Java, where
any list can have zero elements without losing its identity), we need only
one object that has:
a unique identity, disjoint
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
So, to recap:
'(), 0, , #f, 'null, (gensym)
Very bad for representing SQL NULL, because some DBs or DB operations
could theoretically support lists, numbers (doh), strings (doh),
booleans, and symbols, and in those cases we wouldn't want the null
value to clash with valid values.
On Fri, Feb 29, 2008 at 2:57 PM, Tobia Conforto [EMAIL PROTECTED] wrote:
So, to recap:
Perfect recap! :-)
(define-record-type sql-null (sql-null) sql-null?)
Not too bad. Any piece of code could create null values with (sql-
null), even in different compilation units. People
felix winkelmann scripsit:
No, we realize that just as we need only one empty list (unlike Java, where
any list can have zero elements without losing its identity), we need only
one object that has:
a unique identity, disjoint from all other objects
a unique type,
Graham Fawcett scripsit:
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
Thomas Chust scripsit:
this is really a question of taste, isn't it? You could just as well argue
that a NULL value should be of a type that is a subtype of every other
existing type but contains no other concrete instances, which would imply
that all the type predicates should return #t
Thomas Chust scripsit:
for example in Java there are some places where the dynamic type of null is
effectively a subtype of another class:
// this returns (String)null and doesn't throw a ClassCastException
foo.getClass().cast(null)
c
Yes, well, that is where static typing is done at
On Fri, Feb 29, 2008 at 9:56 PM, John Cowan [EMAIL PROTECTED] wrote:
Why do we need this? I can't remember right now...
To represent the null object of foreign environments that do not conflate
null with the empty sequence -- not only SQL but also Lua, Java (and
other JVM languages),
felix winkelmann scripsit:
When you look for a generic null or void object, that is used for a
particular library, then any unique value is sufficient, whether immediate
or not.
I agree; however, this is not a matter of a particular library, but
of a large number of libraries, not all of
On Thu, Feb 28, 2008 at 7:31 PM, Tobia Conforto [EMAIL PROTECTED] wrote:
Graham Fawcett wrote:
There does seem to be a good case for an immediate value that *can*
be tested this way, though. John et. al. wouldn't have used (void)
in eggs if there weren't.
What about providing a
20 matches
Mail list logo
