If Lispers feel justified in getting hysterical over a non-issue like
StudlyCaps vs studly-caps, why are they surprised that The Great
Unwashed have a cow over parentheses?
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<··········@nyc.rr.com>...
> If Lispers feel justified in getting hysterical over a non-issue like
> StudlyCaps vs studly-caps, why are they surprised that The Great
> Unwashed have a cow over parentheses?
It's not only Lispers. For example, here is Rob Pike's view:
I eschew embedded capital letters in names; to my prose-oriented eyes,
they are too awkward to read comfortably. They jangle like bad typography.
[_Notes on Programming in C_, Feb 21, 1989]
Kaz Kylheku wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<··········@nyc.rr.com>...
>
>>If Lispers feel justified in getting hysterical over a non-issue like
>>StudlyCaps vs studly-caps, why are they surprised that The Great
>>Unwashed have a cow over parentheses?
>
>
> It's not only Lispers. For example, here is Rob Pike's view:
>
> I eschew embedded capital letters in names; to my prose-oriented eyes,
> they are too awkward to read comfortably. They jangle like bad typography.
> [_Notes on Programming in C_, Feb 21, 1989]
Interesting, I myself get distracted by all the hyphens.
At the same time, i use s/c only in class names and slotnames. I suppose
I shouldn't care if I am designing at the right level of abstraction,
but I like knowing if I am looking at a slot reference or a function
doing more interesting stuff. I guess if I see a slot (and know it) I
know I do not have to go check "what's in there" when working on
unfamiliar code.
ironically, i hate reaching for the shift key, so i should hate s/c. go
figger.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
* Kenny Tilton
| Interesting, I myself get distracted by all the hyphens.
With Emacs, you can use whatever you like.
Emacs is the only editor where WYSINWYG is a feature. Life would be hell
if I had to look at HTML without the ability to convert it into a rational
syntax upon reading from and back into the irrational upon writing to
file. That this horrible XML crap has to be exchanged among morons and
their software held me back from working with it for years, as the sheer
displeasure of looking at the retarded syntax and its verbose end-tags an
braindamaged attributes was enough to turn me off working with the Web.
But if it is "only syntax", then it /is/ only syntax, and parsing it into
something rational should not be a problem and I should be able to work
with something pleasurable despite the massive lack of care for aesthetics
in the language designer. I have come to prefer {} over <>, but whether
to use \foo{} instead of {foo} is also a personal decision. So *TeX and
*ML all look the same to me, and all the helper packages for Emacs that
try so hard to parse these moronic syntaxes got it all wrong. A fool and
his syntax should soon be parted.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> wrote:
+---------------
| Life would be hell if I had to look at HTML without the ability to
| convert it into a rational syntax upon reading from and back into
| the irrational upon writing to file.
...
| I have come to prefer {} over <>, but whether to use \foo{} instead
| of {foo} is also a personal decision.
+---------------
So which do you find you use more often, and why?
I once tried (with some modest success) to use \foo{} to encode HTML,
and since I had also used \(s-expr) for embedded Lisp (well, Scheme,
but that was a long time ago) I ended up using a hacky [] for attributes,
e.g., \body[bgcolor="#ffffff"]{body text}, which very quickly got ugly,
which is why lately I've been using Tim Bradshaw's HTOUT: package, e.g.,
((:body :bgcolor "#ffffff") body text).
Anyway, I'm curious as to what you used with the \foo{...} and {foo ...}
syntaxes to represent attributes...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Erik Naggum
Subject: Re: Alternative *ML syntaxes [was: Re: StudlyCaps ]
Date:
Message-ID: <3246567106498053@naggum.no>
* Rob Warnock
| Anyway, I'm curious as to what you used with the \foo{...} and {foo ...}
| syntaxes to represent attributes...
I have explained this here previously, but it bears repeating. There are
no attributes. Attributes stem from the notion that there is a useful
distinction between users of the contents of elements, but it is not
useful to separate the users. If the syntax for elements is supposed to
be good enough for the users, it should be good enough for the language
designer, to put it succinctly. Few language designers, however, are
willing to live with the decisions they force on their users. Common
Lisp is one of few languages that do. (And of course some of the people
who do not grasp the elegance of this now want different syntax for the
"real" language constructs. This kind of fluctuation between good and
bad ideas is to be expected as the good ideas are taken for granted and
ignorants have to reinvent the bad ones from time to time, like the tree
of liberty must be refreshed from time to time with the blood of patriots
and tyrants.)
So where you have an attribute, I have an extra element. <foo bar="zot">
...</foo> becomes {foo {bar zot} ...}, which saves not only on the amount
of syntax involved, but on the mechanisms used to protect characters from
misinterpretation, primarily because the number of characters that need
to be protected is also dramatically reduced in number and a single \ can
be used both to escape {}\ and to introduce named entities instead of
clobbering the normally useful characters <>&, and also does not require
names for the characters used in the markup. In fact, if you cannot find
the character in Unicode, you should reconsider using it. Consequently,
\entity should be used for external references. SGML's parameter entities
were a major design mistake and are better solved with real macros.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> wrote:
+---------------
| * Rob Warnock
| | Anyway, I'm curious as to what you used with the \foo{...} and {foo ...}
| | syntaxes to represent attributes...
|
| I have explained this here previously, but it bears repeating. There
| are no attributes. ... So where you have an attribute, I have an extra
| element. <foo bar="zot"> ...</foo> becomes {foo {bar zot} ...}
+---------------
Got it, thanks. That of course requires that the processor for "foo"
reach into its body to extract those sub-elements when outputting (say)
HTML, which is no biggy when the processor in is Lisp.
But if one is dealing with an already-existing tag & attribute name
space (such as W3C HTML), it also introduces the ugly possibility of
name collision between tag names and attribute names, with the resulting
possibly ambiguities in some constructs ("bar" as a tag vs. "bar" as
an "attribute"). Perhaps in the case of HTML there are no conflicts of
this type (I haven't checked thoroughly), but if one tried to generate
output into somebody's arbitrary XML form, say, where they hadn't defined
the DTD with that conflict in mind...
Oh, well, one could always hack one's input format to use XML namespaces
to separate "attribute" tag names from "tag" tag names, I suppose.
(Or does HTML and/or XML already require that the tag & attribute names
be disjoint?)
+---------------
| ...which saves not only on the amount of syntax involved, but on the
| mechanisms used to protect characters from misinterpretation, primarily
| because the number of characters that need to be protected is also
| dramatically reduced in number and a single \ can be used both to
| escape {}\ and to introduce named entities instead of clobbering the
| normally useful characters <>&, and also does not require names for
| the characters used in the markup.
+---------------
That's why I somewhat prefer \foo{...} to {foo ...}, since I tend to
use curlies in writing plain text (e.g., sample C code), and almost
never use "\". (MS users MMV.)
+---------------
| In fact, if you cannot find the character in Unicode, you should
| reconsider using it. Consequently, \entity should be used for
| external references. SGML's parameter entities were a major design
| mistake and are better solved with real macros.
+---------------
TeX has shown that \entity and \func{...} can coexist, has it not?
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote in message news:<······················@giganews.com>...
> Erik Naggum <····@naggum.no> wrote:
> +---------------
> | * Rob Warnock
> | | Anyway, I'm curious as to what you used with the \foo{...} and {foo ...}
> | | syntaxes to represent attributes...
> |
> | I have explained this here previously, but it bears repeating. There
> | are no attributes. ... So where you have an attribute, I have an extra
> | element. <foo bar="zot"> ...</foo> becomes {foo {bar zot} ...}
> +---------------
>
> Got it, thanks. That of course requires that the processor for "foo"
> reach into its body to extract those sub-elements when outputting (say)
> HTML, which is no biggy when the processor in is Lisp.
What, and <foo bar="zot"> does not require reaching into a body to
retrieve the attribute? How can that be when it codes for the same
data structure as the alternate notation?
> But if one is dealing with an already-existing tag & attribute name
> space (such as W3C HTML), it also introduces the ugly possibility of
> name collision between tag names and attribute names, with the resulting
> possibly ambiguities in some constructs ("bar" as a tag vs. "bar" as
> an "attribute").
It's just a difference in notation. A difference in notation cannot
introduce new name clashes.
There is no ambiguity in (foo (foo zot) ...). You know that the inner
foo designates an attribute because of its structural relationship
with respect to the outer foo, which is a tag.
If you were parsing HTML in Lisp, you might well translate <foo
foo="zot">stuff</zot> into (foo (foo zot) stuff). There is no loss of
information.
> TeX has shown that \entity and \func{...} can coexist, has it not?
TeX has shown that a terrible language can achieve amazing longevity,
when it's the only interface to a means of producing nice looking
documents.
Oops! ···@ashi.footprints.net (Kaz Kylheku) was seen spray-painting on a wall:
> ····@rpw3.org (Rob Warnock) wrote in message news:<······················@giganews.com>...
>> Erik Naggum <····@naggum.no> wrote:
>> +---------------
>> | * Rob Warnock
>> | | Anyway, I'm curious as to what you used with the \foo{...} and {foo ...}
>> | | syntaxes to represent attributes...
>> |
>> | I have explained this here previously, but it bears repeating. There
>> | are no attributes. ... So where you have an attribute, I have an extra
>> | element. <foo bar="zot"> ...</foo> becomes {foo {bar zot} ...}
>> +---------------
>>
>> Got it, thanks. That of course requires that the processor for "foo"
>> reach into its body to extract those sub-elements when outputting (say)
>> HTML, which is no biggy when the processor in is Lisp.
>
> What, and <foo bar="zot"> does not require reaching into a body to
> retrieve the attribute? How can that be when it codes for the same
> data structure as the alternate notation?
>
>> But if one is dealing with an already-existing tag & attribute name
>> space (such as W3C HTML), it also introduces the ugly possibility of
>> name collision between tag names and attribute names, with the resulting
>> possibly ambiguities in some constructs ("bar" as a tag vs. "bar" as
>> an "attribute").
>
> It's just a difference in notation. A difference in notation cannot
> introduce new name clashes.
>
> There is no ambiguity in (foo (foo zot) ...). You know that the inner
> foo designates an attribute because of its structural relationship
> with respect to the outer foo, which is a tag.
>
> If you were parsing HTML in Lisp, you might well translate <foo
> foo="zot">stuff</zot> into (foo (foo zot) stuff). There is no loss of
> information.
Um, how does one distinguish the following fragments?
<foo foo="zot"> stuff </zot>
<foo> <foo> zot </foo> stuff </zot>
--
(reverse (concatenate 'string ·············@" "sirhc"))
http://cbbrowne.com/info/sgml.html
"Unlike computers, guns don't have Y2K problems..."
Christopher Browne <········@acm.org> writes:
> Oops! ···@ashi.footprints.net (Kaz Kylheku) was seen spray-painting on a wall:
> > ····@rpw3.org (Rob Warnock) wrote in message news:<······················@giganews.com>...
> >> Erik Naggum <····@naggum.no> wrote:
> >> +---------------
> >> | * Rob Warnock
> >> | | Anyway, I'm curious as to what you used with the \foo{...} and {foo ...}
> >> | | syntaxes to represent attributes...
> >> |
> >> | I have explained this here previously, but it bears repeating. There
> >> | are no attributes. ... So where you have an attribute, I have an extra
> >> | element. <foo bar="zot"> ...</foo> becomes {foo {bar zot} ...}
> >> +---------------
> >>
> >> Got it, thanks. That of course requires that the processor for "foo"
> >> reach into its body to extract those sub-elements when outputting (say)
> >> HTML, which is no biggy when the processor in is Lisp.
> >
> > What, and <foo bar="zot"> does not require reaching into a body to
> > retrieve the attribute? How can that be when it codes for the same
> > data structure as the alternate notation?
> >
> >> But if one is dealing with an already-existing tag & attribute name
> >> space (such as W3C HTML), it also introduces the ugly possibility of
> >> name collision between tag names and attribute names, with the resulting
> >> possibly ambiguities in some constructs ("bar" as a tag vs. "bar" as
> >> an "attribute").
> >
> > It's just a difference in notation. A difference in notation cannot
> > introduce new name clashes.
> >
> > There is no ambiguity in (foo (foo zot) ...). You know that the inner
> > foo designates an attribute because of its structural relationship
> > with respect to the outer foo, which is a tag.
> >
> > If you were parsing HTML in Lisp, you might well translate <foo
> > foo="zot">stuff</zot> into (foo (foo zot) stuff). There is no loss of
> > information.
>
> Um, how does one distinguish the following fragments?
>
> <foo foo="zot"> stuff </zot>
(foo (foo "zot") stuff)
>
> <foo> <foo> zot </foo> stuff </zot>
>
(foo () (foo () zot) stuff)
I don't think you can get away from this.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
* Christopher Browne
| Um, how does one distinguish the following fragments?
Show me an /actual/ case, and I will explain it to you.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Christopher Browne
> | Um, how does one distinguish the following fragments?
>
> Show me an /actual/ case, and I will explain it to you.
I don't know if you consider this an "actual case" because I think
it's unlikely that you use it, but I still hope that you'll explain:
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<Description about="http://www.lisp.org">
<dc:Publisher>ALU</dc:Publisher>
</Description>
</RDF>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<Description about="http://www.lisp.org" dc:Publisher="ALU" />
</RDF>
Actually, these are equivalent to an RDF-savy processor, but not to a
generic XML processor. However, you'll have to decide which syntax to
use at some point, and I think this is actually /harder/ when only one
choice is valid - do you really have explicit rules that tell your
translator that "href" is an attribute of "a", not a child element? Do
you use a DTD at some point (which, after all, doesn't have to exist)?
I would agree that *ML attributes are, well, questionable. I think
there can be a useful distinction between attributes as "specializers"
of elements and child-elements (mostly in "real" text markup, in the
"XML as a universal data encoding" world it is indeed mostly
meaningless, but then they get everything else wrong as well...), but
surely the flat-ness of attribute content just plain sucks. I'm
afraid, however, that I didn't get your point that "Attributes stem
from the notion that there is a useful distinction between users of
the contents of elements". Care to explain?
(Disclaimer: I don't consider RDF XML syntax sane either. In fact I
think it's quite amusing and very telling that there are now several
XML-related languages for which a "simpler" syntax has been invented,
like N3/N-Triples for RDF, or the linear topic-map notation, or RELAX
NG compact. In the last case, James Clark (IIRC) once mentioned how
building a parser for the compact (non-XML) syntax was way easier then
implementing the SAX-based XML version...)
<regards/>
Henrik
* Henrik Motakef
| I don't know if you consider this an "actual case" because I think it's
| unlikely that you use it, but I still hope that you'll explain:
What is to explain? The fact that these are interchangeable just proves
my point.
| However, you'll have to decide which syntax to use at some point, and I
| think this is actually /harder/ when only one choice is valid - do you
| really have explicit rules that tell your translator that "href" is an
| attribute of "a", not a child element?
There already /is/ an explicit rule to tell me that!
| Do you use a DTD at some point (which, after all, doesn't have to exist)?
If there is no DTD, I am frankly not particularly interested in it. SGML
(and XML) without a DTD is like writing Lisp code without specifying the
package in which you are supposed to read the source. Assuming that the
code is intended for the Common-Lisp package or some package using it,
may appear to be a reasonable choice to people of exceptionally little
awareness of other possibilities, but if they complain that other people
did not "get" the package they were intended for when it was specified
some other place in "plain text", I believe patience is wasted on dealing
with such people.
| I'm afraid, however, that I didn't get your point that "Attributes stem
| from the notion that there is a useful distinction between users of the
| contents of elements". Care to explain?
The original idea with attributes was that you should be able to remove
everything between < and > and whatever you wound up with would be the
"real" contents of the document, as a sort of "pleaser" for those who had
objected to all the garbage they had to type. That is, there would be a
human user of the document's "real" contents and a program user of the
stuff between < and >.
| ([...] In the last case, James Clark (IIRC) once mentioned how building a
| parser for the compact (non-XML) syntax was way easier then implementing
| the SAX-based XML version...)
Because of the massive amount of noise that XML parsers introduce to the
reading application and the immense failure of the *ML community to grasp
the simplicity of the Lisp `read� function, the internal representation of
SGML and XML is so underspecified as to be essentially absent. Because
these languages were designed to deal with a processor that kept track of
a relatively small number of state changes at the edges of elements (i.e.,
their start- and end-tags) and then passing information straight through,
not for storing information in memory for later processing, the whole idea
of using an edge detector when you need the real information is ludicrous.
As for actually storing information that can be processed intelligently
both from a stream and from a random-access medium like a file, I have
come to favor ASN.1 over all this tag soup. The dream of locating and
retrieving fargments of information from large documents with various
forms of silly path specifiers is so dumb in the parse-the-stream world of
SGML that all the work I did with HyTime showed me how nutty the syntax
was and how much smarter the "evil competition" was. *sigh*
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> As for actually storing information that can be processed intelligently
> both from a stream and from a random-access medium like a file, I have
> come to favor ASN.1 over all this tag soup.
I have come upon ASN.1 for the first time while looking at the
Genbank specs. I did not pay too much attention to it because of time
limitations and because of the XML hoopla all around.
Could you summarize what makes ASN.1 suitable for "flat file"
representations? (I.e. I'd like to know whether it makes sense to
invest time into it).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
* Marco Antoniotti
| Could you summarize what makes ASN.1 suitable for "flat file"
| representations? (I.e. I'd like to know whether it makes sense to
| invest time into it).
ASN.1 defines a typed and structured data language, which is then encoded
using encoding rules. Almost all encoding rules use type-length-data
tuples, which means that you know exactly how many bytes to skip if you
are not going to use a particular element of the data.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
* Christopher Browne
| Um, how does one distinguish the following fragments?
Perhaps you are unaware of the DTD and its role in *ML languages? Many
people seem to know so little about SGML and XML that what I think must
be hostile provocations is simply sheer ignoranace of the languages. Then
again, many of the users of these languages are also unable to understand
how they are supposed to design applications with them, but that is no
excuse for not knowing the language when designing an alternative to it.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Christopher Browne
>> Um, how does one distinguish the following fragments?
>
> Perhaps you are unaware of the DTD and its role in *ML languages?
May I infer that you have a DTD parser lying around somewhere? Maybe
even a fully SGML-conformant one? In Common Lisp? Care to share? ;-)
However, even if DTDs are still somehow priviledged in XML compared to
other schema languages (simply by being part of the XML 1.* spec), in
practice the only thing you really /need/ a DTD for are entity
declarations (and notations, but they aren't too useful in XML
anyway). What do you do with XML applications that lack a DTD, most
prominent example being XSLT? Do you simply ignore them, or do you
construct a DTD from what you get?
Regards
Henrik
* Henrik Motakef
| May I infer that you have a DTD parser lying around somewhere? Maybe
| even a fully SGML-conformant one? In Common Lisp? Care to share? ;-)
As sharing in any way could be construed as encouragement to use SGML or
XML, I have to decline.
| However, even if DTDs are still somehow priviledged in XML compared to
| other schema languages (simply by being part of the XML 1.* spec), in
| practice the only thing you really /need/ a DTD for are entity
| declarations (and notations, but they aren't too useful in XML anyway).
That the DTD is sort of "implied" by the application or the instance in
no way negates it. Although some elements may have sub-element contents
according to their own position in the hierarchy, which could be hard to
express in a "standard" DTD, sender and receiver even of XML-encoded data
need to agree on /something/. The situation may not actually be better
than it was absent the stupid tags, but the only thing you have on an XML
without a pre-agreed structure is attributes and sub-elements and data.
| What do you do with XML applications that lack a DTD, most prominent
| example being XSLT? Do you simply ignore them, or do you construct a DTD
| from what you get?
I try to ignore XSLT. Most of the time, document instances have enough
information to construct useful content models and keep track of which
things are attributes. It is not particularly hard. The biggest problem
is in fact that some users actually need the retarded syntax.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In the last exciting episode, Erik Naggum <····@naggum.no> wrote::
> * Christopher Browne
> | Um, how does one distinguish the following fragments?
>
> Perhaps you are unaware of the DTD and its role in *ML languages?
> Many people seem to know so little about SGML and XML that what I
> think must be hostile provocations is simply sheer ignoranace of
> the languages. Then again, many of the users of these languages
> are also unable to understand how they are supposed to design
> applications with them, but that is no excuse for not knowing the
> language when designing an alternative to it.
No, I quite know what a DTD is. I have fought /etc/sgml/CATALOG files
into place on more than one occasion.
I think you missed the ambiguity I was pointing out. Marco nicely
caught it, namely that it /isn't/ as simple as mapping
<foo><bar></bar> </foo> onto (foo (bar)); there needs to be the extra
(foo () (bar ())) hooks to allow for attributes, otherwise things
certainly are going to be troublesome.
I know that the extra lists are needed (or some equivalent), and in
any case, this isn't an issue of what a DTD is like, but rather how it
would map onto Lisp...
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
"Documentation wants to be obsolete."
-- Bruce R. Lewis
* Christopher Browne
| I think you missed the ambiguity I was pointing out.
Give me some goddamn credit, already! This SGML shit is braindamaged
enough as it is. People who should be smart enough not to create idiotic
problems because they look at things without context, actually still seem
to think that they can make do without context information. WHY?
Show me an actual case where you fail to grasp the obvious solution, and
I will help you. Inventing a moronic "general" solution for a problem
that exists only if it has that "general" solution is just plain stupid.
I actually believe that people naturally avoid the ambiguity, and this is
not some retarded 90%-solution belief, it is based on years of actual
experience with SGML application design. The reason is that for a number
of /actual/ applications, not some half problemizing, half masturbatory
"academic" exercise, naming an attribute and an element the same will in
fact create problems.
A problem does not need a solution unless it actually happens in real
life. Just because some two-bit hacker cannot keep track of context
while processing text files does /not/ mean that there is a problem.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> A problem does not need a solution unless it actually happens in real
> life.
This will be the premise of the Tilton Prize for CPL Algorithms: a
real-world example of multiple inheritance that manifests the flaw in
CL's calculation of the class precedence list.
I think I could offer a pretty decent prize, but I would want the judges
to be pretty decent at OO design. I am not saying it does not happen, I
am saying it is a message from God to (sorry, Tim) refactor.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Christopher Browne <········@acm.org> writes:
> In the last exciting episode, Erik Naggum <····@naggum.no> wrote::
> > * Christopher Browne
> > | Um, how does one distinguish the following fragments?
> >
> > Perhaps you are unaware of the DTD and its role in *ML languages?
> > Many people seem to know so little about SGML and XML that what I
> > think must be hostile provocations is simply sheer ignoranace of
> > the languages. Then again, many of the users of these languages
> > are also unable to understand how they are supposed to design
> > applications with them, but that is no excuse for not knowing the
> > language when designing an alternative to it.
>
> No, I quite know what a DTD is. I have fought /etc/sgml/CATALOG files
> into place on more than one occasion.
>
> I think you missed the ambiguity I was pointing out. Marco nicely
> caught it, namely that it /isn't/ as simple as mapping
> <foo><bar></bar> </foo> onto (foo (bar)); there needs to be the extra
> (foo () (bar ())) hooks to allow for attributes, otherwise things
> certainly are going to be troublesome.
>
> I know that the extra lists are needed (or some equivalent), and in
> any case, this isn't an issue of what a DTD is like, but rather how it
> would map onto Lisp...
Well. I do not remembere the details, but I think that Erik's
proposal was handling that case. In Erik's scheme, the above
<foo><bar></bar></foo>
would render (if I remember correctly) into
<foo | <bar>>
Which is definitively an improvement (at the expense of the special
treatment of #\|.
<foo foo=bar><bar></bar></foo>
would render (again, I am citing from memory) as
<foo foo bar | <bar>>
Note that you could do it in CL as well, just by assuming the symbol
whose name is "!" as separator. The above would look like
(foo foo bar ! (bar))
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Erik Naggum
Subject: Re: Alternative *ML syntaxes [was: Re: StudlyCaps ]
Date:
Message-ID: <3246631730734601@naggum.no>
* Rob Warnock
| Perhaps in the case of HTML there are no conflicts of this type (I
| haven't checked thoroughly), but if one tried to generate output into
| somebody's arbitrary XML form, say, where they hadn't defined the DTD
| with that conflict in mind...
I would strongly urge you to please find an actual conflict before even
considering the problem. Where there is a conflict, solve it locally.
This does not need a global solution or even any problemizing because it
happens extremely rarely and when it does, you can deal with it in the
mapping. This is, after all, an editing tool. A little human effort to
take care of problem that never happens is better than a lot of human
effort to ensure a problem that never happens /could/ never happen.
| (Or does HTML and/or XML already require that the tag & attribute names
| be disjoint?)
Attribute names are local to an element (please note the terminology),
but element names are global.
| That's why I somewhat prefer \foo{...} to {foo ...}, since I tend to
| use curlies in writing plain text (e.g., sample C code), and almost
| never use "\". (MS users MMV.)
The whole point here is to make the syntax more navigable with Emacs, not
less so than *ML.
| TeX has shown that \entity and \func{...} can coexist, has it not?
Yes, by attaching magic meaning to whitespace. I want unescaped { and }
to be markup, unconditionally.
I believe we have different goals with the syntax. Besides, I want to
clean up the fantastically ugly mess that is TeX, too, not mimic it.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
>>>>> On Wed, 13 Nov 2002 08:31:01 GMT, Kenny Tilton ("Kenny") writes:
Kenny> If Lispers feel justified in getting hysterical over a non-issue like
Kenny> StudlyCaps vs studly-caps, why are they surprised that The Great
Kenny> Unwashed have a cow over parentheses?
I'm not sure what you're trying to say in the first part,
but as to the second: who's surprised?
Kenny Tilton wrote:
> If Lispers feel justified in getting hysterical over a non-issue like
> StudlyCaps vs studly-caps, why are they surprised that The Great
> Unwashed have a cow over parentheses?
I don't want to make any sweeping generalizations, but it seems to me
that both of these reactions spring from something analogous to a rule
of thumb that when you are in country X, you ought to try not only to
speak the language of country X with syntactic correctness, but also use
the appropriate semantics and idioms of that language.
Having a cow over parentheses is like going to, say, China and just
speaking English to everyone, expecting them to understand. And when
they don't understand, the solution is to speak English louder and
slower. I suppose natives oughtn't necessarily be surprised at this
behavior, but it might somewhat justify the tendency of the natives to
think that the foreigners were a bunch of bloody morons.
Similarly, if you know and speak the language, but don't fully
understand the idioms and colloquial usage, you might say something that
people don't fully understand, or that just seems a bit "off" to them.
This is not necessarily cause to get hysterical, but it's not
necessarily an irrational behavior, either. Carrying this back to
programming, when I program in Java, I use StudlyCaps, because it fits
in with what (apparently) most other people, including the library
designers, do. When I'm writing Common Lisp, I use non-studly-caps for
the same reasons.
Joe
Joseph Dale wrote:
> Kenny Tilton wrote:
>
>> If Lispers feel justified in getting hysterical over a non-issue like
>> StudlyCaps vs studly-caps, why are they surprised that The Great
>> Unwashed have a cow over parentheses?
>
>
> Similarly, if you know and speak the language, but don't fully
> understand the idioms and colloquial usage, you might say something that
> people don't fully understand, or that just seems a bit "off" to them.
> This is not necessarily cause to get hysterical, but it's not
> necessarily an irrational behavior, either.
Agreed. My use of "hysterical" was a bit over the top, but I have in the
past gotten some relatively strong objections to my use of StCaps. I
plan to back off that for shared stuff precisely to do as Romans do.
But my implicit point was that, in re extending the use of Lsip, sexprs
are a much bigger problem than it should be, because other people have
generalized the conventional synatx to be the preferred appearance of
all languages.
Mind you, I am not saying change the syntax. Dylan been there done that
to no avail, at the cost of losing a lot of Lispers.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>
>Joseph Dale wrote:
>> Kenny Tilton wrote:
>>
>>> If Lispers feel justified in getting hysterical over a non-issue like
>>> StudlyCaps vs studly-caps, why are they surprised that The Great
>>> Unwashed have a cow over parentheses?
>>
>>
>> Similarly, if you know and speak the language, but don't fully
>> understand the idioms and colloquial usage, you might say something that
>> people don't fully understand, or that just seems a bit "off" to them.
>> This is not necessarily cause to get hysterical, but it's not
>> necessarily an irrational behavior, either.
>
>Agreed. My use of "hysterical" was a bit over the top, but I have in the
>past gotten some relatively strong objections to my use of StCaps. I
>plan to back off that for shared stuff precisely to do as Romans do.
Quite apart from the social aspect, I am intrigued that
you are actually able to use StudlyCaps in something
approaching a natural fashion in CL... How?
Dorai Sitaram wrote:
> Quite apart from the social aspect, I am intrigued that
> you are actually able to use StudlyCaps in something
> approaching a natural fashion in CL... How?
Not sure what you mean by how or "natural fashion", but maybe you mean
where/when do I use them?
I use them for class names and slot names. functions get hyphens.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
In article <··············@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>Dorai Sitaram wrote:
>> Quite apart from the social aspect, I am intrigued that
>> you are actually able to use StudlyCaps in something
>> approaching a natural fashion in CL... How?
>
>Not sure what you mean by how or "natural fashion", but maybe you mean
>where/when do I use them?
>
>I use them for class names and slot names. functions get hyphens.
My question is very basic. I mean how do you get
CL to accept
(defun StudlyCaps ... etc)
without too much pain on your part? I assume you
are not using approaches like |StudlyCaps| or
\Studly\Caps, which would be tedious.
Dorai Sitaram wrote:
>
> My question is very basic. I mean how do you get
> CL to accept
>
> (defun StudlyCaps ... etc)
>
> without too much pain on your part? I assume you
> are not using approaches like |StudlyCaps| or
> \Studly\Caps, which would be tedious.
CL does not mind. Of course, it ignores my studlification so I can code
(make-instance 'ixgrid... as well as IXGrid.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
> CL does not mind. Of course, it ignores my studlification so I can code
> (make-instance 'ixgrid... as well as IXGrid.
'Beware the modern mode, my son!
The jaws that bite, the case that catch'
(sounds of Edward Lear spinning at about 16rpm).
Twas brillig...,
:)w
Will Deakin wrote:
> Kenny Tilton wrote:
>
>> CL does not mind. Of course, it ignores my studlification so I can code
>> (make-instance 'ixgrid... as well as IXGrid.
>
>
> 'Beware the modern mode, my son!
> The jaws that bite, the case that catch'
>
true, true, one recipient of cells found all the places i had gotten
sloppy with case. i suppose that's one good argument against studlies,
provided one can come up with a good argument /for/ modern mode.
Me, not sure why, but case insensitivity is one of Lisp's nicer features.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Hi Kenny Tilton,
> true, true, one recipient of cells found all the places i had gotten
> sloppy with case. i suppose that's one good argument against studlies,
> provided one can come up with a good argument /for/ modern mode.
You don't need to come with any good argument for the so-called modern
mode. Instead explain why you want your libraries to break if loaded in
the useful ANSI defined :invert mode.
> Me, not sure why, but case insensitivity is one of Lisp's nicer
> features.
ANSI CL is not case insensitive. But I understand what you meant to say.
Regards,
Adam
Hi Will Deakin,
> Kenny Tilton wrote:
>
>> CL does not mind. Of course, it ignores my studlification so I can code
>> (make-instance 'ixgrid... as well as IXGrid.
>
> 'Beware the modern mode, my son!
> The jaws that bite, the case that catch'
>
> (sounds of Edward Lear spinning at about 16rpm).
>
> Twas brillig...,
>
> :)w
:-) Forget the so-called `modern' mode. This breaks plain olde fashioned
*read-table* :invert.
If one must use StudlyCaps and it is desired that the code also works when
loaded with *read-table* :invert then always refer to the symbols in their
defined case. And of course don't type the built in symbols in uppercase.
As I'm yet to come across anyone who prefers to type CL symbol names in
uppercase this is no great loss.
Regards,
Adam
* ADAM WARNER
| AS I'M YET TO COME ACROSS ANYONE WHO PREFERS TO TYPE CL SYMBOL NAMES IN
| UPPERCASE THIS IS NO GREAT LOSS.
IT IS ACTUALLY QUITE INTERESTING TO TRY THIS. IN EMACS, C-X C-U WILL VERY
HAPPILY GIVE YOUR ENTIRE WORK A QUAINT ARCHAIC FEELING. YOU CAN VIRTUALLY
HEAR THE PRINTER CHURN OUT ILLUMINATED PARCHMENT.
I WISH THERE WERE SOME WAY TO MAKE "ALIASES" FOR SYMBOLS IN COMMON LISP
SO THAT WE COULD HAVE BOTH UPPER- AND LOWER-CASE SYMBOL NAMES, BUT NO
SUCH LUCK.
--
ERIK NAGGUM, OSLO, NORWAY
ACT FROM REASON, AND FAILURE MAKES YOU RETHINK AND STUDY HARDER.
ACT FROM FAITH, AND FAILURE MAKES YOU BLAME SOMEONE AND PUSH HARDER.
Hi Erik Naggum,
> * ADAM WARNER
> | AS I'M YET TO COME ACROSS ANYONE WHO PREFERS TO TYPE CL SYMBOL NAMES
> | IN UPPERCASE THIS IS NO GREAT LOSS.
>
> IT IS ACTUALLY QUITE INTERESTING TO TRY THIS. IN EMACS, C-X C-U WILL
> VERY HAPPILY GIVE YOUR ENTIRE WORK A QUAINT ARCHAIC FEELING. YOU CAN
> VIRTUALLY HEAR THE PRINTER CHURN OUT ILLUMINATED PARCHMENT.
>
> I WISH THERE WERE SOME WAY TO MAKE "ALIASES" FOR SYMBOLS IN COMMON
> LISP SO THAT WE COULD HAVE BOTH UPPER- AND LOWER-CASE SYMBOL NAMES,
> BUT NO SUCH LUCK.
Yes, I know the work you put into trying to achieve this. By the way your
`...they killed Kenny' line earlier in this thread really made me LOL.
Regards,
Adam
Adam Warner wrote:
> Hi Erik Naggum,
>
> By the way your
> `...they killed Kenny' line earlier in this thread really made me LOL.
>
Screw you guys, I'm going home.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Hello!
Dorai Sitaram <····@gte.com> wrote:
>[...]
>My question is very basic. I mean how do you get
>CL to accept
>(defun StudlyCaps ... etc)
>without too much pain on your part? I assume you
>are not using approaches like |StudlyCaps| or
>\Studly\Caps, which would be tedious.
One possibility is: just let CL fold the case to upcase as it
does always (i.e. the symbol's really named "STUDLYCAPS").
Another one is: (setf (readtable-case *readtable*) :invert)
Kind regards,
Hannah.
On Wed, 13 Nov 2002 10:03:09 GMT, Joseph Dale <·········@sbcglobal.net>
wrote:
> Kenny Tilton wrote:
> > If Lispers feel justified in getting hysterical over a non-issue like
> > StudlyCaps vs studly-caps, why are they surprised that The Great
[...]
> Similarly, if you know and speak the language, but don't fully
> understand the idioms and colloquial usage, you might say something that
> people don't fully understand, or that just seems a bit "off" to them.
> This is not necessarily cause to get hysterical, but it's not
> necessarily an irrational behavior, either. Carrying this back to
StudlyCaps symbols, for example, may be less user-friendly with grep than
studly-caps ones. If you are not sure about the consistency of style
conventions of a particular code base, you have to search for:
[Ss]tudly[Cc]aps
in the former case, but just:
studly.caps
in the latter case. This may just be an inconvenience, and there are
probably better tools to search Lisp code. But you get the picture.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso wrote:
> StudlyCaps symbols, for example, may be less user-friendly with grep than
> studly-caps ones. If you are not sure about the consistency of style
> conventions of a particular code base, you have to search for:
>
> [Ss]tudly[Cc]aps
>
> in the former case, but just:
>
> studly.caps
>
> in the latter case. This may just be an inconvenience, and there are
> probably better tools to search Lisp code. But you get the picture.
if you're using grep, you might as well do <grep -i 'studly.?caps'>,
which gets them all.
--
Joost Kremers http://baserv.uci.kun.nl/~jkremers
lrwxrwxrwx 1 root root 11 nov 2 21:37 vi -> emacsclient*
The majority of programming languages aren't specified with s-exprs, being
biased towards Algol like syntax. It's most likely that a persons first
language contact will be with an Algol syntax biased language. Until
further education takes place, the parenthesis may seem puzzling.
I'm not sure if Lispers find this surprising. Tedious, predictable maybe.
I remember first coming across Lisp (years ago), being a C/C++ programmer,
and being hit by:
1. Parenthesis.
2. Strange keywords (lambda, car, cdr, mapcar...)
Because I found Lisp looked totally different to other languages, I was
hooked.
How many non-Lisp programmers ever have parenthesis/s-exprs explained to
them? That they don't exist soley to make Lisp look funky or obscure but
are instrumental in providing a higher level of programming flexibility and
power?
The keywords take some explaining because they are either legacy or of
mathmatical origin, which may be beyond the knowledge base of many
programmers.
As a side note, the other thing that might put people of is seeing how the
Lisp community continues to ruthlessly tear pieces our of each other.
Hark, I hear the distant engines of the mighty flame chariots...
--
Justin Johnson
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
···············@nyc.rr.com...
> If Lispers feel justified in getting hysterical over a non-issue like
> StudlyCaps vs studly-caps, why are they surprised that The Great
> Unwashed have a cow over parentheses?
>
> --
>
> kenny tilton
> clinisys, inc
> ---------------------------------------------------------------
> ""Well, I've wrestled with reality for thirty-five years, Doctor,
> and I'm happy to state I finally won out over it.""
> Elwood P. Dowd
>
"Justin Johnson" <·······@mobiusent.com> wrote in message news:<··················@demeter.uk.clara.net>...
> I remember first coming across Lisp (years ago), being a C/C++ programmer,
> and being hit by:
>
> 1. Parenthesis.
> 2. Strange keywords (lambda, car, cdr, mapcar...)
I must be the only person in the entire world who can hold strangeness
unevaluated.
> Because I found Lisp looked totally different to other languages, I was
> hooked.
At least you're a neophile =) Seen Forth?
> The keywords take some explaining because they are either legacy or of
> mathmatical origin, which may be beyond the knowledge base of many
> programmers.
I suppose that there are many programmers who were ignorant of the origin
of car/cdr/lambda' -- but I don't see how this ignorance necessitates
more explaining. "Undefined terms" from Geometry come to mind.
> As a side note, the other thing that might put people of is seeing how the
> Lisp community continues to ruthlessly tear pieces our of each other.
After listening to cll for a month or so, I've seen many people
complaining about all the violence and no violence. Maybe if people
started ignoring it they would see that it isn't there?
* ············@hotmail.com (Julian Fondren)
| I must be the only person in the entire world who can hold strangeness
| unevaluated.
Cute, but I believe everyone who can is liable to feel that way.
| After listening to cll for a month or so, I've seen many people
| complaining about all the violence and no violence. Maybe if people
| started ignoring it they would see that it isn't there?
comp.lang.lisp has evolved beyond violence. We have meta-violence!
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Justin Johnson wrote:
> Because I found Lisp looked totally different to other languages, I was
> hooked.
Good one.
> As a side note, the other thing that might put people of is seeing how the
> Lisp community continues to ruthlessly tear pieces our of each other.
I noticed the sme thing at my tai chi school. You'd think we'd be thick
as thieves since we all have the same special interest and even the same
teacher. Not! So my theory is: create any group of people and infighting
and gossip will break out immediately.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
> ...So my theory is: create any group of people and infighting and
> gossip will break out immediately.
Ahhh. It is the inner monkey in us all trying to escape...
;)w
In article <············@sparta.btinternet.com>, Will Deakin
<···········@hotmail.com> wrote:
>Kenny Tilton wrote:
>
>> ...So my theory is: create any group of people and infighting and
>> gossip will break out immediately.
>
>Ahhh. It is the inner monkey in us all trying to escape...
No more dancing monkeys please.
sv0f wrote:
> I wrote:
> >Ahhh. It is the inner monkey in us all trying to escape...
> No more dancing monkeys please.
The image I have is more gurning than prancing.
:)w
Kenny Tilton <·······@nyc.rr.com> writes:
> Justin Johnson wrote:
> > Because I found Lisp looked totally different to other languages, I was
> > hooked.
>
> Good one.
>
> > As a side note, the other thing that might put people of is seeing how the
> > Lisp community continues to ruthlessly tear pieces our of each other.
Well there are two main ideas about how to treat peers here:
1: be nice to people when you point out there mistakes, so they do not
become hurt
2: correct people and expect them to deal with it like adults and
professionals
I belong to two. And there have been discussions between them about
method.
We also have more then our fair share of nuts that wander in and
sometimes stay. The you said dirty words brigade comes to mind, not
the people who are in group one. But the I will use these
unacceptable words/tactic, that I abhor, against you the foul evil
one nut jobs that come out of left field. They almost always attack
Erik out of the blue.
>
> I noticed the sme thing at my tai chi school. You'd think we'd be
> thick as thieves since we all have the same special interest and even
> the same teacher. Not! So my theory is: create any group of people and
> infighting and gossip will break out immediately.
>
Well are you all there for the same reason? There is the classic
guys in a cooking class bit that says "If a guy signs up for a cooking
class he is probably there to meet women, learning to cook is not the
main reason" . And yes some men want to learn to cook.
Another theory is that groups form in response to outside pressure,
they are forged. Your school has no external force pushing you
together.
marc
>
> --
>
> kenny tilton
> clinisys, inc
> ---------------------------------------------------------------
> ""Well, I've wrestled with reality for thirty-five years, Doctor,
> and I'm happy to state I finally won out over it.""
> Elwood P. Dowd
* Justin Johnson
| As a side note, the other thing that might put people of is seeing how
| the Lisp community continues to ruthlessly tear pieces our of each other.
The Lisp community? You mean, like the Black community and the Jewish
community and the Muslim community do horrible things that you can fault
every Black, Jew, and Muslim for, respectively (or disrespectively :)? Or
did you have something less sinister in mind? Perhaps you should upgrade
your mind with the concept of "Individual"? With a Common Lisp mind, you
can load patches right into the running image and not have to wait to be
reincarnated.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
+ Erik Naggum <····@naggum.no>:
| With a Common Lisp mind, you can load patches right into the
| running image and not have to wait to be reincarnated.
Ooooh, that's handy. Does that also mean I won't have to explicitly
get rid of bad ideas? Just stop referring to them and the garbage
collector will silently remove them?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
* Harald Hanche-Olsen
| Does that also mean I won't have to explicitly get rid of bad ideas?
| Just stop referring to them and the garbage collector will silently
| remove them?
Yes, with a Common Lisp mind, you do not have to free your mind.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On 13 Nov 2002 21:46:43 +0000, Erik Naggum <····@naggum.no> wrote:
>
> Yes, with a Common Lisp mind, you do not have to free your mind.
wow-punch-line!! :)
morphius: free .... your .... mind!
neo: ?? err.... but have a GC - dont forget I am a hacker!
morphius: you are the ONE!!!
--
quasi
http://abhijit-rao.tripod.com/digital/lisp.html
"I slept with Faith, and found a corpse in my arms on awaking; I drank and danced all night with Doubt, and found her a virgin in the morning."
~ A. Crowley
* Justin Johnson <·······@mobiusent.com>:
> All I was trying to say was that the nature of some debates on this ng
> /might/ put people off when first learning Lisp and visiting here.
If you witnessed an argument in a public house, would it put you off
drinking?
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
| If you witnessed an argument in a public house, would it put you off
| drinking?
If the argument got to the point where people were shouting loudly and
generally being offensive and maybe even started throwing chairs about then
I wouldn't be surprised to find people that had just arrived leaving
quickly.
--
Justin Johnson
"Dave Pearson" <··········@davep.org> wrote in message
······························@hagbard.davep.org...
| * Justin Johnson <·······@mobiusent.com>:
|
| > All I was trying to say was that the nature of some debates on this ng
| > /might/ put people off when first learning Lisp and visiting here.
|
| If you witnessed an argument in a public house, would it put you off
| drinking?
|
| --
| Dave Pearson: | lbdb.el - LBDB interface.
| http://www.davep.org/ | sawfish.el - Sawfish mode.
| Emacs: | uptimes.el - Record emacs uptimes.
| http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
"Justin Johnson" <·······@mobiusent.com> writes:
> | If you witnessed an argument in a public house, would it put you
> | off drinking?
>
> If the argument got to the point where people were shouting loudly
> and generally being offensive and maybe even started throwing chairs
> about then I wouldn't be surprised to find people that had just
> arrived leaving quickly.
Heh. My grandpa used to /enter/ a bar when he heard people shouting
and fighting inside. After some really load noises, everything would
be quiet and peaceful and he'd get out again. But then, he also
survived Stalingrad and Sibiria...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
* Justin Johnson <·······@mobiusent.com>:
> | If you witnessed an argument in a public house, would it put you off
> | drinking?
>
> If the argument got to the point where people were shouting loudly and
> generally being offensive and maybe even started throwing chairs about
> then I wouldn't be surprised to find people that had just arrived leaving
> quickly.
IOW, they wouldn't be put off drinking (learning Lisp) but they might be put
off frequenting the public house (the newsgroup that contains the "fights").
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
"Justin Johnson" <·······@mobiusent.com> writes:
> Point taken. It was an over generalization.
>
> It might have been better worded as: some people within the community
> continue to ruthlessly tear pieces out of each other.
>
> Although when reading this ng for a while you can't help but feel that there
> is a degree of civil war in the Lisp camps. The Common Lisp camp seems to
> have a firm hold over this particular ng, other Lispers will be tarred and
> feathered, Schemers will be shot at dawn for their academic tom foolery.
no I have seen helpfull and friendly discussions about ISO Lisp. But
with that said scheme, elisp and autolisp have there own groups and
they generaly get pointed there. If someone say's that
scheme/dlyan/perl/fortran is real cool and why do not you Common Lisp
people get with the program then it can get a little warm. The thing
is that schemers come here a lot and basicly start shit repetedly with
"Why do not you do this like scheme", tail recursion comes up a lot.
marc
* Justin Johnson
| Although when reading this ng for a while you can't help but feel that there
| is a degree of civil war in the Lisp camps. The Common Lisp camp seems to
| have a firm hold over this particular ng, other Lispers will be tarred and
| feathered, Schemers will be shot at dawn for their academic tom foolery.
Oh, but this one is easy. Scheme has its own community. Their basic
misconception in this world is that since they know Scheme, they know
something about Common Lisp. This is like telling Pat Robertson that
Islam is a religion and Christianity is a religion, so of course they
ought to be friends and please stop this silly warring and in-fighting.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Kenny Tilton <·······@nyc.rr.com> writes:
> If Lispers feel justified in getting hysterical over a non-issue like
> StudlyCaps vs studly-caps, why are they surprised that The Great
> Unwashed have a cow over parentheses?
I think I missed the StudlyCaps issue, so I don't know what you
mean. Hysterical people abound: it is wise to ignore them.
Now that trick with the cow and the paretheses sounds really
interesting...
Regs.
Mario S. Mommer
Kenny Tilton <·······@nyc.rr.com> writes:
> If Lispers feel justified in getting hysterical over a non-issue like
> StudlyCaps vs studly-caps, why are they surprised that The Great
> Unwashed have a cow over parentheses?
I honestly think StudlyCaps are inherently more difficult to read.
S-expressions, c_style_word_delimiting, and lisp-style-word-delimiting
all only took be a very brief time to get used to. StudlyCaps took me
a while. Now that I'm used to them, I have no problem, and I write
ClassName, slotName, and so on, when I Talk Small.
For StudlyCaps in Lisp, my first instinct is "Don't do it!". My next
instinct is, well ... if you want to do it, don't use :invert
readtable-case, and make sure that you hyphenate where things would
get hard to read alllowercase; because, you might want to write in
StudlyCaps, but if I'm using your code, I don't want your function and
slot and class names to stick out LikeASoreThumb in my code.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> For StudlyCaps in Lisp, my first instinct is "Don't do it!". My next
> instinct is, well ... if you want to do it, don't use :invert
> readtable-case
Well, I would have to disagree. I think that if you want to go
with a case-sensitive style, then using :invert for readtable-case
is the only way to go. I can't imagine wanting to have to type
all the built-in lisp functions in UPPERCASE will be convenient,
but to each his own.
-Tom.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > For StudlyCaps in Lisp, my first instinct is "Don't do it!". My next
> > instinct is, well ... if you want to do it, don't use :invert
> > readtable-case
>
> Well, I would have to disagree. I think that if you want to go
> with a case-sensitive style, then using :invert for readtable-case
> is the only way to go.
If you own the world, go ahead. But if I want to use your code
written with an invert-case readtable, I'll have to do this:
(frob-slot (\Some\Slot obj))
That's kind of anti-social.
> I can't imagine wanting to have to type all the built-in lisp
> functions in UPPERCASE will be convenient, but to each his own.
??? That's not how it works:
(setf (readtable-case *readtable*) :invert) => :invert
(symbol-name 'foo) => "FOO"
(symbol-name 'FOO) => "foo"
(symbol-name 'Foo) => "Foo"
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@tornado.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > I can't imagine wanting to have to type all the built-in lisp
> > functions in UPPERCASE will be convenient, but to each his own.
>
> ??? That's not how it works:
>
> (setf (readtable-case *readtable*) :invert) => :invert
> (symbol-name 'foo) => "FOO"
> (symbol-name 'FOO) => "foo"
> (symbol-name 'Foo) => "Foo"
What I meant was that if one didn't use :INVERT, then writing
case-sensitive code would probably entail using :PRESERVE as the
readtable case. With :PRESERVE, one would need to type the built-in
functions in UPPERCASE.
- Tom.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@tornado.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > > For StudlyCaps in Lisp, my first instinct is "Don't do it!". My next
> > > instinct is, well ... if you want to do it, don't use :invert
> > > readtable-case
> >
> > Well, I would have to disagree. I think that if you want to go
> > with a case-sensitive style, then using :invert for readtable-case
> > is the only way to go.
>
> If you own the world, go ahead. But if I want to use your code
> written with an invert-case readtable, I'll have to do this:
>
> (frob-slot (\Some\Slot obj))
>
> That's kind of anti-social.
That seems to apply to any case-sensitive code, regardless of whether it
is written with :invert or :preserve or even with escape syntax in one's
own code:
(defun |SomeSlot| (obj)
(|annoyLispHackers| obj))
It just seems that if one wishes to buck the Lisp convention, the most
convenient way is via readtablecase = :invert.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
* Kenny Tilton
| If Lispers feel justified in getting hysterical over a non-issue like
| StudlyCaps vs studly-caps, why are they surprised that The Great Unwashed
| have a cow over parentheses?
Because if anyone gets hysterical over it, it is because you import the
conventions of another language into Common Lisp, and if they are
surprised that the masses have a cow over parentheses, it is because they
take with them the conventions of other languages into Common Lisp.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> * Kenny Tilton
> | If Lispers feel justified in getting hysterical over a non-issue like
> | StudlyCaps vs studly-caps, why are they surprised that The Great Unwashed
> | have a cow over parentheses?
>
> Because if anyone gets hysterical over it, it is because you import the
> conventions of another language into Common Lisp,
To be precise, the importation from another language is how others
construe what is simply me naming classes and slots as I prefer.
This is like someone getting attacked for wearing their favorite colors
in a neighborhood where certain street gangs attach unexpected
significance to those colors.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
* Kenny Tilton
| To be precise, the importation from another language is how others
| construe what is simply me naming classes and slots as I prefer.
I see that you conveniently elided the balancing point of the sentence in
order to get that stupid comment in,which would not be possible if you
had kept it. I prefer honest people.
| This is like someone getting attacked for wearing their favorite colors
| in a neighborhood where certain street gangs attach unexpected
| significance to those colors.
Oh, my God, they killed Kenny!
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> * Kenny Tilton
> | To be precise, the importation from another language is how others
> | construe what is simply me naming classes and slots as I prefer.
>
> I see that you conveniently elided the balancing point of the sentence in
> order to get that stupid comment in,which would not be possible if you
> had kept it.
Nonsense, I quoted enough to show the clause with which I was concerned,
"you import". the issue was the perhaps (perhaps, I say) idiomatic use
of "you" where "one" would also have served. Not knowing if the intent
of "you" was me, I simply offered my comment "to be precise", only
narrowing the number of interpretations in play, perhaps still to
include your meaning. Indeed, the "you import" may not have been
intended to mean i was deliberately wearing gang colors on their turf,
as in "you (only incidentally) import", one more reason to merely
precisify the story while avoiding language of contradiction.
Offense was taken anyway where none was intended and indeed was
scurpulously avoided, providing support for those who think NG exchanges
should eschew bluntness.
> I prefer honest people.
Not me. They might turn me in.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
"Kenny Tilton" <·······@nyc.rr.com> wrote in message ·····················@nyc.rr.com...
> This is like someone getting attacked for wearing their favorite colors
> in a neighborhood where certain street gangs attach unexpected
> significance to those colors.
>
hEY sTUDLYcAP! ((((dEFFUNING wITH uS UH????!))))
(hANDLER-cASE (aNOTHERcHANCE sTUDLYcAP)
(cAPITILIZATIONeRROR ()
(dEATHtO sTUDLYcAP)))
wADE
Wade Humeniuk wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message ·····················@nyc.rr.com...
>
>>This is like someone getting attacked for wearing their favorite colors
>>in a neighborhood where certain street gangs attach unexpected
>>significance to those colors.
>>
>
>
> hEY sTUDLYcAP! ((((dEFFUNING wITH uS UH????!))))
> (hANDLER-cASE (aNOTHERcHANCE sTUDLYcAP)
> (cAPITILIZATIONeRROR ()
> (dEATHtO sTUDLYcAP)))
OK, youse guys clearly have snapped. <G>
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd