We are pleased to announce the availability of Qi 6.1
from www.lambdassociates.org. Qi 6.1 runs under CLisp
and is available as open source under the GNU licence.
Qi is an award-winning Lisp-based functional
programming language that offers the best of
Common Lisp with the advantages of pattern matching,
lambda calculus consistency, and optional static
type checking. It uses sequent calculus notation
to define types, and has the most powerful type
system of any existing functional language, including
ML and Haskell.
The web page www.lambdassociates.org/qilisp.htm
which gives a 15 minute tutorial for Lisp programmers.
A complete documentation is available online and
in the download.
Mark Tarver
Lambda Associates
Mark Tarver wrote:
> We are pleased to announce the availability of Qi 6.1
> from www.lambdassociates.org. Qi 6.1 runs under CLisp
> and is available as open source under the GNU licence.
"Functional Programming in Qi appears in September 2005."
http://www.lambdassociates.org/members.htm
I hope you will announce its availability, to remind us...
Will do.
Mark
Tayssir John Gabbour wrote:
> Mark Tarver wrote:
> > We are pleased to announce the availability of Qi 6.1
> > from www.lambdassociates.org. Qi 6.1 runs under CLisp
> > and is available as open source under the GNU licence.
>
> "Functional Programming in Qi appears in September 2005."
> http://www.lambdassociates.org/members.htm
>
> I hope you will announce its availability, to remind us...
Your tutorial page needs indentation in the code, and I noticed some
places where your CL code didn't feel right. For example:
(DEFUN f (X)
(COND ((ZEROP X) 1)
((= X 1) 0)
(T (ERROR "Input to f is not 0 or 1.~%"))))
This would be better written like this (forgive my lack of indentation,
blame Google Groups):
(defun f (x)
(ecase x
(0 1)
(1 0)))
This isn't too far from your Qi example. The main difference is
something that doesn't show up in this simple example: pattern
matching.
Pattern matching is very useful, but it can be done in CL with the
addition of some macros. I think that a neat thing to make would be a
version of CL which uses pattern matching everywhere. It would be
interesting to see how that turned out.
The type system is really neat. It looks like the most noteworthy part
of Qi. I'd like to point out that CL *does* have optional static type
checking, but it doesn't look nearly as powerful (or dangerous) as
yours.
Good luck on your future work!
-Peter
Peter Scott schrieb:
> The type system is really neat. It looks like the most noteworthy part
> of Qi. I'd like to point out that CL *does* have optional static type
> checking, but it doesn't look nearly as powerful (or dangerous) as
> yours.
You mean by adding manually some macros to statically typecheck?
Andr�
--
André Thieme wrote:
> Peter Scott schrieb:
> > The type system is really neat. It looks like the most noteworthy
part
> > of Qi. I'd like to point out that CL *does* have optional static
type
> > checking, but it doesn't look nearly as powerful (or dangerous) as
> > yours.
>
> You mean by adding manually some macros to statically typecheck?
Maybe I got my terminology mixed up, but when you declare types,
doesn't that make it possible for a good Lisp implementation to
propagate that information to other parts of the program and perform
some amount of type checking? In SBCL 0.8.16, for example:
* (defun add-foo (x)
(+ x "foo"))
; [...]
; caught WARNING:
; Asserted type NUMBER conflicts with derived type
; (VALUES (SIMPLE-BASE-STRING 3) &OPTIONAL).
; See also:
; The SBCL Manual, Node "Handling of Types"
; compilation unit finished
; caught 1 WARNING condition
-Peter
Thankyou, Frontpage Express does handle indentation
somewhere but I need to look for it.
Mark
Peter Scott wrote:
> Your tutorial page needs indentation in the code, and I noticed some
> places where your CL code didn't feel right. For example:
> Good luck on your future work!
>
> -Peter
Peter Scott wrote:
> Your tutorial page needs indentation in the code, and I noticed some
> places where your CL code didn't feel right. For example:
>
> (DEFUN f (X)
> (COND ((ZEROP X) 1)
> ((= X 1) 0)
> (T (ERROR "Input to f is not 0 or 1.~%"))))
>
> This would be better written like this (forgive my lack of indentation,
> blame Google Groups):
>
> (defun f (x)
> (ecase x
> (0 1)
> (1 0)))
>
> This isn't too far from your Qi example. The main difference is
> something that doesn't show up in this simple example: pattern
> matching.
>
> Pattern matching is very useful, but it can be done in CL with the
> addition of some macros. I think that a neat thing to make would be a
> version of CL which uses pattern matching everywhere. It would be
> interesting to see how that turned out.
>
Shameless plug :) CL-UNIFICATION on common-lisp.net
http://common-lisp.net/project/cl-unification/
Cheers
--
marco
On Wed, 20 Apr 2005 03:27:10 -0700, Mark Tarver wrote:
> We are pleased to announce the availability of Qi 6.1 from
> www.lambdassociates.org. Qi 6.1 runs under CLisp and is available as
> open source under the GNU licence.
Mark, there is no such "GNU licence". You make the same mistake on your
wonderfully presented front page <http://www.lambdassociates.org/> and the
FAQ <http://www.lambdassociates.org/aboutqi.htm>.
I've downloaded Qi 6.1 and confirmed the licence is the GNU General
Public License (GPL). Though the file GPL.txt will give Richard Stallman
a heart attack as it concludes with "Copyright 2005 by the Open Source
Initiative ..." I'd suggest cleaning up the copy and paste from
<http://opensource.org/licenses/gpl-license.php> or downloading the GPL as
text from <http://www.gnu.org/licenses/gpl.txt>.
You may want to reconsider the implications of your choice of licence,
especially if you're trying to promote widespread adoption of your
language implementation. CLISP may be the only Common Lisp implementation
it can be integrated with (i.e. without forcing a licensing change to the
GPL).
By the way, nice idea for a language. I can see from the tutorial how
pattern matching could be a useful addition to Lisp. I especially
appreciate how it integrates with standard Common Lisp. I'm also building
a superset of Common Lisp (for my own use) and I believe it's a sound
approach to ensure that one ends up with a language demonstrably (or
at least arguably) better than Common Lisp.
Regards,
Adam
Thanks for for pointing that out. I've corrected it to
'GNU GPL licence'.
We do intend that the user be allowed to run Qi on any Lisp
platform, and not just CLisp. Carl Shapiro is looking at a port
to Allegro. Sam's post suggests that the GPL licence is not
a problem. If it is, we'll find another licence which will
allow people this freedom.
The licence itself was copied from opensource.org/licences - a
repository of software licences. I must have accidently copied
the Open Source tag at the bottom of the page. I'll remove it.
Mark
Adam Warner wrote:
> On Wed, 20 Apr 2005 03:27:10 -0700, Mark Tarver wrote:
>
> > We are pleased to announce the availability of Qi 6.1 from
> > www.lambdassociates.org. Qi 6.1 runs under CLisp and is available
as
> > open source under the GNU licence.
>
> Mark, there is no such "GNU licence". You make the same mistake on
your
> wonderfully presented front page <http://www.lambdassociates.org/>
and the
> FAQ <http://www.lambdassociates.org/aboutqi.htm>.
>
> I've downloaded Qi 6.1 and confirmed the licence is the GNU General
> Public License (GPL). Though the file GPL.txt will give Richard
Stallman
> a heart attack as it concludes with "Copyright 2005 by the Open
Source
> Initiative ..." I'd suggest cleaning up the copy and paste from
> <http://opensource.org/licenses/gpl-license.php> or downloading the
GPL as
> text from <http://www.gnu.org/licenses/gpl.txt>.
>
> You may want to reconsider the implications of your choice of
licence,
> especially if you're trying to promote widespread adoption of your
> language implementation. CLISP may be the only Common Lisp
implementation
> it can be integrated with (i.e. without forcing a licensing change to
the
> GPL).
>
> By the way, nice idea for a language. I can see from the tutorial how
> pattern matching could be a useful addition to Lisp. I especially
> appreciate how it integrates with standard Common Lisp. I'm also
building
> a superset of Common Lisp (for my own use) and I believe it's a sound
> approach to ensure that one ends up with a language demonstrably (or
> at least arguably) better than Common Lisp.
>
> Regards,
> Adam
On Wed, 20 Apr 2005 07:36:26 -0700, Mark Tarver wrote:
>
> Thanks for for pointing that out. I've corrected it to 'GNU GPL
> licence'.
Suggested ways to reference the GPL are "GNU General Public License", "GNU
GPL" or just "GPL". If you expand the above out it becomes becomes
"General Public License licence". This is sometimes intentional when an
abbreviation loses its original meaning. We used to have an Auckland
Savings Bank in Auckland which was abbreviated as ASB. When it became a
company it was renamed as ASB Bank Limited. It is no longer a community
Savings Bank (nor even Auckland specific) so there is in fact no
duplication of Bank. One can't expand out the ASB in ASB Bank Ltd even
though its reputation is derived from its community roots. GPL is not in
this category of abbreviation. It is still sensible to be able to
expand and sound out "GPL" as "General Public License".
> We do intend that the user be allowed to run Qi on any Lisp platform,
> and not just CLisp. Carl Shapiro is looking at a port to Allegro.
> Sam's post suggests that the GPL licence is not a problem. If it is,
> we'll find another licence which will allow people this freedom.
You are currently distributing Qi bundled together with a memory image of
CLISP. Part of the build process of Qi involves dumping a new memory
image using EXT:SAVEINITMEM. If you want the memory images of other Lisp
implementations to be distributable under each project's original terms
then the GPL is an unsuitable choice.
I have not run lispinit.mem nor Qi but I have run a strings on
lispinit.mem. It contains this text:
~%Qi is distributed without warranty under the terms of the GPL
licence.~% You may not change or remove any copyright notices attached
to this software.~%~%
1. I agree to the terms of the GPL licence.~%
2. I do not agree to the terms of the GPL licence.~%0
3. I want to read the GPL licence and come back to this.~%~%t
Choose:
Answer
agree
disagree
lookat-GPL
~%~%This is not a valid answer.~%~%
~%Thankyou. Qi will be initialised to accept your agreement.~%
You will not be queried again.~%
You may be intending to make the distribution of Qi unfriendly to non-GPL
and proprietary software development in order to sell a differently
licensed/proprietary implementation of Qi at a later date. Who knows. I'm
just pointing out that GPL licensing of Qi may be counterproductive to
widespread adoption of your language implementation, if that is a primary
motivation.
Would Python be a popular language today if its reference implementation
was GPL'd? Would CLISP still no have no thread support if its licensing
was more permissive?
These are questions without definite answers. But they're questions that
could help you think through the issues and your primary motivation for
building Qi. CLISP used to have a small bounty on adding threads. A
company wants to wants to hire an SBCL developer to make SBCL's native
pthreads support more robust:
<http://article.gmane.org/gmane.lisp.steel-bank.general/643>
Whatever the dynamics I just got an impression from the language you used
that you may not be aware of some of the issues with GPL licensing and
Lisp implementations.
Regards,
Adam
> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-21 12:28:55 +1200]:
>
> You are currently distributing Qi bundled together with a memory image
> of CLISP. Part of the build process of Qi involves dumping a new
> memory image using EXT:SAVEINITMEM. If you want the memory images of
> other Lisp implementations to be distributable under each project's
> original terms then the GPL is an unsuitable choice.
Please stop the FUD.
he _CAN_ distribute his GNU GPL application as a CMUCL/SBCL core file.
> Would Python be a popular language today if its reference
> implementation was GPL'd? Would CLISP still no have no thread support
> if its licensing was more permissive?
I see no reason to agree with you here.
I have never heard of anyone not using CLISP because of licensing
issues (since there are none, see file COPYRIGHT in a CLISP distribution).
I have never heard of anyone wishing to work on CLISP but not doing so
because of licensing issues (again, since there are none).
_Please_ stop the FUD.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/> <http://www.palestinefacts.org/>
<http://www.jihadwatch.org/> <http://pmw.org.il/>
Your mouse has moved - WinNT has to be restarted for this to take effect.
On Thu, 21 Apr 2005 09:44:25 -0400, Sam Steingold wrote:
>> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-21 12:28:55 +1200]:
>>
>> You are currently distributing Qi bundled together with a memory image
>> of CLISP. Part of the build process of Qi involves dumping a new
>> memory image using EXT:SAVEINITMEM. If you want the memory images of
>> other Lisp implementations to be distributable under each project's
>> original terms then the GPL is an unsuitable choice.
>
> Please stop the FUD.
> he _CAN_ distribute his GNU GPL application as a CMUCL/SBCL core file.
I am sincere and I do not intentionally FUD. I believe you have
substantially misinterpreted my reply and I have provided a fuller
explanation for your benefit.
I made it abundantly clear in what you snipped that the distributed memory
image included a dump of Qi itself. If the same build procedure was
applied to other non-GPL Lisp implementations then the new memory images
would not be distributable under each project's original terms. Thus the
GPL would be an unsuitable choice if one wanted new dumped memory images
to be distributable under each project's original terms.
Please underscore this whole phrase: "the memory images of other Lisp
implementations to be distributable under each project's original terms".
Yes he can distribute his GNU GPL application as a CMUCL/SBCL core file
but the core file will not be distributable under CMUCL/SBCL's original
terms. Moreover Mark mentioned porting to Allegro. I'm pretty sure Franz
would not appreciate an Allegro memory image including Qi being
distributed under the terms of the GNU GPL (in fact it would simply be
non-distributable).
Regards,
Adam
Probably what Carl Shapiro will do with Qi 6.1 sources is
configure them to be loaded into Allegro and create a little
installation program. No Allegro image will be distributed
and people will have to run the installation themselves to
install it.
There might be a conflict about Franz themselves trying to
configure it as part of their own system because of the
the GPL licence.
CLisp seems to be a good platform. My timings suggest that
the speed difference between Allegro and CLisp is only 25%
under Qi Prolog. But we'll see better when the port takes
place. The new multi-thread version of CLisp will be very
useful for Qi/Tk.
Mark
Mark
Adam Warner wrote:
> On Thu, 21 Apr 2005 09:44:25 -0400, Sam Steingold wrote:
> >> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-21 12:28:55
+1200]:
> >>
> >> You are currently distributing Qi bundled together with a memory
image
> >> of CLISP. Part of the build process of Qi involves dumping a new
> >> memory image using EXT:SAVEINITMEM. If you want the memory images
of
> >> other Lisp implementations to be distributable under each
project's
> >> original terms then the GPL is an unsuitable choice.
> >
> > Please stop the FUD.
> > he _CAN_ distribute his GNU GPL application as a CMUCL/SBCL core
file.
>
> I am sincere and I do not intentionally FUD. I believe you have
> substantially misinterpreted my reply and I have provided a fuller
> explanation for your benefit.
>
> I made it abundantly clear in what you snipped that the distributed
memory
> image included a dump of Qi itself. If the same build procedure was
> applied to other non-GPL Lisp implementations then the new memory
images
> would not be distributable under each project's original terms. Thus
the
> GPL would be an unsuitable choice if one wanted new dumped memory
images
> to be distributable under each project's original terms.
>
> Please underscore this whole phrase: "the memory images of other Lisp
> implementations to be distributable under each project's original
terms".
> Yes he can distribute his GNU GPL application as a CMUCL/SBCL core
file
> but the core file will not be distributable under CMUCL/SBCL's
original
> terms. Moreover Mark mentioned porting to Allegro. I'm pretty sure
Franz
> would not appreciate an Allegro memory image including Qi being
> distributed under the terms of the GNU GPL (in fact it would simply
be
> non-distributable).
>
> Regards,
> Adam
Mark Tarver wrote:
>
> There might be a conflict about Franz themselves trying to
> configure it as part of their own system because of the
> the GPL licence.
To use internally? I don't think GPL restricts it in any way.
Nevertheless, have you thought about using a less threatening license?
BSD-style perhaps?
I think trying to restrict what people do internally with
a piece of software is a waste of time - who can check anyway,
right?
What I don't think is right is that people can copy a piece
of open source, add 4 lines and then sell it as binary and
pocket the cash and give nothing back even if they say
'and I got this from ...'.
The BSD licence does allow you to do just that and so I don't
feel its a suitable choice. GPL stops that.
My position is "What is given for free should be freely available."
Thats a bit more tolerant than Stallman's view which regards
closed source as an evil blight. If someone wants to write code,
compile it and sell it, I see nothing wrong in it. As long as its
their work.
What is legally interesting about Qi is that it generates type
secure Lisp code which you can run outside Qi. If you look at
appendix B in FPQi its very simple to generate Lisp from Qi. The
Lisp is 98% non-Qi-packaged portable Lisp. So how does the GPL
apply to this?
The licence says
"The source code for a work means the **preferred form of the work for
making modifications to it**. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to control
compilation and installation of the executable."
>From this definition, it is clear that under GPL, the programmer
has to distribute Qi source if he uses Qi. The Lisp that Qi generates
is fast but not designed to be read (you can read it, tho', its just
missing nice parameter names and its very CARrey-CDRrey).
What about the documentation? You can copy it and print it off as
long as you don't charge money for it which is not quite GPL but very
close. I'll publish the book under one of the new on-demand presses
so it will be quite cheap. The margins will help sustain the work.
I guess there is one case that is affected, which is the Lisp developer
who wants to run Qi under a commercial Lisp and wants his work not to
be open source because he wants to preserve commercial investment. In
this case, he would need a commercial licence from me and we'd talk it
through. I don't want to stand in the way of a man feeding his family,
only not at my expense. I don't see that the GPL stops that sort of
arrangement.
Does that seem fair to people? It seems fair to me.
Mark
alex goldman wrote:
> Mark Tarver wrote:
>
> >
> > There might be a conflict about Franz themselves trying to
> > configure it as part of their own system because of the
> > the GPL licence.
>
> To use internally? I don't think GPL restricts it in any way.
> Nevertheless, have you thought about using a less threatening
license?
> BSD-style perhaps?
Mark Tarver wrote:
> The
> Lisp is 98% non-Qi-packaged portable Lisp.
2% is more than enough, if they are GPL'ed source code.
> From this definition, it is clear that under GPL, the programmer
> has to distribute Qi source if he uses Qi.
If Qi is only used for compilation, and not runtime, I doubt that GPL would
place any restictions on him. (Otherwise GCC would be used to only compile
GPLed software)
IANAL
From: Sam Steingold
Subject: Re: Qi and the GPL licence
Date:
Message-ID: <uoec6vqpd.fsf@gnu.org>
> * Mark Tarver <··········@hxbayvar.pb.hx> [2005-04-22 05:31:40 -0700]:
>
> Does that seem fair to people?
yes.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://pmw.org.il/> <http://www.mideasttruth.com/> <http://www.iris.org.il>
<http://www.camera.org> <http://www.dhimmi.com/> <http://www.jihadwatch.org/>
Live Lisp and prosper.
Sam Steingold wrote:
> running w2k
Won't you get excommunicated from GNU for that?
From: Sam Steingold
Subject: Re: Qi and the GPL licence
Date:
Message-ID: <uacnqvpcb.fsf@gnu.org>
> * alex goldman <·····@fcnzz.re> [2005-04-22 07:23:29 -0700]:
> Sam Steingold wrote:
>> running w2k
> Won't you get excommunicated from GNU for that?
1. You can only be excommunicated from a religion.
My religion is not "Free Software" nor is it "Lisp".
2. At work I use whatever my employer puts on my desk.
My home is MS-free.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.iris.org.il>
<http://www.memri.org/> <http://pmw.org.il/> <http://www.camera.org>
Our business is run on trust. We trust you will pay in advance.
Sam Steingold wrote:
>>* alex goldman <·····@fcnzz.re> [2005-04-22 07:23:29 -0700]:
>>Sam Steingold wrote:
>>
>>>running w2k
>>
>>Won't you get excommunicated from GNU for that?
>
>
> 1. You can only be excommunicated from a religion.
Only from some, hierarchical or fascistly controlled religions. I
don't think anybody can remove your being a buddhist. Certainly
nobody can steal Taoism from me.
Religious groups should be voluntary gatherings of people anyway,
just like this newsgroup. Whoever doesn't like it is free to leave.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
From: Sam Steingold
Subject: Re: Qi and the GPL licence
Date:
Message-ID: <uu0lyu6f7.fsf@gnu.org>
> * Ulrich Hobelmann <···········@jro.qr> [2005-04-22 10:15:07 -0500]:
>
>> 1. You can only be excommunicated from a religion.
>
> Only from some, hierarchical or fascistly controlled religions.
any group can "excommunicate" its member for any reason.
this has nothing to do with religion -
but everything with the right of free association.
what I was trying to say is that usually the term "excommunication" is
used by religions (societies and clubs "expel" their members).
> Certainly nobody can steal Taoism from me.
Interesting.
On one hand you claim that your religion is very very tolerant,
on the other hand you call other religions "fascistly controlled".
Have you actually encountered a "fascist control"?
How long have you lived in a totalitarian state?
> Religious groups should be voluntary gatherings of people anyway, just
> like this newsgroup. Whoever doesn't like it is free to leave.
that's what they usually are - at least when we are not talking about
"state religions" and "established churches".
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.honestreporting.com>
<http://www.mideasttruth.com/> <http://www.openvotingconsortium.org/>
Please wait, MS Windows are preparing the blue screen of death.
Sam Steingold wrote:
>>Certainly nobody can steal Taoism from me.
>
>
> Interesting.
> On one hand you claim that your religion is very very tolerant,
I don't consider it my religion, or even *a* religion. I just
side with some of its ideas. That's what I mean by voluntary
association :)
> on the other hand you call other religions "fascistly controlled".
> Have you actually encountered a "fascist control"?
> How long have you lived in a totalitarian state?
Well, maybe I should have said dogmatic. I live in a state that
once was totalitarian and has ever since defended democracy (well,
until now; we lose a little bit of freedom every day...).
There are degrees of totalitarianism. I see it everywhere,
although it's certainly far less than in the beginning/middle of
the 20th century!
Just because something takes away "only a little" freedom, doesn't
means it's less totalitarian.
>>Religious groups should be voluntary gatherings of people anyway, just
>>like this newsgroup. Whoever doesn't like it is free to leave.
>
>
> that's what they usually are - at least when we are not talking about
> "state religions" and "established churches".
Yes. Maybe it makes sense that the Catholic Church can say that
you may not call yourself Catholic if you don't comply with their
"standards". This is like not calling yourself a doctor if you
aren't one.
In that the "totalitarian" word certainly doesn't apply to
Churches. However, the excluding people from the church (are you
allowed to go to church anymore after that?) sounds really harsh
(or violent, or totalitarian in a way) to me, just because you
don't agree with all their policies... A church should be an
open, universal building, and *especially* open to sinners
(literally: people who miss the aim).
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
From: Sam Steingold
Subject: Re: Qi and the GPL licence
Date:
Message-ID: <u64yeu0tm.fsf@gnu.org>
> * Ulrich Hobelmann <···········@jro.qr> [2005-04-22 12:53:00 -0500]:
>
> Sam Steingold wrote:
>> on the other hand you call other religions "fascistly controlled".
>> Have you actually encountered a "fascist control"?
>> How long have you lived in a totalitarian state?
>
> Well, maybe I should have said dogmatic.
Maybe - I would not have replied then ;-)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://pmw.org.il/> <http://www.dhimmi.com/>
<http://www.iris.org.il> <http://www.memri.org/>
Isn't "Microsoft Works" an advertisement lie?
On Fri, 22 Apr 2005 05:31:40 -0700, Mark Tarver wrote:
> What is legally interesting about Qi is that it generates type
> secure Lisp code which you can run outside Qi. If you look at
> appendix B in FPQi its very simple to generate Lisp from Qi. The
> Lisp is 98% non-Qi-packaged portable Lisp. So how does the GPL
> apply to this?
As you say this is legally very interesting!
> The licence says
>
> "The source code for a work means the **preferred form of the work for
> making modifications to it**. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to control
> compilation and installation of the executable."
>
> From this definition, it is clear that under GPL, the programmer
> has to distribute Qi source if he uses Qi.
This is not clear at all. You've described Qi being used as a Lisp source
to Lisp source transformer. From Appendix B:
Qi is written in and is compatible with Lisp code and any Qi program
can be turned into a corresponding Lisp program by means of the dump
function in Qi. Given an Qi program in a text file (call it foo), the
command (dump "foo") will load the Qi code in foo into Qi and produce a
file foo.lsp with the equivalent Lisp program within it.
The GPL doesn't apply to an independent work Qi transforms unless the
work also includes Qi itself. This can occur with code generators that
include themselves in the resulting work. If this is a concern with Qi
(you've mentioned that the transformed code is "98% non-Qi-packaged
portable Lisp") then the Bison exception could be suitable:
<http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCCanIUseGPLToolsForNF>
Can I use GPL-covered editors such as GNU Emacs to develop non-free
programs? Can I use GPL-covered tools such as GCC to compile them?
Yes, because the copyright on the editors and tools does not cover the
code you write. Using them does not place any restrictions, legally,
on the license you use for your code.
Some programs copy parts of themselves into the output for technical
reasons--for example, Bison copies a standard parser program into its
output file. In such cases, the copied text in the output is covered by
the same license that covers it in the source code. Meanwhile, the part
of the output which is derived from the program's input inherits the
copyright status of the input.
As it happens, Bison can also be used to develop non-free programs.
This is because we decided to explicitly permit the use of the Bison
standard parser program in Bison output files without restriction. We
made the decision because there were other tools comparable to Bison
which already permitted use for non-free programs.
> What about the documentation? You can copy it and print it off as
> long as you don't charge money for it which is not quite GPL but very
> close. I'll publish the book under one of the new on-demand presses
> so it will be quite cheap. The margins will help sustain the work.
If it isn't explicit that the documentation you distribute in the Qi
zip file is not GPL'd you should try and make it explicit ASAP.
> I guess there is one case that is affected, which is the Lisp developer
> who wants to run Qi under a commercial Lisp and wants his work not to
> be open source because he wants to preserve commercial investment. In
> this case, he would need a commercial licence from me and we'd talk it
> through. I don't want to stand in the way of a man feeding his family,
> only not at my expense. I don't see that the GPL stops that sort of
> arrangement.
If Qi can be used as a source transformer at build time only and Qi itself
is not distributed with the resulting product then Qi may be able to be
used for proprietary/closed source software development (just like GCC).
Many thanks for your description of Qi.
Regards,
Adam
> This is not clear at all. You've described Qi being used as a Lisp
source
> to Lisp source transformer. From Appendix B:
No, Qi is a Lisp generator - not a transformer. The input is not legal
Lisp and cannot be read outside a Qi compiler.
Mark
On Fri, 22 Apr 2005 07:36:42 -0700, Mark Tarver wrote:
>> This is not clear at all. You've described Qi being used as a Lisp
>> source to Lisp source transformer. From Appendix B:
>
> No, Qi is a Lisp generator - not a transformer. The input is not legal
> Lisp and cannot be read outside a Qi compiler.
Of course! Sorry. I guess I was thinking of reader macros transforming
unusual looking Lisp input into standard Common Lisp output. What I wrote
still applies to the generation of Lisp source code from Qi source code.
Regards,
Adam
> If it isn't explicit that the documentation you distribute in the Qi
> zip file is not GPL'd you should try and make it explicit ASAP.
Its in the text itself (.PDF)and in the index page to the HTML.
The following copyright applies to "Functional Programming in Qi" and
is written into the text.
All right reserved. No part of this book covered by the copyright
hereon may be reproduced or used in any form or by any means-graphic,
electronic, or mechanical, including photocopying, recording, taping,
or information storage and retrieval system for money - without
permission of the author.
This means you are free to print off or make electronic copies of this
text at your expense, but you cannot sell them for money unless by my
permission.
Perhaps I should put it on all the HTML chapters too.
> Many thanks for your description of Qi.
You're welcome.
Mark
On Fri, 22 Apr 2005 03:58:00 -0700, Mark Tarver wrote:
> Probably what Carl Shapiro will do with Qi 6.1 sources is configure them
> to be loaded into Allegro and create a little installation program. No
> Allegro image will be distributed and people will have to run the
> installation themselves to install it.
Sure. If you're solely distributing your own source code you can licence
it however you wish. Just as with Copyright law, the GPL doesn't limit
private use of the work ("Activities other than copying, distribution and
modification are not covered by this License; they are outside its scope.
The act of running the Program is not restricted ...")
> There might be a conflict about Franz themselves trying to configure it
> as part of their own system because of the the GPL licence.
There should only be a conflict if someone distributes an executable built
with Allegro and Qi. Franz's runtime licence is clearly incompatible with
the GPL: <http://www.franz.com/products/licensing/FSLA.lhtml>
[And by the way Duane, Allegro's runtime licence also appears to be
incompatible with some LGPL/LLGPL software. Compare this clause ...
8. in distributing your application, (i) prohibit each recipient of the
application from reverse engineering, decompiling, or disassembling the
application;
... with the LGPL:
6. As an exception to the Sections above, you may also combine or link
a "work that uses the Library" with the Library to produce a work
containing portions of the Library, and distribute that work under
terms of your choice, provided that the terms permit modification of
the work for the customer's own use and reverse engineering for
debugging such modifications.
...
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies the
executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.]
> CLisp seems to be a good platform. My timings suggest that the speed
> difference between Allegro and CLisp is only 25% under Qi Prolog. But
> we'll see better when the port takes place. The new multi-thread
> version of CLisp will be very useful for Qi/Tk.
At its core CLISP is a non-JIT fast bytecode interpreter. In tight loops a
native code compiler can be many times faster.
CLISP:
(time (funcall
(compile nil
(lambda ()
(let ((x 0))
(dotimes (i 9999999)
(when (zerop (random 2))
(incf x)))
x)))))
Real time: 8.073201 sec.
Run time: 8.05 sec.
Space: 13824 Bytes
4999827
SBCL (running the same code on the same machine):
Evaluation took:
0.57 seconds of real time
0.53 seconds of user run time
0.0 seconds of system run time
0 page faults and
0 bytes consed.
4999155
Regards,
Adam
From: Sam Steingold
Subject: Re: configuring Qi 6.1 for other Lisps
Date:
Message-ID: <uu0lyvqrd.fsf@gnu.org>
> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-23 01:16:45 +1200]:
>
>
>> CLisp seems to be a good platform. My timings suggest that the speed
>> difference between Allegro and CLisp is only 25% under Qi Prolog. But
>> we'll see better when the port takes place. The new multi-thread
>> version of CLisp will be very useful for Qi/Tk.
>
> At its core CLISP is a non-JIT fast bytecode interpreter. In tight
> loops a native code compiler can be many times faster.
I don't think this is a common use case.
You can, alternatively, compare (! 100000) in CLISP and SBCL :-)
> CLISP:
> (time (funcall
> (compile nil
> (lambda ()
> (let ((x 0))
> (dotimes (i 9999999)
> (when (zerop (random 2))
> (incf x)))
> x)))))
>
> Real time: 8.073201 sec.
> Run time: 8.05 sec.
> Space: 13824 Bytes
> 4999827
>
> SBCL (running the same code on the same machine):
> Evaluation took:
> 0.57 seconds of real time
> 0.53 seconds of user run time
> 0.0 seconds of system run time
> 0 page faults and
> 0 bytes consed.
> 4999155
wow!!! are you saying that SBCL compiler DOES NOT CONS at ALL?!
cool! very very impressive.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/> <http://www.dhimmi.com/>
<http://www.mideasttruth.com/> <http://www.palestinefacts.org/>
Booze is the answer. I can't remember the question.
On Fri, 22 Apr 2005 10:18:46 -0400, Sam Steingold wrote:
>> At its core CLISP is a non-JIT fast bytecode interpreter. In tight
>> loops a native code compiler can be many times faster.
>
> I don't think this is a common use case.
> You can, alternatively, compare (! 100000) in CLISP and SBCL :-)
To get something running in reasonable time and not printing screeds of
output I chose to (time (/ (! 10000) (! 9999)))
CLISP:
[19]> (defun ! (n) (let ((product 1)) (loop for i from 2 to n do (setf product (* product i))) product))
!
[20]> (compile '!)
! ;
NIL ;
NIL
[21]> (time (/ (! 10000) (! 9999)))
Real time: 1.048694 sec.
Run time: 1.05 sec.
Space: 139320928 Bytes
GC: 268, GC time: 0.3 sec.
SBCL:
* (defun ! (n) (let ((product 1)) (loop for i from 2 to n do (setf product (* product i))) product))
!
* (time (/ (! 10000) (! 9999)))
Evaluation took:
1.046 seconds of real time
0.82 seconds of user run time
0.19 seconds of system run time
2 page faults and
139,427,944 bytes consed.
10000
In this case the overhead of computing the bignums overwhelms any gains
within the faster loop code.
Numerically intensive code will generally be faster with a native code
compiler, especially when the code is declared to operate upon machine
types like (unsigned-byte 32).
CLISP's comparatively small fixnums are still a real impediment because
they limit the maximum size of arrays. One can't even create a 16MB array
of octets (assuming a 32 bit platform):
(make-array #x1000000 :element-type '(unsigned-byte 8))
*** - MAKE-ARRAY: dimension 16777216 is not of type `(INTEGER 0 (,ARRAY-DIMENSION-LIMIT))
Regards,
Adam
From: Sam Steingold
Subject: Re: configuring Qi 6.1 for other Lisps
Date:
Message-ID: <ubr86u1cl.fsf@gnu.org>
> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-23 03:07:34 +1200]:
>
> On Fri, 22 Apr 2005 10:18:46 -0400, Sam Steingold wrote:
>
>>> At its core CLISP is a non-JIT fast bytecode interpreter. In tight
>>> loops a native code compiler can be many times faster.
>>
>> I don't think this is a common use case.
>> You can, alternatively, compare (! 100000) in CLISP and SBCL :-)
>
> To get something running in reasonable time and not printing screeds of
> output I chose to (time (/ (! 10000) (! 9999)))
>
> CLISP:
> [19]> (defun ! (n) ...)
1. CLISP has a built-in ! and I hinted at that with the smiley.
2. Thanks for discovering a bug - redefining ! should not be easy.
> CLISP's comparatively small fixnums are still a real impediment
> because they limit the maximum size of arrays. One can't even create a
> 16MB array of octets (assuming a 32 bit platform):
I have never needed 16MB arrays, and I have processed gigabytes of data
with CLISP (12GB memory images on AMD64, running for days).
I am not interested in arguing about CLISP vs ACL vs LW vs CMUCL/SBCL &c.
All implementations shine in some areas and suck in others.
In _my_ experience CLISP has been adequate in solving _my_ problems.
(I have also used CMUCL and the free ACL for Linux).
Good luck.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.iris.org.il> <http://www.memri.org/> <http://www.jihadwatch.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Never let your schooling interfere with your education.
On Fri, 22 Apr 2005 14:12:58 -0400, Sam Steingold wrote:
>> * Adam Warner [2005-04-23 03:07:34 +1200]:
>>
>> On Fri, 22 Apr 2005 10:18:46 -0400, Sam Steingold wrote:
>>
>>>> At its core CLISP is a non-JIT fast bytecode interpreter. In tight
>>>> loops a native code compiler can be many times faster.
>>>
>>> I don't think this is a common use case.
>>> You can, alternatively, compare (! 100000) in CLISP and SBCL :-)
>>
>> To get something running in reasonable time and not printing screeds of
>> output I chose to (time (/ (! 10000) (! 9999)))
>>
>> CLISP:
>> [19]> (defun ! (n) ...)
>
> 1. CLISP has a built-in ! and I hinted at that with the smiley.
>
> 2. Thanks for discovering a bug - redefining ! should not be easy.
Indeed I was not aware EXT:! was built-in.
Looks like I'll have to one-up it with memoisation:
(let ((cache #(1)))
(defun factorial (n)
(when (>= n (length cache))
(let ((array (make-array (1+ n) :element-type 'integer)))
(replace array cache)
(loop for i from (length cache) to n do
(setf (aref array i) (* i (aref array (1- i)))))
(setf cache array)))
(aref cache n)))
This should be more space efficient and faster than the common approach of
looking N up in an EQL hash table.
Regards,
Adam
> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-22 11:43:38 +1200]:
>
> I made it abundantly clear in what you snipped that the distributed
> memory image included a dump of Qi itself. If the same build procedure
> was applied to other non-GPL Lisp implementations then the new memory
> images would not be distributable under each project's original
> terms. Thus the GPL would be an unsuitable choice if one wanted new
> dumped memory images to be distributable under each project's original
> terms.
This is backwards: he wrote Qi and wants to distribute it under GPL as a
CMUCL core file. If you want to build something on top of Qi, it is
only fair that you abide by his chosen license. If you do not care
about Qi, you don't need his distribution and you can distribute your
application based on the original CMUCL core under _your_ chosen license.
> Please underscore this whole phrase: "the memory images of other Lisp
> implementations to be distributable under each project's original
> terms".
The desire to distribute a CMUCL core which includes Qi under the
original CMUCL terms (PD) is _not_ reasonable.
Try telling something like that to a developer of a proprietary product.
E.g., CL-HTTP cannot be distributed under the original CMUCL (PD)
license either. So?
> Yes he can distribute his GNU GPL application as a CMUCL/SBCL core
> file but the core file will not be distributable under CMUCL/SBCL's
> original terms.
yes, this is precisely what Mark wants,
and I think this is entirely reasonable -
both that he wants it and
that the copyright law allows him to do that.
> Moreover Mark mentioned porting to Allegro. I'm pretty sure Franz
> would not appreciate an Allegro memory image including Qi being
> distributed under the terms of the GNU GPL (in fact it would simply be
> non-distributable).
this means that he has to do something tricky,
like distributing Qi sources with a Makefile or something.
BTW, this is similar to the reverse situation: suppose you write a
proprietary program and you want to distribute it with CLISP (which is
covered by GNU GPL).
If your program does not rely on CLISP internals
(i.e., it is not a CLISP extension)
then all you need to do is provide your compiled *.fas files along with
instruction on how to build the memory image you distribute.
The bottom line is: if, as RMS wanted, _all_ software were PD, the
problem would not have existed in the first place :-)
In the real world, however, one does have to watch for licensing issues.
The are _not_ insurmountable though.
Yes, you _CAN_ distribute proprietary software running under a GNU GPL lisp.
Yes, you _CAN_ distribute GNU GPL software running under a proprietary lisp.
It may require you to make an extra step or two, but these steps are
negligible compared to your original development effort, and refusing to
make them smacks of ideological purism unknown outside of the FSF. :-)
IANAL.
PS. I did not mean to insult you in any way. Sorry if I did.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.memri.org/> <http://www.jihadwatch.org/>
<http://www.iris.org.il> <http://www.camera.org>
Any connection between your reality and mine is purely coincidental.
On Fri, 22 Apr 2005 10:39:51 -0400, Sam Steingold wrote:
>> I made it abundantly clear in what you snipped that the distributed
>> memory image included a dump of Qi itself. If the same build procedure
>> was applied to other non-GPL Lisp implementations then the new memory
>> images would not be distributable under each project's original
>> terms. Thus the GPL would be an unsuitable choice if one wanted new
>> dumped memory images to be distributable under each project's original
>> terms.
>
> This is backwards: he wrote Qi and wants to distribute it under GPL as a
> CMUCL core file. If you want to build something on top of Qi, it is
> only fair that you abide by his chosen license. If you do not care
> about Qi, you don't need his distribution and you can distribute your
> application based on the original CMUCL core under _your_ chosen license.
Sam, I began this discussion thinking Qi was a language extension to
Common Lisp and its authors might want it to be adopted by Common Lisp
implementations. That is just like one could (require 'bsd-sockets) one
could also (require 'qi). To promote the language. That's all. I have no
ulterior interest in Qi.
> The desire to distribute a CMUCL core which includes Qi under the
> original CMUCL terms (PD) is _not_ reasonable.
If one wants a language extension adopted by Common Lisp implementations
it may be reasonable to meet their terms of distribution (which also
include permissive licenses: CMUCL and SBCL do not just consist of public
domain code).
We now have ample information about Mark's desires which indicate that
this is not a significant concern. So the matter's closed. I raised the
scenarios for his consideration and he's addressed them.
> PS. I did not mean to insult you in any way. Sorry if I did.
This is appreciated, thanks.
Regards,
Adam
On Sat, 23 Apr 2005 04:19:02 +1200, Adam Warner wrote:
> Sam, I began this discussion thinking Qi was a language extension to
> Common Lisp and its authors might want it to be adopted by Common Lisp
> implementations. That is just like one could (require 'bsd-sockets) one
> could also (require 'qi). To promote the language. That's all. I have no
> ulterior interest in Qi.
Just to be complete, I've also realised the Qi language could be adopted
at the distribution level (e.g. by Debian GNU/Linux) rather than by
individual Common Lisp implementations and the same level of integration
could still be available.
Regards,
Adam
> * Adam Warner <······@pbafhygvat.arg.am> [2005-04-20 23:38:22 +1200]:
>
> You may want to reconsider the implications of your choice of licence,
> especially if you're trying to promote widespread adoption of your
> language implementation. CLISP may be the only Common Lisp
> implementation it can be integrated with (i.e. without forcing a
> licensing change to the GPL).
IMNSHO (IANAL) this is false.
Software covered by GNU GPL can be run using any CL implementation.
The _other_ way _COULD_ be problematic (in _theory_!): it is conceivable
that the nature of the CL distribution model may result GNU GPL of the
implementation infecting the product.
In practice it is _NOT_: proprietary applications _can_ be
distributed with CLISP (http://clisp.cons.org/impnotes/app-dev.html)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/> <http://www.iris.org.il>
<http://www.dhimmi.com/> <http://www.mideasttruth.com/> <http://www.memri.org/>
Between grand theft and a legal fee, there only stands a law degree.