Re: Embedding Html in Lisp

[Thomas Lord <lord@emf.net>]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 3226 bytes --]