Hi,
when there's a need to peek at DECLARE expressions, how does one
portably recognize shortcut type specifiers from other
implementation-specific declarations?
E.g.
(declare (fixnum my-var)) ; aka (declare (type fixnum var))
(declare (foo my-var)) ; is foo a type-specifier or something
; completely different?
I found no place in CLHS that e.g. would restrict short-cut notation
to the types defined in CLHS (see section 4.2.3) only, thus a priori, every
declaration is ambiguous: could it be a type or not?
The glossary says:
declaration identifier n.
one of the symbols declaration [...] or type;
or a symbol which is the name of a type;
or a symbol which has been declared to be a declaration identifier
by using a declaration declaration.
Simple tests using TYPEP or SUBTYPEP did not seem useable to portably
tell whether some arbitrary symbol is a type specifier.
(For those who wonder, J. Amsterdam's Iterate package likes to
recognize type declarations.)
Thanks for your help,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> writes:
> Simple tests using TYPEP or SUBTYPEP did not seem useable to portably
> tell whether some arbitrary symbol is a type specifier.
This looks portable to me:
[3]> (handler-case (prog1 t (subtypep 'something t)) (error () nil))
NIL
[4]> (handler-case (prog1 t (subtypep 'integer t)) (error () nil))
T
--
__Pascal Bourguignon__ http://www.informatimago.com/
Joerg Hoehle <······@users.sourceforge.net> writes:
> Simple tests using TYPEP or SUBTYPEP did not seem useable to portably
> tell whether some arbitrary symbol is a type specifier.
This looks portable and correct to me:
[8]> (handler-case (values (subtypep 'integer t)) (error () nil))
T
[9]> (handler-case (values (subtypep 'something t)) (error () nil))
NIL
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
Pascal Bourguignon wrote:
> This looks portable and correct to me:
>
> [8]> (handler-case (values (subtypep 'integer t)) (error () nil))
> T
> [9]> (handler-case (values (subtypep 'something t)) (error () nil))
> NIL
Alas, it's not behavior required by the standard (even in safe
code.)
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Pascal Bourguignon wrote:
>
>> This looks portable and correct to me:
>> [8]> (handler-case (values (subtypep 'integer t)) (error () nil))
>> T
>> [9]> (handler-case (values (subtypep 'something t)) (error () nil))
>> NIL
>
> Alas, it's not behavior required by the standard (even in safe
> code.)
Because SUBTYPEP is allowed to inflict nasal demons if the first
argument is not, in fact, a type specifier?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Paul F. Dietz wrote:
> Peter Seibel wrote:
>
>> Because SUBTYPEP is allowed to inflict nasal demons if the first
>> argument is not, in fact, a type specifier?
>
> Yes.
Where is that specified? I found no exceptional situations listed under
subtypep.
Hakon Alstadheim wrote:
> Where is that specified? I found no exceptional situations listed under
> subtypep.
That's what I meant -- yes, the behavior is undefined, since no
exceptional situations are listed (or, as far as I can tell,
implied elsewhere).
Paul
Paul F. Dietz wrote:
> Hakon Alstadheim wrote:
>
>> Where is that specified? I found no exceptional situations listed
>> under subtypep.
>
> That's what I meant -- yes, the behavior is undefined, since no
> exceptional situations are listed (or, as far as I can tell,
> implied elsewhere).
The standard would have to say if some input could lead to undefined
behavoiour, would it not? Cmucl seems to return (values t t ) for
anything that might conceivably be a typespec, throwing an error
otherwise. The only alternative to throwing an error would be to return
(values nil t) since an illegal typespec is definitely known not to be a
subtype of t. Are you really saying that the hyperspec page on subtypep
allows for totally undefined behaviour? It seems I need to work on my
hyperspec-reading-skills.
I can see where it lists the types of arguments, and I se that it does
not specify anywhere what happens if the actual arguments are something
else. Is that enough to allow for undefined behaviour?
Hakon Alstadheim wrote:
> The standard would have to say if some input could lead to undefined
> behavoiour, would it not?
See section 1.4.4.3:
"Except as explicitly specified otherwise, the consequences are
undefined if these type restrictions are violated."
Paul
Paul F. Dietz wrote:
> Pascal Bourguignon wrote:
>
>> This looks portable and correct to me:
>>
>> [8]> (handler-case (values (subtypep 'integer t)) (error () nil))
>> T
>> [9]> (handler-case (values (subtypep 'something t)) (error () nil))
>> NIL
>
>
> Alas, it's not behavior required by the standard (even in safe
> code.)
>
Well, it is true that the spec for SUBTYPEP is lacking any explicit
references to "Exceptional Situations", however, I think the following
is an exhaustive list of things that may happen if the first argument is
not a type specifier.
(1) SUBTYPEP returns NIL, T
(2) SUBTYPEP signals an error
(3) the CL implementation crashes
(4) a White Sperm Whale appears in Chapter 12 of War and Peace
...
(42) 42
...
I'd wager that the above code or the following can be accepted as
appropriate
(defun type-specifier-p (x)
(ignore-errors (subtypep x t))
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Paul F. Dietz wrote:
>> Pascal Bourguignon wrote:
>>
>>> This looks portable and correct to me:
>>>
>>> [8]> (handler-case (values (subtypep 'integer t)) (error () nil))
>>> T
>>> [9]> (handler-case (values (subtypep 'something t)) (error () nil))
>>> NIL
>> Alas, it's not behavior required by the standard (even in safe
>> code.)
>>
>
> Well, it is true that the spec for SUBTYPEP is lacking any explicit
> references to "Exceptional Situations", however, I think the following
> is an exhaustive list of things that may happen if the first argument
> is not a type specifier.
>
> (1) SUBTYPEP returns NIL, T
> (2) SUBTYPEP signals an error
> (3) the CL implementation crashes
> (4) a White Sperm Whale appears in Chapter 12 of War and Peace
> ...
> (42) 42
> ...
>
> I'd wager that the above code or the following can be accepted as
> appropriate
>
> (defun type-specifier-p (x)
> (ignore-errors (subtypep x t))
That could be agreagated to a clarifying CLRFI...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: Sam Steingold
Subject: CLRFI (was Re: recognizing a type specification)
Date:
Message-ID: <ull3jc8we.fsf_-_@gnu.org>
> * Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-08-03 17:44:39 +0200]:
>
> That could be agreagated to a clarifying CLRFI...
please do not waste your time asking for CLRFI and writing them until
<http://clrfi.alu.org/clrfi> lists more than 1 CLRFI.
don't cook for a patient that shows no heartbeat.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.camera.org>
<http://www.memri.org/> <http://pmw.org.il/> <http://ffii.org/>
Parachute for sale, used once, never opened, small stain.
Sam Steingold <···@gnu.org> writes:
>> That could be agreagated to a clarifying CLRFI...
>
> please do not waste your time asking for CLRFI and writing them until
> <http://clrfi.alu.org/clrfi> lists more than 1 CLRFI.
>
> don't cook for a patient that shows no heartbeat.
If the ALU volunteers and is active in organizing a CLRFI process, good.
But if not, this doesn't prevent us to do it anyway.
We could easily just post CLRFI proposals on cliki.net.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
> * Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-08-03 18:23:18 +0200]:
>
> Sam Steingold <···@gnu.org> writes:
>>> That could be agreagated to a clarifying CLRFI...
>>
>> please do not waste your time asking for CLRFI and writing them until
>> <http://clrfi.alu.org/clrfi> lists more than 1 CLRFI.
>>
>> don't cook for a patient that shows no heartbeat.
>
> If the ALU volunteers and is active in organizing a CLRFI process, good.
> But if not, this doesn't prevent us to do it anyway.
> We could easily just post CLRFI proposals on cliki.net.
then it's not CLRFI any longer.
when you say "CLRFI", you are talking about http://clrfi.alu.org.
if you want to say "CLIKI", just say so.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
<http://www.memri.org/> <http://ffii.org/> <http://pmw.org.il/>
MS Windows vs IBM OS/2: Why marketing matters more than technology...
Sam Steingold <···@gnu.org> writes:
>> * Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-08-03 18:23:18 +0200]:
>>
>> Sam Steingold <···@gnu.org> writes:
>>>> That could be agreagated to a clarifying CLRFI...
>>>
>>> please do not waste your time asking for CLRFI and writing them until
>>> <http://clrfi.alu.org/clrfi> lists more than 1 CLRFI.
>>>
>>> don't cook for a patient that shows no heartbeat.
>>
>> If the ALU volunteers and is active in organizing a CLRFI process, good.
>> But if not, this doesn't prevent us to do it anyway.
>> We could easily just post CLRFI proposals on cliki.net.
>
> then it's not CLRFI any longer.
>
> when you say "CLRFI", you are talking about http://clrfi.alu.org.
> if you want to say "CLIKI", just say so.
Perhaps I mean http://clrfi.cliki.net
--
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
> * Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-08-03 20:06:27 +0200]:
>
> clrfi.cliki.net
*** - POSIX:RESOLVE-HOST-IPADDR ("clrfi.cliki.net"): "host not found"
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.palestinefacts.org/> <http://www.honestreporting.com>
<http://www.mideasttruth.com/> <http://www.iris.org.il>
A PC without Windows is like ice cream without ketchup.
Pascal Bourguignon <····@mouse-potato.com> writes:
> If the ALU volunteers and is active in organizing a CLRFI process, good.
CLRFI != ALU
http://clrfi.alu.org/faq#question-2
Carl Shapiro <·············@panix.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> If the ALU volunteers and is active in organizing a CLRFI process, good.
>
> CLRFI != ALU
>
> http://clrfi.alu.org/faq#question-2
Indeed, that was my point.
--
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
Sam Steingold wrote:
> > * Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-08-03 17:44:39 +0200]:
> >
> > That could be agreagated to a clarifying CLRFI...
>
> please do not waste your time asking for CLRFI and writing them until
> <http://clrfi.alu.org/clrfi> lists more than 1 CLRFI.
>
> don't cook for a patient that shows no heartbeat.
I just heard about what went on at the recent CLRFI meeting during the
ILC. It appears that the ·············@... mailing list is now publicly
viewable.
http://clrfi.alu.org/pipermail/clrfi-editors/2004-December/000128.html
http://clrfi.alu.org/admin/lisp/submit/G2459542.clp
In addition, your old submission appears to be listed now:
http://clrfi.alu.org/clrfi
Well. There goes my joke about CLRFI being the Lisp counterpart of
/dev/null. ;( But seriously, I hope this is the last obstacle to
openness, and serious business can begin to commence...
MfG,
Tayssir
--
http://www.monzy.com/intro/drama_lyrics.html
Tayssir John Gabbour wrote:
> Sam Steingold wrote:
> > please do not waste your time asking for CLRFI and writing them until
> > <http://clrfi.alu.org/clrfi> lists more than 1 CLRFI.
> >
> > don't cook for a patient that shows no heartbeat.
>
> I just heard about what went on at the recent CLRFI meeting during the
> ILC. It appears that the ·············@... mailing list is now publicly
> viewable.
> http://clrfi.alu.org/pipermail/clrfi-editors/2004-December/000128.html
> http://clrfi.alu.org/admin/lisp/submit/G2459542.clp
>
> In addition, your old submission appears to be listed now:
> http://clrfi.alu.org/clrfi
>
> Well. There goes my joke about CLRFI being the Lisp counterpart of
> /dev/null. ;( But seriously, I hope this is the last obstacle to
> openness, and serious business can begin to commence...
For those interested in CLRFI trivia, there's a litigation fear people
raised at that ILC meeting, as a company named Goldhill (which appears
defunct, but lawyers rarely mind) might frivolously sue by interpreting
CLRFI's (semi-) official pronouncements as an attempt to get rid of
competitors by agreeing on incompatible standards.
Some at the meeting proposed that a more author-driven process might
help in this regard, sidestepping any (semi-) official entity. Leaving
it up to the various implementations to decide whether to adopt each
CLRFI, rather than actively binding or pressuring them to do so.
This could be temporary; there's also a two-step compromise where the
author-driven process is done now, and a more official-ish one is done
later.
There was also talk of turning CLRFI into an official nonprofit
standardization entity. And apparently the ANSI procedures have become
more lightweight than in the past, so there could be a renewed X3J13
committee.
Changing the subject, a lot of discussion apparently is spent on the
horrible and nightmarish CLRFIs people might submit, driving it to a
strict and formal process so only "good" proposals will ever get
through. Doesn't sound quite healthy, but I don't particularly care
about this issue and haven't researched it.
MfG,
Tayssir
http://www.monzy.com/intro/drama_lyrics.html
Tayssir John Gabbour wrote:
> For those interested in CLRFI trivia, there's a litigation fear people
> raised at that ILC meeting, as a company named Goldhill (which appears
> defunct, but lawyers rarely mind) might frivolously sue by interpreting
> CLRFI's (semi-) official pronouncements as an attempt to get rid of
> competitors by agreeing on incompatible standards.
Has anyone involved in CLRFI tried to contact Goldhill to invite them to
name a representative to the process? Based on previous traffic in this
newsgroup, I don't expect they'd respond. But if one sent the invite to
all four contacts listed on their site, and kept proof that it'd been
received by Goldhill's mail server, that proof, along with the various
"I sent them email and they didn't respond" messages in c.l.l over the
past few years would likely be enough to get any lawsuit summarily
dismissed on the grounds that Goldhill isn't trading, and good-faith
efforts were made to get them involved.
Does anyone have any reason to believe that Goldhill's principals are
likely to do such a thing? I suppose one could have the same fears about
Symbolics...
> There was also talk of turning CLRFI into an official nonprofit
> standardization entity. And apparently the ANSI procedures have become
> more lightweight than in the past, so there could be a renewed X3J13
> committee.
The last thing the CLRFI process needs is more red tape. I don't think
it currently has the inertia to overcome any sort of drag whatsoever on
its forward process.
> Changing the subject, a lot of discussion apparently is spent on the
> horrible and nightmarish CLRFIs people might submit, driving it to a
> strict and formal process so only "good" proposals will ever get
> through. Doesn't sound quite healthy, but I don't particularly care
> about this issue and haven't researched it.
I'm not too worried. My reasoning is that if CL 'vendors' don't pick up
on a CLRFI, it's just the sound of one hand clapping anyway. Maybe the
process should have two numbering schemes, one each for proposed and
accepted CLRFIs. That way the dumb ideas won't eat up numbers and cause
the list of approved or generally accepted CLRFIs to look like a list of
prime numbers.
Thanks a lot for updating c.l.l on progress. I'd been hoping for an
announcement after ILC05, here or on their opened mail-lists.
--
Cameron MacKinnon
Toronto, Canada
From: Roland Kaufmann
Subject: Re: CLRFI (was Re: recognizing a type specification)
Date:
Message-ID: <tl2fytpigad.fsf@space.at>
>>>>> "Tayssir" == Tayssir John Gabbour <···········@yahoo.com> writes:
Tayssir> Tayssir John Gabbour wrote:
[[good news about CLRFIs]]
Tayssir> Changing the subject, a lot of discussion apparently is
Tayssir> spent on the horrible and nightmarish CLRFIs people might
Tayssir> submit, driving it to a strict and formal process so only
Tayssir> "good" proposals will ever get through. Doesn't sound
Tayssir> quite healthy, but I don't particularly care about this
Tayssir> issue and haven't researched it.
There is a long discussion on comp.lang.scheme about a horrible SRFI
(indentation-based syntax) and discussion whether the SRFI process
makes it too easy for authors to submit "bad" SRFIs as long as the
follow the rules.
regards
Roland
> * Tayssir John Gabbour <···········@lnubb.pbz> [2005-08-04 12:25:55 -0700]:
>
> I just heard about what went on at the recent CLRFI meeting during the
> ILC. It appears that the ·············@... mailing list is now publicly
> viewable.
> http://clrfi.alu.org/pipermail/clrfi-editors/2004-December/000128.html
> http://clrfi.alu.org/admin/lisp/submit/G2459542.clp
>
> In addition, your old submission appears to be listed now:
> http://clrfi.alu.org/clrfi
thanks.
Now, what is the process of clrfi "approval"?
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.palestinefacts.org/> <http://www.mideasttruth.com/>
<http://www.jihadwatch.org/> <http://www.honestreporting.com>
Binaries die but source code lives forever.
Sam Steingold wrote:
> > * Tayssir John Gabbour <···········@lnubb.pbz> [2005-08-04 12:25:55 -0700]:
> >
> > I just heard about what went on at the recent CLRFI meeting during the
> > ILC. It appears that the ·············@... mailing list is now publicly
> > viewable.
> > http://clrfi.alu.org/pipermail/clrfi-editors/2004-December/000128.html
> > http://clrfi.alu.org/admin/lisp/submit/G2459542.clp
> >
> > In addition, your old submission appears to be listed now:
> > http://clrfi.alu.org/clrfi
>
> thanks.
>
> Now, what is the process of clrfi "approval"?
Based on my 2nd-hand info, people might wish to create their own
discussions and move forward without expecting someone to take care of
the details for them.
Tayssir
Sam Steingold wrote:
>>* Tayssir John Gabbour <···········@lnubb.pbz> [2005-08-04 12:25:55 -0700]:
>>
>>I just heard about what went on at the recent CLRFI meeting during the
>>ILC. It appears that the ·············@... mailing list is now publicly
>>viewable.
>>http://clrfi.alu.org/pipermail/clrfi-editors/2004-December/000128.html
>>http://clrfi.alu.org/admin/lisp/submit/G2459542.clp
>>
>>In addition, your old submission appears to be listed now:
>>http://clrfi.alu.org/clrfi
>
> thanks.
>
> Now, what is the process of clrfi "approval"?
I have been at the inofficial CLRFI meeting at ILC'05, and I think the
consensus is to turn the process into an author-driven thing, at least
as an intermediate solution. Any official or semi-official approval by
some self-elected official or semi-official group of people can lead to
all sorts of legal problems, including people wanting to sue us because
they could feel as if they were excluded from the whole thing. That's,
by the way, one of the reasons why the was a considerable time of
apparent inactivity because some people tried to figure out how to turn
CLRFI into an official standardization organization, or some such.
An author-driven process, at least as an intermediate solution, would
mean that noone but the authors of proposals themselves can decide
whether they would like to retract a proposal or turn it into some kind
of finalized state. This also means that the possible legal problems
would also remain with the authors (which is far less dangerous, as far
as I can see), because noone else has stamped things in any way.
Currently, there is work going on in the background to set up the
technical infrastructure to get things going. Essentially, there will be
a CLRFI Wiki, with access control features so that only authors can
access their own CLRFIs etc. This will probably still take some time.
Please note that this is just my interpretation of what's going on. The
fact that I was at the CLRFI meeting doesn't mean that this is some kind
of official statement of the group of people who were there.
Pascal
--
In computer science, we stand on each other's feet. - Brian K. Reid
Pascal Costanza wrote:
> I have been at the inofficial CLRFI meeting at ILC'05, and I think the
> consensus is to turn the process into an author-driven thing, at least
> as an intermediate solution. Any official or semi-official approval by
> some self-elected official or semi-official group of people can lead to
> all sorts of legal problems, including people wanting to sue us because
> they could feel as if they were excluded from the whole thing.
Can anyone point me to a case where this has happened before (i.e. a
disgruntled party suing a standards body for non-inclusiveness)?
Will there be a call for interested parties, and a membership policy?
I'm trying to get a sense of whether CRRFI is planning on being
exclusive or inclusive.
> Please note that this is just my interpretation of what's going on. The
> fact that I was at the CLRFI meeting doesn't mean that this is some kind
> of official statement of the group of people who were there.
I prefer unofficial statements over no statements at all. Thanks.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> I have been at the inofficial CLRFI meeting at ILC'05, and I think the
>> consensus is to turn the process into an author-driven thing, at least
>> as an intermediate solution. Any official or semi-official approval by
>> some self-elected official or semi-official group of people can lead
>> to all sorts of legal problems, including people wanting to sue us
>> because they could feel as if they were excluded from the whole thing.
>
> Can anyone point me to a case where this has happened before (i.e. a
> disgruntled party suing a standards body for non-inclusiveness)?
Here is a section from the "Evolution of Lisp" (uncut version) at
http://www.dreamsongs.com/Essays.html
"The route chosen was the X3 route, rather than IEEE. X3 is a set of
standards committees having to do with computers and information
processing, all within the organization called CBEMA. Committees under
X3 are authorized to submit proposed standards to ANSI, which then
executes the public review process and publishes the standard. This
arrangement is to prevent the technical experts from being sued by
companies, as happened when some companies that used COBOL sued the
individual technical experts for jeopardizing their companies by
creating a COBOL standard that would cost a lot of most to adapt to.
ANSI feared it would be hard to find technical experts to do the
standards work if they could be sued as individuals for their efforts."
> Will there be a call for interested parties, and a membership policy?
> I'm trying to get a sense of whether CRRFI is planning on being
> exclusive or inclusive.
There was a consensus that at least all vendors (commercial and open
source) should be contacted. If you're interested (and since you are a
vendor in that sense), it's probably best to contact the CLRFI editors
mailing list.
Pascal
--
In computer science, we stand on each other's feet. - Brian K. Reid
Pascal Costanza wrote:
> Cameron MacKinnon wrote:
>
>> Can anyone point me to a case where this has happened before (i.e. a
>> disgruntled party suing a standards body for non-inclusiveness)?
>
>
> Here is a section from the "Evolution of Lisp" (uncut version) at
> http://www.dreamsongs.com/Essays.html
>
> ...as happened when some companies that used COBOL sued the
> individual technical experts for jeopardizing their companies by
> creating a COBOL standard that would cost a lot of most to adapt to.
Thanks. That was enough to google up (cobol+standard+sued) a very nice
summary page:
http://www.venable.com/publications.cfm?action=view&publication_id=1211&publication_type_id=2
To summarize, one is far more likely to be sued if the standard requires
intellectual property (especially patents) which must be licensed. If
any of these CLRFIs contain code, I'd suggest that the author be
prevailed upon to grant license to everyone, or to declare the code
public domain.
Also: "The [US Federal Trade Commission] has provided some guidance in
evaluating the legality of standardization programs under the antitrust
laws � it suggests that standards should be voluntary; groups should not
exclude competition or control production. The process is very
important � it should be fully open to membership, everyone needs a
voice, procedures must be clear, technical justifications must be
articulated."
Addamax v. Open Software Foundation, 888 F. Supp. 274 (D. Mass. 1995),
aff�d, 152 F.3d 48 (1st Cir.1998) �� Standard-setting is not per se
illegal. Plaintiff sued on theory that standard-setting process itself
reduced market prospects and lost.
Anyone who is concerned should really read the above page. My reading of
it says that keeping the process open and staying away from patented
technology will keep one quite safe.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Anyone who is concerned should really read the above page. My reading
> of it says that keeping the process open and staying away from
> patented technology will keep one quite safe.
I suppose if you have better lawyers than ANSI,
and all the vendors who were X3J13, then you might
come to a different conclusion than they did.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Cameron MacKinnon <··········@clearspot.net> writes:
> > Anyone who is concerned should really read the above page. My reading
> > of it says that keeping the process open and staying away from
> > patented technology will keep one quite safe.
>
> I suppose if you have better lawyers than ANSI,
> and all the vendors who were X3J13, then you might
> come to a different conclusion than they did.
Actually, Chris, this is Cameron's conclusion you're rebutting, not
the conclusion of the page at Venable.com he cites. The page he cites
does not reach the boiled down conclusion that he cites. It makes a
long list of issues that one should not overlook, and while the list
looks relatively comprehensive, I don't think it even goes quite so
far as to insist it is complete. But I certainly think that
shortening it does not make it more complete.
I am not a lawyer, so I won't opine further here one way or another on
what the weaknesses of Cameron's summary seems to me to be. I actually
think that no one is served by getting any less detailed than the
original URL he points to. I'll just say instead that if wanted to
instruct a lawyer to sue someone for violation of one of the issues
that Venable.com has recommended you consider, and the person I was
suing was concerned only with "process openness" and "IP
entanglement", I know what issues I personally would go after since we
were periodically menaced with some of these during the ANSI CL process.
I'm not going to single out my choices mostly to again not give undue
emphasis on one rather than another of Venable's list.
I'd instead just recommend that people dealing seriously with this area
not get any less detailed or attentive than this list, and at least
consider the fact that they could still have overlooked something,
consider hiring a lawyer to represent them, etc.
Free legal advice is sometimes said to be worth about what you pay for
it. I bet if you employed even those lawyers themselves, they would
not just read you what they'd published for free, but would immediately
set about questioning whether their own list was appropriately complete.
Kent M Pitman wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>>I suppose if you have better lawyers than ANSI,
>>and all the vendors who were X3J13, then you might
>>come to a different conclusion than they did.
>
>
> Actually, Chris, this is Cameron's conclusion you're rebutting, not
> the conclusion of the page at Venable.com he cites. The page he cites
> does not reach the boiled down conclusion that he cites. It makes a
> long list of issues that one should not overlook, and while the list
> looks relatively comprehensive, I don't think it even goes quite so
> far as to insist it is complete. But I certainly think that
> shortening it does not make it more complete.
Good grief, that's what passes for a rebuttal?? I suppose if this area
of IP law had evolved at all since ANSI consulted its lawyers, or if the
cumulative scope of the standards that ANSI administers were much
broader than what we've been discussing here, or if larger
organizations' deeper pockets meant that they had to be more careful to
ward off lawsuits, conclusions might be different.
> ...I know what issues I personally would go after since we
> were periodically menaced with some of these during the ANSI CL process.
If you have the time, I'm sure I'm not the only one here interested in
what you can remember about the menaces. Who made threats, and about
what issues? I found a curious message at
http://listserv.acm.org/scripts/wa.exe?A2=ind0206c&L=oscas&F=&S=&P=2455
which may or may not be related, but it contained nothing I could use to
discover the message to which it replied.
> Free legal advice is sometimes said to be worth about what you pay for
> it. I bet if you employed even those lawyers themselves, they would
> not just read you what they'd published for free, but would immediately
> set about questioning whether their own list was appropriately complete.
If their list was intended as a public service, I'd agree with you. As
the purpose of that page is to scare up business, I suspect its creation
involved a small group of people brainstorming about every possible
threat. Which isn't necessarily to say that, were one to employ them,
they wouldn't spend their time and their client's money trying to think
of something else. :-)
Because I think a new standardization (or 'blessing') process is
important to reverse Lisp's long, slow slide into irrelevancy, I've
tried to advocate for such, and to rebut the doomsayers. It's good that
I haven't had to argue THIS issue in person, because I doubt I could
keep a straight face while doing it. When Lisp and AI were big, the
Europeans were funding research and drafting ISO, DoD was pushing ANSI
and Japan had its Fifth Generation Project, there were stakes worth
fighting for and pockets deep enough to attract (and fund) lawsuits.
Unless I'm vastly misreading the current state of the Lisp market, Homer
Simpson could count potential deep-pocketed defendants on one hand with
fingers left over, and the number of potential plaintiffs who could fund
a lawsuit is likely zero. It strikes me as hubristic and dreaming of
faded glory for the current community to think that there's anything
worth suing over.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Good grief, that's what passes for a rebuttal??
I wasn't trying to rebutt. I wasn't trying to take a position at all.
I was trying to say there is some legal danger in someone who is in a
hurry taking your shortened summary as anything to rely upon.
> If their list was intended as a public service, I'd agree with you. As
> the purpose of that page is to scare up business, I suspect its
> creation involved a small group of people brainstorming about every
> possible threat. Which isn't necessarily to say that, were one to
> employ them, they wouldn't spend their time and their client's money
> trying to think of something else. :-)
The fact that lawyers do this does not mean you are free of the
possibility of lawsuit.
Let's ignore ethics for a moment. My personal view is that the way
you tell you're probably ethical is that you haven't stopped
questioning yourself. I am leary of anyone's claim that it's possible
to just ignore certain broad classes of ethical questions. It's one
thing to say you've examined them and you have an answer on file.
It's another to say that you reject the questions because of who's
asking. And, IMO, the list of questions they ask are ones that call
for more answers than you provided even at an ethical, if not legal,
level.
Fairness requires more than oppenness. Dictators [I won't mention
them by name to avoid Godwin's Law being invoked] have used unfairness
in the open. I mention this not to compare your action to such
people, but to say that trivially it must be the case that a
transparent process is not ipso facto a fair process.
> Because I think a new standardization (or 'blessing') process is
> important to reverse Lisp's long, slow slide into irrelevancy, I've
> tried to advocate for such, and to rebut the doomsayers.
I'm not a doomsayer in this regard. I'm just saying that a particular piece
of text you wrote sounded oversimplified.
I didn't even accuse what you were advocating (and I didn't read far
enough to even know what that might be) of being a bad thing. I just said
that your apparent desire to boil down the decision procedure about its
goodness or badness to two simple one-word bullet-points seemed unreasonable
as a justification. I didn't say that whatever the original subject was
unreasonable. Nor reasonable. I took no position at all.
Kent M Pitman wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>
>>Good grief, that's what passes for a rebuttal??
>
>
> I wasn't trying to rebutt.
I didn't say you were.
> Let's ignore ethics for a moment. My personal view is that the way
- ^^^^^^ <- perhaps you meant legalities here?
> you tell you're probably ethical is that you haven't stopped
> questioning yourself. I am leary of anyone's claim that it's possible
> to just ignore certain broad classes of ethical questions. It's one
> thing to say you've examined them and you have an answer on file.
> It's another to say that you reject the questions because of who's
> asking. And, IMO, the list of questions they ask are ones that call
> for more answers than you provided even at an ethical, if not legal,
> level.
The only ethical issue I can see here is "Are we using standard-setting
to harm Lisp vendors?" There aren't broader questions because the act
being contemplated doesn't compel or coerce anyone to do anything, nor
does it have any impact on the physical environment.
> Fairness requires more than oppenness. Dictators [I won't mention
> them by name to avoid Godwin's Law being invoked] have used unfairness
> in the open. I mention this not to compare your action to such
> people, but to say that trivially it must be the case that a
> transparent process is not ipso facto a fair process.
I haven't been discussing the fairness of the CLRFI process, except as
it relates to the possibility of getting sued. Outside of that
possibility, I'm confident that the CLRFI editors will come up with a
process that is, and is perceived to be fair.
> I didn't even accuse what you were advocating (and I didn't read far
> enough to even know what that might be) of being a bad thing. I just said
> that your apparent desire to boil down the decision procedure about its
> goodness or badness to two simple one-word bullet-points seemed unreasonable
> as a justification. I didn't say that whatever the original subject was
> unreasonable. Nor reasonable. I took no position at all.
I wasn't discussing goodness and badness, I was discussing lawsuit
avoidance. It is perhaps true that my summary was overly brief, but I'd
submit that anyone who was genuinely worried about legal action, yet too
lazy to click through to the link that I helpfully provided is beyond
help anyway.
I think that you're engaging in scare tactics with your advice to
consult a lawyer. Most [good] lawyers, if consulted on this issue, would
say "Whoa, not my field. You need a specialist." and then go on to
recommend a $500/hour IP lawyer at a white shoe law firm. That lawyer,
in turn, would not want to advise without an understanding of the
BUSINESS situation, and would happily listen to his client telling him
that a) there's no money to sue over and b) there's nobody left to sue.
That's a bit of a simplification, because people sue for two reasons:
They feel they've been wronged and want recompense or a court ordered
change in behaviour, or they want money (a "shakedown", if you will).
I've been implicitly and then explicitly discounting the latter, because
I can see no money here. So I'm arguing that CLRFI only has to worry
about people (vendors) who actually feel wronged. Since there's so few
vendors left, it would be quicker and cheaper to get them on board, than
to worry about some nuisance suit filed by a zombie from the grave.
This, as I understand it, is what CLRFI plans upon doing. Or, as Lyndon
Johnson so memorably put it, "Better to have him inside the tent pissing
out, than outside pissing in."
Are you planning on getting legal advice regarding Substandards(tm)?
Surely this issue of legalities applies equally there. How do you plan
on handling it?
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> That's a bit of a simplification, because people sue for two reasons:
> They feel they've been wronged and want recompense or a court ordered
> change in behaviour, or they want money (a "shakedown", if you will).
> I've been implicitly and then explicitly discounting the latter, because
> I can see no money here. So I'm arguing that CLRFI only has to worry
> about people (vendors) who actually feel wronged. Since there's so few
> vendors left, it would be quicker and cheaper to get them on board, than
> to worry about some nuisance suit filed by a zombie from the grave.
> This, as I understand it, is what CLRFI plans upon doing. Or, as Lyndon
> Johnson so memorably put it, "Better to have him inside the tent pissing
> out, than outside pissing in."
The CLRFI people's conservative legal stance appears reasonable to me.
Even after reading your link; it mentions ways that the "standards
process could result in the exclusion of innovative products from
market entry."
I did think an earlier response to you sounded gratuitously dismissive.
I dislike the idea that "lawyers know more than you, so your opinion is
worthless"... (But you know, any profession worth its salt acts as a
gatekeeper to some body of knowledge; it's not something that a couple
Lisp users invented one day. ;)
Perhaps you know something about these standardization processes you
haven't mentioned yet?
Tayssir
Tayssir John Gabbour wrote:
> The CLRFI people's conservative legal stance appears reasonable to me.
> Even after reading your link; it mentions ways that the "standards
> process could result in the exclusion of innovative products from
> market entry."
IFF customers get together and demand CLRFI conformance, AND CLRFI
creates standards that preclude innovations that the market would want.
Exclusion requires a cartel, a monopoly, or government regulation. These
are all possible, but much more difficult, in software markets. The
quote above is from a discussion of toilet valves, one of the few cases
to have gone to court. I haven't read it, but I assume that building
codes mandate ANSI standard plumbing, so exclusion from the standard
meant exclusion from the market.
As I've said, the field we're discussing is so small that we shouldn't
have to fear a suit from a random plaintiff, maybe some company with a
secret Lisp implementation that gets $1MM in sales to customers who will
henceforth demand CLRFI compliance. All the potential plaintiffs are
known to us.
> Perhaps you know something about these standardization processes you
> haven't mentioned yet?
I've never been involved in one. All my knowledge comes from that
paragon of reliable hearsay, the 'net.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> As I've said, the field we're discussing is so small that we shouldn't
> have to fear a suit from a random plaintiff, maybe some company with a
> secret Lisp implementation that gets $1MM in sales to customers who
> will henceforth demand CLRFI compliance. All the potential plaintiffs
> are known to us.
By the way, given that there are both free and commercial Scheme
implementations, how, if at all, did the SRFI editors deal with the
suit issue?
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On Mon, 08 Aug 2005 19:36:03 +0200, Paolo Amoroso <·······@mclink.it> wrote:
> By the way, given that there are both free and commercial Scheme
> implementations, how, if at all, did the SRFI editors deal with the
> suit issue?
The commercial guys wear suits and the other ones wear t-shirts.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Paolo Amoroso wrote:
> By the way, given that there are both free and commercial Scheme
> implementations, how, if at all, did the SRFI editors deal with the
> suit issue?
SRFI's are not standards; they are not binding on any implementation,
and implementations do not gain any "blessed" status by implementing
them, other than the ability to list them as implemented.
Indeed, there are several final SRFI's which are actively BAD ideas,
finalized by their authors despite near-universal negative feedback
in the discussion phase, and the response from implementors has
been to universally ignore them.
The effect is that these are _suggestions_ for or _requests_ to
implementors. If you were going to implement some extension, you
can check first to see if there's a SRFI for it to give yourself
a "standard" syntax, and you can read through the discussion
archive to see if you want to adjust the semantics, or even drop
the extension, to avoid hair you hadn't necessarily thought of
or be compatible with other schemes that implement a given SRFI.
Conversely, if you get a lot of call from your users for a particular
feature, SRFI's give them a vocabulary to make specific, useful,
technical suggestions that will increase code portability, rather
than being vague and leaving almost every detail open to question.
"We really need SRFI-9 records" is way more detailed and useful
than "We need some kind of user-defined aggregate data type."
Bear
Cameron MacKinnon wrote:
> As I've said, the field we're discussing is so small that we shouldn't
> have to fear a suit from a random plaintiff, maybe some company with a
> secret Lisp implementation that gets $1MM in sales to customers who will
> henceforth demand CLRFI compliance. All the potential plaintiffs are
> known to us.
There are indeed more or less dead companies out there that did sell
commercial Common Lisp implementations. The fear that was expressed at
the CLRFI meeting was that current owners of the intellectual property
rights of those implementations could see a semi-official
standardization effort as an opportunity to at least make some money by
suing parties involved in such an effort.
Goldhill was mentioned as a company that apparently does not respond to
inquiries about their product anymore. (Just to make sure, Goldhill was
not mentioned as a likely case to take such action, and I don't know
whether anyone actually acknowledged that they are indeed "dead". It's
just that their website doesn't look too promising.)
It seems to me that the SRFI approach avoids such problems by not
suggesting any binding character whatsoever, and especially not stamping
specific SRFIs as approved by some kind of self-elected committee who
could be interpreted as being exclusionary.
What standard organizations like ANSI provide are clearly defined
processes that make sure that anyone can influence and have a say in
specific standardization efforts. Since their processes are accredited,
they are on pretty safe grounds. (At least that's how I understood it.)
The possibilities that were discussed at the CLRFI meeting were:
- Becoming part of ANSI (or some other standardization org) again.
- Becoming an standardization organization.
- Turning the process into an author-driven process (similar to SRFI).
- Doing the latter, at least for the time being, and taking some next
steps to do one of the first two options later.
Again, this is not an official statement for the people who were at the
meeting, but just my understanding of what was discussed.
Pascal
--
In computer science, we stand on each other's feet. - Brian K. Reid
Pascal Costanza wrote:
> Cameron MacKinnon wrote:
>
>> As I've said, the field we're discussing is so small that we shouldn't
>> have to fear a suit from a random plaintiff, maybe some company with a
>> secret Lisp implementation that gets $1MM in sales to customers who
>> will henceforth demand CLRFI compliance. All the potential plaintiffs
>> are known to us.
>
>
> There are indeed more or less dead companies out there that did sell
> commercial Common Lisp implementations. The fear that was expressed at
> the CLRFI meeting was that current owners of the intellectual property
> rights of those implementations could see a semi-official
> standardization effort as an opportunity to at least make some money by
> suing parties involved in such an effort.
Yes, I understand the fear. My thoughts are as follows. Their strategy
couldn't be to actually go to court, because if they did, you'd just
question them on their sales in the last few years. If they're
essentially zero, these companies can't possibly argue that their
business is being harmed by anything you do, because they don't have any
business anyway. Which leaves their strategy as hoping for a settlement.
But you wouldn't settle, because you don't have the money to settle with
anyway. So they'd have to file a suit, rather than just sending a
threatening letter. Since they've got a weak case and are suing someone
with few assets, they aren't likely to find a lawyer who will work on
contingency (~30% of damages if they win, nothing if they lose). Their
lawyer is going to want to see about $10,000 in cash to start the suit.
Do you think any of these companies are likely to risk $10,000 or more
on the preposterous claim that you're reducing their nonexistent sales?
If you can show that you're running a fairly open process and that they
were invited to participate and didn't respond, so much the better.
> It seems to me that the SRFI approach avoids such problems by not
> suggesting any binding character whatsoever, and especially not stamping
> specific SRFIs as approved by some kind of self-elected committee who
> could be interpreted as being exclusionary.
I don't have a problem with the SRFI approach at all. I just think that
the fears of an alternative approach attracting a lawsuit are overblown.
I could be wrong. But if it was me looking to file a nuisance lawsuit,
I'd pick a juicier target, and I hope I'd be able to show some actual
damages, or at least plausible ones.
> What standard organizations like ANSI provide are clearly defined
> processes that make sure that anyone can influence and have a say in
> specific standardization efforts. Since their processes are accredited,
> they are on pretty safe grounds. (At least that's how I understood it.)
>
> The possibilities that were discussed at the CLRFI meeting were:
>
> - Becoming part of ANSI (or some other standardization org) again.
Kent has made the case in the past that getting sucked into the ANSI
morass costs more time and money than people would want to spend.
> - Becoming an standardization organization.
Likely you'd want to incorporate as a nonprofit. Whenter that's
possible, and what the prerequisites are, would vary from jurisdiction
to jurisdiction. Shop around.
> - Turning the process into an author-driven process (similar to SRFI).
> - Doing the latter, at least for the time being, and taking some next
> steps to do one of the first two options later.
Sounds good to me.
--
Cameron MacKinnon
Toronto, Canada
Pascal Costanza <··@p-cos.net> writes:
> Goldhill was mentioned as a company that apparently does not respond
> to inquiries about their product anymore. (Just to make sure, Goldhill
When I created at alu.cliki.net the page:
http://alu.cliki.net/implementation
that later became:
http://lisp.tech.coop/implementation
I sent email to Gold Hill asking whether they were still in business
and sold Common Lisp implementations, which they confirmed. I can't
remember exactly when I did that, but it was probably less than 3-4
years ago.
Unfortunately, I no longer have the original message. And I can't
remember who answered my query.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Cameron MacKinnon <··········@clearspot.net> writes:
> The only ethical issue I can see here is "Are we using standard-setting
> to harm Lisp vendors?"
Even this has two branches:
"Are we using standard-setting with the intent of harming Lisp vendors?"
(this seems to be the one you think you can solve in advance)
"Are we having the unintentional effect of harming any or all Lisp vendors?"
(this can only be answered by continual monitoring and hence cannot be
solved by merely in advance assuring opeenness and lack of IP entanglement)
"If we are harming any Lisp vendors, is the nature and extent of the harm
acceptable?"
(this can also only be answered on a case-by-case basis)
The same question can be asked of users. You might assume that
standard-setting benefits users, but that is not necessarily so.
It can stifle competition, and that in turn can keep important things
from happening.
I observe that the primary reason I've heard cited for wanting to make
this push into a process like this is to replace the ANSI process, which
is no longer operational. And yet, at the same time, there are discussions
going on that observe that the presence of the ANSI standardization process
had an apparent effect of stopping a lot of branching among the community.
I'm not saying the process you propose will necessarily do the same, but it
seems indisputable that it might since all you're talking about is
"standards setting" and we've already observed empirically that it happens.
Moreover, I'm not saying this discussion needs to be had publicly. It
doesn't need to be answered to the community's satisfaction. I'm
responding because of the fact that you did raise it publicly; I did
not raise the matter, and likely would not have had you not raised it in
a way that seemed to call for comment.
> > Fairness requires more than oppenness. Dictators [I won't mention
> > them by name to avoid Godwin's Law being invoked] have used unfairness
> > in the open. I mention this not to compare your action to such
> > people, but to say that trivially it must be the case that a
> > transparent process is not ipso facto a fair process.
>
> I haven't been discussing the fairness of the CLRFI process, except as
> it relates to the possibility of getting sued.
You've discussed what is necessary in your opinion to avoid being sued, and
yet others (not just the site you mentioned, but ANSI itself) have indicated
that lack of fairness is the primary thing that can get you sued. So of
course you've discussed it.
> Outside of that possibility, I'm confident that the CLRFI editors will
> come up with a process that is, and is perceived to be fair.
That's an amazing statement.
First, there's nothing wrong with you being confident about whatever you
like. If you tell me that you're confident that the doors of heaven will
open tomorrow and only the Lisp faithful will be allowed in, I'm obliged
to accept that as true. (Yet I can still classify it as amazing.)
But these people were not elected by the Lisp community. The Lisp
community is not the ALU. The ALU is not the set of people present at
an ALU meeting. One of the key reasons we went for ANSI is that it had
a process that assured that it was not a clique. Anyone can join.
This is not so for the CLRFI group. This may well be a feature, I can't
say. But it surely does not guarantee acceptance from my point of view,
so you may be confident but I am personally withholding judgment for now.
One test I often use when analyzing systems is to change some element
of the system to be a more recognizable system. So the question would
be: If someone created a system like this for managing an organization
in which I held a minority viewpoint, would I feel confident that my
minority views would be respected. (Implicit in this is that I do not
believe minorities are necessarily wrong and majorities are
necessarily right, nor even that ignoring minorities is "fair" and
letting majorities get their way is "fair".)
I certainly would NOT feel that this kind of process would achieve
fair or forward-thinking effects in another language community in
which I held a minority point of view. Why? Because I believe all
new ideas begin as minority effects, and because organizations that
control themselves from within are able to resist outside effects and
therefore stave off trends toward change that ought be their lifeblood.
Further, the need to convince a controlling body is not equivalent to
the need to convince a body of users. The controllers (witness the US
Congress) eventually spend full time just making rules, and often have
no time for living life. They therefore lack appreciation of the
issues that confront real users. There may be many that are
experiencing an effect, but they may articulate an effect differently
such that a majority view is not visible.
I therefore also would not accept this kind of process as fair in any
political process.
It might work (for some suitably chosen definition of "work") for some
set of people in spite of my remarks here. I do not claim to be
omniscient. Then again, I'm not sure there's even the possibility of
sharing a notion of working.
But I believe I have reasonable reasons for believing that the
structure of this is not set up to defaultly ensure success. And
hence I am not, as you say, "confident" in either fairness nor a
perception of fairness.
I'm trying my best not to assert that it cannot work, that it shouldn't
be tried, etc. What I want to be asserting here is not "it's wrong" but
rather "it's not OBVIOUSLY right". If it is right, it will be right
because of effects that are much less simplistic than you are asserting.
> > I didn't even accuse what you were advocating (and I didn't read far
> > enough to even know what that might be) of being a bad thing. I just said
> > that your apparent desire to boil down the decision procedure about
> > its goodness or badness to two simple one-word bullet-points seemed
> > unreasonable
> > as a justification. I didn't say that whatever the original subject was
> > unreasonable. Nor reasonable. I took no position at all.
>
> I wasn't discussing goodness and badness, I was discussing lawsuit
> avoidance.
Here I'll just say that the attempt to merely avoid lawsuits while ignoring
the issue of goodness/badness seems misguided.
Lawsuits exist, in part, to make you think about goodness/badness. This is
like trying to avoid police speedtraps on the highway but not worrying about
whether you should be speeding. There are some speedtraps that are just
ridiculous, but others that are not. If you get so caught up in the science
of avoiding them that you stop asking yourself whether you should be driving
so fast, you're on the wrong side of the ethical line, IMO.
> It is perhaps true that my summary was overly brief, but
> I'd submit that anyone who was genuinely worried about legal action,
> yet too lazy to click through to the link that I helpfully provided is
> beyond help anyway.
That's a lame excuse.
The world is full of complex information that needs summary. I'd
accept a short summary that they provide. But if you elect to summarize,
you enter the world of discussion and should expect response.
> I think that you're engaging in scare tactics with your advice to
> consult a lawyer.
You can think what you like. What I'm doing is assuring that no one thinks
that my advice substitutes for lawyerly advice.
> Most [good] lawyers, if consulted on this issue, would say "Whoa,
> not my field. You need a specialist." and then go on to recommend a
> $500/hour IP lawyer at a white shoe law firm.
In part because this is indeed specialty stuff that the average lawyer seems
as incompetent to deal with as any Visual Basic programmer would be to deal
with Lisp code. The mere being of a programmer is not competence in all
areas of programming, and the mere being of a lawyer is not competence in all
areas of law.
> That lawyer, in turn, would not want to advise without an understanding of
> the BUSINESS situation, and would happily listen to his client telling
> him that a) there's no money to sue over and b) there's nobody left to
> sue.
I agree these issues come into play.
We programmers also find ourselves not optimizing programs based on
algorithmic complexity when the program will not be run on large data,
will not ever be run, will be run seldom on a fast machine, etc. That
doesn't imply that we don't understand the issues, it just means we know
when to apply them and when not to bother.
> That's a bit of a simplification, because people sue for two reasons [...]
> So I'm arguing that CLRFI only has to worry about [...]
It's funny how you both seem to eschew the way lawyers reason in one
breath and then appear to emulate them in another. I'm not saying this
is a wrong way of reasoning in practice. I'm saying that anyone reading
along who thinks this is all legality boils down to should be careful.
We had a similar non-meta discussion about Lisp the other day where we
were talking about the issue of certain kinds of optimization, and I
was saying that often there are solutions that are quite appropriate
to an actual end-programmer but where language designers, vendors,
teachers, book writers, etc. should not be advocating those ways.
That is, the job of the latter group is to explain how to make
decisions, not to prematurely make those decisions. (It's the "teach
a person to fish" vs "feed him a fish" issue in another set of scales.)
I have found over the years as people read my writings a lot that it's
useful to qualify things that are provisional/conditional thoughts
with the provisions/conditions that underly them where I can think of
them exactly to lead them away from the trap of thinking I'm speaking
in absolutes. I don't always do it, but when I don't, I often find I
confuse people. And I generally don't resent people adding
qualifications to clarify that there are other ways to think about
things.
I don't disagree with your having another position, I just worry when
you present your position in terms of absolutist terms (that you are
confident this is fair and will be recognized as fair) that you will
confuse some people into thinking there is no known opposing view.
I've tried hard not to publicly oppose this process because I don't
want to be seen as defeatist. I'm content to sit back and see what it
does as long as it pushes itself as "just one option among possibly
many" However, if this process (or some overzealous advocate for it)
tries to assert that it is uniquely fair, or even just unambiguously fair,
then I have a problem with it and have less wiggle room to remain silent.
> people (vendors) who actually feel
> wronged. Since there's so few vendors left, it would be quicker and
> cheaper to get them on board, than to worry about some nuisance suit
> filed by a zombie from the grave.
As long as you're raising the issue, I think users should have
standing to sue, not just vendors. (I don't know if they do. But I
find it odd to hear you speak as if you can somehow be sure none
could, and that only vendors are worth discussing. Note that ANSI
treats users and vendors as peers--it does not make a user/vendor
distinction. I suspect this is not accidental.)
Moreover, exactly the thing you want to do "get all the vendors on board"
is what's potentially anticompetitive. It might work against new entrants
to the market with new ideas. It seems deliberately structured to do so,
in fact.
> Are you planning on getting legal advice regarding Substandards(tm)?
> Surely this issue of legalities applies equally there. How do you plan
> on handling it?
I generally don't publicly document the processes I go through in
order to attain a legal posture. If I publish a legal notice, it will
in a static place where you can read it--and, I suppose, raise it for
discussion.
In case I missed saying it anywhere above--all of the above is just my
personal opinion. I am not alleging a credential in this area that
makes my opinion better than anyone else's.
Kent M Pitman wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>I haven't been discussing the fairness of the CLRFI process, except as
>>it relates to the possibility of getting sued.
...
>>Outside of that possibility, I'm confident that the CLRFI editors will
>>come up with a process that is, and is perceived to be fair.
>
>
> That's an amazing statement.
Well, let me follow up by saying that if they don't, they are not likely
to gain the widespread support of vendors and customers, and the process
will wither and die. This acts as an incentive for them. The scenario
that you seem to be worrying about, that CLRFI will become a tyranny
upon users and vendors alike, can't really happen without community
support. There's no DoD here holding huge purse strings and demanding
conformance.
> I've tried hard not to publicly oppose this process because I don't
> want to be seen as defeatist. I'm content to sit back and see what it
> does as long as it pushes itself as "just one option among possibly
> many" However, if this process (or some overzealous advocate for it)
> tries to assert that it is uniquely fair, or even just unambiguously fair,
> then I have a problem with it and have less wiggle room to remain silent.
I think it's currently the fairest option we've got, I doubt that in two
years' time we'll have more options to choose from, and I think Lisp's
position is deteriorating without modernization.
>>Since there's so few vendors left, it would be quicker and
>>cheaper to get them on board...
>
>
> As long as you're raising the issue, I think users should have
> standing to sue, not just vendors. (I don't know if they do. But I
> find it odd to hear you speak as if you can somehow be sure none
> could, and that only vendors are worth discussing. Note that ANSI
> treats users and vendors as peers--it does not make a user/vendor
> distinction. I suspect this is not accidental.)
For a user to sue, he'd have to make the case that he was somehow
prevented from buying or building nonstandard product. I assume your
argument is along the lines of: "But for the standard, someone would
have provided a product more to my liking." I think this would be tough
to prove, even to the low standard (balance of probabilities) that a
civil action requires.
ANSI's treatment of vendors and customers as equals makes sense when one
considers markets that are regulated (e.g. a building code mandating
ANSI standard materials) or that can come under the control of cartels.
While we've seen some of this in software, I'm personally cheering for
the day when the Lisp market is big enough to potentially have such
problems.
> Moreover, exactly the thing you want to do "get all the vendors on board"
> is what's potentially anticompetitive. It might work against new entrants
> to the market with new ideas. It seems deliberately structured to do so,
> in fact.
The areas that I've been hoping for standardization in have been ones
where, frankly, we need new ideas like we need a hole in the head --
TCP/IP APIs, etcetera. I've been hoping for a process to unify existing
practice (much like XJ313's mandate). Further, the vast majority of the
opposition I've seen to a new process has been, essentially, that people
like Lisp just the way it is. People with new ideas (or old ideas which
have been rejected by CL) have typically been told that they're welcome
to implement them, but that the CL community has no real interest. So I
find this sudden argument -- that a standardization process would stifle
all that wonderful innovation that we've been fostering -- a bit rich.
In order for new standards to work against new entrants, we'd have to
get to the point where a significant fraction of the market for Lisp was
saying "we won't buy unless you support CLRFI." I feel that the current
worry should be whether CLRFI survives infancy, not whether it may grow
up to be an innovation stifling monster.
> In case I missed saying it anywhere above--all of the above is just my
> personal opinion. I am not alleging a credential in this area that
> makes my opinion better than anyone else's.
Well, you have been involved in standards-making before, and you even
say that XJ313 was subjected to threats of lawsuits. I've found your
reminicences of the process helpful and informative, and I'm sure others
who weren't there have as well. Reading history beats repeating it, we
just have to be mindful of how our current situation (Lisp's
marginalization and smaller market) affects the calculus.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Kent M Pitman wrote:
> > ······@news.dtpq.com (Christopher C. Stacy) writes:
> >
> >> I suppose if you have better lawyers than ANSI, and all the vendors
> >> who were X3J13, then you might come to a different conclusion than
> >> they did.
> > Actually, Chris, this is Cameron's conclusion you're rebutting, not
> > the conclusion of the page at Venable.com he cites. The page he cites
> > does not reach the boiled down conclusion that he cites. It makes a
> > long list of issues that one should not overlook, and while the list
> > looks relatively comprehensive, I don't think it even goes quite so
> > far as to insist it is complete. But I certainly think that
> > shortening it does not make it more complete.
>
> Good grief, that's what passes for a rebuttal??
My only point was: If I were considering the actions you advocate,
I would consult a lawyer, rather than kidding around.
Pascal Costanza wrote:
> Sam Steingold wrote:
> > Now, what is the process of clrfi "approval"?
>
> I have been at the inofficial CLRFI meeting at ILC'05, and I think the
> consensus is to turn the process into an author-driven thing, at least
> as an intermediate solution. Any official or semi-official approval by
> some self-elected official or semi-official group of people can lead to
> all sorts of legal problems, including people wanting to sue us because
> they could feel as if they were excluded from the whole thing. That's,
> by the way, one of the reasons why the was a considerable time of
> apparent inactivity because some people tried to figure out how to turn
> CLRFI into an official standardization organization, or some such.
Thanks Pascal, for the firsthand update. I think if people know the
problems, they're far more forgiving.
Halting CLRFI because of legal worries sounds perfectly sensible. The
only problem was not responsibly informing people, forcing them to fall
back on the most cynical models of how CLRFI acts. And I'm glad that
Nick Levine, you, and no doubt others raised the openness issue at the
meeting, because that lays a decent foundation of trust.
Tayssir
Pascal Bourguignon wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Paul F. Dietz wrote:
>>
>>>Pascal Bourguignon wrote:
>>>
>>>
>>>>This looks portable and correct to me:
>>>>
>>>>[8]> (handler-case (values (subtypep 'integer t)) (error () nil))
>>>>T
>>>>[9]> (handler-case (values (subtypep 'something t)) (error () nil))
>>>>NIL
>>>
>>>Alas, it's not behavior required by the standard (even in safe
>>>code.)
>>>
>>
>>Well, it is true that the spec for SUBTYPEP is lacking any explicit
>>references to "Exceptional Situations", however, I think the following
>>is an exhaustive list of things that may happen if the first argument
>>is not a type specifier.
>>
>>(1) SUBTYPEP returns NIL, T
>>(2) SUBTYPEP signals an error
>>(3) the CL implementation crashes
>>(4) a White Sperm Whale appears in Chapter 12 of War and Peace
>> ...
>>(42) 42
>> ...
>>
>>I'd wager that the above code or the following can be accepted as
>>appropriate
>>
>>(defun type-specifier-p (x)
>> (ignore-errors (subtypep x t))
>
>
> That could be agreagated to a clarifying CLRFI...
>
Yep. I would definitively like it.
Moreover, ANSI is also lacking portable ways to access the "types"
namespace. I.e.
(deftype foo (x y z) ...)
creates a type named FOO somewhere, but we cannot portably know where.
Also, we cannot portably know what the typespec (FOO 'q 'w 'e) expands into.
Cheers
--
Marco