Re: Embedding Html in Lisp

[A Soare]

Thanks a lot for your reaction. You asked very well a question.


> 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?
> 

What is behind of the phenomenon that I discovered here? Good
question...

The general principle discovered here is: 

«The class of Markup languages is a subset of functional
languages. Every markup language is a very special case of
functional language.»

That says everything.

Html is defined as a very simplified functional language.
Xml is a simplified functional than html a little different of html.
Every markup language is a very simplified example of functional language.

To understand this principle, it is easy. Consider a functional
language like an implementation of a lambda-calculus, and
consider an implementation of a lambda-calculus as an evaluator.

Consider lisp evaluator as first example. To interpret html we need a
lisp evaluator in which the objects have just 2 types: strings and
list (in emacs Lisp the evaluator supports objects of 19 types (from
which 12 are Subtypes Lisp_Misc, because the evaluator allocated for
type object location just 3 bits)). (using these 2 types we can
express everything that html want to express). So HTML evaluator
embedded in LISP uses very little from the power of the lisp
evalutor. (imagine Edward Scissorhands working to create an html
evaluator from a lisp evaluator).

So I define html as a functional language defined by an evaluator with
2 types. It does not matter whether the evaluator supports closure
property or not and these kind of details. Imagine the tag (center 30
"string"). Do we need a closure property to execute it? What does it
have to do? Simple: It knows the width that is allocated for the
object that it must return, and it knows the value of the object. So
it will create a string in which this object is centered. It will
return:

"           string             "
(if the string was aligned on a single line) or something like:

"           string1           "
"           string2           "
"           string3           "
"           string4           "

if the string =
"
s1
s2
s3
s4. etc.

The same reasoning for XML. For XML we need 3 types (symbol + string +
list as I imagine).

All these markup languages are very simplified types of functional
languages. This is the genetal phenomenon. This is the new definition
of html. Is't an element of the class of functional languages.

Sorry for not having expressed myself clear from the first message.

So I proved that Html deserves so much! It's a simplified
lambda-calculus like Lisp!


A.S.

PS: for the rest of the message I will answer you later or tomorrow.









> 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
> 
> 



____________________________________________________

En quelques secondes, créez-vous une autre adresse mail ! http://mail.voila.fr


____________________________________________________

En quelques secondes, créez-vous une autre adresse mail ! http://mail.voila.fr