LISP and AI
A. Bijanki
Where can I find some LISP & AI links on the web?
David Bakhash
> I've heard that LISP is very useful to people researching AI. Why is this?
> Where can I find some LISP & AI links on the web?
A very short and simplistic answer to this is that language is very
flexible. If you're gonna program a computer to simulate
intelligence, then a good start is to have a language where a
programmer can describe things not just at a high level, but also in a
way that feels native to the domain of the problem at hand. The Lisp
programming languages are more easy modified. It just makes sense.
It's not a good language for AI, absolutely speaking, but it's far
better than anything else out there to my knowledge.
I don't think the AI shines through in any way. I think that people
who do AI tend to use something in the Lisp family because of
tradition almost as much as the bulk of the wanting-to-be-cutting-edge
neophytes choose Java. Not that there's anything wrong with Java in
this example, but still, lots of people use it because of hype and
heresy, and word-of-mouth (and of course the relative ease of finding
a job with that skillset).
Lisp is a bit different. First off, fewer firms use Lisp. Speaking
about CL specifically, it's not the most widely-used language. It has
not been popular for web dev't either. Furthermore, there are only a
few supported commercial implementations. And how many people are
coding AI systems these days anyway? Only a small percentage of the
programs written today are AI-related.
anyway, CL is what I believe to be a language that's excellent for
expressing complex ideas.
read about it and get tools and resources at http://www.alu.org.
dave
Courageous
> I don't think the AI shines through in any way. I think that people
> who do AI tend to use something in the Lisp family because of
> tradition almost as much as the bulk of the wanting-to-be-cutting-edge
> neophytes choose Java. Not that there's anything wrong with Java in
> this example, but still, lots of people use it because of hype and
> heresy, and word-of-mouth (and of course the relative ease of finding
> a job with that skillset).
Well, to be fair, Java is world's easier than C++, and so is
a good evolution considering what it's replacing. You have to
realize that easy-to-use embedded container libraries and the
like are a new concept to old-school programmers. :) God
forbid they see what you can do with map and a lambda function. :)
Java also has this "standardized kitchen sink" notion, where
every possible thing under the sun is being thrown into the JDK
as a part of the toolkit. This has a good side and a down side, but
forget ye not that the good side of it is driving alot of
the masses towards Java (and probably will continue to do
so for quite a while, especially as Java becomes more prevalent
and native compilers become more popular).
> anyway, CL is what I believe to be a language that's excellent for
> expressing complex ideas.
The metalinguistic capabilities of the language are just way
cool, dude. I'm currently working in an environment which
opaquely embeds continuation code behind various macro calls
in conjunction with a scheduler which understands the continuation
(it's a simulation environment, hence the presence of the
scheduler). This environment allows expressions like this:
(race
(call-cab 'yellow-cab)
(call-cab 'red-top)
(sequentially
(sleep 20)
(fail self)))
Which is to say, "get a cab -- either red or yellow -- within
20 simulated time unts, or the show is over, buster". Keep in
mind that this very small 6 line code fragment tells the
simulation scheduler the maximum amount of simulation time
that can go by for 3 different lisp forms and sees that it
happens. The same scheduler can be told to prioritize certain
ongoing tasks or that certain ongoing tasks conflict with
eachother.
C//
David Bakhash
> > anyway, CL is what I believe to be a language that's excellent for
> > expressing complex ideas.
>
> The metalinguistic capabilities of the language are just way
> cool, dude. I'm currently working in an environment which
> opaquely embeds continuation code behind various macro calls
> in conjunction with a scheduler which understands the continuation
> (it's a simulation environment, hence the presence of the
> scheduler). This environment allows expressions like this:
>
> (race
> (call-cab 'yellow-cab)
> (call-cab 'red-top)
> (sequentially
> (sleep 20)
> (fail self)))
>
> Which is to say, "get a cab -- either red or yellow -- within
> 20 simulated time unts, or the show is over, buster". Keep in
> mind that this very small 6 line code fragment tells the
> simulation scheduler the maximum amount of simulation time
> that can go by for 3 different lisp forms and sees that it
> happens. The same scheduler can be told to prioritize certain
> ongoing tasks or that certain ongoing tasks conflict with
> eachother.
I don't really see how your macros are so legible or obvious given
what you're trying to do.
But Courageous's post does give an example of what part of a program
might look like in Lisp. Lisp programs can vary structurally more
than programs written in most other languages.
hope this helps.
dave
(p.s. pick up ANSI Common Lisp, by Paul Graham, if you can.)
Courageous
> > (race
> > (call-cab 'yellow-cab)
> > (call-cab 'red-top)
> > (sequentially
> > (sleep 20)
> > (fail self)))
> I don't really see how your macros are so legible or obvious given
> what you're trying to do.
Well, I was neither trying to show legibility nor obviousness.
As it turns out, every single form in the above expression involves
either dealing with a continuation or dealing with the scheduler.
Full tasks are being spun up and are competing with eachother (in
the race), but one of the tasks (in the sequentially) is causing
the overall body of the (not shown) function to fail if 20
simulated seconds go by, possibly giving up on the race form.
Note the term "20 simulated seconds". Schedulng the passage of
fictional time versus real time is a fairly non-trivial task.
Equivalent lisp would be a real headache. What I was showing was
the ability to generate another language within Lisp. Which is
what the SCORE (simulation core) language is, as shown in the
example above.
I'm sure there are a vast sea of other examples, written by
other individuals who've customized a language to fit their
domain space. This is very easy to do in Lisp. Few other languages
can claim that.
This ability to transmogrify the language into something more
suitable to the domain space is probably one of the reasons the
AI community continues to use Lisp.
SCORE itself is a specialized language/environment for doing
human performance modelling. It's pretty good at it.
C/
David McClain
Courageous <jkra...@san.rr.com> wrote in message
news:390E4BA4...@san.rr.com...
> As it turns out, every single form in the above expression involves
> either dealing with a continuation or dealing with the scheduler.
Since CL does not have first-class continuations just what exactly do you
mean by this?
- DM
Joe Marshall
`Upward' continuations are easily done with CATCH/THROW in
CommonLisp. `Downward' continuations are usually used for
co-routining, and can be emulated via `stack-groups' or other
process-scheduling hacks.
David McClain
> David McClain wrote:
> >
> > Courageous <jkra...@san.rr.com> wrote in message
> > news:390E4BA4...@san.rr.com...
> > > As it turns out, every single form in the above expression involves
> > > either dealing with a continuation or dealing with the scheduler.
> >
> > Since CL does not have first-class continuations just what exactly do
you
> > mean by this?
>
> section of the code. I was looking through some of the
> macro code today, and couldn't find the initial
> continuation generators. I've asked the author, however,
> and will get back to you.
>
>
> C/
Thanks, I am really very interested in this topic!
- DM
Courageous
Courageous
> > > Since CL does not have first-class continuations just what exactly do
> > > you mean by this?
> > Well, that's a good question since I didn't write that
> > section of the code. I was looking through some of the
> > macro code today, and couldn't find the initial
> > continuation generators. I've asked the author, however,
> > and will get back to you.
> Thanks, I am really very interested in this topic!
BTW, typing (apropos 'continuation) in my ACL interpreter
shows the presence of the construct and variations in
several packages, but not, of course, in common lisp.
Looking through the code, I could find no obvious package
prefixes on any of our continuation stuff. I was told
once that it was part of Scheme (by someone who quite
well could have been confused), and this, of course,
confused me even more, as we are compiling with ACL.
Is the SCM package in ACL a Scheme support package?
(I noted some continuation stuff in an SCM package,
but my ACL docs don't explain the package).
Anyway, I'm sure the author will get back with me in
a day or two. I'm very interested in this two.
BTW, there is a stack-free version of Python available
(http://www.stackless.com) which offers continuations,
coroutines, microthreads, etc. I'm still experimenting
with it.
C/
Barry Margolin
Courageous <jkra...@san.rr.com> wrote:
>BTW, typing (apropos 'continuation) in my ACL interpreter
>shows the presence of the construct and variations in
>several packages, but not, of course, in common lisp.
>Looking through the code, I could find no obvious package
>prefixes on any of our continuation stuff. I was told
>once that it was part of Scheme (by someone who quite
>well could have been confused), and this, of course,
>confused me even more, as we are compiling with ACL.
>Is the SCM package in ACL a Scheme support package?
>(I noted some continuation stuff in an SCM package,
>but my ACL docs don't explain the package).
Sometimes things that are referred to as "continuations" are not true
first-class continuations, they're just functional arguments.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Courageous
>
> In article <390F8F7C...@san.rr.com>,
> Courageous <jkra...@san.rr.com> wrote:
> >BTW, typing (apropos 'continuation) in my ACL interpreter
> >shows the presence of the construct and variations in
> >several packages, but not, of course, in common lisp.
> >Looking through the code, I could find no obvious package
> >prefixes on any of our continuation stuff. I was told
> >once that it was part of Scheme (by someone who quite
> >well could have been confused), and this, of course,
> >confused me even more, as we are compiling with ACL.
> >Is the SCM package in ACL a Scheme support package?
> >(I noted some continuation stuff in an SCM package,
> >but my ACL docs don't explain the package).
>
> Sometimes things that are referred to as "continuations" are not true
> first-class continuations, they're just functional arguments.
I was pondering how that might be in our current setting.
The thing is, when we type (sleep 30) -- which is not the
lisp sleep -- it kicks it back to the simulation shcheduler
such that the next line of lisp code isn't executed until
30 units of model time have passed. While I can imagine
something other than a first class continuation accounting
for this, lord would it be hairy.
C/
Barry Margolin
Courageous <jkra...@san.rr.com> wrote:
>Barry Margolin wrote:
>> Sometimes things that are referred to as "continuations" are not true
>> first-class continuations, they're just functional arguments.
>
>I was pondering how that might be in our current setting.
>The thing is, when we type (sleep 30) -- which is not the
>lisp sleep -- it kicks it back to the simulation shcheduler
>such that the next line of lisp code isn't executed until
>30 units of model time have passed. While I can imagine
>something other than a first class continuation accounting
>for this, lord would it be hairy.
Threads?
But I'm not sure how this is relevant to the question. I was responding to
someone who said they did (apropos 'continuation) and saw some matches.
All this means is that someone used the word "continuation" in the name of
a function or variable. Just because they use the word in a name, doesn't
mean they're actually implementing that concept.
In particular, many of Genera's macros are implemented like:
(defmacro with-open-file ((var &rest open-arguments) &body body)
`(with-open-file-internal #'(lambda (,var) ,@body) ,@open-arguments))
(defun with-open-file-internal (continuation &rest open-arguments)
(let (stream)
(unwind-protect
(progn
(setq stream (apply #'open open-arguments))
(funcall continuation stream))
(when stream
(close stream)))))
For whatever reason, they conventionally referred to the functional
arguments to these helper functions as continuations. But they're not what
we typically mean by continuations in computer science.
Courageous
> >I was pondering how that might be in our current setting.
> >The thing is, when we type (sleep 30) -- which is not the
> >lisp sleep -- it kicks it back to the simulation shcheduler
> >such that the next line of lisp code isn't executed until
> >30 units of model time have passed. While I can imagine
> >something other than a first class continuation accounting
> >for this, lord would it be hairy.
>
> Threads?
Possibly, albeit insufferably expensive if so. This requires
that the the thread go completely to sleep until a wakeback
occurs, right? Ergo, a simulation with 1000 entities would
require 1000 threads. Ouch.
Unless CL threads are microthreadish?
> But I'm not sure how this is relevant to the question. I was responding to
> someone who said they did (apropos 'continuation) and saw some matches.
> All this means is that someone used the word "continuation" in the name of
> a function or variable.
Oh, right. Yeah, I knew that. You can't really tell anything from
the apropos, this was just part of my hunt to determine where the
devil the stuff is coming from. The macro code in the SCORE language
definition is pretty hard to read, as I'm pretty new at lisp.
C/
Erik Naggum
| Is the SCM package in ACL a Scheme support package?
| (I noted some continuation stuff in an SCM package,
| but my ACL docs don't explain the package).
SCM seems to stand for Source Code Management. There is no
continuation stuff in it, and it has nothing to do with Scheme.
It is explained in the manual in source_file_recording.htm.
#:Erik
Erik Naggum
| Possibly, albeit insufferably expensive if so. This requires that
| the the thread go completely to sleep until a wakeback occurs,
| right? Ergo, a simulation with 1000 entities would require 1000
| threads. Ouch.
Why all this groundless _angst_ before you even know what they are?
Why make all these random guesses and scare yourself with with?
| Unless CL threads are microthreadish?
Read the manual, see how they work, talk to the vendor, heed their
advice, use something else if it doesn't work to your satisfaction.
The scheduler in Allegro CL doesn't seem to have any problems with
1000 threads. 1000 threads that are created only to run (sleep 10)
and terminate, allocate about 5M of memory and spend less than 1 s
CPU on my system. That doesn't seem to be worth any angst.
#:Erik
Pierre R. Mai
> > >I was pondering how that might be in our current setting.
> > >The thing is, when we type (sleep 30) -- which is not the
> > >lisp sleep -- it kicks it back to the simulation shcheduler
> > >such that the next line of lisp code isn't executed until
> > >30 units of model time have passed. While I can imagine
> > >something other than a first class continuation accounting
> > >for this, lord would it be hairy.
> >
> > Threads?
>
> Possibly, albeit insufferably expensive if so. This requires
> that the the thread go completely to sleep until a wakeback
> occurs, right? Ergo, a simulation with 1000 entities would
> require 1000 threads. Ouch.
>
> Unless CL threads are microthreadish?
Most CL implementations do their Lisp-side threading in user-land,
thereby gaining the advantage of very light-weight threads, and a
fairly cheap way of maintaining the usual CL semantics w.r.t. to
dynamic binding, etc.
Some implementations also allow foreign code to run in multiple
kernel-land threads, and some implementations are currently
experimenting with (or already supporting) kernel-land lisp threads.
While kernel-land threads allow a single process to take advantage of
multiple processors on SMP machines, this comes at a price, and so I'd
expect that even if future implementations will support kernel-land
threading, they'll continue to support user-land and possibly
multiplexed user-land threading.
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Courageous
> | Is the SCM package in ACL a Scheme support package?
> | (I noted some continuation stuff in an SCM package,
> | but my ACL docs don't explain the package).
>
> SCM seems to stand for Source Code Management. There is no
> continuation stuff in it, and it has nothing to do with Scheme.
> It is explained in the manual in source_file_recording.htm.
You know, we own licenses for ACL, but not much documentation
seems to exist. How criticical are the ACL manuals themselves,
and how extensive are they? (yes, I have all the .html, is that
the whole shebang?)
C/
Erik Naggum
| You know, we own licenses for ACL, but not much documentation seems
| to exist. How criticical are the ACL manuals themselves, and how
| extensive are they? (yes, I have all the .html, is that the whole
| shebang?)
Well, the manuals are quite extensive once you sit down with them.
However, I'm not too thrilled about the HTML delivery because of the
unsolved navigation problem in the WWW incarnation of hypertext (it
had been solved prior to the WWW, of course; HTML is the MS-DOS of
hypertext). I have asked (begged) for PDF files so I can at least
have something that reads better than the HTML delivery and which
also prints better than the HTML files come out like from the sucky
browsers. Franz Inc have indicated they will accomodate some of my
wishes for the ACL 6.0 release. Until then, the ACL 4.3 manuals are
still in use, simply because they are printed and bound.
#:Erik
Russell Wallace
> Well, the manuals are quite extensive once you sit down with them.
> However, I'm not too thrilled about the HTML delivery because of the
> unsolved navigation problem in the WWW incarnation of hypertext (it
> had been solved prior to the WWW, of course; HTML is the MS-DOS of
> hypertext).
I'm curious: what do you see as the navigation problem to which HTML
missed the solution?
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
Erik Naggum
| I'm curious: what do you see as the navigation problem to which HTML
| missed the solution?
The ability of one document to introduce a link between two other
documents, sometimes known as a "meta-link". Where implemented,
they are easily used to track how you arrived at a given document,
and thus you can browse your "journey" through a number of
documents. This particular "application" can be implemented by many
other means, but the general facility that would make it simple and
easy is missing from HTML.
I think of HTML links as GOTO. The effort required to keep from
getting messy outweights the merits of their proper use.
(The even-more-impenetrable-than-the-SGML-standard SGML-related
standard on Hypertext and Timeน, actually got this completely right,
incorporating all available hypertext research at the time it was
published, and subsequently updated intelligently to account for
further development. Unfortunately, it uses SGML for its own
meta-notation, which makes it an order of magnitude more complex
than necessary, and it relies so heavily on the entity structure,
which is the least understood aspect of SGML and also completely
missed by "the HTML generation", that it takes more effort to study
it than even most would-be experts can ever hope to be rewarded for
having done.)
#:Erik
-------
น ISO/IEC 10744:1997 Information technology -- Hypermedia/Time-based
Structuring Language (HyTime), 468 pages.
Erann Gat
> * Russell Wallace <rwal...@esatclear.ie>
> | I'm curious: what do you see as the navigation problem to which HTML
> | missed the solution?
>
> The ability of one document to introduce a link between two other
> documents, sometimes known as a "meta-link". Where implemented,
> they are easily used to track how you arrived at a given document,
> and thus you can browse your "journey" through a number of
> documents. This particular "application" can be implemented by many
> other means, but the general facility that would make it simple and
> easy is missing from HTML.
Can you give an example? I presume that a browser history is an example
of "this particular application" being "implemented by ... other means"
but I don't see how having bidirectional links in HTML would add any
functionality.
Erann Gat
g...@jpl.nasa.gov
Bulent Murtezaoglu
[very OT on cll, sorry]
I actually posted rant as a bug to sourceforge on this. I prefer info,
docbook, pdf, and even ps over html.
TB> Actually I
TB> would *really like* paper manuals as printing and binding is a
TB> pain even with a souped up double-sided printer which we don't
TB> currently have.
Double-sided printing and spiral binding facility can be acquired for about
$700-800 if you shop around (this is what it cost me for all new equipment
thru auctions and such). This is not much since you're likely to spend
around $500 anyway on a decent 10+ ppm laser printer with postscript.
This will only help you if the vendor provides something that produces
reasonable hard copy. I detest printing html.
BM
Erik Naggum
| I presume that a browser history is an example of "this particular
| application" being "implemented by ... other means" but I don't see
| how having bidirectional links in HTML would add any functionality.
The idea is not a "bidirectional links", but the bibliographic
reference, which was a quite well developed concept prior to HTML.
I wrote: "The ability of one document to introduce a link between
two other documents'. This is not a bidrectional link in the first
place. It's a third-party link if you want. There is no anchor
marked up as such in either of the documents involved, and the link
is certainly not in the documents in question. Instead, the anchors
are described in the third document through various means of naming
nested objects and the link between them is then established, with a
purpose, such as a comment describing how the two anchor points
related.
HTML missed the opportunity (to put it mildly) to aid in locating
and naming the structured, nested objects in a document, as well, so
it's no wonder people can't really escape thinking about links and
anchors _in_ the documents without spending some effort thinking
about why it doesn't even make sense to predefine which words or
ranges of text should be elevated to anchorhood. After all, most of
prefer to buy the marker pens separately from the books and color on
our own, but with HTML, only pre-colored books are available.
#:Erik
Tim Bradshaw
> Can you give an example? I presume that a browser history is an example
> of "this particular application" being "implemented by ... other means"
> but I don't see how having bidirectional links in HTML would add any
> functionality.
Well, it certainly wouldn't be hard to add more functionality than any
browser I've ever used! (which I admit is basically just various
incarnations of netscape and ie (as well I guess as mosaic and chimera
in the old days)) I find the forward and back buttons terminally
deficient, and the history facilities pretty much so (IE's seems
better than netscapes). Where is the obvious graphical representation
of your browsing history?
(Actually, does anyone know how hard it would be to get netscape to
tell some external program every time it visited a url?)
--tim
Tim Bradshaw
> I have asked (begged) for PDF files so I can at least
> have something that reads better than the HTML delivery and which
> also prints better than the HTML files come out like from the sucky
> browsers. Franz Inc have indicated they will accomodate some of my
> wishes for the ACL 6.0 release. Until then, the ACL 4.3 manuals are
> still in use, simply because they are printed and bound.
Because I think Franz people read this, I'll add a `me too' to this,
even though they probably already know. Actually I would *really
like* paper manuals as printing and binding is a pain even with a
souped up double-sided printer which we don't currently have. I would
pay for these in fact.
--tim
Tim Bradshaw
> This will only help you if the vendor provides something that produces
> reasonable hard copy. I detest printing html.
This is even more offtopic...
I haven't actually tried it on Franz's documentation but there's a
wonderful program called html2ps which can do really quite a
reasonable job with a lot of HTML -- certainly enormously better than
Netscape and so on.
Actually it's a seriously horrible perl script, but it does work very
well, if slowly. (Except when new perl releases randomly break some
obscure part of perl requiring deeply obscure fixes. But that's perl
for you: a language defined by its single implementation which somehow
manages to have the kind of obscure compatibility problems I somehow
never see when porting between 3 CL systems on 3 OSs.)
--tim
Espen Vestre
> This is even more offtopic...
>
> I haven't actually tried it on Franz's documentation but there's a
> wonderful program called html2ps which can do really quite a
> reasonable job with a lot of HTML -- certainly enormously better than
> Netscape and so on.
I have, happy as clam, returned to LaTeX again for documentation.
With pdflatex which comes readily installed with the latest teTeX
(starting with version 1.0, I think) package, I deliver all the
pretty-looking documentation in PDF (in fact, I have completely
stopped creatin DVI, everything is compiled to PDF), and I publish
them on my own internal webserver in HTML, which is easily generated
from the LaTeX source with hyperlatex
(http://www.cs.ust.hk/~otfried/Hyperlatex/).
(I'm also considering using pdflatex as a means from auto-generating
reports and documentation from lisp programs, why wait for XML-
based tools to arrive when you can use the power of TeX?)
--
(espen)
Rudolf Schlatte
[...]
> (I'm also considering using pdflatex as a means from auto-generating
> reports and documentation from lisp programs, why wait for XML-
> based tools to arrive when you can use the power of TeX?)
You too?
Some time ago, I auto-generated huge amounts of useless documentation
doing something like:
(defun make-headers-document (infile outfile find-fn print-fn)
(with-open-file (instream infile)
(ltx:with-latex-document
(:output outfile :packages '(("babel" ("german"))
("inputenc" ("latin1"))
("fontenc" ("T1"))
("hyperlatex"))
:title (concatenate 'string "File: " infile)
:author "Rudi Schlatte")
(while-bind (next-block (funcall find-fn instream))
(funcall print-fn next-block)))))
find-fn snarfs a block of code (procedure or whatever), print-fn
semi-parses it and prints whatever it sees fit.
It is really a pleasure to see twenty-odd page documents of boring
documentation being churned out by a program instead of by myself...
I even made up some sort of markup for the comments in the source,
giving me a crude kind of literate programming. Perhaps I will play
with cross-indices a bit, then the documentation will be better than
written by hand (and always semi-accurate to boot).
I'm enclosing the Latex package; note that it is not very refined
since it was hacked together late one night; these are just the
building blocks. I will have some time and motivation to enhance it a
bit during the next month, though. Comments, Critique & Code welcome.
;;; -*- Lisp -*-
;;; Bare-bones Latex output from Common Lisp.
;;; Written by Rudi Schlatte <rsch...@ist.tu-graz.ac.at>
;;; Use it as you please.
;;; Issues:
;;; No math mode (did not need it for what this was written for)
;;; Almost no useful commands (there will be things like
;;; (section "The section title" :toc-entry "sec-title" :label "foo" ...)
;;; at some point in the future.
(defpackage "LATEX-GEN" (:nicknames "LTX") (:use "COMMON-LISP")
(:export "WITH-LATEX-DOCUMENT" "LATEX-COMMAND-0" "LATEX-COMMAND-1"
"WITH-LATEX-ENVIRONMENT" "OUTPUT" "LF" "PAR" "ESCAPE-CHARACTERS"))
(in-package "LATEX-GEN")
(defvar *latex-stream* cl:*standard-output*
"All Latex output goes here. Bound by with-latex-document macro.")
(defmacro while (test &body body)
`(loop (unless ,test (return))
,@body))
(defun output (control-string &rest arglist)
"Output to *latex-stream* as per format."
(apply #'format *latex-stream* control-string arglist))
(defun lf ()
"Latex linefeed."
(output "~&"))
(defun par ()
"Latex paragraph (empty line)."
(output "~&~%"))
(defun escape-characters (string
&optional (the-chars "$&%#_{}") (escape-char #\\))
(with-output-to-string (result-string)
(loop for char across string
when (find char the-chars :test #'char=)
do (write-char escape-char result-string)
do (write-char char result-string))
result-string))
(defun latex-option-list (string-list)
(format nil "~@[[~{~A~^,~}]~]" string-list))
(defun print-header (class option-list package-list title author date)
"Prints the LaTeX document preamble.
class: document class name.
option-list: list of document class options.
package-list: list with (package-to-use [(option-list)]) entries.
title: document title.
If nil, none of \\title, \\author, \\date will be printed.
author: document author
date: creation date. if nil, \\date will not be printed."
(output "\\documentclass~A{~A}~%"
(latex-option-list option-list) class)
(output
;; This is hairy; package name comes before list of options
;; but gets printed afterwards; also options can be non-existent,
;; so I test before jumping around in the arglist
"~@[~{~{\\usepackage~*~#[~;[~{~A~^,~}]~]{~@*~A}~%~#[~;~*~]~}~}~]~%~%"
package-list)
(when title
(latex-command-1 "title" title) (lf)
(latex-command-1 "author" author) (lf)
(when date
(latex-command-1 "date" date) (lf))
(par)))
(defmacro with-latex-environment ((name &optional option-list) &body body)
`(progn
(output ,(concatenate 'string "~&\\begin"
(latex-option-list option-list) "{" name "}~%"))
,@body
(output ,(concatenate 'string "~&\\end{" name "}~%"))))
(defun latex-command-0 (name)
"Output Latex command \"name\" (no arguments)"
(output "\\~A" name))
(defun latex-command-1 (name contents)
"Output Latex Command \"name\" (one mandatory argument)"
;; FIXME: We sanitize the contents string here, escaping LaTeX
;; special characters. This may not be the right thing for some
;; commands. Eventually, there will be (section "Foo") & Cie. and
;; they will take care of their arguments themselves.
(output "\\~A{~A}" name (escape-characters contents)))
(defmacro with-latex-document ((&key (output *standard-output*)
(class "article")
(options nil)
(packages nil)
(title nil)
(author "")
(date nil))
&rest body)
`(ctypecase ,output
(string (with-open-file (*latex-stream* ,output
:direction :output)
(print-header ,class ,options
,packages ,title
,author ,date)
(with-latex-environment ("document")
(when ,title
(latex-command-0 "maketitle") (par))
,@body)))
(stream (let ((*latex-stream* ,output))
(print-header ,class ,options ,packages ,title
,author ,date)
(with-latex-environment ("document")
(when ,title
(latex-command-0 "maketitle") (par))
,@body)))))
Paolo Amoroso
wrote:
> I'm curious: what do you see as the navigation problem to which HTML
> missed the solution?
You may check the site of user interface and usability expert Jakob
Nielsen:
There are documents--be sure to peek around, I don't have the URLs
handy--where he states something along the lines that current Web
technology offers stone age tools compared to early hypertext research.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso
> browser I've ever used! (which I admit is basically just various
> incarnations of netscape and ie (as well I guess as mosaic and chimera
> in the old days)) I find the forward and back buttons terminally
If you have a Unix box handy, have a look at Lynx: you'll love it :)
Kragen Sitaker
>(Actually, does anyone know how hard it would be to get netscape to
>tell some external program every time it visited a url?)
X11 Netscape has a window property _MOZILLA_URL that tells you what URL
it's at, and has at least since version 2.0. I seem to recall that,
with Xlib, you can use PropertyChangeMask to be notified when a window
property changes with XPropertyEvents, and I think you can then use
XGetTextProperty to get the URL.
I think you can use SubstructureNotifyMask on the root window to be
notified when new windows pop up.
Obviously there are race conditions all over the place here --- a new
Netscape window can visit several URLs before you manage to select
PropertyChangeMask on it, and the property could change several times
between when you handle the XPropertyEvent and when you manage to
XGetTextProperty.
ObLisp: Does anyone use CLX? Does it suck as badly as Xlib?
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
Erann Gat
> * g...@jpl.nasa.gov (Erann Gat)
> | I presume that a browser history is an example of "this particular
> | application" being "implemented by ... other means" but I don't see
> | how having bidirectional links in HTML would add any functionality.
>
> The idea is not a "bidirectional links", but the bibliographic
> reference, which was a quite well developed concept prior to HTML.
Seems to me that bibliographic references have precisely the semantics
of hyperlinks. They are pointers contained in one document that point
to a second document. There is no third document involved.
> I wrote: "The ability of one document to introduce a link between
> two other documents'. This is not a bidrectional link in the first
> place. It's a third-party link if you want. There is no anchor
> marked up as such in either of the documents involved, and the link
> is certainly not in the documents in question. Instead, the anchors
> are described in the third document through various means of naming
> nested objects and the link between them is then established, with a
> purpose, such as a comment describing how the two anchor points
> related.
OK, third-part link then. I still don't see what you would *do*
with such a link that you can't do using HTML as it stands.
Here are two related documents, A and B:
"This is document A, a short treatise on the topology of mazes of
twisty little passages, all alike."
"This is document B, a rather more lengthy exposition on the topology
of mazes of twisty little passages, all different."
Neither document A or B contain any links.
Now I write document C which contains one of your third-party links:
"This is document C, a meta-analysis of maze topology studies
...
<THIRD-PARTY-LINK HREF1=document-A HREF2=document-B>
..."
What happens? How does this link get rendered? What happens when you
click on it?
E.
Lars Syrstad
> Now I write document C which contains one of your third-party links:
>
> "This is document C, a meta-analysis of maze topology studies
> ...
> <THIRD-PARTY-LINK HREF1=document-A HREF2=document-B>
> ..."
>
> What happens? How does this link get rendered? What happens when you
> click on it?
I think what Erik is talking about is a mechanism that lets a
third-party document refer to individual portions of other documents,
without the need to add anchors at the relevant places in those other
documents. Assume that I want to create a tutorial of some
programming language. I could write my little thing, adding lots of
links pointing to select portions of other sources -- official
documentation, standards, FAQs, etc -- with no need for anchors in
those other documents at the places to which I wish to refer. Think
of it as me creating a path through the documents of others to suit me
and my audience. And to do this, we need something more than HTML.
(And when I click on any of those links in my document, it may just
show that select portion of that other document. And another click
may show the entire document. Or I may simply ask my browser to
inline the select portion of the other text into my document,
effectively creating quotes.)
Or maybe Erik isn't talking about that at all, but I still would like
it...
- Lars.
--
There's something I don't like
About a band that always smiles
-- Dead Kennedys
Rob Warnock
+---------------
| (Actually, does anyone know how hard it would be to get netscape to
| tell some external program every time it visited a url?)
Phil Karn at Qualcomm (whom some of you old-timers may remember as
being "KA9Q" and the author of the "NOS" TCP/IP suite for a DOS PC)
has written a neat little hack that may do what you want:
<URL:http://people.qualcomm.com/karn/code/httproute/>
This package contains a daemon, written as a Perl script plus
configuration file, that provides a simple HTTP router, banner
advertisement blanker, cache and cookie cutter. You configure
your web browser to use it as a web proxy.
-Rob
p.s. I've been intending to rewrite it in Scheme, but haven't gotten
around to it yet...
-----
Rob Warnock, 41L-955 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
Rainer Joswig
(Rob Warnock) wrote:
Well, you can also use CL-HTTP as a proxy. This is an example
to get rid of unwanted ads:
(in-package :http)
(defparameter *default-image*
(url:url "http://www.ision.net/i/start/logo.gif"))
(defparameter *unwanted-hosts*
'("ad.doubleclick.net" "adserv.spiegel.de" "m.doubleclick.net"))
(defparameter *unwanted-url-strings*
'("werb" "anzei" "banners" "ads" "pic"))
(defmethod invoke-proxy-service :around ((server proxy-server-mixin)
uri
(method (eql :get))
request-http-version)
(let ((path (url:path uri)))
(when (or (member (url:host-string uri)
*unwanted-hosts*
:test #'string-equal)
(some (lambda (unwanted-string)
(some (lambda (uri-part)
(search unwanted-string uri-part))
path))
*unwanted-url-strings*))
(setf (server-url server) *default-image*
uri *default-image*))
(call-next-method server uri method request-http-version)))
Erik Naggum
| Seems to me that bibliographic references have precisely the semantics
| of hyperlinks.
Yes, this is actually true.
| They are pointers contained in one document that point to a second
| document. There is no third document involved.
This is obviously false, however.
| OK, third-part link then. I still don't see what you would *do*
| with such a link that you can't do using HTML as it stands.
That's frankly not my problem, and you're not listening enough that
I care to spend all the time it would take to explain it to you.
| What happens? How does this link get rendered? What happens when
| you click on it?
Sigh. How do the "links" you already have in HTML get rendered?
What happens when you "click" on them? What, exactly, do you expect
to be _different_?
I don't have the patience for this. Sorry.
#:Erik
Paolo Amoroso
> even though they probably already know. Actually I would *really
> like* paper manuals as printing and binding is a pain even with a
> souped up double-sided printer which we don't currently have. I would
An interesting opinion in favor of printed documentation is that of Bruce
Tognazzini (he was Apple's "user interface evangelist" for several years):
How to Publish a Great User Manual
http://www.asktog.com/columns/017ManualWriting.html
Andrew Cooke
Lars Syrstad <la...@tihlde.hist.no> wrote:
> I think what Erik is talking about is a mechanism that lets a
> third-party document refer to individual portions of other documents,
> without the need to add anchors at the relevant places in those other
> documents. Assume that I want to create a tutorial of some
> programming language. I could write my little thing, adding lots of
> links pointing to select portions of other sources -- official
> documentation, standards, FAQs, etc -- with no need for anchors in
> those other documents at the places to which I wish to refer. Think
> of it as me creating a path through the documents of others to suit me
> and my audience. And to do this, we need something more than HTML.
there is (was?) software that lets you put "public" annotations on other
pages - i guess it works by providing a proxy that checks a central
"post-it" server as it downloads the requested document. this isn't what
anyone has been discussing, exactly, but it could be persuaded/extended
to provide similar functionality (everyone would have to use the proxy
and server, it's not exactly scaleable...)
however, i can't remember the name or where i heard about it. and
anyway, i suspect hardly any pages have comments, and those that do
will be drivel. perhaps it has some kind of community concept - so
perhaps a c.l.l community would share annotations. or erik could have
his own (private write, public read) (which gets nearer what i think he
wanted, but in a horrible round-about way).
andrew
http://www.andrewcooke.free-online.co.uk/index.html
Sent via Deja.com http://www.deja.com/
Before you buy.
Erann Gat
> I don't have the patience for this. Sorry.
That's good, because my patience for you is also wearing quite thin.
Why don't you do us both a favor and stop responding to my questions?
Let someone else do it.
> * Erann Gat
> | Seems to me that bibliographic references have precisely the semantics
> | of hyperlinks.
>
> Yes, this is actually true.
>
> | They are pointers contained in one document that point to a second
> | document. There is no third document involved.
>
> This is obviously false, however.
Why is this obviously false? This is a question directed to anyone
in the group *except* Erik (whose patience I do not wish to try any
further). If it's so obvious then surely there will be dozens
of people out there who know.
E.
Espen Vestre
> Why is this obviously false? This is a question directed to anyone
> in the group *except* Erik (whose patience I do not wish to try any
> further). If it's so obvious then surely there will be dozens
> of people out there who know.
Yes, I was puzzled by this too. The only thing I could think of
was the fact that bibliographic references may refer to a section
or page range of a second document and not only a _point_ in it.
--
(espen)
Erik Naggum
| Why don't you do us both a favor and stop responding to my questions?
Because you ask me questions. It's called cause and effect.
| Why is this obviously false?
Ask librarians, not programmers, if you want to know about
bibliographic references.
Now go away and don't destroy the rest of this discussion with your
attitude problems. Let somewone else ask the questions.
#:Erik
Philip Lijnzaad
Andrew> there is (was?) software that lets you put "public" annotations on other
Andrew> pages
Well, the old Mosaic had this thing but only for private annotations. Kind-a
useful (all the more if the underlying pages just would stay where they are
;-)
As for public annotation, I know it has been tried in the domain of
biological databases (the now defunct gdb had something like this, and
swissprot has something similar). In all these cases, it only worked
properly if you know the annotators were any good.
Philip
--
/dev/brain: character special (53/0)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Jochen Schneider
> there is (was?) software that lets you put "public" annotations on other
> pages - i guess it works by providing a proxy that checks a central
> "post-it" server as it downloads the requested document. this isn't what
> anyone has been discussing, exactly, but it could be persuaded/extended
> to provide similar functionality (everyone would have to use the proxy
> and server, it's not exactly scaleable...)
>
http://crit.org does this. Seems to be kind of slow, though.
Jochen
--
C++ : an octopus made by nailing extra legs onto a dog
Erik Naggum
| Yes, I was puzzled by this too. The only thing I could think of
| was the fact that bibliographic references may refer to a section
| or page range of a second document and not only a _point_ in it.
Please ignore HTML and the WWW in any discussion of hypertext. They
are like bringing PostScript and laser printers into a discussion of
literature.
There is no worse implementation of hypertext concepts than the
in-band anchors that requires changing both (there are only two in
HTML) documents if you need a particular connection. In fact, the
HTML/WWW implementation of "hypertext" is so fundamentally flawed
that it is probably a great disservice to hypertext to call it
"hypertext" to begin with, and as witness, the inability of people
to consider a bibliographic references that does not match the HTML
_implementation_.
Consider the glossary that defines hypertext links _to_ its defined
terms. Instead of myriad explicit links in each document in the
document set covered by the glossary, the links may be defined as
whatever matches a rule in those documents. A rendering engine
would load the glossary and apply the rules to highlight glossary
terms, or perhaps make them more accessible by popping up a small
window with the definition. Instead of this being coded explicitly
wherever a glossary term is used, it would all be arranged in the
glossary, once.
Consider the root document of a document set that contains rules for
which documents (such as the glossary) whose rules should apply to
which documents in the set. Conventional bibliographic references
expresses such relationships with annotations in the library records.
Note that there is no unique text to highlight or click on in this
case. This is meta-information for the hypertext system.
Consider the critique of a document that includes excerpts from it
and does so using in-lined hypertext links instead of copies of the
text itself. Consider the meta-critique that contains a full list
of all such references for the purposes of scholarly research and
ratings. The former would not necessarily be able to influence the
base document when somebody reads it, such as to inform the reader
adbout the critique, but the latter would, as well as responses and
rejoinders in a debate where various authors both discuss the type
of critique and rate them.
Consider the continuous publication of a medical journal where it is
incredibly important to link from articles in the past to new and
updated articles in the future with crucial information about the
role of the update. A new article would typically contain a small
passage that it updates, contradicts, etc, previous articles. It is
not uncommon for the journal librarian/editor to supply such links
in a separate bibliographic unit, such as a side-bar. A mechanized
hypertext system would represent such links with meta-documents that
_all_ the articles in the system would point to for updates to
themselves.
Consider the continuous application and concurrent drafting of laws
and regulations in a society. The entire legal world is intertwined
in extremely interesting ways from a theoretical hypertext point of
view. Political discussions often take the form of contributing to
a decision on what may be done within the framework of certain
regulations, such as budgets, legal authorities and procedures, etc.
Counter-arguments frequently attack the hypertextual nature of the
argument instead of the textual contents in the shape of denying or
rejecting an interpretation of such authority or its application.
Court arguments frequently involve comparing prior applications and
cases to present cases. Yet, each document produced contains only a
small number of the hypertextual links involved: the remainder are
implicit or take the shape of "to"-links instead of "from"-links.
In the world of bibliographic references, there is a lot more going
on than just pointing to books or pages, or a footnote someplace
that has an ISBN. Trivializing the bibliographic reference to
whatever HTML can represent is like arguing that PostScript cannot
represent irony, so therefore it is only characters, like all other
characters, or denying that laser printers can reason because they
produce documents that contain reasoning. (Nobody argues that laser
printers can reason, just as nobody argues that hypertext links can
be "discovered" from context and contents, which is a strawman
argument frequently used against advanced hypertext theory.)
For those who want to understand how hypertext started, I urge you
to read Vannevar Bush's original article in the Atlantic Monthly.
In particular, he discusses machine-aided annotations in a way that
would make it impossible for anyone who had read that article to
even think that hypertext links were contained _in_ documents --
that is merely an implementation optimization applicable in a few
circumstances and not at all generally. Generally, we make links
into, between, and out of read-only documents that we do not own or
control. HTML does not allow us to work with documents we do not
own or control except by pointing at them as static objects.
#:Erik
Espen Vestre
> In the world of bibliographic references, there is a lot more going
> on than just pointing to books or pages, or a footnote someplace
> that has an ISBN.
ok, I was thinking in terms of old-fashioned bibliographic references
printed on dead trees (disregarding any software which might be
involved in producing it), which basically is a simple one-way pointer
which involves only two documents (and which has its flaws too: we all
know from school how section and page number references to a textbook
become invalid when a new version of it is out...)
--
(espen)
Erik Naggum
| ok, I was thinking in terms of old-fashioned bibliographic
| references printed on dead trees (disregarding any software which
| might be involved in producing it), which basically is a simple
This is unfortunately a very misguided view of the old-fashioned
bibliographic reference. I'm sorry to say so, but the bibliographic
reference includes a lot more than one-way "pointers", which is a
special case or a narrow view, depending on how you look at it. If,
for instance, I wish to compare CLtL2 with CLtS (S for Standard),
you can either regard my two bibliographic references in any given
comparison on a given point as two one-way pointers from my document
into those two documents, but that is very nearly irrelevant to the
purpose and actual references involved. A reader of a comparison
would naturally want to have both text available and would have to
regard my commentary on their _relationship_ as the real purpose of
my text. My document thus contains third-party hypertext links (and
bibliographic references) with that purpose between two other
documents.
This may not be all that obvious to a reader of modern literature,
but pick up any commentary on religious writings and track down the
references to the Bible, say. This is a lot more explicit than the
intertwined legal world I referred to, but it also less available to
most people today. (I wouldn't know about it all were it not for
the many people who use SGML and HyTime for dealing with the rich
set of references in precisely such literature.)
On the other hand, what you refer to as "old-fashioned" may be a
trivialization of the bibliographic reference into the _expression_
of a bibliographic reference that follows certain formal rules. The
fact that there is an enormous number of ways to express a reference
(such that actually locating the document that has been referred to
may be very, very difficult), should not obscure the more abstract
concept. Instead, I'd hope that the plethora of ways to refer to
texts should communicate the failure of trivializations to capture
the author's (or indexer's or librarian's) purpose and intent.
#:Erik
Will Hartung
Erik Naggum wrote in message <31668560...@naggum.no>...
> For those who want to understand how hypertext started, I urge you
> to read Vannevar Bush's original article in the Atlantic Monthly.
> In particular, he discusses machine-aided annotations in a way that
> would make it impossible for anyone who had read that article to
> even think that hypertext links were contained _in_ documents --
> that is merely an implementation optimization applicable in a few
> circumstances and not at all generally. Generally, we make links
> into, between, and out of read-only documents that we do not own or
> control. HTML does not allow us to work with documents we do not
> own or control except by pointing at them as static objects.
For those interested...
http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm
Will
Pierre R. Mai
> Erik Naggum wrote in message <31668560...@naggum.no>...
> > For those who want to understand how hypertext started, I urge you
> > to read Vannevar Bush's original article in the Atlantic Monthly.
> > In particular, he discusses machine-aided annotations in a way that
> > would make it impossible for anyone who had read that article to
> > even think that hypertext links were contained _in_ documents --
> > that is merely an implementation optimization applicable in a few
> > circumstances and not at all generally. Generally, we make links
> > into, between, and out of read-only documents that we do not own or
> > control. HTML does not allow us to work with documents we do not
> > own or control except by pointing at them as static objects.
>
>
> For those interested...
>
> http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm
Another very informative source of concepts, ideas, and implementation
of a "more advanced" (this should in fact be "less retarted")
Hypertext system is the already mentioned HyTime standard (ISO/IEC
10744), as well as numerous documents, articles and books surrounding
it. A good starting point for explorations of HyTime is
Regs, Pierre.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Erann Gat
> * Erann Gat
> | Why don't you do us both a favor and stop responding to my questions?
>
> Because you ask me questions. It's called cause and effect.
You could choose not to answer. It's called free will.
But, Erik, I am actually not asking you questions. I am asking the
*group* questions (actually only one question). If you don't want to
answer, that's fine. Don't. There's no need to announce your personal
desires to the world.
> | Why is this obviously false?
>
> Ask librarians, not programmers, if you want to know about
> bibliographic references.
>
> Now go away and don't destroy the rest of this discussion with your
> attitude problems. Let somewone else ask the questions.
Librarians and programmers are not mututally exclusive groups.
I happen to personally know at least one person with a degree in
library science who reads this newsgroup, and for all either one of
us knows there are many more. So, Erik Naggum, if you wish not to
answer my question, just be quiet and let someone else do it.
E.
Erann Gat
> Consider the glossary that defines hypertext links _to_ its defined
> terms. Instead of myriad explicit links in each document in the
> document set covered by the glossary, the links may be defined as
> whatever matches a rule in those documents. A rendering engine
> would load the glossary and apply the rules to highlight glossary
> terms, or perhaps make them more accessible by popping up a small
> window with the definition. Instead of this being coded explicitly
> wherever a glossary term is used, it would all be arranged in the
> glossary, once.
...
> HTML does not allow us to work with documents we do not
> own or control except by pointing at them as static objects.
Not true. For a simple counterexample see Google's "show matches"
feature, which renders HTML documents with (dynamically selected)
glossary terms highlighted.
E.
Russell Wallace
>
> On Thu, 04 May 2000 18:40:40 +0100, Russell Wallace <rwal...@esatclear.ie>
> wrote:
>
> > I'm curious: what do you see as the navigation problem to which HTML
> > missed the solution?
>
> You may check the site of user interface and usability expert Jakob
> Nielsen:
>
> http://www.useit.com/
>
> There are documents--be sure to peek around, I don't have the URLs
> handy--where he states something along the lines that current Web
> technology offers stone age tools compared to early hypertext research.
Looks interesting! I've bookmarked it, will take a detailed rummage
through it later. Thanks.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
Erik Naggum
| Not true. For a simple counterexample see Google's "show matches"
| feature, which renders HTML documents with (dynamically selected)
| glossary terms highlighted.
PostScript can also represent irony. _Please_ get the point.
#:Erik
Erik Naggum
| There's no need to announce your personal desires to the world.
Gee, that's really good advice. I wonder if it works on you.
| Librarians and programmers are not mututally exclusive groups.
Nobody has said they were. Tell me, _are_ you a strawman, or do you
just play one on the Net?
| So, Erik Naggum, if you wish not to answer my question, just be
| quiet and let someone else do it.
There's no need to announce your personal desires to the world.
So, Erann Gat, why are you so desperately picking a fight?
Out of free will today?
#:Erik
Erann Gat
> | Librarians and programmers are not mututally exclusive groups.
>
> Nobody has said they were.
Not in so many words, no. But you admonished me as follows:
> Ask librarians, not programmers, if you want to know about
> bibliographic references.
From this admonition I infered that you thought that I was asking
this question of programmers and not librarians (else why the admonition?).
But this is not the case. There are librarians here. For all I
knew *you* could have been a librarian. (For all you know, *I*
am a librarian.)
Actually, that's an interesting point. Erik, are you a librarian?
If you are, why didn't you just answer my question? And if you aren't,
why should anyone listen to what you have to say on the subject of
bibliographic references?
> So, Erann Gat, why are you so desperately picking a fight?
I am not trying to pick a fight. I am trying to ask a question, to wit:
>| Seems to me that bibliographic references have precisely the semantics
>| of hyperlinks.
>
> Yes, this is actually true.
>
>| They are pointers contained in one document that point to a second
>| document. There is no third document involved.
>
> This is obviously false, however.
My question: why is it obviously false? This question is directed
at anyone who wishes to answer it. Those who do not care to answer
are kindly requested to keep that desire to themselves.
Erann Gat
g...@jpl.nasa.gov
Erann Gat
> * Erann Gat
> | Not true. For a simple counterexample see Google's "show matches"
> | feature, which renders HTML documents with (dynamically selected)
> | glossary terms highlighted.
>
> PostScript can also represent irony.
OK. So?
> _Please_ get the point.
That is precisely what I am trying to do. (Actually, at this point
I am trying to figure out if there actually *is* a point to be gotten.
I am beginning to have my doubts.)
In any case, it is clear that I am not going to get the point from
your explanations. So, Erik, be quiet, and if there is anyone out
there who thinks they understand what Erik is trying to say and thinks
they can explain it to me (and is willing to try) please do. Otherwise
let's drop this.
E.
Andrew McDowell
You might try poking around there.
Andrew Cooke <and...@andrewcooke.free-online.co.uk> wrote:
> there is (was?) software that lets you put "public" annotations on other
> pages ...
<snip>
Rahul Jain
9, 2000 12:32 PM, g...@jpl.nasa.gov (Erann Gat) wrote:
> In article <31668560...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>
>> HTML does not allow us to work with documents we do not
>> own or control except by pointing at them as static objects.
>
> feature, which renders HTML documents with (dynamically selected)
> glossary terms highlighted.
So you're saying the code to modify the pages that way is in HTML?
I think not.
I could do the same in RTF if I wanted to.
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- mailto:rahul...@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Erik Naggum
| In any case, it is clear that I am not going to get the point from
| your explanations.
Good, we agree on something, but it is obviously because you don't
read anything I write, anyway, except what you can take potshots at.
| So, Erik, be quiet
So, Mr. Gat, what would it take for you to realize what you're doing?
You started to ask really annoying questions with so much silliness
built into them there was no way you could be satisfied unless you
could "win" an idiotic fight, which you have tried ever since, and
you proceeded to get even more personal than the last time you had
diarrhea in public. Can you _please_ get over whatever it is your
_real_ problem is? Feel free to drop this any time, but leave me
out of it. This is your personal need for something distasteful,
whatever it is; it has _nothing_ to do with me or hypertext or Lisp
or anything else. If you don't have something worthwhile to say,
don't pretend it's my fault.
#:Erik
thi
> In any case, it is clear that I am not going to get the point from
> your explanations. So, Erik, be quiet, and if there is anyone out
> there who thinks they understand what Erik is trying to say and thinks
> they can explain it to me (and is willing to try) please do. Otherwise
> let's drop this.
google's rendering requires creation of a new chunk of output html based
(presumably) on the cached version of the input html. when erik naggum
says "HTML does not allow us to work with documents we do not own or
control except by pointing at them as static objects", the phrase "work
with" can be considered "work with directly". indirection here is not
valued highly because of the danger of version skew. google-rendered
pages warn of this, too.
thi
Christopher Browne
>In article <31668865...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>> * Erann Gat
>> | Not true. For a simple counterexample see Google's "show matches"
>> | feature, which renders HTML documents with (dynamically selected)
>> | glossary terms highlighted.
>>
>
>OK. So?
>
>> _Please_ get the point.
>
>That is precisely what I am trying to do. (Actually, at this point
>I am trying to figure out if there actually *is* a point to be gotten.
>I am beginning to have my doubts.)
The point is that you aren't seeing the difference between "static"
and "dynamic."
HTML is inherently a _STATIC_ language. That is, in fact,
more-or-less the point of the language.
HTML _doesn't_ compute things, unless you extend it by embedding some
other language in it (e.g. - stuff like embedded Perl, PHP). The same
is true for anything based on SGML.
Thus:
> (staticp 'SGML)
T
> (staticp 'HTML)
T
The fact that Google presents what _appears_ to be a more dynamic face
on things does not mean that HTML has gotten any more dynamic.
It merely displays that you can build indices that provide some more
powerful static views of the data. The value of that should not be
underestimated, but it still does not make it dynamic.
--
Rules of the Evil Overlord #121. "If I come into possession of an
artifact which can only be used by the pure of heart, I will not
attempt to use it regardless." <http://www.eviloverlord.com/>
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
Christopher Browne
>> Consider the glossary that defines hypertext links _to_ its defined
>> terms. Instead of myriad explicit links in each document in the
>> document set covered by the glossary, the links may be defined as
>> whatever matches a rule in those documents. A rendering engine
>> would load the glossary and apply the rules to highlight glossary
>> terms, or perhaps make them more accessible by popping up a small
>> window with the definition. Instead of this being coded explicitly
>> wherever a glossary term is used, it would all be arranged in the
>> glossary, once.
>> HTML does not allow us to work with documents we do not
>> own or control except by pointing at them as static objects.
>
>feature, which renders HTML documents with (dynamically selected)
>glossary terms highlighted.
Ah, but that's not an _HTML_ application, but rather an application of
HTML + "Whatever Google Does internally."
And, more importantly, it doesn't disagree with #Erik describing them
as "static objects."
Google examines a set of web pages, _as static objects_, and adds some
indexing on top of them.
If I change my web page, Google does not automatically discover that,
at query time, and change the highlighting. It does not discover the
change until it runs through some form of reindexing to rediscover the
change to the _static_ object that is my web page.
THAT is what isn't dynamic.
It's a subtle distinction.
--
"When we understand knowledge-based systems, it will be as before
-- except our fingertips will have been singed." -- Alan Perlis
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/html.html>
Courageous
> You started to ask really annoying questions...
Which is to say someone found them annoying, not that the
questions per se were questions that are, by nature, annoying,
don't you think? To wit: they were annoying to *you*.
C/
Erik Naggum
| To wit: they were annoying to *you*.
What a brilliant piece of insight! I'm glad you're helping us
figure out these difficult things.
Some real wit: "Questions" that are followed by a denial of any
possibility of accepting an answer are inherently destructive. Yes,
I find that annoying. People who ask "questions" only so they can
pick a fight with people annoy me. People who have a track record
of listening only to themselves talk also annoy me. But you know
all about this, already. You've been reasonable lately, however,
and you have seen me answer your questions with care and interest.
_You_ should know by now that if you want to be stupid, you get what
you deserve from me, but if you want to be productive and you listen
to other people's opinions and ideas when you ask them questions, I
answer with care and interest. Erann Gat doesn't have any interest
in what he's asking. He's out to deny that I have said anything
worthwhile (see his replies for specific clues to this motivation),
which has been on his agenda for a long time, and he's told me, face
to face, that he thinks it's productive to employ an amazingly
unintelligent copycat version of what he _doesn't_ understand that
I'm doing in order to shut me down. Yes, that's very annoying.
Erann Gat is an annoying parasite as long as he is in this mode, and
he doesn't get out of it by himself. When I answered Espen Vestre's
followup questions, Erann Gat proved that he didn't read it at all,
only continued to pick a fight, which is his real goal. Yes, that's
quite annoying. He can be quite productive and interesting when he
gets over his personal problems, however, like a few other people
who can't deal with my rejecting their silliness.
Now, consider whether you want to help Erann Gat on his mission from
the Gods or whether you want to help shut him down before he makes
his usual rounds of insane accusations. He's been known to accuse
people in his typical roundabout ways of Holocaust revisionism when
he doesn't understand what they say, and I found that pretty damn
annoying, too.
#:Erik
Erik Naggum
| From this admonition I infered that you thought that I was asking
| this question of programmers and not librarians (else why the
| admonition?). But this is not the case. There are librarians here.
It may come as a shock to you, but this is not a newsgroup for
librarians even if there be librarians here. You would get answers
from the _intersection_ between those interested in Lisp and those
with a librarian past (or present) at _best_.
So I repeat: If you want to understand bibliographic references,
talk to (a forum for) _librarians_, not (a forum for) programmers.
I regret it every time I express myself in such a way that you can
pull an Erann Gat out of the proverbial hat and quibble over some
pretty clear phrasing just to pick fights, but it is unfortunately
impossible for either man or machine to predict how you will read
normal English prose to find "flaws". I have long ago concluded
that there is nothing in what I say or do that triggers your insane
quibbling, and consequently nothing I can change to make you less
irrational.
The reason I'm pointing you to librarians is that it is obvious to
me that you don't want to understand bibliographic references, you
only want me to be wrong. "There is no third document involved" is
not a signal from a person who wants to understand anything, it's
the metallic sound of a mind closing like a steel trap.
| For all I knew *you* could have been a librarian.
For all I know, you _could_ be smart enough to realize why you are
counter-prouctive. The evidence is wanting, however.
| Actually, that's an interesting point. Erik, are you a librarian?
| If you are, why didn't you just answer my question? And if you
| aren't, why should anyone listen to what you have to say on the
| subject of bibliographic references?
Excuse me? _You're_ the idiot who wants to make librarians and
programmers into mutually exclusive groups. I merely suggested you
ask "librarians" and not "programmers", but your limited mental
abilities didn't quite grasp that the mere existence of a librarian
in a group of programmers doesn't constitute asking librarians if
you ask these programmers. How can I help you understand this? I
_have_ tried by inserting the rather obvious "(a forum for)" in the
rephrasing above. I hope, but do not believe, this will help.
| I am not trying to pick a fight. I am trying to ask a question ...
Yeah, I'm sure. Consider your previous paragraph. "Why should
anyone listen to you" is _just_ a question. Sure. Not picking a
fight at all. Geez, do you even believe your own silliness?
| My question: why is it obviously false?
If you could open your mind enough to let the thought in that a
bibliographic reference may be located in a different document than
the document that made the reference (commentaries on the works of
philosophers often supply "latent" references, to take another
example), you see that it is completely unreasonable to deny that a
third document may be involved in the general case, hence obviously
false that "there is no third document involved". Bibliographic
references have historically never been _restricted_ to simple
one-way pointers, either (although that is the most common version)
-- insisting that they are is just plain stupid.
#:Erik
Espen Vestre
> Some real wit: "Questions" that are followed by a denial of any
> possibility of accepting an answer are inherently destructive. Yes,
> I find that annoying. People who ask "questions" only so they can
> pick a fight with people annoy me.
Erik, sometimes you are missing the distinction between wanting to
pick a fight and trying to find counterexamples in order to understand
the answers...
It seems like it's not really clear what the problem we're discussing
really *is*. _Which_ flaws of HTML are we really after? Someone
seems to think that it's the static nature of HTML documents, which
seems beside the point to me. Aren't we just talking about the long
realized fact that HTML documents have much too little _structure_
(much less than e.g. LaTeX documents) in order to be efficiently
automatically processed for any other purpose than rendering them on
your screen?
(The most irritating about this thread, though, is that I can't even
remember why on earth we started discussing the flaws of HTML in this
newsgroup)
--
(espen)
Pierre R. Mai
> It seems like it's not really clear what the problem we're discussing
> really *is*. _Which_ flaws of HTML are we really after? Someone
It seems to me that the flaw under discussion was the limited semantic
model (and therefore the limited technological implementation) of
linking that is embodied in HTML:
a) Links are inherently uni-directional in HTML: There is no way to
traverse a link from the destination to the source (without having
to have traversed it in the "right" direction in the first place).
b) Links are always embedded in the "source" document. You can't have
"third-party" links, or indeed, because of a), second-party links
(e.g. including a link from A to B in B, instead of in A).
c) Indeed, HTML doesn't recognise that links can have varying roles to
play: The link between a translation and an original text is very
different in semantics and pragmatics (as well as application
handling) from the link that links a comment to the text commented
on, etc.
d) The underlying addressing model is severely limited:
- Addressing for source and destination of a link is asymmetric:
The source part uses implicit addressing, the destination uses url
+ fragment addressing.
- Fragment addressing is too coarse, doesn't support ranges
other than those of the element hierarchy, and requires
cooperation from the author of the destination document.
There are more flaws that can be directly attributed to HTML's
linking model, as well as other flaws that result out of the
interaction with other HTML/HTTP/Web design choices or accidents,
like the current domination of location-based URL-based addressing
vs. location-independent URN-based addressing.
Now I can understand the rationale for chosing a severely limited
linking model, namely ease of understanding and use for the lay
person, though I am not bound to agree that a richer model couldn't
have been sneaked past the lay person. But be that as it may, it
doesn't remove the severe technical and semantic limitations of HTML's
linking model.
BTW: I've seen the "but any of these can be implemented using HTML's
linking (and addressing) model and/or using extra-HTML means, like
dynamic HTML generation" argument raised. Let me just say that I (as
well as probably many other readers of c.l.l) am using Common Lisp,
because I don't think that this argument has any merit when used
w.r.t. programming languages, and doubly so when used in the context
of document description languages:
- Anything that can be written in Common Lisp can be written in
assembler. But that doesn't mean that anything that can be
expressed in Common Lisp can be expressed in assembler: Meaning and
intent get lost during down-translation. This is evil in the case
of programming languages, but it is doubly so in the case of DDLs.
- The use of extra-lingual constructs and mechanisms to implement
semantically rich linking really deprives the underlying DDL of it's
raison d'être: DDLs exist to let users describe as much of the
semantic content of documents as is practicable and useful.
Resorting to extra-lingual means to denote arguably useful semantic
constructs like bi-directional links only shows the
limitations/unsuitability of the underlying DDL.
Of course it can be argued (and has been), that DDLs themselves are
really misguided and futile attempts at codifying semantics. I don't
want to go there in c.l.l, though.
> seems to think that it's the static nature of HTML documents, which
> seems beside the point to me. Aren't we just talking about the long
I quite agree that IMHO the issue under discussion is not really
related to the dynamic vs. static debate, especially since static
vs. dynamic are not absolute concepts when applied to documents.
> realized fact that HTML documents have much too little _structure_
> (much less than e.g. LaTeX documents) in order to be efficiently
> automatically processed for any other purpose than rendering them on
> your screen?
While this may be considered a superset of the problem under
discussion here, the limitations of HTML's linking and addressing
models is a much more specific, and -- given the goals and uses of
HTML in the Web -- a much more serious problem, IMHO.
> (The most irritating about this thread, though, is that I can't even
> remember why on earth we started discussing the flaws of HTML in this
> newsgroup)
IIRC, because of a offhand remark by Erik, during the critique of
Franz' current HTML-only delivery of their manuals (which AFAIK will
be changed with the release of ACL 6.0).
IMHO the thread would be much less irritating, if people took the
trouble of reading about less retarded models for linking, like
e.g. HyTime. There are very short tutorials and introductions to
HyTime, so that reading the non-trivial standard isn't really needed
to get a basic understanding of some of the concepts contained
therein. Note that HyTime is neither the beginning nor the end of
serious thought about the semantics of linking, addressing and
Hypertext/HyperMedia, but coming from HTML, it should provide enough
food for thought for starters.
Without this, the thread has a tendency to degenerate into the common
newbie discussion with people coming upon a community and body of
work, and out-right ignoring the experience embodied in the community
and their body or work, without taking the trouble to understand them
first. The CL community is often the "victim"[1] of such behaviour, so
it seems we should strive to avoid such behaviour w.r.t. other
communities.
Regs, Pierre.
Footnotes:
[1] The real victim of such behaviour is really the person itself,
since it will be denied the fruits of labour and thought the
community has to offer...
Janos Blazi
> people in his typical roundabout ways of Holocaust revisionism when
> he doesn't understand what they say, and I found that pretty damn
> annoying, too.
>
> #:Erik
Enter Janos.
Please Erik (or anybody else), answer this question:
What does "Holocaust revisionism" mean?
Janos Blazi
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Espen Vestre
> What does "Holocaust revisionism" mean?
Certainly, you must have heard about the David Irving Trial?
"The Holocaust History Project" (http://www.holocaust-history.org/)
seems to be a good (*) starting point for learning about recent Holocaust
revisionism, including coverage of David Irvings writings and the
trial.
(but let's keep this out of c.l.l, o.k.?)
(*) At least it looks o.k. to me
--
(espen)
Janos Blazi
>
> Certainly, you must have heard about the David Irving Trial?
>
> "The Holocaust History Project" (http://www.holocaust-history.org/)
> seems to be a good (*) starting point for learning about recent Holocaust
> revisionism, including coverage of David Irvings writings and the
> trial.
>
> (but let's keep this out of c.l.l, o.k.?)
Well, Erik started talking about it and you did not admonish him either... I
think I should be permited to talk about it as well.
I am not going to go through that homepage and I did not hear about David
Irving either. What I am interested is this:
Do the revisionists deny the Holocaust or do they say that it happened ?
(Actually Erik compared Erann Gat's way of doing things to such "Holocaust
revisionism" (which was a strange comparison by the way for somebody who's
only "sin" was that maybe he did not understand how references worked) and I
should like to find out, which point of view is bad in Erik's opinion.)
Espen Vestre
> Well, Erik started talking about it and you did not admonish him either...
honestly, I didn't read that posting to its end because I'm tired of
all the noise in this newsgroup, including your attempt at trying
to inform yourself on well-known political topics in a programming
newsgroup.
> think I should be permited to talk about it as well.
>
> I am not going to go through that homepage and I did not hear about David
> Irving either.
So read an old issue of Der Spiegel before you ask any more, OK?
http://www.spiegel.de/politik/ausland/0,1518,72542,00.html
Having not heard about the David Irving trial is so unbelievable (*) that
I wonder which newspapers you read or television news you watch.
> (Actually Erik compared Erann Gat's way of doing things to such "Holocaust
> revisionism"
No, he didn't, read it again!
(*) I happened to be in Germany at the time he lost his case, and it
was very well covered by german press, including local newspapers.
--
(espen)
William Deakin
> What does "Holocaust revisionism" mean?
Ask David Irving.
Janos Blazi
Maybe he can read this posting.
J.B.
Erann Gat
> >> HTML does not allow us to work with documents we do not
> >> own or control except by pointing at them as static objects.
> >
> >Not true. For a simple counterexample see Google's "show matches"
> >feature, which renders HTML documents with (dynamically selected)
> >glossary terms highlighted.
>
> Ah, but that's not an _HTML_ application, but rather an application of
> HTML + "Whatever Google Does internally."
So? What is an HTML application? The most common use of HTML is to
write documents that get rendered in browsers, i.e. it's an application
of HTML + "Whatever the browser does internally." DHTML gets tweaked
by the server before being output, i.e. it's an application of HTML
+ "Whatever the server does internally?" How is what Google
does any different?
Look at the claim again. *HTML* does not *allow* us to work
with documents we do not own or control. It seems to me that whatever
constraints there may be on working with a particular document, those
constraints do not arise because the document is in HTML, those
constraints arise because Google doesn't own or control the document.
HTML is not imposing any additional restrictions on working with the
document that were not already imposed by the fact that the document
is owned and controlled by someone else. So the claim about HTML is,
at best, a red herring.
E.
Hartmann Schaffer
g...@jpl.nasa.gov (Erann Gat) writes:
> In article <Ea3S4.69008$MB.14...@news6.giganews.com>, cbbr...@hex.net wrote:
>
>> >> HTML does not allow us to work with documents we do not
>> >> own or control except by pointing at them as static objects.
>> >
>> >Not true. For a simple counterexample see Google's "show matches"
>> >feature, which renders HTML documents with (dynamically selected)
>> >glossary terms highlighted.
>>
>> Ah, but that's not an _HTML_ application, but rather an application of
>> HTML + "Whatever Google Does internally."
>
> So? What is an HTML application? The most common use of HTML is to
> write documents that get rendered in browsers, i.e. it's an application
> of HTML + "Whatever the browser does internally." DHTML gets tweaked
> by the server before being output, i.e. it's an application of HTML
> + "Whatever the server does internally?" How is what Google
> does any different?
sorry, but you are wrong. what goes on in the browser (disregarding
plugins) is interpretation of html, nothing more. dhtml uses dynamic
processes on the server side to create a static document. google adds
an extra layer to produce more comprehensive static documents, but they
remain unchanged until the server decides (for whatever reason) to rerun
its extra html processes again.
> ...
--
Hartmann Schaffer
Erann Gat
> | My question: why is it obviously false?
>
> If you could open your mind enough to let the thought in that a
> bibliographic reference may be located in a different document than
> the document that made the reference (commentaries on the works of
> philosophers often supply "latent" references, to take another
> example), you see that it is completely unreasonable to deny that a
> third document may be involved in the general case, hence obviously
> false that "there is no third document involved". Bibliographic
> references have historically never been _restricted_ to simple
> one-way pointers, either (although that is the most common version)
On that criterion it is "obviously false" that birds can fly.
> -- insisting that they are is just plain stupid.
I never insisted that they are, I just *said* that they are. There's
a big difference. (See note below.)
So, let's pick this up again: bibliographic references are *usually*
(in the "most common version" to use precisely your words)
pointers contained in one document that refer to a second document
with no third document involved, and your canonical counterexample
to the blanket statement is commentaries on the works of philosophers.
I am given to understand that this is a forum for programmers,
not philosophers or librarians. But be that as it may, I have,
amazingly enough, actually read some commentaries on the works of
philosophers, and I still don't know what you are talking about.
The closest thing I can think of is where the commentator commenting
on the work of philosopher A makes reference to A's reference to
philosopher B. (This, of course, can be and sometimes is carried
to ridiculous extremes where A comments on B's commentary of C's
discussion of D's ...) But this doesn't seem to me like the "third
party" link that you were talking about, this is just a reference to
another reference, which you can do in HTML. So I think I'm still missing
something. A real example would help a lot.
E.
---
Note for Erik and other language lawyers: The statement "There is no
third document involved" is ambiguous as to whether it means there is
*never* a third document involved or whether it means that there is
*usually* no third document involved, in the same way that the statement
"Birds can fly" is ambiguous. So in fact I never even *said*
that bibliographic references are *restricted* to being one-way pointers,
and I certainly never *insisted* on it. In fact, I can't think of an
example of a bibliographic reference that is anything other than a one-way
pointer, but I do not deny that such a thing might be possible. I'm still
waiting for an example, though.
Michael Hudson
> > So? What is an HTML application? The most common use of HTML is to
> > write documents that get rendered in browsers, i.e. it's an application
> > of HTML + "Whatever the browser does internally." DHTML gets tweaked
> > by the server before being output, i.e. it's an application of HTML
> > + "Whatever the server does internally?" How is what Google
> > does any different?
>
> sorry, but you are wrong. what goes on in the browser (disregarding
> plugins) is interpretation of html, nothing more. dhtml uses dynamic
> processes on the server side to create a static document.
Umm, I think you mean DTML; dhtml is usually an abbreviation for
Dynamic HTML which means (I think) using Javascript to manipulate the
document on the client side (using DOM and stuff like that) - you
know, things like rollever buttons. I guess you could use that to
implement some of the things that were discussed in this thread, but I
wouldn't want to.
Cheers,
M.
--
languages shape the way we think, or don't.
-- Erik Naggum, comp.lang.lisp
Erann Gat
> Centuries ago, Nostradamus foresaw a time when Erann Gat would say:
> >In article <31668865...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
> >> * Erann Gat
> >> | Not true. For a simple counterexample see Google's "show matches"
> >> | feature, which renders HTML documents with (dynamically selected)
> >> | glossary terms highlighted.
> >>
> >> PostScript can also represent irony.
> >
> >OK. So?
> >
> >> _Please_ get the point.
> >
> >That is precisely what I am trying to do. (Actually, at this point
> >I am trying to figure out if there actually *is* a point to be gotten.
> >I am beginning to have my doubts.)
>
> The point is that you aren't seeing the difference between "static"
> and "dynamic."
I don't think that was Erik's point. His original statement was something
to the effect that HTML was deficient because it could not express a
third-party link. I still don't know what a third-party link is or
what it's supposed to be good for. The only concrete example I have
seen in this discussion is Pierre's reference to HyTime (Thanks Pierre!)
but HyTime Ilinks seem to me to be nothing more than pairs of simple
one-way links with indirection. Certainly HyTime seems just as static as
HTML.
> HTML _doesn't_ compute things,
If you mean that HTML is not a programming language, granted, but so what?
What could you do more easily with HTML if it were a programming language?
Would that make it easier to, say, implement GSM (Google Show Matches)?
(If you literally mean that HTML doesn't compute things, then Common Lisp
doesn't compute things either. *Programs* written in Common Lisp compute,
but Common Lisp itself does not.)
> The fact that Google presents what _appears_ to be a more dynamic face
> on things does not mean that HTML has gotten any more dynamic.
>
> It merely displays that you can build indices that provide some more
> powerful static views of the data. The value of that should not be
> underestimated, but it still does not make it dynamic.
Being static is not in and of itself necessarily a drawback. It's
only a drawback if it makes it significantly harder (or impossible)
to do something useful. Erik seems to be claiming that there is
something about the structure of HTML that makes it significantly
harder to do certain useful things. The example he cited was setting
up glossaries. I cited Google as an existence proof that doing glossaries
with HTML is not hard. (It's not conclusive proof, of course, because
we don't really know how much work Google had to put in to make this
happen, but I think it's pretty clear that it's not all that hard.)
I'll say this again: what makes Web documents static from the point of
view of third parties who don't own or control the documents is not the
fact that they are written in HTML, it's the fact that they don't own or
control the document. The document could be in Smalltalk but it will
still be a static document to you if you don't have write permission for it.
E.
Erik Naggum
| On that criterion it is "obviously false" that birds can fly.
I rest my case: You're clinically insane.
#:Erik
Andrew McDowell
>In fact, I can't think of an
> example of a bibliographic reference that is anything other than a one-way
> pointer, but I do not deny that such a thing might be possible. I'm still
> waiting for an example, though.
Ok...I don't mean to step into a fight or anything...but I think I'm
actually learning something from all of this...and believe it or not, it's
very relevant to some work I'm doing now.
In a previous post, Erik states:
> This is unfortunately a very misguided view of the old-fashioned
> bibliographic reference. I'm sorry to say so, but the bibliographic
> reference includes a lot more than one-way "pointers", which is a
> special case or a narrow view, depending on how you look at it. If,
> for instance, I wish to compare CLtL2 with CLtS (S for Standard),
> you can either regard my two bibliographic references in any given
> comparison on a given point as two one-way pointers from my document
> into those two documents, but that is very nearly irrelevant to the
> purpose and actual references involved. A reader of a comparison
> would naturally want to have both text available and would have to
> regard my commentary on their _relationship_ as the real purpose of
> my text. My document thus contains third-party hypertext links (and
> bibliographic references) with that purpose between two other
> documents.
I think that the limitation that Erik has pointed out is that a reader of
CLtL2 would be blissfully unaware of the comparison between the document he
is currently reading and CLtS, the actual material contained in CLtS, and
the relation between CLtL2 and CLtS that Erik pointed out.
Did I understand this correctly?
-Drew
David Thornley
>* g...@jpl.nasa.gov (Erann Gat)
>| I presume that a browser history is an example of "this particular
>| application" being "implemented by ... other means" but I don't see
>| how having bidirectional links in HTML would add any functionality.
>
> The idea is not a "bidirectional links", but the bibliographic
> reference, which was a quite well developed concept prior to HTML.
>
I assume you mean something like "Naggum, op cit, p. 837" by
bibliographic link? In other words, that you want the ability to
write a link that refers to a position in the other document, rather
than a predefined anchor?
> I wrote: "The ability of one document to introduce a link between
> two other documents'. This is not a bidrectional link in the first
> place. It's a third-party link if you want.
So, what you'd like also is an ability from document A to put a link
in an arbitrary place in document B that goes to an arbitrary place in
document C? (Obviously, this would have to be limited to a particular
viewing of the documents; if it were possible to put arbitrary links in
other people's pages in general, all pages on the Web would have multiple
links to porn sites.)
So, assume for the sake of argument that there are web sites with the
contents of Norvig's PAIP and Graham's On Lisp, and you want to write
a page on certain sorts of macros. You have the facility to define
some sort of session in which the reader will see the links you define.
You define links to arbitrary parts of Norvig's and Graham's books,
regardless of whether there's an <a> there or not. You define links
between the two books that will be seen as long as the reader is in
that session, again at arbitrary places. You put links in Graham's
book in arbitrary places, pointing to notes you've written on how
and why you disagree with Graham here. You put a link in Norvig, pointing
to a more general macro you've written.
Having done all this, you package the whole thing up as Erik's Guide
to Macros, put it on your site, and I could surf over there and see
your material, Norvig's, and Graham's as you wish to present it.
Is that an adequate description of what you are complaining about?
Or are there other things you'd want to be able to do? I've been
having trouble following the list of deficiencies, and would like
to be sure I've got it.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Erik Naggum
| In other words, that you want the ability to write a link that
| refers to a position in the other document, rather than a predefined
| anchor?
Yes, that, too. The biblical chapters and verses arose for the
purpose of the references. Legal documents have their structure
from the need to refer to individual sentences and items in lists.
| So, what you'd like also is an ability from document A to put a link
| in an arbitrary place in document B that goes to an arbitrary place
| in document C?
Yes.
| (Obviously, this would have to be limited to a particular viewing of
| the documents; if it were possible to put arbitrary links in other
| people's pages in general, all pages on the Web would have multiple
| links to porn sites.)
This is an important point. Which links are active on a given page
is controlled by the set of linking documents you have selected.
The "viewing" is controlled by the browser, which knows about _your_
linking preferences, glossaries, dictionaries, etc, and merges them
with those contained in (or referenced) the document itself.
| Is that an adequate description of what you are complaining about?
No. I't s good start, however.
| Or are there other things you'd want to be able to do?
Again as an example, I want to say, in a formalized way, "That part
of document A contradicts that part of document B" and put it in a
collection of comments on various documents on the Net. When
somebody picks up this collection of comments, they can visit the
documents I have commented on in various ways and have an annotation
box pop up in places where I had made such comments and go visit the
other document to look at it. However, this is not _too_ exciting.
The exciting part is when the links themselves can be referenced,
aggregated, etc. That's when you _really_ need the ability to point
to something and make it link to something else.
| I've been having trouble following the list of deficiencies, and
| would like to be sure I've got it.
Think of it this way: If you are writing a novel, which would
typically include dialog, you are not worrying about how to make
irony come out right on your laser printer, because there's no point
in making it visually distinct from any other text and there's no
point in involving the printer unless you have a language to talk
about the irony of a particular piece of text that could affect the
printer's behavior. You would, however, worry about how to express
the irony in your own language. The printer would simply render it
in whatever way it usually renders text. When people get stuck in
the HTML world, they naturally complain about the pointlessness of
talking about irony because there's no browser that would render
<irony>foo</irony> differently from anything else, and it would look
just like any other text. If they _wanted_ the browser to render
irony differently, they would simply write the low-level stuff that
HTML defines to cause the browsers to change the rendering, but they
would _still_ not think that _HTML_ supports irony. HTML supports
the mechanisms that allows something else entirely to express irony
through its rendering-friendly language. It is that something else
that I'm interested in. In the case of your novel and the laser
printer, it's capturing the author's intent in a language able to
talk about its own usasge, such as English. In the case of HTML,
it's whatever caused that particular "code" to be produced in the
first place, ultimately _some_ authors' intent.
Because HTML can do certain simple tricks, and because most people
aren't aware of what they are doing, it is possible to conflate the
expression with the intention, indeed common to do so among those
who aren't and don't want to be educated. This doesn't remove the
intent. It only means that some people will insist that if they can
express it in HTML, there's no point in talking about the intent and
other languages that would make it easier to talk about the intent.
The fundamental deficiency in HTML is that it reduces hypertext and
the intertwinedness of human communication to a question of how it
is rendered and what happens when you click on it. By giving the
world a language in which numerous important concepts can no longer
be expressed, these concepts are removed from our world. When music
was written down with notes, a lot of music that was very hard to
write down with notes vanished, and music became note-friendly.
When tasks are automated, the skills that went into the automation
vanishes and only the skills required to keep the automated solution
going remains. When children learn to speak particular languages,
their ability to speak other languages deteriorates and vanishes.
HTML is to the browser what PostScript is to the laser printer.
Normal people don't worry about PostScript when they want to employ
irony in a dialog. Normal people shouldn't worry about HTML when
they want to make hypertext links. They should think of what their
_real_ needs are, and trust me, those needs are _not_ covered as
such by HTML, but they can still be _expressed_ in HTML such that a
browser can render it to the reader, just like PostScript does not
cover the needs of an author as such, but most everything an author
wants to say can be _expressed_ in PostScript and come out right.
(And that which cannot be expressed in PostScript will have a
natural tendency to become unwanted unless people change to a new
language.)
That is to say, everything I want _may_ be implemented with a chain
of proxy servers that add their particular thing to the incoming
HTML, just as I could add filters that hacked PostScript to get
special effects on the laser printer. The end result as it is given
to the browser or laser printer is _still_ HTML or PostScript,
respectively, but neither the HTML nor the PostScript were created
to do what the proxy servers and filters have done _to_ them. It is
not productive to argue that "it's just HTML! HTML can do it all!"
when the software that produces the HTML is driven by so much more
input than whatever generated the original HTML _or_ the browser,
and which simply tries to teach the browser how to do things HTML
_can't_ do on its own. Which means that whether it is done by a
chain of proxy servers or a smarter browser that understands a
_richer_ language than HTML is immaterial, but you still can't get a
browser that only understands HTML to do any of this stuff without
the proxy servers in between. For instance, CSS may be employed to
change the rendering of an HTML document, and CSS may be provided by
the user to override a document's rendering. The HTML may contain a
reference to some CSS that instructs the browser on what to do, but
that still doesn't give HTML the credit for the rendering.
To put it in yet another way: What I want the browser to do, is
accept input from a number of sources, merge them, and produce a
synthetical document that reflects decisions that none of the
sources individually can know about, because they rest with the
reader. To achieve this without the necessary languages to describe
relationships _between_ (other) documents is so cumbersome that it
is effectively removed from the wish list to begin with. (Imagine
setting up a chain of numerous proxy services for each of the
documents you want to look at -- you can't even click on links,
anymore, because you may want to select another linking document.)
I really hope this helps.
#:Erik
Hartmann Schaffer
Michael Hudson <mw...@cam.ac.uk> writes:
> h...@inferno.nirvananet (Hartmann Schaffer) writes:
>
> ...
>> > of HTML + "Whatever the browser does internally." DHTML gets tweaked
>> > by the server before being output, i.e. it's an application of HTML
>> > + "Whatever the server does internally?" How is what Google
>>
> ...
>> plugins) is interpretation of html, nothing more. dhtml uses dynamic
>> processes on the server side to create a static document.
>
> Umm, I think you mean DTML; dhtml is usually an abbreviation for
> Dynamic HTML which means (I think) using Javascript to manipulate the
> document on the client side (using DOM and stuff like that) - you
> know, things like rollever buttons. I guess you could use that to
> implement some of the things that were discussed in this thread, but I
> wouldn't want to.
i wasn't aware of that. basically i used the terminology af the
article i was responding to. thaks for the correction
--
Hartmann Schaffer
Fernando
wrote:
>If you mean that HTML is not a programming language, granted, but so what?
>What could you do more easily with HTML if it were a programming language?
Write html files, for example (seriously ;-). When you need
to write many pages with a common look and feel, your life suddenly
becomes miserable, precisely because html doesn't have any scripting
capabilities. For example, if you need to display images always in a
standard way (with low and high bandwidth versions, a border and a
caption) the only solution html gives you is copy and paste. :-P
Now I'm using a html preprocessor for these purposes, but a
markup language implemented in Common Lisp (or scheme) that would let
you use all the lisp tools to handle the data and latter render to
sgml would be much better...
>Being static is not in and of itself necessarily a drawback. It's
>only a drawback if it makes it significantly harder (or impossible)
>to do something useful.
Erik is pretty "static" too, so forget about having the last
word... };-)
>Erik seems to be claiming that there is
>something about the structure of HTML that makes it significantly
>harder to do certain useful things. The example he cited was setting
I'm afraid I have to agree with him here. Html comes from
sgml, and it shows it's low origin: an unnecessarily complicated
syntax to solve what Lisp had solved (in a better way) decades ago...
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
John Clonts
Fernando <spa...@must.die> wrote:
> On Wed, 10 May 2000 12:08:16 -0700, g...@jpl.nasa.gov (Erann Gat)
> >Erik seems to be claiming that there is
> >something about the structure of HTML that makes it significantly
> >harder to do certain useful things. The example he cited was setting
>
> I'm afraid I have to agree with him here. Html comes from
> sgml, and it shows it's low origin: an unnecessarily complicated
> syntax to solve what Lisp had solved (in a better way) decades ago...
>
Could you elaborate one level on this last part-- What had lisp solved,
and how?
Thank you,
John
Sent via Deja.com http://www.deja.com/
Before you buy.
Seth Gordon
> So, let's pick this up again: bibliographic references are *usually*
> (in the "most common version" to use precisely your words)
> pointers contained in one document that refer to a second document
> with no third document involved, and your canonical counterexample
> to the blanket statement is commentaries on the works of philosophers...
Another counterexample that may help ... The Talmud contains many arguments over
Jewish law in which:
(a) Biblical verses are quoted to support one side or another of an argument.
Sometimes only a fragment of the verse is quoted, and you can't understand how
the verse helps the arguer's case unless you read the entire verse in context.
(b) Because of the free-associative structure of the text, and because many
legal arguments in the Talmud do not end in a decisive victory for one side or
the other, it's hard (even if you know the source language) to simply pick up a
volume of Talmud, read a few pages of discussion, and walk away knowing the
answer to some legal question. Some medieval commentators (such as Maimonides)
wrote easier-to-read legal digests, based on the Talmud.
Contemporary printed editions of the Talmud, therefore, put diacritical marks in
the text to indicate (a) Biblical quotations, and (b) statements that eventually
became accepted as binding Jewish law. For each of these diacritical marks,
notes elsewhere on the page indicate (a) the book and chapter cited, and (b) the
relevant chapters and sections in standard digests of Jewish law.
--
--Why is it that most kids are attracted to computers while
most adults are quite wary of computers?
--Most adults are smarter than most kids. ["Ask Uncle Louie"]
== seth gordon == sgo...@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
Erann Gat
<spa...@must.die> wrote:
> >Erik seems to be claiming that there is
> >something about the structure of HTML that makes it significantly
> >harder to do certain useful things. The example he cited was setting
>
> I'm afraid I have to agree with him here. Html comes from
> sgml, and it shows it's low origin: an unnecessarily complicated
> syntax to solve what Lisp had solved (in a better way) decades ago...
I agree that HTML has many drawbacks. But inability to introduce a
third-party link isn't one of them -- as far as I can tell. I'm
willing to be convinced otherwise, but so far I have not seen a
good argument.
E.
Erann Gat
Yes, I'm insane. I have long suffered from the delusion that I might
be able to learn something from you. But my condition seems to be
improving rapidly of late.
Now, go read up about penguins and ostriches. And rhetoric.
E.
Pierre R. Mai
> I agree that HTML has many drawbacks. But inability to introduce a
> third-party link isn't one of them -- as far as I can tell. I'm
> willing to be convinced otherwise, but so far I have not seen a
> good argument.
Ok, first let's define third-party link:
A third-party link is a link that expresses a connection between
(a certain part of) a document A and (a certain part of) a document
B, that is contain in a document C, with A, B and C being pair-wise
unequal.
Now, without resorting to any program or process, how would you
represent this connection using HTML?
My contention is that you will find it impossible to directly express
said connection in HTML.
Just like most machine languages are unable to _express_ the concept
of a function call directly, HTML is unable to express this concept
directly. This doesn't mean that it is impossible to _implement_ the
concept of a functions call in machine language (usually using a
combination of stack accessing and manipulation instructions, register
loading and storing and jump/call instructions), just as it is not
impossible to _implement_ third party-links using HTML (usually via
the use of additional processes). But that is beside the point, or
otherwise we'd all be programming in machine language, which we
aren't, and for good reasons, since expressive power is what counts,
both with programming languages, and even more so with document
description languages.
But I'm merely echoing things (and doing so poorly, I suspect) that
Erik has already pointed out...
Regs, Pierre.
David Thornley
>
> This is an important point. Which links are active on a given page
> is controlled by the set of linking documents you have selected.
> The "viewing" is controlled by the browser, which knows about _your_
> linking preferences, glossaries, dictionaries, etc, and merges them
> with those contained in (or referenced) the document itself.
>
dictionary, encyclopedia, atlas, and the Hyperspec to read things
in a context?
> The exciting part is when the links themselves can be referenced,
> aggregated, etc. That's when you _really_ need the ability to point
> to something and make it link to something else.
>
So I could write something like "These links of Naggum to Norvig..."
or compare the Naggum and Pitman links?
Attempted summary of a very large snipped part:
The problem is not HTML, but the fact that HTML is very basic.
It is hard to think of doing some of these things in HTML.
Similarly, Intel machine language is not a problem, but it is
a good thing that there are compilers for other languages.
It is possible for a Lisp programmer to do things that are very
difficult for an assembly language programmer, and more specifically
is likely to think of things that an assembly language programmer
would not.
Therefore, it would be possible to write a real hypertext language
that would process numerous things and deliver the result to the
browser in HTML, much as it is possible to write a Lisp program and
compile it. This has not yet become mainstream because most people
don't see the desirability, much as most assembly language programmers
would not see the desirability of being able to write functions that work
with data types to be determined later.
Is this a reasonable summary of what you're saying? (I do not think
that either of us is stupid, or inept in the use of the English language,
so I figure that this has to be potentially difficult concepts to convey.)
Robert Monfera
Erann Gat wrote:
> DHTML gets tweaked by the server before being output
Hartmann Schaffer wrote:
> sorry, but you are wrong. what goes on in the browser (disregarding
> plugins) is interpretation of html, nothing more. dhtml uses dynamic
> processes on the server side to create a static document.
Is there a server DHTML? AFAIK DHTML works on the client side. Once I
used DHTML to hack together a simple time+expense application that
worked exclusively in a browser. DHTML is a shortcut for saying DOM +
Javascript + HTML (optional) + CSS (optional). No server, Java or
Activex is needed (Javascript has roots in lisp).
Robert
Courageous
> Yes, I'm insane. I have long suffered from the delusion that I might
> be able to learn something from you. But my condition seems to be
> improving rapidly of late.
Nah, he needs to schedule that surgery he's been planning.
That might make up for it, but I doubt it.
C/
Fernando
wrote:
>> I'm afraid I have to agree with him here. Html comes from
>> sgml, and it shows it's low origin: an unnecessarily complicated
>> syntax to solve what Lisp had solved (in a better way) decades ago...
>>
>
>Could you elaborate one level on this last part-- What had lisp solved,
>and how?
What I mean is that it would be OK to represent structured
text as lisp code (instead of sgml). After all, when you pass an sgml
text through nsgmls you get something that looks like a s-expresion,
so it can't be a totally crazy idea.. ;-)
You could have the equivalent of a sgml page coded as a big
lisp list. Not only you have a simple and easy to parse syntax
(compare this with sgml), but you would have parts that are
dynamically generated (thus removing the need for an html
pre-processor --see my previous post) but you would have all the Lisp
tools availlable to modify and trnasform this text.
Think about how much work you would need to design a
tree-walker in Lisp to process this list in order to render the text
into rtf, html, etc... Now think about doing the same thing to an
sgml document...
I really think that sgml is way too complex for the rather
simple goals it achieves.
Erik Naggum
I'm glad you two have found each other, but this is not a good place
for intermoron romanticism. Please take it to personal e-mail, at
least to _contain_ the vileness of your behaviorial characteristics.
If you ever recover, please consider less obsessing with me (or
anyone else for that matter) as a _person_ and start on the wondrous
journey of discovery that you experience when you listen to ideas
and _what_ people are saying, rather than primarily or only _who_.
#:Erik
Erik Naggum
| So I would design a personal environment, which might include a
| dictionary, encyclopedia, atlas, and the Hyperspec to read things
| in a context?
Yes, but also including your own comments on things you had read,
other people's comments, and probably news wires and mailing lists
that supplied interrelationships in the form of third-party links.
| So I could write something like "These links of Naggum to Norvig..."
| or compare the Naggum and Pitman links?
Yes.
| Attempted summary of a very large snipped part:
| The problem is not HTML, but the fact that HTML is very basic.
| It is hard to think of doing some of these things in HTML.
| Similarly, Intel machine language is not a problem, but it is
| a good thing that there are compilers for other languages.
| It is possible for a Lisp programmer to do things that are very
| difficult for an assembly language programmer, and more specifically
| is likely to think of things that an assembly language programmer
| would not.
A compiler is a also good starting point for a comparison, but I
tend to think of HTML as the PostScript of real hypertext -- the
language of the renderer. It would be possible, but fairly time
consuming and very difficult, to write anything directly in
PostScript, so people prefer markup languages like LaTeX or SGML
that "compile" to PostScript or WYSIWYG tools that constantly
recompute the rendering.
Note, however, that a compiler is still limited as a comparison to a
fixed number of source files. The crucial element in my argument
against HTML is that there is no way to "load" third-party links or
rules into the rendering environment from other documents. At least
PostScript has that -- you can download functions and modify the
printer's behavior. None of the "dynamic" features smacked on top
of HTML manage to get any of this right.
| Therefore, it would be possible to write a real hypertext language
| that would process numerous things and deliver the result to the
| browser in HTML, much as it is possible to write a Lisp program and
| compile it.
Yes, _provided_ that it is done sufficiently close to the reader
that the _reader's_ experiences and context can influence the HTML
that the browser sees and displays. This requires _very_ powerful
proxy servers and a "visual" recognition of the HTML that is being
transmitted from various places.
| This has not yet become mainstream because most people don't see the
| desirability, much as most assembly language programmers would not
| see the desirability of being able to write functions that work with
| data types to be determined later.
I think it is not yet mainstream because people _fear_ hypertext
before they know how to navigate in it -- and with good cause, too.
The navigation problem on the Net is basically unsolved, but tools
that could remember and deal with your own set of links would help a
lot, and those would have to be maintained as third-party links in a
sort of "active history", able to answer the question "now, what did
I come here to look for?", which is both unasked and unanswered
today. But convincing people that something conceptually more
complex is a simplifier is very hard marketing work. (Just ask the
Lisp vendors. :)
| Is this a reasonable summary of what you're saying? (I do not think
| that either of us is stupid, or inept in the use of the English
| language, so I figure that this has to be potentially difficult
| concepts to convey.)
FWIW, I'm pleased with your understanding of what I've been trying
to explain for years with admittedly limited success (hence my "I
don't have the patience for this" which was rudely overruled :).
#:Erik
Erik Naggum
| I really think that sgml is way too complex for the rather
| simple goals it achieves.
After spending about 6 years with SGML, and in the process becoming
an international authority, I came to conclude that the complexity
of SGML qua language outweighs its benefits even when applied very
carefully and intelligently, and that never happened because people
didn't really understand what the simple goals were. I considered
this fairly tragic at the time I decided to quit SGML altogether.
(And "improvements" like XML actually make things a lot worse.)
As for SGML and Lisp: I wrote a complete SGML parser in Emacs Lisp
in 1990 and had a lot of fun with it, but it was very hard for other
people to use for some reason. When I was encouraged to speak about
it, one of the forefigures in the SGML world commented "that's great
-- for you and the other two guys who know Lisp" and ridiculing Lisp
solutions became de rigeur in the SGML community, even though people
struggled with problems that various Lisp solutions had solved.
#:Erik
Espen Vestre
> (And "improvements" like XML actually make things a lot worse.)
Could you care to elaborate on that? It would be rather on-topic,
actually, since I imagine I'm not the only one on c.l.l who gets
bombarded with requests for buzzword compatibility in lisp applications,
with XML one of the most frequent.
My impression of XML so far is that the ideas behind it seem sensible,
but that several of the applications I've seen do little more than
wasting enormous amount of bytes (And then I'm not basically thinking
of the sick documents you get out of Office 2000, but rather the use
of XML-based formats for purposes where size and quick parsability
really counts, for instance "internet call data record" formats).
--
(espen)
Erann Gat
(Pierre R. Mai) wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > I agree that HTML has many drawbacks. But inability to introduce a
> > third-party link isn't one of them -- as far as I can tell. I'm
> > willing to be convinced otherwise, but so far I have not seen a
> > good argument.
>
> Ok, first let's define third-party link:
>
> A third-party link is a link that expresses a connection between
> (a certain part of) a document A and (a certain part of) a document
> B, that is contain in a document C, with A, B and C being pair-wise
> unequal.
>
> Now, without resorting to any program or process, how would you
> represent this connection using HTML?
Without resorting to any program or process how would you represent
this connection in *any* language?
> My contention is that you will find it impossible to directly express
> said connection in HTML.
Here is one of many, many possibilities:
<meta name=associated-links content="LINKA LINKB">
<a href=... REL="LINKA">...</a>
<a href=... REL="LINKB">...</a>
Let me try to speed up the discussion by anticipating some objections.
Objection: This is not legal HTML.
Answer: Yes it is. Read section 5.2.5 and 5.7.3 of RFC 1866 carefully.
Objection: Browsers don't know what to do this this tag.
Answer: Of course they don't. They don't know that to do with XLink
and HiTime and all these other schemes that are floating around either.
That's my whole point. In order for *any* of these languages to do
*anything* useful you have to write a *program* that knows how to do
something useful with them. This is tautological. There are things
that current browsers can't do. But to assign the cause of these
shortcomings to HTML is IMO, to borrow Erik's phrase, obviously wrong.
The deficiency is not in HTML, it's in the currently available crop of
HTML user agents.
> Just like most machine languages are unable to _express_ the concept
> of a function call directly, HTML is unable to express this concept
> directly.
Not true. See above. HTML is extensible through the meta tag and
other mechanisms (like adding URL schemes). The claim that HTML
is unable to do these things shows a distressing lack of imagination.
> This doesn't mean that it is impossible to _implement_ the
> concept of a functions call in machine language (usually using a
> combination of stack accessing and manipulation instructions, register
> loading and storing and jump/call instructions), just as it is not
> impossible to _implement_ third party-links using HTML (usually via
> the use of additional processes).
It is not possible to *implement anything* using HTML. HTML is not
a programming language.
> But that is beside the point, or
> otherwise we'd all be programming in machine language, which we
> aren't, and for good reasons, since expressive power is what counts,
> both with programming languages, and even more so with document
> description languages.
And my point is that HTML is not as inexpressive as you say it is.
E.
Wade Humeniuk
said. Hyperlinks like HTML are just make links that the author thinks are
important in his/her explanation or view of the world. This is highly
dependent on the authors vocabulary (experience) of the subject and
processes that the author used to get to that point. Part of the use of
these enhanced links is to put the author's context into the equation to
show the reader how the connection is made. It embodies a historical and
contextual view and allows justification of the connections. It also lets
the reader, based on his experience, have access to the accumulated thought
that has gone into the organization of the knowledge and to add his own
context and to extend the knowledge. Is this the goal? To implement these
types of links you would need to imbed code (like postscript) directly into
a web document, because this is the only method expressive enough to do the
job. SGML is not expressive enough to do the job (which I agree with).
Its just as important how things are connected as what is connected. When
one is learning how things are connected are probably more important because
what is connected are just statements (some true or some false). It more
important to pass on how to learn (connections), to learn from those who
have gone before and be able to validate what you have learned.
Wade
at ncal point verio point com x@x.x tom
> Note, however, that a compiler is still limited as a comparison to a
> fixed number of source files. The crucial element in my argument
> against HTML is that there is no way to "load" third-party links or
> rules into the rendering environment from other documents.
Sure there is. One of the first things I did when the web appeared
was to write a proxy-based system that would let you add links to
other people's pages, add comments, and show you reverse links. There
are now a bunch of proxy based systems around. AltaVista lets you do
reverse link searches, and if you wanted to, you could easily
integrate that into your browser. Alexa provides "What's Related"
hyperlinking from your browser in Netscape and IE (they ship with it).
On Windows, programs can hook into the browser at a very deep level,
and there are all sorts of companies that add all sorts of links and
text to the HTML in your browser, from reverse links, chat, and
glossaries to comparative shopping.
If you are a web site author, you can also choose to let people do
things with your pages like chatting, adding links, adding comments,
editing the pages, and rating. Web rings provide another way of
adding links to pages, and Wikis provide full, automatic,
bidirectional hyperlinking.
For just a few links, look at:
http://crit.org/
http://www.alexa.com/
http://www.udanax.com/
http://TWiki.SourceForge.net/cgi-bin/view/Main/WebHome
http://www.webring.com/
The current level of usage of such techniques is likely more a
reflection of demand for them and scaling issues than any problems
implementing them based on HTML.
Tom.