Fernando D. Mato Mira <········@iname.com> wrote in message
······················@iname.com...
> (deftype NAME-THIS (typ) `(or null ,typ))
>
> Winner arbitrarily chosen by secret jury. Only prize is celebrity ;)
>
How about MAYBE-TYPE
From: ·······@my-deja.com
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <87n8b2$363$1@nnrp1.deja.com>
In article <··················@dfw-read.news.verio.net>,
"Joe Marshall" <·········@alum.mit.edu> wrote:
>
> Fernando D. Mato Mira <········@iname.com> wrote in message
> ······················@iname.com...
> > (deftype NAME-THIS (typ) `(or null ,typ))
> >
> > Winner arbitrarily chosen by secret jury. Only prize is celebrity ;)
> >
>
> How about MAYBE-TYPE
I've used MAYBE for something like this in several systems:
(DEFTYPE MAYBE (&REST TYPES) `(OR NULL ,@TYPES))
The difference between this type and the one above is that I can
write things like
(MAYBE INTEGER SIMPLE-VECTOR)
when INTEGER and SIMPLE-VECTOR are both valid in this context.
Probably 80+% of the time that I use the MAYBE macro, though,
it has just a single element in the TYPES list.
When I chose the name, I wasn't familiar with CLIM and the other
systems mentioned in other messages in this thread, or I probably
would've done what they do. (And for that matter, now that I'm more
familiar with the Common Lisp type system, I no longer feel
much need to abbreviate this idiom, since I can now read
(OR NULL INTEGER SIMPLE-VECTOR)
easily enough, and it's just as concise. So if I were starting
over again, I probably wouldn't define the macro at all.
Bill Newman
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Tim Bradshaw
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <ey3emasvmgw.fsf@cley.com>
* Fernando D Mato Mira wrote:
> (deftype NAME-THIS (typ) `(or null ,typ))
> Winner arbitrarily chosen by secret jury. Only prize is celebrity ;)
The CLIM & Symbolics presentation system would call this NULL-OR-TYPE
-- (accept '(null-or-type number)) for instance -- so I think that
would be a good choice.
--tim
From: Fernando D. Mato Mira
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <389B4E27.7613107A@iname.com>
Tim Bradshaw wrote:
> * Fernando D Mato Mira wrote:
> > (deftype NAME-THIS (typ) `(or null ,typ))
> > Winner arbitrarily chosen by secret jury. Only prize is celebrity ;)
>
> The CLIM & Symbolics presentation system would call this NULL-OR-TYPE
> -- (accept '(null-or-type number)) for instance -- so I think that
> would be a good choice.
>
> --tim
Looks familiar..
;; Make a type specifier of the form: (or FOO NULL)
(cl:defun type-or-null (typ)
`(or ,typ null))
Actually, I'm looking for a single word, as if one were to do:
(deftype optional (typ) `(or nil ,typ))
Except that in Lisp all types are optional (i.e., nil is a subtype of all
types, so the above is redundant).
[ObNewbie: this has nothing to do with declarations being optional]
[Tangential issue: What does ILU pass as empty value for OPTIONAL types?
That's missing from the manual..]
From a homogeneization point of view, it's a good suggestion. If all the
smart people that came up with CLIM could not think of anything better,
this looks pretty hopeless..
Thanks,
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Fernando D. Mato Mira
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <389B526B.CC095B83@iname.com>
Thesaurus: discretionary, elective, facultative, nonobligatory, voluntary
Hm.. What about RELAXED or LAIDBACK?
Tst, tst. one month of .au and see what happens! ;-)
[I don't like the optimization associations of RELAXED though]
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" <········@iname.com> writes:
> Tim Bradshaw wrote:
>
> > * Fernando D Mato Mira wrote:
> > > (deftype NAME-THIS (typ) `(or null ,typ))
> > > Winner arbitrarily chosen by secret jury. Only prize is celebrity ;)
> >
> > The CLIM & Symbolics presentation system would call this NULL-OR-TYPE
> > -- (accept '(null-or-type number)) for instance -- so I think that
> > would be a good choice.
> >
> > --tim
>
> Looks familiar..
>
> ;; Make a type specifier of the form: (or FOO NULL)
> (cl:defun type-or-null (typ)
> `(or ,typ null))
Tim's right. Use NULL-OR-TYPE, like the LispM did.
There's no need to diverge from established practice.
It's a good name.
From: Fernando D. Mato Mira
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <389C514C.2E9E5111@iname.com>
Kent M Pitman wrote:
> "Fernando D. Mato Mira" <········@iname.com> writes:
>
> > Tim Bradshaw wrote:
> >
> > > * Fernando D Mato Mira wrote:
> > > > (deftype NAME-THIS (typ) `(or null ,typ))
> > > > Winner arbitrarily chosen by secret jury. Only prize is celebrity ;)
> > >
> > > The CLIM & Symbolics presentation system would call this NULL-OR-TYPE
> > > -- (accept '(null-or-type number)) for instance -- so I think that
> > > would be a good choice.
> > >
> > > --tim
> >
> > Looks familiar..
> >
> > ;; Make a type specifier of the form: (or FOO NULL)
> > (cl:defun type-or-null (typ)
> > `(or ,typ null))
>
> Tim's right. Use NULL-OR-TYPE, like the LispM did.
> There's no need to diverge from established practice.
> It's a good name.
Is it as good as to make it in a future version of the standard?
Seems too long to be the canonical name for it..
After digressing a bit along the laidback line (COOL, DUDE, KOOK..) I think
that for the pleasure of "you know who(s)" and the `pleasure' of the
"others",
ihe name should be:
BOOL
(collect-append 'string (scan-fn 'string (lambda () ";-") (lambda (x)
(declare (ignore x)) ">")))
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <ey3wvoit5rs.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Is it as good as to make it in a future version of the standard?
> Seems too long to be the canonical name for it..
Why would you want it in the standard? The whole point of DEFTYPE is
so you can define these things yourself. It also has the great
advantage that you know immediately what it means.
--tim
From: Fernando D. Mato Mira
Subject: re: [CONTEST] Name this type specifier
Date:
Message-ID: <389EAAB6.86E36AA2@iname.com>
Tim Bradshaw wrote:
> * Fernando D Mato Mira wrote:
>
> > Is it as good as to make it in a future version of the standard?
> > Seems too long to be the canonical name for it..
>
> Why would you want it in the standard? The whole point of DEFTYPE is
> so you can define these things yourself. It also has the great
> advantage that you know immediately what it means.
That's like asking "Why are there abbreviations at all in the
standard?". Obviously
some type expressions (like this one) are so common that they deserve to
be there,
if only to encourage the use of a common vocabulary.
Some might be pretty obvious (like this one seems to be in the end), but
it took it 3 days
to settle in my head (including going through goofs like calling it
OPTIONAL).
I don't care if Symbolics and CLIM settled for such a crappy name (as
you pointed out, that;s what DEFTYPE is for).
It's not practical to type, it has a ugly `infix' flavor, plus the TYPE
in the name is awful [specially if you write
(declare (type (null-or-type foo)). Why not NULL-OR, like 1+? (not that
I really like these kind either)].
The implementation of SERIES is complicated enough to make it more
difficult to read by using that name.
If find it nice mainly because:
T = (BOOL T) [that's Lisp!]
BOOLEAN = (BOOL (MEMBER T))
Also, NULL-OR-TYPE is a concrete type: it IS (or NULL <type>). Period.
On the other hand, BOOL is an abstract type. It denotes the intention of
result values a la GETHASH.
In a Scheme-like dialect, you'd define BOOL as (OR (MEMBER #f) <type>)
[Actually, in a `Common Scheme', eg, when faking
CL on top of Scheme, I'd personally define it as (OR (MEMBER #f) NULL
<type>).
Sorry if I didn't start by this last point before. I was looking for a
name for the expansion, not the concept (although some conceptual idea
shows in the `thesaurus' post (ie, "optional", but with NULL), it's not
precisely the same one, and the one just mentioned is precisely the case
I'm dealing with).
[I see now Gareth and Jason make other proposals. Great!]
Regards and thanks,
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
On Fri, 4 Feb 2000 23:20:30 GMT, Kent M Pitman <······@world.std.com> wrote:
> Tim's right. Use NULL-OR-TYPE, like the LispM did.
> There's no need to diverge from established practice.
> It's a good name.
FTR, and not because I disagree with the name NULL-OR-TYPE/TYPE-OR-NULL for
CL's function/type, Dylan calls the equivalent function "false-or", e.g.
false-or(<number>)
The different name is because Dylan distiguishes the empty list #() and false
#f. A Common Lisp version of Dylan's name might be OR-NULL.
However, if there is existing practice within CL then we should stick to it.
Also, while I remember, Harlequin's Dylan team had just started to experiment
with a naming convention for such types by combining the predicate and type
naming conventions:
define constant <number>? = false-or(<number>);
In Common Lisp the direct equivalent would be awkward because there is no
special convention for type names that would distinguish a 'possible type' name
from an ordinary predicate function.
__Jason
From: Tim Bradshaw
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <ey3aelgv9l5.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Except that in Lisp all types are optional (i.e., nil is a subtype of all
> types, so the above is redundant).
I can't see a sense in which this is true: the object NIL is not a
member of every type, and the type NULL is not the bottom element of
the type graph as it has one member, NIL. The type T *is* the top of
the graph however.
But I may be misunderstanding you (and even if I'm not some type
theorist will now take me to pieces for using incorrect terminology
and being otherwise confused.).
--tim
> From a homogeneization point of view, it's a good suggestion. If all the
> smart people that came up with CLIM could not think of anything better,
> this looks pretty hopeless..
I think it's also a good name because there are already 2
not-insignificant systems (clim and genera) which use this naming.
--tim
From: Robert Monfera
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <389B645E.6276F220@fisec.com>
Tim Bradshaw wrote:
>
> * Fernando D Mato Mira wrote:
>
> > Except that in Lisp all types are optional (i.e., nil is a subtype of all
> > types, so the above is redundant).
>
> I can't see a sense in which this is true: the object NIL is not a
> member of every type, and the type NULL is not the bottom element of
> the type graph as it has one member, NIL. The type T *is* the top of
> the graph however.
>
> But I may be misunderstanding you (and even if I'm not some type
> theorist will now take me to pieces for using incorrect terminology
> and being otherwise confused.).
I had the same thoughts, but probably Fernando refers to
(subtypep nil 'number)
T
T
I'm unsure about the concept of nil being the subtype of every other
type, and its significance though.
Robert
From: Tim Bradshaw
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <ey366w4uxw3.fsf@cley.com>
* Robert Monfera wrote:
> I had the same thoughts, but probably Fernando refers to
> (subtypep nil 'number)
> T
> T
I'm an idiot. The type NIL (not NULL) *is* the bottom of the type
graph. Dang!
--tim
From: Gareth Rees
Subject: Re: [CONTEST] Name this type specifier
Date:
Message-ID: <un1pdl1o3.fsf@pobox.com>
Fernando D. Mato Mira <········@iname.com> wrote:
> (deftype NAME-THIS (typ) `(or null ,typ))
LIFT (by analogy with that concept in denotational semantics).
--
Gareth Rees