From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Embedding Html in Lisp Date: Mon, 23 Jun 2008 09:56:06 -0700 Message-ID: <485FD5A6.6090200@emf.net> References: <10403029.8884311214227267799.JavaMail.www@wwinf4622> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070804080807070204090507" X-Trace: ger.gmane.org 1214237439 10207 80.91.229.12 (23 Jun 2008 16:10:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Jun 2008 16:10:39 +0000 (UTC) Cc: Thien-Thi Nguyen , "Emacs Dev \[emacs-devel\]" To: alinsoar@voila.fr Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 23 18:11:15 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KAodL-0005zQ-PD for ged-emacs-devel@m.gmane.org; Mon, 23 Jun 2008 18:11:12 +0200 Original-Received: from localhost ([127.0.0.1]:44558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAocV-0001MI-OC for ged-emacs-devel@m.gmane.org; Mon, 23 Jun 2008 12:10:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KAocQ-0001LV-M9 for emacs-devel@gnu.org; Mon, 23 Jun 2008 12:10:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KAocO-0001KI-EF for emacs-devel@gnu.org; Mon, 23 Jun 2008 12:10:14 -0400 Original-Received: from [199.232.76.173] (port=33765 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAocO-0001KF-BW for emacs-devel@gnu.org; Mon, 23 Jun 2008 12:10:12 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:42629) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KAocN-0005v0-Uc for emacs-devel@gnu.org; Mon, 23 Jun 2008 12:10:12 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.114.9] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 33620983; Mon, 23 Jun 2008 09:09:52 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <10403029.8884311214227267799.JavaMail.www@wwinf4622> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:99786 Archived-At: This is a multi-part message in MIME format. --------------070804080807070204090507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit A Soare wrote: >> Html is lisp. >> >> You dignify html a lot more than it deserves! >> > > With the classical definition of HTML , yes. > > With the new definition, they can be compared. > > Are there any "structured data" languages that you know of that can *not* be transformed to lisp in a similar way? In other words, is HTML really special this way? Or is this a specific instance of a generalized phenomenon? Code is data and data is code. An interesting point of history: one of the very first lisp programs *ever* did symbolic differentiation. It would take input like: (exp x 2) # x squared and produce output like: (* x 2) That program manipulated the math expressions just as data. On the other hand, there is no reason you couldn't have passed one of the expressions to EVAL, e.g., to get a numeric value from it. It would have been inconvenient, though, to try to write the differentiation program by defining the function EXP as a function that interpreted its arguments as sub-expressions and returned the derivative of the overall expression. (Of course, now some Schemer will be tempted to show some Scheme macros that do symbolic differentiation but, that's not the point.) By analogy, for some uses it might be handy to interpret HTML elements as procedure calls. For other uses, it is handy to interpret them as lists. For still other uses, it is handy to interpret them as tree objects (e.g., the DOM data structure). As for a browser in Emacs: in spite of recent cracks (funny!) bout "yet another Emacs in Javascript" -- Emacs in a browser might be a lot easier than a browser in Emacs, judging by how Mozilla works. E.g., Mozilla parses HTML and build a tree. That tree acts a lot like an Emacs buffer in the sense that extension programs can edit the tree abstractly and the display of that tree is automatically updated. The standards for proper display of a web page are defined in terms of these trees. By the time Emacs gained enough functionality to handle such standards, it would resemble a small superset of the functionality that already exists in Mozilla. Conversely, it is probably a much smaller job to modify some of the key components of Mozilla so that they provide all of the functionality of Emacs buffers and display. For the task you describe, though -- a desire not to make a full browser but to be able to access a few simple web pages from Emacs -- of course Emacs can handily do that (and it sounds like you are getting some stuff to start working, so congratulations!). -t --------------070804080807070204090507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit A Soare wrote:
   Html is lisp.

You dignify html a lot more than it deserves!
    

With the classical definition of HTML , yes.

With the new definition, they can be compared.

  


Are there any "structured data" languages that you know
of that can *not* be transformed to lisp in a similar way?
In other words, is HTML really special this way?  Or
is this a specific instance of a generalized phenomenon?

Code is data and data is code.

An interesting point of history:  one of the very first
lisp programs *ever* did symbolic differentiation.
It would take input like:

   (exp x 2)      # x squared

and produce output like:

   (* x 2)

That program manipulated the math expressions just as
data.   On the other hand, there is no reason you couldn't
have passed one of the expressions to EVAL, e.g., to get
a numeric value from it.

It would have been inconvenient, though, to try to write
the differentiation program by defining the function EXP
as a function that interpreted its arguments as sub-expressions
and returned the derivative of the overall expression.
(Of course, now some Schemer will be tempted to show
some Scheme macros that do symbolic differentiation but,
that's not the point.)

By analogy, for some uses it might be handy to interpret
HTML elements as procedure calls.  For other uses, it is handy
to interpret them as lists.   For still other uses, it is handy to
interpret them as tree objects (e.g., the DOM data structure).

As for a browser in Emacs: in spite of recent cracks (funny!) bout
"yet another Emacs in Javascript" -- Emacs in a browser might be
a lot easier than a browser in Emacs, judging by how Mozilla
works.   E.g., Mozilla parses HTML and build a tree.  That tree
acts a lot like an Emacs buffer in the sense that extension programs
can edit the tree abstractly and the display of that tree is automatically
updated.   The standards for proper display of a web page are defined
in terms of these trees.   By the time Emacs gained enough functionality
to handle such standards, it would resemble a small superset of the
functionality that already exists in Mozilla.   Conversely, it is
probably a much smaller job to modify some of the key components
of Mozilla so that they provide all of the functionality of Emacs
buffers and display.

For the task you describe, though -- a desire not to make a full
browser but to be able to access a few simple web pages from Emacs --
of course Emacs can handily do that (and it sounds like you are getting
some stuff to start working, so congratulations!).

-t

--------------070804080807070204090507--