MS discovers S-expressions
frr
Irrelevant, off-topic, but somehow funny ('those who ignore lisp are
doomed...)":
This is from MS site:
<uncle Bill says>
"XAML" is the primary way to create a UI in the "Longhorn" programming model
because it provides a way to separate UI definition from logic and enables
you to integrate code within or behind markup. The ability to mix code with
markup is important because XML does not support flow control well.
</uncle Bill says>
The last sentence is interesting and mentions one of the key features that
attracted me to Lisp: the ability to represent structured data (markup) and
code at the same time with sexprs.
Unfortunately, MS isn't reinventing the wheel, they are reinventing the
flat-tire (Mozilla's XUL).
"(...) XML does not support flow control well": That's precisely why it should
be discarded, specialy when there's a better alternative available (sexprs).
Sigh.....
Marc Spitzer
>
> The last sentence is interesting and mentions one of the key features that
> attracted me to Lisp: the ability to represent structured data (markup) and
> code at the same time with sexprs.
Well, sexprs do not support flow control, CL does and it *uses* sexprs
as the syntax of a lisp program, ie code and data.
after all what is (if (= a b) a b) as a sexpr? it becomes useful when
you give some special value to the token 'if' when it is in the correct
place in the sexpr.
>
> Unfortunately, MS isn't reinventing the wheel, they are reinventing the
> flat-tire (Mozilla's XUL).
>
> "(...) XML does not support flow control well": That's precisely why it should
> be discarded, specialy when there's a better alternative available (sexprs).
> Sigh.....
Well XML does not support anything well, even XML.
marc
Joe Marshall
> Well XML does not support anything well, even XML.
Except, perhaps, the toner and paper industries.
Erik Naggum
> Well XML does not support anything well, even XML.
* Joe Marshall
| Except, perhaps, the toner and paper industries.
Do not forget the memory and disk and bandwidth and Internet router
vendors. Where would we /be/ today if he had software as storage-
efficient as we had only 10 years ago? Take the Internet RFC index in
XML, which has 65% XML and 35% contents. Back when I did standards,
the telecom people designed things like ASN.1 with compact encodings
so they would not waste any /bits/. Now watch me stumble and lie here
on Memory Lane while the world rushes by.
--
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.
pete kirkham
> * Marc Spitzer
>
>>Well XML does not support anything well, even XML.
>
>
> * Joe Marshall
> | Except, perhaps, the toner and paper industries.
>
> Do not forget the memory and disk and bandwidth and Internet router
> vendors. Where would we /be/ today if he had software as storage-
> efficient as we had only 10 years ago? Take the Internet RFC index in
> XML, which has 65% XML and 35% contents. Back when I did standards,
> the telecom people designed things like ASN.1 with compact encodings
> so they would not waste any /bits/. Now watch me stumble and lie here
> on Memory Lane while the world rushes by.
>
starting to use the mapping of XML schema/relaxng/DTD to ASN.1 spec and
so define data that gets transmitted long hand to web browsers but as
binary where bandwidth matters. We also sometimes wrap our XML parsers
so they act as readers to our lisp interpreters, but everything ends up
written in Java if we want to 'sell' it.
Pete
Brandon J. Van Every
> * Marc Spitzer
>> Well XML does not support anything well, even XML.
>
> * Joe Marshall
>> Except, perhaps, the toner and paper industries.
>
> Do not forget the memory and disk and bandwidth and Internet router
> vendors. Where would we /be/ today if he had software as storage-
> efficient as we had only 10 years ago? Take the Internet RFC index
> in XML, which has 65% XML and 35% contents. Back when I did
> standards, the telecom people designed things like ASN.1 with
> compact encodings so they would not waste any /bits/. Now watch me
> stumble and lie here on Memory Lane while the world rushes by.
I wasn't aware that XML ever pretended to be a binary standard. I admit my
ignorance, but I thought it's supposed to be a "vaguely human-readable" text
standard. You seem to be complaining that everything should be encoded in
binary for efficiency purposes, dispensing with any other possible
criterion.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Marc Spitzer
> Erik Naggum wrote:
>> * Marc Spitzer
>>> Well XML does not support anything well, even XML.
>>
>> * Joe Marshall
>>> Except, perhaps, the toner and paper industries.
>>
>> Do not forget the memory and disk and bandwidth and Internet router
>> vendors. Where would we /be/ today if he had software as storage-
>> efficient as we had only 10 years ago? Take the Internet RFC index
>> in XML, which has 65% XML and 35% contents. Back when I did
>> standards, the telecom people designed things like ASN.1 with
>> compact encodings so they would not waste any /bits/. Now watch me
>> stumble and lie here on Memory Lane while the world rushes by.
>
> I wasn't aware that XML ever pretended to be a binary standard. I admit my
> ignorance, but I thought it's supposed to be a "vaguely human-readable" text
> standard. You seem to be complaining that everything should be encoded in
> binary for efficiency purposes, dispensing with any other possible
> criterion.
see binary:
<bit>0</bit>
marc
Henrik Motakef
> Erik Naggum wrote:
> > Do not forget the memory and disk and bandwidth and Internet router
> > vendors. Where would we /be/ today if he had software as storage-
> > efficient as we had only 10 years ago? Take the Internet RFC index
> > in XML, which has 65% XML and 35% contents. Back when I did
> > standards, the telecom people designed things like ASN.1 with
> > compact encodings so they would not waste any /bits/. Now watch me
> > stumble and lie here on Memory Lane while the world rushes by.
>
> I wasn't aware that XML ever pretended to be a binary standard. I admit my
> ignorance, but I thought it's supposed to be a "vaguely human-readable" text
> standard. You seem to be complaining that everything should be encoded in
> binary for efficiency purposes, dispensing with any other possible
> criterion.
Surely not everything, but seeing tools that are explicitly designed
to hide the "human-readable" format from any human's view makes you
wonder... Debugging auto-generated SOAP messages is not in any way
more fun than it would be with a binary protocol.
Kenny Tilton
Oh. Like?:
<hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit></hex>
Thx, that answers everything.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Rayiner Hashem
> doomed...)":
a poor job of it. C# 2.0 will have real closures and lambda (yay!) but
doesn't generalize iterators and enumerators on top of them (boo!).
Project Xen (the language formerly known as X#) will bring support for
some domain specific languages (SQL and XML) into C#, but they won't
provide a general framework (macros) for adding support for custom
ones. And oblivious to Lisp-family compiler technology, they retain
the struct/class distinction...
In one way it might be a good thing, since more people are exposed to
these powerful ideas, but its painful to see them being done so
hackishly...
Erik Naggum
| I wasn't aware that XML ever pretended to be a binary standard.
Good, because nobody said anything to that effect.
| I admit my ignorance, but I thought it's supposed to be a "vaguely
| human-readable" text standard. You seem to be complaining that
| everything should be encoded in binary for efficiency purposes,
| dispensing with any other possible criterion.
I do no such thing. Please learn to accept responsibility for your
interpretation of what other people write and try to do a better job
of reading what people actually write. Please become aware of your
preconceptions and unlearn your resemblace-based reasoning habits.
Just because something looks like something you know, does not mean
that it is what you already know. You need to be aware of differences
from what you already expect in order to avoid pissing people off by
pretending that they said what you object to.
Harald Hanche-Olsen
| <hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit></hex>
See also RFC 3252.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Marc Spitzer
> + Kenny Tilton <kti...@nyc.rr.com>:
>
> | <hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit></hex>
>
> See also RFC 3252.
And I thought I was making a bad joke.
marc
Ng Pheng Siong
> > See also RFC 3252.
> And I thought I was making a bad joke.
RFC 3252 - Binary Lexical Octet Ad-hoc Transport (BLOAT)
Issued on 1 Apr 2002.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
Dave Roberts
> Do not forget the memory and disk and bandwidth and Internet router
> vendors. Where would we /be/ today if he had software as storage-
> efficient as we had only 10 years ago? Take the Internet RFC index in
> XML, which has 65% XML and 35% contents. Back when I did standards,
> the telecom people designed things like ASN.1 with compact encodings
> so they would not waste any /bits/. Now watch me stumble and lie here
> on Memory Lane while the world rushes by.
>
Agreed on XML. It certainly is verbose. But I get shivers up my spine when
anybody mentions ASN.1. That is NOT the way to go. (Memories of various ATM
signalling specs and everything coming from ITU -- yuck!) ASN.1: bandwidth
efficient? Yes, generally so. Speed efficient? Not at all. Way too much
packing and unpacking to save a bit here or there. Personally, I vote for
things like Sun's old XDR (search Google for the RFC, it's used in NFS and
they standardized it in an RFC as a result). Not as comprehensive as ASN.1
in the whole data model and not quite as space efficient, but far more
efficient in space than XML and oodles faster than ASN.1. XDR assumes a
32-bit machine and aligns pretty much everything to a 32-bit boundary. Even
with endian swapping on an Intel machine (XDR is big-endian), it rocks.
Even that can be solved with the types of wire encodings used by DCE RPC
and CORBA.
Dave Roberts
Friedrich Dominicus
You did have seen it's name "BLOAT" and the date of publication?
Regards
Friedrich
Erik Naggum
| Agreed on XML. It certainly is verbose. But I get shivers up my spine
| when anybody mentions ASN.1. That is NOT the way to go.
This generally depends on the encoding rules. There are many of them.
Only some of them are CPU-intensive. Some of the problem is that
ASN.1 is not a precise match for the programming language's internal
data structures. Environments that make a better fit between ASN.1
and the data structures of the programming language suffer much less
than those that insist on using only «native» data structures.
Just for kicks, I did a search for «XML» at groups.google.com to see
its incidence rate and tabulated the results per month. One has to
search for many much shorter intervals, or the number of matches
becomes a useless constant, so in case anyone else wants to know, the
data and the simple figure are available here:
http://naggum.no/2004/024/651-xml-google.data
http://naggum.no/2004/024/692-xml-google.gif
Harald Hanche-Olsen
The 1 April RFCs are a great tradition. My personal favourite is
still RFC 1149, Standard for the transmission of IP datagrams on avian
carriers [i.e., carrier pigeons]. (And its follow-up RFC 2549, IP
over Avian Carriers with Quality of Service.)
Avian carriers can provide high delay, low throughput, and low
altitude service.
Rob Warnock
+---------------
| <hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit></hex>
|
| See also RFC 3252.
But note that RFC 3252 suggests (requires? -- I can't tell for sure)
that bitmasks be converted into "human-readable values", so the above
might be more properly represented as:
<hex value="2A"/>
Or maybe (lacking better names for the bits):
<hex bit7="0" bit6="0" bit5="1" bit4="0"
bit3="1" bit2="0" bit1="1" bit0="0"/>
or if one's DTD allows <hex> attributes to default to "0", then just:
<hex bit5="1" bit3="1" bit1="1"/>
But best, of course, would be if the bits' actual semantic meanings
were displayed, e.g, as in the <tos> and <flags> elements in the
example IP packet in Section 2.2:
...
<tos precedence="Routine" delay="Normal" throughput="Normal"
relibility="Normal" reserved="0"/>
...
<flags reserved="0" df="dont" mf="last"/>
...
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paul F. Dietz
> Agreed on XML. It certainly is verbose. But I get shivers up my spine when
> anybody mentions ASN.1. That is NOT the way to go. (Memories of various ATM
> signalling specs and everything coming from ITU -- yuck!) ASN.1: bandwidth
> efficient? Yes, generally so. Speed efficient? Not at all. Way too much
> packing and unpacking to save a bit here or there.
ASN.1's grammar is butt-ugly.
As for efficiency of using ASN.1 specifications -- doesn't this depend on
the encoding rules you've chosen? The packed encoding rules do require
a lot of bit twiddling, but presumably you use that when the bandwidth
really is tight (like, say, in wireless protocols.)
BTW, there are now XML encoding rules for ASN.1. :)
Paul
Marc Spitzer
Marc Spitzer
let me clarify, I looked at the rfc but forgot to check the date.
But my favorite rfc of all time is the rubber chicken rfc.
marc
Dave Roberts
> ASN.1's grammar is butt-ugly.
Yes, agreed.
> As for efficiency of using ASN.1 specifications -- doesn't this depend on
> the encoding rules you've chosen? The packed encoding rules do require
> a lot of bit twiddling, but presumably you use that when the bandwidth
> really is tight (like, say, in wireless protocols.)
Yes, it does. I'm assuming BER here. PER is even better for space, but again
suffers for speed of encoding/decoding. You can, of course, encode ASN.1 in
something that is totally inefficient, if you want. It just isn't typically
done that way. I guess that's your point, though--it's really an encoding
issue, not a specific ASN.1 issue.
> BTW, there are now XML encoding rules for ASN.1. :)
Yes. The general stupidity of people continues to amaze me... ;-)
Ray Dillinger
>
> let me clarify, I looked at the rfc but forgot to check the date.
>
> But my favorite rfc of all time is the rubber chicken rfc.
My favorite specified a network protocol for transmitting sheep over SONET.
Bear
Thomas F. Burdick
> Marc Spitzer wrote:
> >
> > let me clarify, I looked at the rfc but forgot to check the date.
> >
> > But my favorite rfc of all time is the rubber chicken rfc.
(Which one's that?)
> My favorite specified a network protocol for transmitting sheep over SONET.
Personally, I'm a fan of the Infinite Monkey Control Protocol Suite,
but then I like monkey jokes. Maybe I'll work on an implementation,
cl-monkies ;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Joe Marshall
>
> But my favorite rfc of all time is the rubber chicken rfc.
> Ray Dillinger <be...@sonic.net> writes:
>
> My favorite specified a network protocol for transmitting sheep over SONET.
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> Personally, I'm a fan of the Infinite Monkey Control Protocol Suite,
> but then I like monkey jokes. Maybe I'll work on an implementation,
> cl-monkies ;-)
These are good:
A High-Performance Coffee Maker
http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-09.pdf
Intensional Equality ;=) for Continuations.
Andrew W. Appel, ACM SIGPLAN Notices 31(2), pp. 55-57, February 1996
http://ncstrl.cs.princeton.edu/expand.php?id=TR-557-95
@article{ broder84pessimal,
author = "Broder and Stolfi",
title = "Pessimal Algorithms and Simplexity Analysis",
journal = "SIGACTN: SIGACT News (ACM Special Interest Group on Automata and Computability Theory)",
volume = "16",
year = "1984",
url = "citeseer.ist.psu.edu/334813.html" }
--
~jrm
Christopher Browne
> + Friedrich Dominicus <fr...@q-software-solutions.com>:
>
> | Marc Spitzer <mspi...@optonline.net> writes:
> |
> | > Harald Hanche-Olsen <han...@math.ntnu.no> writes:
> | >
> | >> + Kenny Tilton <kti...@nyc.rr.com>:
> | >>
> | >> | <hex><bit>0</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit><bit>1</bit><bit>0</bit></hex>
> | >>
> | >> See also RFC 3252.
> | >
> | > And I thought I was making a bad joke.
> | You did have seen it's name "BLOAT" and the date of publication?
>
> The 1 April RFCs are a great tradition. My personal favourite is
> still RFC 1149, Standard for the transmission of IP datagrams on avian
> carriers [i.e., carrier pigeons]. (And its follow-up RFC 2549, IP
> over Avian Carriers with Quality of Service.)
>
> Avian carriers can provide high delay, low throughput, and low
> altitude service.
What was even better was when a group actually implemented the RFC,
building the world's first RFC 1149 network in Norway.
http://www.blug.linux.no/rfc1149/
--
let name="aa454" and tld="freenet.carleton.ca" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/spiritual.html
"Microsoft has world class quality control" -- Arthur Norman
Olivier Dubuisson
> PER is even better for space, but again
> suffers for speed of encoding/decoding.
This is wrong.
The rationale is explained in the following excerpt of my book on
ASN.1 (Section 20.1) that you can freely download at
http://www.oss.com/asn1/dubuisson.html :
"Though not designed at first for this purpose, the PER provide
encoders
and decoders that generally take less processing time than their
BER counterparts, which goes against a common belief (it obviously
depends
on the ASN.1 specification, but twice as fast procedures are not
unusual). Indeed, many factors are determined statically, i.e. once
for
all during the compilation stage, and integrated in the encoder and in
the decoder. Besides, transfer is also faster than for BER because the
lowest layers of the network stack deal with shorter frames."
Olivier Dubuisson
Erik Naggum
| The rationale is explained in the following excerpt of my book on
| ASN.1 (Section 20.1) that you can freely download at
| http://www.oss.com/asn1/dubuisson.html :
Many, many thanks for making this and the other ASN.1 book available
for free download! The PDF files are just excellent.
--
Erik Naggum | Oslo, Norway 2004-026
Larry Elmore
> Dave Roberts wrote:
>
>> Agreed on XML. It certainly is verbose. But I get shivers up my spine
>> when
>> anybody mentions ASN.1. That is NOT the way to go. (Memories of
>> various ATM
>> signalling specs and everything coming from ITU -- yuck!) ASN.1:
>> bandwidth
>> efficient? Yes, generally so. Speed efficient? Not at all. Way too much
>> packing and unpacking to save a bit here or there.
>
> ASN.1's grammar is butt-ugly.
Yes, it's awful. Although I must say that in the field I work (telecom),
reading ASN.1 specs beats the hell out of some of the other ones I've
seen used, especially BNF.
> As for efficiency of using ASN.1 specifications -- doesn't this depend on
> the encoding rules you've chosen? The packed encoding rules do require
> a lot of bit twiddling, but presumably you use that when the bandwidth
> really is tight (like, say, in wireless protocols.)
It depends also on _which_ Packed Encoding Rules you've chosen. There's
aligned and unaligned versions. Unaligned is optimized for size, aligned
for CPU time.
> BTW, there are now XML encoding rules for ASN.1. :)
Oh, be still my heart.
--Larry
Håkon Alstadheim
> Dave Roberts <ld...@re-move.droberts.com> wrote in message news:<OdTQb.119082$nt4.497839@attbi_s51>...
>> PER is even better for space, but again
>> suffers for speed of encoding/decoding.
>
> This is wrong.
> The rationale is explained in the following excerpt of my book on
> ASN.1 (Section 20.1) that you can freely download at
> http://www.oss.com/asn1/dubuisson.html :
> "Though not designed at first for this purpose, the PER provide
> encoders
To others who want to look for the print version:
Following the link to the publisher you can search for the book.
Searching for "asn.1" gets you another book. For Dubuissons book you
need to search for "asn.i" :-).
--
Håkon Alstadheim, hjemmepappa.