License of the Emacs website (was: Re: First draft of the Emacs website)

License of the Emacs website (was: Re: First draft of the Emacs website)

[Chad Brown]

Subject changed.

> On 03 Dec 2015, at 19:57, Random832 <random832@fastmail.com> wrote:
> 
> On 2015-12-02, Xue Fuqiao <xfq.free@gmail.com> wrote:
>> On Thu, Dec 3, 2015 at 12:36 AM, Random832 <random832@fastmail.com> wrote:
>>> - "Verbatim" copying permission statement is non-free.
>> 
>> The standard copyright terms for GNU web pages is now the Creative
>> Commons Attribution-NoDerivs 3.0 United States License.
> 
> That's also non-free. Why not the GFDL, or CC-BY-SA?
> 
> http://www.gnu.org/licenses/license-list.en.html specifically recommends
> against this license. It's not clear why website text (or layout, etc)
> is so different from documentation as to require different principles.

That’s interesting, because
http://www.gnu.org/licenses/licenses.en.html says:

    The standard copyright terms for GNU web pages is now the Creative
    Commons Attribution-NoDerivs 3.0 United States License.

The web page you site also includes this:

    Works that express someone's opinion—memoirs, editorials, and
    so on—serve a fundamentally different purpose than works for
    practical use like software and documentation. Because of
    this, we expect them to provide recipients with a different
    set of permissions: just the permission to copy and
    distribute the work verbatim. Richard Stallman discusses this
    frequently in his speeches.

    Because so many licenses meet these criteria, we cannot list them all.
    If you are looking for one to use yourself, however, there are two
    that we recommend:

    * GNU Verbatim Copying License (#GNUVerbatim) This was the license used
      throughout the GNU web site for many years. It is very simple, and
      especially well-suited to written works.

    * Creative Commons Attribution-NoDerivs 3.0 license (a.k.a. CC BY-ND)
      (#ccbynd) This is the license used throughout the GNU and FSF web
      sites. This license provides much the same permissions as our verbatim
      copying license, but it's much more detailed. We particularly
      recommend it for audio and/or video works of opinion. Please be
      specific about which Creative Commons license is being used.

This seems like a discussion for someplace other than the emacs-devel
list, so I tried (perhaps crudely?) to redirect it to emacs-tangents.

Thanks,
~Chad

Re: License of the Emacs website (was: Re: First draft of the Emacs website)

[Random832]

On 2015-12-04, Chad Brown <yandros@gmail.com> wrote:
>     Works that express someone's opinion—memoirs, editorials, and
>     so on—serve a fundamentally different purpose than works for
>     practical use like software and documentation.

I don't see how, in general, a software project website fits
into these categories.  Even if it did, I think concerns of
misrepresentation (which I assume are the issue here) should be
dealt with by non-copyright mechanisms.  Or at most require a
disclaimer.

> This seems like a discussion for someplace other than the emacs-devel
> list, so I tried (perhaps crudely?) to redirect it to emacs-tangents.

I hadn't realized Gmane had it yet.

Python vs Lisp (followups to -tangents)

[Random832]

On 2015-12-10, Richard Stallman <rms@gnu.org> wrote:
> I looked at this some years ago, and I concluded there is only a
> little validity in it.  The main essential features of Lisp are not
> present in Python.

For some clue of what you're talking about, your previous
statement on this matter was:

> I skimmed documentation of Python after people told me it was
> fundamentally similar to Lisp. My conclusion is that that is
> not so. `read', `eval', and `print' are all missing in Python.

I must admit, I don't fully understand what you mean by this.

Print is the most confusing. As a feature, Lisp's 'print' can be
described as: Produce a string representation which can be read
back of some objects (certainly not *all* objects - not buffers
or subroutines, for example, and it's not structure-preserving
for lists of lists), and display it on standard output.
Python's 'repr' could be regarded as an exact match in concept
for prin1-to-string, a building block from which Lisp's 'print'
can be trivially made. The essential feature - that there is a
way to get a string that can be read back for objects for which
it is reasonable/easy - is present.

Python's 'eval'/'exec' normally evaluates code directly from a
string, skipping the need for 'read' entirely. However, if
desired, the 'ast' module provides a rich framework for working
with expression trees - the only difference is that they're
built from class-based objects instead of just being a list of
lists/symbols/literals.

Re: Python vs Lisp (followups to -tangents)

[Sam Steingold]

> * Random832 <enaqbz832@snfgznvy.pbz> [2015-12-10 16:13:30 +0000]:
>
> On 2015-12-10, Richard Stallman <rms@gnu.org> wrote:
>
>> I skimmed documentation of Python after people told me it was
>> fundamentally similar to Lisp. My conclusion is that that is
>> not so. `read', `eval', and `print' are all missing in Python.
>
> I must admit, I don't fully understand what you mean by this.
>
> Print is the most confusing. As a feature, Lisp's 'print' can be
> described as: Produce a string representation which can be read
> back of some objects (certainly not *all* objects - not buffers
> or subroutines, for example, and it's not structure-preserving
> for lists of lists), and display it on standard output.

This is false.
Nested lists are certainly printed readably:

--8<---------------cut here---------------start------------->8---
(defvar l '(1 (2 3) 4 (5 (6 (7 (8))))))
(equal l (read (prin1-to-string l)))
==> t
--8<---------------cut here---------------end--------------->8---


> Python's 'repr' could be regarded as an exact match in concept
> for prin1-to-string, a building block from which Lisp's 'print'
> can be trivially made. The essential feature - that there is a
> way to get a string that can be read back for objects for which
> it is reasonable/easy - is present.

True, but irrelevant.
An important feature is missing: repr is not defined for classes
automatically.

> Python's 'eval'/'exec' normally evaluates code directly from a
> string, skipping the need for 'read' entirely.

A string is too unstructured.

> However, if desired, the 'ast' module provides a rich framework for
> working with expression trees - the only difference is that they're
> built from class-based objects instead of just being a list of
> lists/symbols/literals.

These class-based objects cannot be printed readably (IIUC).

The point Richard is making is that Python lacks macros, i.e., you
cannot easily write code which writes code.
You have to either operate at the level of strings (which is hard to get
right) or at the level of AST (which is even harder).

Even more succinctly, in Lisp data and code are the same: lists of
lists, symbols, strings &c.
In Python, data is (mostly) strings and code is AST.


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://memri.org http://islamexposedonline.com
http://truepeace.org http://www.dhimmitude.org http://camera.org
Old Age Comes at a Bad Time.

Re: Python vs Lisp (followups to -tangents)

[Random832]

On 2015-12-10, Sam Steingold <sds@gnu.org> wrote:
> This is false.
> Nested lists are certainly printed readably:

What I meant by "not structure-preserving" is that the output is
the same, ((1 2) (1 2)), for these lists:

(let  ((x '((1 2) (1 2))))         (eq (car x) (cadr x))) ==> nil
(let* ((a '(1 2)) (x `(,a ,a)))    (eq (car x) (cadr x))) ==> t
(let  ((x (read "((1 2) (1 2))"))) (eq (car x) (cadr x))) ==> nil

(Or for that matter, let*
 ((b '(2)) (x (list (cons 1 b) (cons 1 b))))...)

> True, but irrelevant.
>An important feature is missing: repr is not defined for classes
> automatically.

Sure it is. It's just defined to the same kind of useless value
that Lisp has for buffers and subroutines.

>> Python's 'eval'/'exec' normally evaluates code directly from a
>> string, skipping the need for 'read' entirely.
>
> A string is too unstructured.
>
>> However, if desired, the 'ast' module provides a rich framework for
>> working with expression trees - the only difference is that they're
>> built from class-based objects instead of just being a list of
>> lists/symbols/literals.
>
> These class-based objects cannot be printed readably (IIUC).

It's unfortunate that this is not their repr output, but the
ast.dump function provides this:

>>> ast.dump(ast.parse("1 + 1"))
'Module(body=[Expr(value=BinOp(left=Num(n=1), op=Add(), right=Num(n=1)))])'
>>> eval(ast.dump(ast.parse("1 + 1")), ast.__dict__)
<_ast.Module object at 0x7fcd79b24908>

> The point Richard is making is that Python lacks macros, i.e., you
> cannot easily write code which writes code.
> You have to either operate at the level of strings (which is hard to get
> right) or at the level of AST (which is even harder).

I don't see how operating at the level of AST is harder than
operating at the level of lists (backquote operates above the
level of lists; it automatically searches the code you give it
for placeholders to substitute values in. It probably wouldn't
be hard to write an equivalent in Python.)

> Even more succinctly, in Lisp data and code are the same: lists of
> lists, symbols, strings &c.
> In Python, data is (mostly) strings and code is AST.

I guess I don't see how being a little rough around the edges or
not working exactly the same way is the same thing as missing
the essential features entirely.

And this really isn't a valid objection to the claim being
discussed, which is that Python is similar to a hypothetical
M-expression lisp.

Re: Python vs Lisp (followups to -tangents)

[Sam Steingold]

> * Random832 <enaqbz832@snfgznvy.pbz> [2015-12-10 22:31:49 +0000]:
>
> On 2015-12-10, Sam Steingold <sds@gnu.org> wrote:
>> This is false.
>> Nested lists are certainly printed readably:
>
> What I meant by "not structure-preserving" is that the output is
> the same, ((1 2) (1 2)), for these lists:
>
> (let  ((x '((1 2) (1 2))))         (eq (car x) (cadr x))) ==> nil
> (let* ((a '(1 2)) (x `(,a ,a)))    (eq (car x) (cadr x))) ==> t
> (let  ((x (read "((1 2) (1 2))"))) (eq (car x) (cadr x))) ==> nil
>
> (Or for that matter, let*
>  ((b '(2)) (x (list (cons 1 b) (cons 1 b))))...)

please examine the `print-circle' variable.

>> True, but irrelevant.
>>An important feature is missing: repr is not defined for classes
>> automatically.
>
> Sure it is. It's just defined to the same kind of useless value
> that Lisp has for buffers and subroutines.

The #<...> format is reserved for objects which cannot be meaningfully
read back. Still, it contains plenty of information for a human.

Python prints junk when it could have been printing machine-readable info.

>>> Python's 'eval'/'exec' normally evaluates code directly from a
>>> string, skipping the need for 'read' entirely.
>>
>> A string is too unstructured.
>>
>>> However, if desired, the 'ast' module provides a rich framework for
>>> working with expression trees - the only difference is that they're
>>> built from class-based objects instead of just being a list of
>>> lists/symbols/literals.
>>
>> These class-based objects cannot be printed readably (IIUC).
>
> It's unfortunate that this is not their repr output, but the
> ast.dump function provides this:
>
>>>> ast.dump(ast.parse("1 + 1"))
> 'Module(body=[Expr(value=BinOp(left=Num(n=1), op=Add(), right=Num(n=1)))])'
>>>> eval(ast.dump(ast.parse("1 + 1")), ast.__dict__)
> <_ast.Module object at 0x7fcd79b24908>

yep, with some additional cruft Python can almost do something that Lisp
does for free.

>> The point Richard is making is that Python lacks macros, i.e., you
>> cannot easily write code which writes code.
>> You have to either operate at the level of strings (which is hard to get
>> right) or at the level of AST (which is even harder).
>
> I don't see how operating at the level of AST is harder than
> operating at the level of lists (backquote operates above the
> level of lists; it automatically searches the code you give it
> for placeholders to substitute values in. It probably wouldn't
> be hard to write an equivalent in Python.)

I am afraid you do not quite understand what you are talking about.

>> Even more succinctly, in Lisp data and code are the same: lists of
>> lists, symbols, strings &c.
>> In Python, data is (mostly) strings and code is AST.
>
> I guess I don't see how being a little rough around the edges or
> not working exactly the same way is the same thing as missing
> the essential features entirely.
>
> And this really isn't a valid objection to the claim being
> discussed, which is that Python is similar to a hypothetical
> M-expression lisp.

You have seen a car but never rode or driven one and you are trying to
convince me that your tricycle is better.

Seriously, this is the wrong forum for this discussion.
I suggest that you learn more about Lisp (see, e.g., Paul Graham's "On
Lisp", or http://letoverlambda.com/).

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://think-israel.org http://americancensorship.org
http://openvotingconsortium.org http://memri.org http://mideasttruth.com
"A pint of sweat will save a gallon of blood."          -- George S. Patton

Re: Python vs Lisp (followups to -tangents)

[Random832]

Sam Steingold <sds@gnu.org> writes:
> You have seen a car but never rode or driven one and you are trying to
> convince me that your tricycle is better.

The point of the statement you were replying to here was rather
that I'm not convinced that an M-expression lisp isn't more like
a tricycle than a car.

Re: Python vs Lisp (followups to -tangents)

[Christopher Allan Webber]

Random832 writes:

>> The point Richard is making is that Python lacks macros, i.e., you
>> cannot easily write code which writes code.
>> You have to either operate at the level of strings (which is hard to get
>> right) or at the level of AST (which is even harder).
>
> I don't see how operating at the level of AST is harder than
> operating at the level of lists (backquote operates above the
> level of lists; it automatically searches the code you give it
> for placeholders to substitute values in. It probably wouldn't
> be hard to write an equivalent in Python.)

So, I think this thread is getting fairly off topic for the list, but I
can't resist chiming in here.

A project I've contributed to occasionally is Hy, which is sort of a
lisp that uses s-expressions (yes, you do need them if you want
homoiconic properties) which compiles down to Python's AST.  It's pretty
cool, because you can now write macros for Python and do other sorts of
lispy things that are impossible otherwise.  See:

  http://hy.readthedocs.org/en/latest/tutorial.html

Doing this required building a lisp like system on top of Python though.
To add new operations to the language meant making the language
homoiconic in some way, and yes, that meant using Python lists to make
s-expressions.  And yeah, you could compose with Python then.

I think in most ways, Hy was a real lisp, just one that used cpython as
a virtual machine.

However, there are downsides to using a lisp on top of something that
was never intended to be a lisp, which I learned the hard way.  I tried
writing a serious system in Hy, and eventually had to move to Guile
instead.  Why?  Because once you have macros, it becomes very difficult
to tell what line number you're on in (the level of transformations we
did made it so we couldn't keep around that information by the time we
got to the AST, and it was hard to reason about what was going on
there).  This meant debugging was nearly impossible, because when
debugging in Python, line numbers is your primary context for
determining where you are.  I'm not just talking about pdb.set_trace()
(though that too); even tracebacks became impossible to deal with.

Thus Hy is a pretty cool toy to play with, and kind of nice for writing
a quick DSL on top of Python.  And it *has* proven that you could treat
the Python AST as something to compile down to and have macros.  But
even there, it looked like lisp, and even once you had that, underlying
decisions about the implementation you're building on top of can make
things difficult.

Still fun to work on though!  Also a great community and a great route
for Python type people who want to dip their toe into lisp-land.  And a
good chance to learn the above lessons the hard way. :)

 - Chris