I want to introduce an extremely important and hot topic... :D
Seriously, it's something I came across some time ago. Why do we have a
'1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
often find myself doing some kind of 'switching paradigms' between
infix and prefix notation in my head each time I read it in others
code; in fact, I often 'mistype' it in my own, having to change it.
Besides, think about it as a function. A function is 'something' you
give 'something' and makes 'something' with (great definition, isn't
it? :D). In this case, you give it a number and want the function to
'add 1' to it. So, in this way it's even more 'natural' to write it as
'+1'.
Cheers,
Luis.
LuisGLopez wrote:
> I want to introduce an extremely important and hot topic... :D
>
> Seriously, it's something I came across some time ago. Why do we have a
> '1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
> often find myself doing some kind of 'switching paradigms' between
> infix and prefix notation in my head each time I read it in others
> code; in fact, I often 'mistype' it in my own, having to change it.
>
> Besides, think about it as a function. A function is 'something' you
> give 'something' and makes 'something' with (great definition, isn't
> it? :D). In this case, you give it a number and want the function to
> 'add 1' to it. So, in this way it's even more 'natural' to write it as
> '+1'.
That's an even better argument for 1-, which decrements the parameter;
it does not subtract the parameter from 1. #'1+ and #'1- were given
names to make them not be potential numbers.
<http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_2-3-1-1.html>
When a potential number is parsed, the reader returns a number or
signals a reader error. Since functions are named by symbols, the names
for the increment and decrement functions can not be potential numbers.
-- MJF
LuisGLopez schrieb:
> I want to introduce an extremely important and hot topic... :D
>
> Why do we have a '1+' macro (I believe it is a macro, isn't it?) instead of '+1'?
> Besides, think about it as a function. A function is 'something' you
> give 'something' and makes 'something' with (great definition, isn't
> it? :D).
In both cases (1+ is a macro and the definition of functions) you were
not certain.
The next time when you are not certain you might want to check out this
internet site:
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
They call it the "Common Lisp HyperSpec". It explains a lot about lisp.
See:
http://www.lispworks.com/documentation/HyperSpec/Body/f_1pl_1_.htm
What is stated in the HS (short for "HyperSpec") usually is correct.
The HS says that 1+ is a function.
Wikipedia might not always be a great source for gathering knowledge...
but sometimes it does have good explanations. Didn't you hear of this
website yet? If yes, why didn't you check it out for the definition of
a function?
http://en.wikipedia.org/wiki/Function_%28mathematics%29#Formal_definition
André
--
Dear people,
I'm *deeply* sorry for my post; I should have gone to the proper place
in the first time, like CLHS, Wikipedia, etc. I didn't want to bother
anyone here. Please, excuse me.
Luis.
André Thieme ha escrito:
>
> In both cases (1+ is a macro and the definition of functions) you were
> not certain.
> The next time when you are not certain you might want to check out this
> internet site:
> http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
>
> They call it the "Common Lisp HyperSpec". It explains a lot about lisp.
> See:
> http://www.lispworks.com/documentation/HyperSpec/Body/f_1pl_1_.htm
> What is stated in the HS (short for "HyperSpec") usually is correct.
> The HS says that 1+ is a function.
>
> Wikipedia might not always be a great source for gathering knowledge...
> but sometimes it does have good explanations. Didn't you hear of this
> website yet? If yes, why didn't you check it out for the definition of
> a function?
> http://en.wikipedia.org/wiki/Function_%28mathematics%29#Formal_definition
On 2006-01-12 00:57:56 +0000, "LuisGLopez" <············@gmail.com> said:
> I'm *deeply* sorry for my post; I should have gone to the proper place
> in the first time, like CLHS, Wikipedia, etc. I didn't want to bother
> anyone here. Please, excuse me.
Don't apologize! Many lurkers I'm sure were happy that someone
did, and for extra credits, we got Pascal ++ definition which
is quite cute (though probably not that useful :-)
Well done!
--
JFB
"LuisGLopez" <············@gmail.com> wrote in message
·····························@g14g2000cwa.googlegroups.com...
>Dear people,
>
>I'm *deeply* sorry for my post; I should have gone to the proper place
>in the first time, like CLHS, Wikipedia, etc. I didn't want to bother
>anyone here. Please, excuse me.
>
>Luis.
There was nothing wrong with your post.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
For years i've been haunted by the 1- function becuase every time i'd
write a sigmoid i'd say (/ (1- (exp (- x)))) but it took me forever to
find out that 1- means -1, which of course NOW i know but i guess even
a faulty sigmoid function won't destroy the effectiveness of a neural
network. Which is actually one of the things that amazes me about
neural networks, you can set up SO many loose parameters and the system
will still operate, it's very......organic...that way.
PWBDecker
·········@gmail.com writes:
> For years i've been haunted by the 1- function becuase every time i'd
> write a sigmoid i'd say (/ (1- (exp (- x)))) but it took me forever to
> find out that 1- means -1, which of course NOW i know but i guess even
> a faulty sigmoid function won't destroy the effectiveness of a neural
> network. Which is actually one of the things that amazes me about
> neural networks, you can set up SO many loose parameters and the system
> will still operate, it's very......organic...that way.
Actually, this discussion proves once more that using special
characters to name operators is a bad idea. LISP started with PLUS,
MINUS, DIVIDE and MULTIPLY. Instead of proposing ++ and -- (which
indeed may be confonded with INCF and DECF via C/C++), I should have
proposed:
(defun DEC (x &optional (decrement 1)) (- x decrement))
(defun INC (x &optional (increment 1)) (+ x increment))
SET INC DEC : functions (work on values)
SETF INCF DECF : defsetfs (work on places)
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
Pascal Bourguignon <····@mouse-potato.com> writes:
> ·········@gmail.com writes:
> > For years i've been haunted by the 1- function becuase every time i'd
> > write a sigmoid i'd say (/ (1- (exp (- x)))) but it took me forever to
> > find out that 1- means -1, which of course NOW i know but i guess even
> > a faulty sigmoid function won't destroy the effectiveness of a neural
> > network. Which is actually one of the things that amazes me about
> > neural networks, you can set up SO many loose parameters and the system
> > will still operate, it's very......organic...that way.
>
> Actually, this discussion proves once more that using special
> characters to name operators is a bad idea. LISP started with PLUS,
> MINUS, DIVIDE and MULTIPLY.
A minor nit: it had PLUS, MINUS, TIMES, and QUOTIENT. The last is
especially no fun to type.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > ·········@gmail.com writes:
> > > For years i've been haunted by the 1- function becuase every time i'd
> > > write a sigmoid i'd say (/ (1- (exp (- x)))) but it took me forever to
> > > find out that 1- means -1, which of course NOW i know but i guess even
> > > a faulty sigmoid function won't destroy the effectiveness of a neural
> > > network. Which is actually one of the things that amazes me about
> > > neural networks, you can set up SO many loose parameters and the system
> > > will still operate, it's very......organic...that way.
> >
> > Actually, this discussion proves once more that using special
> > characters to name operators is a bad idea. LISP started with PLUS,
> > MINUS, DIVIDE and MULTIPLY.
>
> A minor nit: it had PLUS, MINUS, TIMES, and QUOTIENT. The last is
> especially no fun to type.
Certain Lisps even have DIFFERENCE (MINUS is unary minus). That is
even less fun to type.
Bj�rn
> Actually, this discussion proves once more that using special
> characters to name operators is a bad idea. LISP started with PLUS,
> MINUS, DIVIDE and MULTIPLY. Instead of proposing ++ and -- (which
> indeed may be confonded with INCF and DECF via C/C++), I should have
> proposed: [...]
Some Scheme implementations (e.g. PLT-Scheme) provide `add1' and `sub1'.
On Fri, 13 Jan 2006 10:23:48 +0100, Pascal Bourguignon <····@mouse-potato.com> wrote:
> Actually, this discussion proves once more that using special
> characters to name operators is a bad idea.
"Special" characters, hmm? Yeah, right, let's get rid of them. And
don't forget stuff like hyphen, asterisk, oder parenthesis.
LEFTPARENTHESIS UNWINDHYPHENPROTECT
LEFTPARENTHESIS PROGN LEFTPARENTHESIS INCF ASTERISKACCESSHYPHENCOUNTASTERISK RIGHTPARENTHESIS
LEFTPARENTHESIS PERFORMHYPHENACCESS RIGHTPARENTHESIS RIGHTPARENTHESIS
LEFTPARENTHESIS DECF ASTERISKACCESSHYPHENCOUNTASTERISK RIGHTPARENTHESIS RIGHTPARENTHESIS
certainly looks cleaner than stuff like
(unwind-protect
(progn (incf *access-count*)
(perform-access))
(decf *access-count*))
and it's really just a matter of some Emacs macros to get used to the
new notation.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Fri, 13 Jan 2006 10:23:48 +0100, Pascal Bourguignon <····@mouse-potato.com> wrote:
>
> > Actually, this discussion proves once more that using special
> > characters to name operators is a bad idea.
>
> "Special" characters, hmm? Yeah, right, let's get rid of them. And
> don't forget stuff like hyphen, asterisk, oder parenthesis.
>
> LEFTPARENTHESIS UNWINDHYPHENPROTECT
> LEFTPARENTHESIS PROGN LEFTPARENTHESIS INCF ASTERISKACCESSHYPHENCOUNTASTERISK RIGHTPARENTHESIS
> LEFTPARENTHESIS PERFORMHYPHENACCESS RIGHTPARENTHESIS RIGHTPARENTHESIS
> LEFTPARENTHESIS DECF ASTERISKACCESSHYPHENCOUNTASTERISK RIGHTPARENTHESIS RIGHTPARENTHESIS
No need to be all uppercase, and it'd definitely be easier to read if
you *really* delimited the tokens with, say, ampersands and semicolons.
> LEFTPARENTHESIS UNWINDHYPHENPROTECT
> LEFTPARENTHESIS PROGN LEFTPARENTHESIS INCF ASTERISKACCESS&ndashCOUNTASTERISK RIGHTPARENTHESIS
> LEFTPARENTHESIS PERFORM&ndashACCESS RIGHTPARENTHESIS RIGHTPARENTHESIS
> LEFTPARENTHESIS DECF ASTERISKACCESS&ndashCOUNTASTERISK RIGHTPARENTHESIS RIGHTPARENTHESIS
And while it is true that parens are completely unreadable, there are
less smooth pairing delimiters. These have the advantage of running
faster, too, I understand.
> <unwind-protect>
> <progn>
> <incf variable="∗access–count&lowast" />
> <funcall function="perform–access"></funcall>
> </progn>
<decf variable="∗access–count&lowast" />
> </unwind-protect>
I think everyone will agree that *that* is readable.
Joe Marshall wrote:
> Edi Weitz wrote:
> > On Fri, 13 Jan 2006 10:23:48 +0100, Pascal Bourguignon <····@mouse-potato.com> wrote:
> >
> > > Actually, this discussion proves once more that using special
> > > characters to name operators is a bad idea.
> >
> > "Special" characters, hmm? Yeah, right, let's get rid of them. And
> > don't forget stuff like hyphen, asterisk, oder parenthesis.
> >
> > LEFTPARENTHESIS UNWINDHYPHENPROTECT
> > LEFTPARENTHESIS PROGN LEFTPARENTHESIS INCF ASTERISKACCESSHYPHENCOUNTASTERISK RIGHTPARENTHESIS
> > LEFTPARENTHESIS PERFORMHYPHENACCESS RIGHTPARENTHESIS RIGHTPARENTHESIS
> > LEFTPARENTHESIS DECF ASTERISKACCESSHYPHENCOUNTASTERISK RIGHTPARENTHESIS RIGHTPARENTHESIS
>
> No need to be all uppercase, and it'd definitely be easier to read if
> you *really* delimited the tokens with, say, ampersands and semicolons.
>
> > LEFTPARENTHESIS UNWINDHYPHENPROTECT
> > LEFTPARENTHESIS PROGN LEFTPARENTHESIS INCF ASTERISKACCESS&ndashCOUNTASTERISK RIGHTPARENTHESIS
> > LEFTPARENTHESIS PERFORM&ndashACCESS RIGHTPARENTHESIS RIGHTPARENTHESIS
> > LEFTPARENTHESIS DECF ASTERISKACCESS&ndashCOUNTASTERISK RIGHTPARENTHESIS RIGHTPARENTHESIS
>
> And while it is true that parens are completely unreadable, there are
> less smooth pairing delimiters. These have the advantage of running
> faster, too, I understand.
>
> > <unwind-protect>
> > <progn>
> > <incf variable="∗access–count&lowast" />
> > <funcall function="perform–access"></funcall>
> > </progn>
> <decf variable="∗access–count&lowast" />
> > </unwind-protect>
>
> I think everyone will agree that *that* is readable.
I think you're forgetting that code-is-data. The far easier way to
write it is therefore:
<symbolic-expression xmlns="http://www.lisp.org/schema/sexpr">
<cons>
<car>
<symbol name="unwind-protect" package="common-lisp"/>
</car>
<cdr>
<cons>
<car>
<cons>
<car><symbol name="progn" package="common-lisp"/></car>
<cdr>
<cons>
<car>
<cons>
<car><symbol name="incf"
package="common-lisp"/></car>
<cdr>
<cons>
<car><symbol name="*access-count*"
package="common-lisp-user"/></car>
<cdr><nil/></cdr>
</cons>
</cdr>
</cons>
</car>
<cdr>
<cons>
<car>
<cons>
<car><symbol name="perform-access"
package="common-lisp-user"/></car>
<cdr><nil/></cdr>
</cons>
</car>
<cdr><nil/></cdr>
</cons>
</cdr>
</cons>
</cdr>
</cons>
</car>
<cdr>
<cons>
<car>
<cons>
<car><symbol name="decf"
package="common-lisp-user"/></car>
<cdr>
<cons>
<car><symbol name="*access-count*"
package="common-lisp-user"/></car>
<cdr><nil/></cdr>
</cons>
</cdr>
</cons>
</car>
<cdr><nil/></cdr>
</cons>
</cdr>
</cons>
</cdr>
</cons>
</symbolic-expression>
Which I think you'll all agree is far nicer.
Ah, I see. So you'd like what might be termed a _domain specific
language_ for representing Lisp code apart from its data.
I mean no offence, but such languages have been tried in the past and
been rejected by people, some of whom have doctorates. This clearly
shows that syntax is wrong.
Nevertheless, if you insist on your insane philosophy, you need to
adjust your XML schema for Lisp code to be more XML-y.
The first problem is that the arguments to UNWIND-PROTECT are
determined by order alone. This might work for a hobbyist language such
as Common Lisp, but for an industrial strength programming language
like XML, such a technique is sorely insufficient. The reason Latin has
such a vibrant history to this very day is that it clearly marks its
arguments rather then depending upon order and context. Clearly, XML
should follow suite if it is to emulate Latin's success as a computing
_lingua franca_.
This correction leads to:
> <unwind-protect>
> <protected-form>
> <progn>
> <incf variable="∗access–count&lowast" />
> <funcall function="perform–access"></funcall>
> </progn>
> </protected-form>
> <cleanup-form>
> <decf variable="∗access–count&lowast" />
> </cleanup-form>
> </unwind-protect>
Another subtle fault is that the incf and decf macros should accept
*forms*. The variable attribute is syntax sugar for the supremely rare
occasion where one is incfing a symbol, and if syntax is bad, syntax
*sugar* must be the very devil.
> <unwind-protect>
> <protected-form>
> <progn>
> <incf><variable name="∗access–count&lowast"/></incf>
> <funcall function="perform–access"></funcall>
> </progn>
> </protected-form>
> <cleanup-form>
> <decf><variable name="∗access–count&lowast" /></decf>
> </cleanup-form>
> </unwind-protect>
The same applies, of course, to the funcall function:
> <unwind-protect>
> <protected-form>
> <progn>
> <incf><variable name="∗access–count&lowast"/></incf>
> <funcall><function name="perform–access"></funcall>
> </progn>
> </protected-form>
> <cleanup-form>
> <decf><variable name="∗access–count&lowast" /></decf>
> </cleanup-form>
> </unwind-protect>
Having earlier noted that UNWIND-PROTECT's arguments should be marked,
we should obviously do the same for the other functions. For the sake
of consistency, we'll have every argument declared in the same way:
> <unwind-protect>
> <argument name="protected-form">
> <progn>
> <rest-argument name="form*">
> <element index="0">
> <incf>
> <argument name="place">
> <variable name="∗access–count&lowast"/>
> </argument>
> </incf>
> </element>
> <element index="1">
> <funcall>
> <argument name="function">
> <function name="perform–access">
> </argument>
> </funcall>
> </element>
> </rest-argument>
> </progn>
> </argument>
> <argument name="cleanup-form">
> <decf>
> <argument name="place">
> <variable name="∗access–count&lowast" />
> </argument>
> </decf>
> </argument>
> </unwind-protect>
Of course, optional arguments are only asking for trouble. To make
things easier on the programmer, "optional arguments" are upgraded to
"compulsary arguments with a default value".
> <unwind-protect>
> <argument name="protected-form">
> <progn>
> <rest-argument name="form*">
> <element index="0">
> <incf>
> <argument name="place">
> <variable name="∗access–count&lowast"/>
> </argument>
> <argument name="delta-form">
> <default-argument-value/>
> </argument>
> </incf>
> </element>
> <element index="1">
> <funcall>
> <argument name="function">
> <function name="perform–access">
> </argument>
> <rest-argument name="args"/>
> </funcall>
> </element>
> </rest-argument>
> </progn>
> </argument>
> <argument name="cleanup-form">
> <decf>
> <argument name="place">
> <variable name="∗access–count&lowast" />
> </argument>
> <argument name="delta-form">
> <default-argument-value/>
> </argument>
> </decf>
> </argument>
> </unwind-protect>
Comparing that jewel to the bloated and confusing Lisp original, the
benefits of the XML notation are obvious:
> (unwind-protect
> (progn (incf *access-count*)
> (perform-access))
> (decf *access-count*))
The XSLT stylsheet itself is left as an exercise for the reader.
Nathan Baum wrote:
> Ah, I see. So you'd like what might be termed a _domain specific
> language_ for representing Lisp code apart from its data.
>
> I mean no offence, but such languages have been tried in the past and
> been rejected by people, some of whom have doctorates. This clearly
> shows that syntax is wrong.
Yeah, yeah, but they're not `real' Doctors.
> Nevertheless, if you insist on your insane philosophy, you need to
> adjust your XML schema for Lisp code to be more XML-y.
[code elided]
You laugh now, but you're gonna start getting job offers for hacking
XML if you keep going on like this.
On Sat, 14 Jan 2006 21:59:12 +0100, Nathan Baum
<···········@btinternet.com> wrote:
You are serious :)
I interpreted the post as a joke.
Lisp sexpr for a representation for code that is equal in power to XML.
Like many lispers I therefore have a rather cool attitude on the
direction XML has been going.
Well I was fine with XML 1.0, XTD, XHTML, XML-RPC 1.0.
I am not that wild about XSL, XSLT, SOAP.
It is true I am not an expert in either so feel free to correct me if I am
wrong
Seems to me XSLT is a attept to write a programming language in XML.
1. It is verbose thus consuming excess bandwidth.
2. It is inefficient for a computer to interpret.
3. It is equally inefficient for a programmer to write.
Seems to me the worst of all possible worlds.
Wouln't you be better off with Perl? (shudder)
Then it is the whole motivation of what XLM is trying to do.
To make one representation that fits all. Particularly
the Dublin project for a general toxonometry of all data.
Wasn't this tried in Philosophy (rationalism / Russel / Principia
Matematika)?
And did not Withgenstein in fact prove that this is impossible?
Database theory dictates that 3 metaplanes are neccesary and sufficient.
1. Data
2. tables and relations
3. shema for describing the structure
Seems you need to intersect the object with the universe of discourse.
Like a car is a totally different entity to a insurance salesman than to a
car manefacturer.
I get the feeling that XML is trying to skip level 3 altogether.
Not a good idea..
I may be in a bit over my head here, but these are a few of the thoughts
that have been
going through my mind.
I find it amusing that you think XML is industrial strength while
Common Lisp is not. I'm sure Franz would like to hear abouth that one..
To me Java and XML waste the most precious comodity to a programmer..
time.
You might want to look at the observations of the company Beta Nine
which has extensive experience with Java and J2EE developement and
has just started looking at lisp.
http://homepage.mac.com/svc/RebelWithACause/index.html
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Sat, 14 Jan 2006 21:59:12 +0100, Nathan Baum
> <···········@btinternet.com> wrote:
>
> You are serious :)
No.
> I interpreted the post as a joke.
It was.
> 2. It is inefficient for a computer to interpret.
Is it? Surely one would compile XSLT into a more efficient form.
Ideally, it should be no less efficient than an equivalent XML
transformation program written in assembly.
> 3. It is equally inefficient for a programmer to write.
I suppose that depends upon the programmer. I'm vaguely competent at
XSLT and can write simple stylesheets with ease. But then I was in no
mood to write a stylesheet for the hypothetical "LispML to SexprML"
transformer.
Generally when I want to some text transformed I either use LaTeX,
which produces superior quality output and is generally very concise,
or PHP, which makes it easy to generate new content out of thin air.
If I were going to use XSLT in a production system, I'd write some Lisp
macros to transform a sane transformation specification into XSLT. More
likely is that I'd use that same specification to construct a
transforming function directly, however.
I suspect that most other production systems based upon XSLT actually
generate XSLT automatically from a simpler specification.
> Seems to me the worst of all possible worlds.
> Wouln't you be better off with Perl? (shudder)
Not really. Perl isn't an XML transformation language. Having said
that, I have nothing but love for Perl, especially the upcoming Perl 6,
which grows ever more Lisp-like (as do all languages).
> Then it is the whole motivation of what XLM is trying to do.
> To make one representation that fits all. Particularly
> the Dublin project for a general toxonometry of all data.
No. In fact, XML's purpose is, in a sense, the very opposite of this.
(It may be worth noting that Dublin metadata isn't exclusively an "XML
application" and can just as easily (some might say "more easily") be
stored as symbolic expressions.)
XML is very much like Lisp. It combats the notion that one must make
One Format To Rule Them All by making one metaformat with which one can
construct arbitrarily subformats. Like (well-designed) Lisp (domain
specific languages), you can mix and match (well-designed) XML
(applications).
For example, one should be able to put a MathML equation in an SVG
image in a HTML document. It's easy to object that one can already do
that by storing the three parts in different files and inserting them
in each other. However, one might just as easily object to allowing a
single Lisp source file to use DSLs for parsing text, querying
databases and typesetting musical notation.
Whilst you _could_ use a seperate program for each function, having
them in one source file allows a certain level of interaction between
them. For example, future versions of XHTML/CSS should support using
inline SVG documents as icons for bulleted lists (technically, this is
already supported, but I doubt most browsers are able to render it).
Such icons could change their appearance depending upon where they
appear -- e.g. they could display a stylised version of the current
item's numerical index in the list -- or their content -- e.g. they
could be green for a differential equation, blue for a summation and
red otherwise.
None of this is impossible without XML, but is likely a lot more
difficult. In the numbered list example, I'd have to generate each
bullet image seperately, manually assign each item the correct bullet
image and manually correct those assignments when a new item changes
the numbering for items after it.
Now this is rather more praise than I typically lavish upon XML. The
fundamental point is that whilst XML isn't the _best_ universal generic
structured data format, it is the _only_ universal generic structured
data format. Just getting rid of it or replacing it isn't going to be
an option even in the far future, and even then you'd need to come up
with something _technically superior_ and not just nicer to read and
write.
Lisp doesn't count since Lisp 'data' can't portably self-describe
itself. Plus, a data-is-code format is highly non-optimal for documents
intended for general consumption: there are PDF viruses, and the
intentional security hole in WMF is currently rather famous. Perhaps
the only data-is-code format that hasn't had viruses in it is the
Truetype format. (Truetype fonts contain 'bytecode' instructions for
drawing the font.)
And, really, since XML is _designed_ to be a Lingua Franca for
translation to and from other document formats, y'all can just stop
bitching about XML and use symbolic expressions, converting between XML
when external programs require it. (That's not aimed at you John, I
didn't get the impression you were bitching about XML 'in principle'.)
> 3. shema for describing the structure
> ...
> I get the feeling that XML is trying to skip level 3 altogether.
XML has at least two schema systems. One is the unreasonably limited
'DOCTYPE' system. The other is the unreasonably complex (but actually
effective) XML Schema system. Presumably, XML Schema files are intended
to be generated automatically, like XSLT. For example, a database
server might export a table to XML, and at the same time export a
schema to XML Schema.
> I find it amusing that you think XML is industrial strength while
> Common Lisp is not. I'm sure Franz would like to hear abouth that one..
You were intended to find it amusing that I thought XML was an
industrial strength _programming language_.
On Sun, 15 Jan 2006 04:11:11 +0100, Nathan Baum
<···········@btinternet.com> wrote:
> John Thingstad wrote:
>> On Sat, 14 Jan 2006 21:59:12 +0100, Nathan Baum
>> <···········@btinternet.com> wrote:
>>
>> You are serious :)
>
> No.
lol.. Ok.
>
>> 3. shema for describing the structure
>> ...
>> I get the feeling that XML is trying to skip level 3 altogether.
>
> XML has at least two schema systems. One is the unreasonably limited
> 'DOCTYPE' system. The other is the unreasonably complex (but actually
> effective) XML Schema system. Presumably, XML Schema files are intended
> to be generated automatically, like XSLT. For example, a database
> server might export a table to XML, and at the same time export a
> schema to XML Schema.
>
I am aware of XML Shema but from what I have seen it is more of a
type declaration language. A database schema seems to me to have a
wider scope. It needs to spesify how to construct tables and relations.
I dont like the idea of spewing lage chunks of data over the net and then
picking
out the parts you want with xpath say. Wastefull and overgeneral.
A one size fit's all philosophy simply seems wrong to me.
I should add that altough I have read (some of) the standards the authours
intent
is not always clear to me.
A final note. I see nothing wrong with sending sexpr over the net
but there would be danger interpreting it as code.
As long as you process it as data you should be fine.
It is in fact no different from XML.
But like you said XML is a standard so in order to talk to
other software I use XML. Allego 8 coming out shortly
will have SOAP support among other things so I suppose I
will get a better idea playing with that..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> I am aware of XML Shema
"Hear, O programmers: XML is the One True Syntax.
You shall love it with all your heart, and with all
your soul, and with all your strength." ?
--
Gareth McCaughan
.sig under construc
"John Thingstad" <··············@chello.no> writes:
> Like many lispers I therefore have a rather cool attitude on the
> direction XML has been going.
So the essence of XML is this: the problem it solves is not hard,
and it does not solve the problem well.
- "The Essence of XML", Jérôme Siméon & Philip Wadler
--
··········@acm.org As the air to a bird, or the sea to a fish,
http://www.bawue.de/~jjk/ so is contempt to the contemptible. [Blake]
http://del.icio.us/jjk
Don't forget, guys, if you intend to compile this stuff, you have to
license the patent. That's another by-product of wanting to be
industrial strength, I guess....
http://www.datapower.com/products/xa35.html
:-)
--
Fred Gilham ······@csl.sri.com || Progressive (adj): Value-free;
tolerant; non-judgemental. E.g. traditional archery instruction
methods spent tedious hours teaching the archer to hit a bulls-eye.
Progressive methods achieved better results by telling the student
archer to shoot in the manner he or she found most comfortable, then
calling whatever the arrow hit the bulls-eye.
"Nathan Baum" <···········@btinternet.com> writes:
> far easier way to write it is therefore: [...]
http://homepages.cwi.nl/~atanasso/xml-treatise
--
Johan Bockgård
"LuisGLopez" <············@gmail.com> writes:
> '1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
It's an ordinary function.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Thanks for the correction! :) Any opinion on the rest?
Paolo Amoroso ha escrito:
> "LuisGLopez" <············@gmail.com> writes:
>
> > '1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
>
> It's an ordinary function.
On Wed, 11 Jan 2006 14:18:15 +0100, Paolo Amoroso <·······@mclink.it>
wrote:
> "LuisGLopez" <············@gmail.com> writes:
>
>> '1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
>
> It's an ordinary function.
>
>
> Paolo
Ordinary is a relative term as it is often expanded inline by
the compiler to inc *reg* if the situation permits.
But it is definatly not a macro.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
LuisGLopez wrote:
> I want to introduce an extremely important and hot topic... :D
>
> Seriously, it's something I came across some time ago. Why do we have a
> '1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
> often find myself doing some kind of 'switching paradigms' between
> infix and prefix notation in my head each time I read it in others
> code; in fact, I often 'mistype' it in my own, having to change it.
(1+ 5) is closer to infix than (+1 5), and infix is clearly the much
better notation than prefix or postfix, right? ;-)
More seriously, a better reason could be that +1 can be parsed as a
valid number, so it's better to distinguish between 1+ and +1 (although
they are in different namespaces).
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza ha escrito:
>
> More seriously, a better reason could be that +1 can be parsed as a
> valid number, so it's better to distinguish between 1+ and +1 (although
> they are in different namespaces).
Ouch! You and Emilio are *so* right... Shame on me I couldn't see it by
myself...
Thank you very much!!! :)
Luis.
Pascal Costanza wrote:
> (1+ 5) is closer to infix than (+1 5), and infix is clearly the much
> better notation than prefix or postfix, right? ;-)
Yes, but (1- x) is quite strange syntax. OTOH -1 is a number.
--
the bottom line is that a JavaSchool that won't teach C and won't teach
Scheme is not really teaching computer science, either. -- Joel Spolsky
Ulrich Hobelmann <···········@web.de> writes:
> Pascal Costanza wrote:
>> (1+ 5) is closer to infix than (+1 5), and infix is clearly the much
>> better notation than prefix or postfix, right? ;-)
>
> Yes, but (1- x) is quite strange syntax. OTOH -1 is a number.
(setf (symbol-function ++) (symbol-function 1+)
(symbol-function --) (symbol-function 1-))
(++ x) (-- x)
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
Pascal Bourguignon wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>Pascal Costanza wrote:
>>
>>>(1+ 5) is closer to infix than (+1 5), and infix is clearly the much
>>>better notation than prefix or postfix, right? ;-)
>>
>>Yes, but (1- x) is quite strange syntax. OTOH -1 is a number.
>
>
> (setf (symbol-function ++) (symbol-function 1+)
> (symbol-function --) (symbol-function 1-))
>
> (++ x) (-- x)
If you were going to try to copy C, ++ and -- should correspond to the
macros incf and decf, not the functions 1+ and 1-.
(defmacro ++ (place) `(incf ,place))
(defmacro -- (place) `(decf ,place))
-- MJF
Pascal Bourguignon wrote:
> (setf (symbol-function ++) (symbol-function 1+)
> (symbol-function --) (symbol-function 1-))
Excellent!
I hate '(1+ x)' because looking so much like infix is throws me off
(everything thing else being prefix). In my code I've always been
using '(+ x 1)'.
Cheers,
--jfc
"LuisGLopez" <············@gmail.com> writes:
> I want to introduce an extremely important and hot topic... :D
No it is not.
> Seriously, it's something I came across some time ago. Why do we have a
> '1+' macro (I believe it is a macro, isn't it?) instead of '+1'? I
> often find myself doing some kind of 'switching paradigms' between
> infix and prefix notation in my head each time I read it in others
> code; in fact, I often 'mistype' it in my own, having to change it.
>
> Besides, think about it as a function. A function is 'something' you
> give 'something' and makes 'something' with (great definition, isn't
> it? :D). In this case, you give it a number and want the function to
> 'add 1' to it. So, in this way it's even more 'natural' to write it as
> '+1'.
You can write:
(setf (symbol-function '\+1) (symbol-function '1+))
then:
(\+1 2)
(|+1| 2)
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
On 2006-01-11 16:08:41 +0000, Pascal Bourguignon <····@mouse-potato.com> said:
> "LuisGLopez" <············@gmail.com> writes:
>> I want to introduce an extremely important and hot topic... :D
> No it is not.
Your repeated sense of well timed humor never fails to amaze ne :-)
--
JFB
Espen Vestre wrote:
> ·········@gmail.com writes:
>
>>Lisp uses the principle of maximum surprise.
>
> Our chief weapon is surprise! ...surprise and fear!
Our two weapons are fear and surprise...and ruthless efficiency....
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/