|
From: | Thomas Lord |
Subject: | Re: Embedding Html in Lisp |
Date: | Mon, 23 Jun 2008 09:56:06 -0700 |
User-agent: | Thunderbird 1.5.0.5 (X11/20060808) |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |