According to my timepiece, we should be hearing about how horrible the
parenthesis are and how much more `natural' infix notation is, right...
about.... NOW.
Well, I may be a few seconds early, but I'm curious to hear from the
newbies that are no longer using training wheels as to how awful they
thought parenthesis were at the beginning, how long it took them to get
used to them, and what they think now.
(Extra points to those that have attempted to write a production-level
parser for C, Java, or other such language recently.)
-----
After this, we will discuss `stand-alone' images and whether Scheme
programmers are somehow purer and will therefore enter Heaven in fewer
flips of Purgatory-space than Lisp programmers. Brandon J. Van Every
will analyze why it is impossible to program games in Lisp (he shows
that this is a weak form of his thesis that it is impossible to program
anything in any language). Robert Maas will give his report on the job
market.
On 9 Jan 2006 16:48:45 -0800, <··········@gmail.com> wrote:
>
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
They disappeared some time ago, about the only time I notice them is
when I fumble and need to use emacs to match up the correct
parenthesis pairs. I cannot even remember what color scheme is
running in slime now, I see stuff mainly as streams and filters and my
fingers take care of the rest. How long did that take? No idea, I
just noticed a few months after starting that I hadn't thought about
them in a long time. I guess that parenthesis never got to the
'awful' state, having dealt with BIND 7 notation for too long.
> After this, we will discuss `stand-alone' images and whether Scheme
> programmers are somehow purer and will therefore enter Heaven in fewer
> flips of Purgatory-space than Lisp programmers. Brandon J. Van Every
> will analyze why it is impossible to program games in Lisp (he shows
> that this is a weak form of his thesis that it is impossible to program
> anything in any language). Robert Maas will give his report on the job
> market.
Ah, spring is in the air! Take me out to the ball game.
--
If you don't like LOOP, how do you feel about DOLIST ?
Joe,
Note: after writing this, it turned into more of an post about me and
Lisp vs. me and "all those parens". Be warned... :)
I began using [Common] Lisp seriously about a year and a half ago. I
had fleeting bouts with it before then, but only in the hypothetical
sense (Pure Lisp, Scheme -- not that Scheme's hypothetical, but
certainly more academic; please, no flame wars about Scheme).
Coming from a background where I have already had to use Forth quite a
bit apart from C (all embedded work), the parens didn't throw me for a
complete loop (after all, how different can prefix be from postfix?),
but it still took some getting used to. I will say, using the LispWorks
editor, and having the "correct" indentation done for me helped
*tremendously*. Proper indentation is as important to Lisp as it is to
Python, plain and simple.
I started Lisp testing a couple things:
1. Could Lisp be as extensible as Forth (yes, this is funny now, but it
was a serious concern to me 2 years ago)?
Well, Lisp is - without a doubt - the most extensible language there
is. Paul Graham was right when he stated: "[A notation for code using
trees of symbols], which (with [the whole language always available])
is what makes Lisp macros possible, is so far still unique to Lisp,
perhaps because (a) it requires those parens, or something just as bad,
..."
I have since used Lisp to write GBA assembler (ARM7TDMI) as a domain
specific language (just compile the Lisp source and there is my GBA
game), and a BASIC compiler for the GBA (which was peviously done in
Forth): Google DragonBASIC.
My regular expression parser in Lisp would have been more difficult to
write in another language, and being able to add syntax to the language
(in my case #/.../) was a huge win; i could compile regular expressions
at compile time instead of runtime. That, combined with the DEFLEXER
macro and LispWorks' DEFPARSER let me make a BASIC lexer/parser in
about 100 lines of code. Can we say "slam dunk"?
2. Could Lisp be as (fast as / good for) game production as C code?
I'm still hesitant on this one. Something I will state unequivocally is
that Lisp is certainly *much* faster to develop with. Using my own game
engine with LispWorks, I can put together some very good code very
quickly. The important (read: speed) code is still written in C. But, I
can start my game running in a window (multi-threaded), and using the
listener or the open editor, just modify a function and recompile just
that function and see the game change right then and there.
I don't expect non game programmers to understand just how important
this can be in game development. Before submitting a game to Microsoft,
Sony, or Nintendo, one must test *thoroughly* the game (those companies
test the games themselves, but it costs money to submit a game, so you
want to submit as few times as possible). With games today being larger
and more "open world" (read: emergent) than ever before, we typically
end up putting in tons of debug information. When a tester hits an
assert, it could potentially be hours into a game, and because of
random events be extremely tricky to reproduce.
With an REPL being available while the game is running, if a problem
occurs, I could simply modify small functions where I see the problem
and keep repeating the steps over and over (without having to quit the
game) until fixed. This win is so big I can't stress it enough. Another
trivial example might be creating a particle effect in code and
watching it loop. In the REPL I can simply tweak various code
parameters until it looks exactly the way I want, then copy/paste into
the function.
I won't even touch scripting!
I still am very concerned with potential memory usage. Games can run
for a long time, and pauses for garbage collection can't be tollerated.
I'm not saying they will, but eventually large objects that are created
past the 1st generation will eventually need to be collected. The games
I make on my own for fun are on the PC and so it isn't as big a concern
[to me]. At work we still use C, and that certainly isn't changing
anytime soon (sadly). But it would be very nice to have a Lisp where I
could give it a pool of memory or at least control garbage collection
(to happen at level loads, pause screens, etc). Perhaps environments I
work with now do this, but if so, I'm unaware.
Another area where I still find Lisp lacking, though, is in bit
manipulation. And no, I don't mean LOGIOR, LOGAND, etc. I mean pointer
casting and reading bits as different data. An example of this was when
I went to create a simple TGA image reader. In C this is as simple as
defining the structure and performing an fread. Boom. Done. In Lisp I
need to read byte-by-byte (a little exageration) and convert it into a
form that Lisp handles better. And trying to manipulate frame buffer
data at runtime in Lisp is not for the faint of heart. If anyone has
suggestions here for me, I'm all ears. :)
So, where does all this leave me?
Well, I certainly wish I was using Lisp at work. Aside from a couple
things I need DirectX to do, I don't even touch Visual Studio at home
any more. Everything is in Lisp.
Lisp (like Forth) has taught me to look at problems differently. If I
never touch Lisp again, I now have new tools at my disposal for solving
the problems that I will face.
There should be "hobbyist" licenses for LispWorks and Allegro. I'd love
to shell out the $1K+ price, but with matenance fees and no real income
being produced from it, I have a hard time convincing myself to do so.
Even 1/2 the price (or no upgrade fees) would make it worthwhile.
*cough* (hint) *cough*
And one of (if not all) the major Lisp vendors should put together a
*serious* DirectX package so I don't have to touch C any more [at
home]. OpenGL doesn't cut it any more on Win32 (please, no flame wars
about DirectX vs OpenGL).
I still have more to learn. Everything I thought was a new, "modern"
idea, is nothing but rehash of something that was thought of 40+ years
ago. :-)
Jeff M.
P.S. when I make a post like this, I typically get emails asking for my
3D Lisp game engine code. Please don't. I can't provide it due to
contracts with my work. And I do this as a hobby for myself outside of
work (yes, I am crazy).
From: Duane Rettig
Subject: Re: About those parenthesis....
Date:
Message-ID: <o0hd8co487.fsf@franz.com>
"Jeff M." <·······@gmail.com> writes:
> Another area where I still find Lisp lacking, though, is in bit
> manipulation. And no, I don't mean LOGIOR, LOGAND, etc. I mean pointer
> casting and reading bits as different data. An example of this was when
> I went to create a simple TGA image reader. In C this is as simple as
> defining the structure and performing an fread. Boom. Done. In Lisp I
> need to read byte-by-byte (a little exageration) and convert it into a
> form that Lisp handles better. And trying to manipulate frame buffer
> data at runtime in Lisp is not for the faint of heart. If anyone has
> suggestions here for me, I'm all ears. :)
See
http://groups.google.com/group/comp.lang.lisp/msg/2a3d699114a6f26b
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Jeff M." <·······@gmail.com> writes:
> I went to create a simple TGA image reader. In C this is as simple as
> defining the structure and performing an fread. Boom. Done. In Lisp I
> need to read byte-by-byte (a little exageration) and convert it into a
> form that Lisp handles better. And trying to manipulate frame buffer
Maybe you should look at:
http://www.cs.uit.no/~frodef/sw/binary-types/
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jeff M. <·······@gmail.com> wrote:
> But it would be very nice to have a Lisp where I could give it a pool of
> memory or at least control garbage collection (to happen at level loads,
> pause screens, etc). Perhaps environments I work with now do this, but if
> so, I'm unaware.
In LispWorks you can invoke MARK-AND-SWEEP to the garbage collect at
those opportune times.
There are also a number of tweakable GC settings described in the
LispWorks Reference Manual (HCL package). For instance, perhaps
AVOID-GC/NORMAL-GC might be of use to you? (I don't have first-hand
experience of these, sorry.)
> I went to create a simple TGA image reader. In C this is as simple as
> defining the structure and performing an fread. Boom. Done. In Lisp I
> need to read byte-by-byte (a little exageration) and convert it into a
> form that Lisp handles better.
One has to do similarly in C if portable code is required. Though I am
aware that certain applications (such as 3D game engines :-) trade-off
platform neutrality for greater runtime performance on a specific
platform.
> There should be "hobbyist" licenses for LispWorks and Allegro. I'd love
> to shell out the $1K+ price, but with matenance fees and no real income
> being produced from it, I have a hard time convincing myself to do so.
> Even 1/2 the price (or no upgrade fees) would make it worthwhile.
> *cough* (hint) *cough*
What do you want that, say, LispWorks Personal Edition doesn't offer?
Executable generation? Unrestricted memory heap size?
--
Duncan Harvey
> What do you want that, say, LispWorks Personal Edition doesn't offer?
> Executable generation? Unrestricted memory heap size?
Recently LW Personal Edition did up the heap size which did help a lot.
Being able to generate executables would certainly be nice, but I do
understand the reasons for not providing this. In fact, LW Personal
Edition is what I'm currently using at home.
I may be part of a very small minority, so I'm assuming the
powers-that-be will simply ignore this. Not being able to use the GUI
builder (for example) is frustrating. But producing executables is
certainly the biggest loss.
I should reiterate, though, that I'm not asking to get everything for
free. I'm more than happy to pay a reasonable amount for [what is] a
great product. The only difference here is that what is "reasonable" is
probably different for a company creating production code that will
generate revenue and an individual looking to put out a freeware
product here and there. The difficulty for the LW (or Allegro) team, I
would imagine, is that trying to separate out what someone can/can't do
with their product becomes very difficult. What's preventing me from
using LW as a web server with a "hobbyist" license?
For example, $1K seems extremely fair if I knew I could get all
upgrades in the future (but as it is, $275/year for a maintenance fee
is a lot for a someone not making money off of it, especially when
major updates aren't guaranteed to be once/year). As it stands, the
longer I have to wait for an upgrade, the more I'm paying for it. I
suppose that's designed under the premise that the longer I wait, the
more features will be present in the new version, but I wonder how true
that really is. Is there historical data someone can point me to?
They (LW/Allegro) are great products, and I will certainly be
purchasing one in the future, I just keep waiting for that "sweet spot"
in my mind to come around before doing so....
Jeff M.
Jeff M. wrote:
> 2. Could Lisp be as (fast as / good for) game production as C code?
>
> I'm still hesitant on this one.
This is a tricky one. On the one hand, I am convinced that Lisp *could
be made* to be as fast as C on game code. I've written blitters in
lisp that approach hand-tuned C code and have no problem keeping up
with the frame rate. With a decent compiler and enough practice, it
doesn't seem that difficult.
On the other hand, it doesn't seem that easy, either. If it were truly
trivial, there wouldn't be a question about it. One problem is that
unless you ask otherwise, Lisp will attempt to do the most general,
most predictable thing. The second problem is that Lisp provides a
rich set of very high-level libraries and these are really easy to use.
Compare this with C. Unless you ask otherwise, C will do whatever
requires the least amount of work for the compiler. This means, for
example, that integer arithmetic is performed modulo some word size
that varies from machine to machine. This is fast, but leads to
bizarre behavior (for instance, you can add two positive numbers and
get an answer less than either). Higher order functions like qsort or
bsearch are so painful to use that no one uses them casually.
So, could Lisp be as fast as C for games? I think `yes, it can and is,
for some people' and `not yet' for most.
> I still am very concerned with potential memory usage. Games can run
> for a long time, and pauses for garbage collection can't be tollerated.
Hmmm, but pauses between levels and when `entering new areas' can?
That's where the C code is collecting.
> I'm not saying they will, but eventually large objects that are created
> past the 1st generation will eventually need to be collected. The games
> I make on my own for fun are on the PC and so it isn't as big a concern
> [to me]. At work we still use C, and that certainly isn't changing
> anytime soon (sadly). But it would be very nice to have a Lisp where I
> could give it a pool of memory or at least control garbage collection
> (to happen at level loads, pause screens, etc). Perhaps environments I
> work with now do this, but if so, I'm unaware.
It frustrates me (and Henry Baker, as well, if I recall) that the
technology for real-time garbage collection has been around for at
least a quarter of a century and practically no one implements it! (By
real time, I mean that we can prove that all GC pauses are bounded on
the order of at most a couple of milliseconds. Fast enough as to not
have a noticable effect on the refresh rate.)
> Another area where I still find Lisp lacking, though, is in bit
> manipulation. And no, I don't mean LOGIOR, LOGAND, etc. I mean pointer
> casting and reading bits as different data. An example of this was when
> I went to create a simple TGA image reader. In C this is as simple as
> defining the structure and performing an fread. Boom. Done. In Lisp I
> need to read byte-by-byte (a little exageration) and convert it into a
> form that Lisp handles better. And trying to manipulate frame buffer
> data at runtime in Lisp is not for the faint of heart. If anyone has
> suggestions here for me, I'm all ears. :)
You can do these in lisp, but it certainly isn't as easy at it should
be. I think that Corman Lisp might have the edge here: it can parse
the C struct in the header file and generate the lisp code to
manipulate it.
I recall the quote from Dr. Strangelove: `What good is a doomsday
device if nobody knows about it?!' You *can* do this sort of
bit-twiddling in Lisp, but it isn't common knowledge how to do it.
> Well, I certainly wish I was using Lisp at work. Aside from a couple
> things I need DirectX to do, I don't even touch Visual Studio at home
> any more. Everything is in Lisp.
>
> Lisp (like Forth) has taught me to look at problems differently.
Heh heh heh, ruined for life.
>
> There should be "hobbyist" licenses for LispWorks and Allegro. I'd love
> to shell out the $1K+ price, but with matenance fees and no real income
> being produced from it, I have a hard time convincing myself to do so.
> Even 1/2 the price (or no upgrade fees) would make it worthwhile.
> *cough* (hint) *cough*
What's wrong with the free ones?!
> And one of (if not all) the major Lisp vendors should put together a
> *serious* DirectX package so I don't have to touch C any more [at
> home]. OpenGL doesn't cut it any more on Win32 (please, no flame wars
> about DirectX vs OpenGL).
This is interesting to me. I know nothing about graphics and always
thought that DirectX vs. OpenGL was mostly a matter of taste.
It'd be interesting to have a version of Lisp where the evaluation and
GC functionality were synchronized with the main graphics loop. That
is, make the graphics engine support Lisp rather than vice versa. I
bet this would blow the doors off other game technologies.
> I still have more to learn. Everything I thought was a new, "modern"
> idea, is nothing but rehash of something that was thought of 40+ years
> ago. :-)
It is fun to read the really old papers. Some of the ideas back then
would be appropriate to try out now on modern hardware. The fact that
they tried them out on punch cards and vacuum tube computers with less
memory than my wristwatch is astounding. Of course there were a lot of
failures, but we should revist the ideas that failed solely because the
machines of the time weren't up to it.
On 10 Jan 2006 13:01:33 -0800, "Joe Marshall" <··········@gmail.com> wrote:
> This is interesting to me. I know nothing about graphics and always
> thought that DirectX vs. OpenGL was mostly a matter of taste.
I also know nothing about this stuff but it looks like the next
Windows will treat OpenGL like a second-class citizen:
<http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On 10 Jan 2006 13:01:33 -0800, "Joe Marshall" <··········@gmail.com> wrote:
>
>
>>This is interesting to me. I know nothing about graphics and always
>>thought that DirectX vs. OpenGL was mostly a matter of taste.
>
>
> I also know nothing about this stuff but it looks like the next
> Windows will treat OpenGL like a second-class citizen:
>
> <http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001>
>
> Cheers,
> Edi.
>
Windoze tends to do that. If you want to use OpenGL, than support *nix!
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: About those parenthesis....
Date:
Message-ID: <87y81nd8l1.fsf@qrnik.zagroda>
"Jeff M." <·······@gmail.com> writes:
> I still am very concerned with potential memory usage. Games can run
> for a long time, and pauses for garbage collection can't be tollerated.
> I'm not saying they will, but eventually large objects that are created
> past the 1st generation will eventually need to be collected. The games
> I make on my own for fun are on the PC and so it isn't as big a concern
> [to me]. At work we still use C, and that certainly isn't changing
> anytime soon (sadly). But it would be very nice to have a Lisp where I
> could give it a pool of memory or at least control garbage collection
> (to happen at level loads, pause screens, etc). Perhaps environments I
> work with now do this, but if so, I'm unaware.
My compiler (not of Lisp, but the language is not very far from Lisp)
tries to automatically choose appropriate moments for GC.
(It uses a two-generation copying GC.)
If all threads are going to wait, and the amount of allocation in the
old heap since last GC has passed half of the amount which would
require a GC, then a major GC is performed.
Similarly, if all threads are going to wait and at the young heap is
at least half full, then a minor GC is performed.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Jeff M. wrote:
> I won't even touch scripting!
One problem that has been identified in the past rgd. exporting the REPL
for scripting in a game is that you can't prevent the end-user from
messing with the internals. I.e., packages can't be "locked" down, and
made immutable. This is however a requirement for any (successful)
commercial online game (to prevent cheating).
I must be one of the freaks because I've never had a problem with them.
It may have helped that I was not CS trained. From what I've read
here and elsewhere, I can see how one can become biased by a professor
or curriculum.
My first exposure to Lisp code was in Metamagical Themas. I had been
programming for about 8 years by that time and had seen (& coded in)
various languages. It neither repulsed me, nor blew me away, but I
remember liking the "approach" (i.e., what I would later learn was
functional programming). Since I wasn't blown away at the time, I
never looked further into it.
Several years passed, and while trying to learn new concepts/approaches
to programming I came across SICP at a used bookstore for about $18.
After reading a few sections, I unhesitatingly went to Amazon.com and
bought a new copy of the 2nd edition. Still the parens didn't bother
me. It was about this time that Kent Pitman's answers to readers
questions appeared on Slashdot. His answer to the question (I'm
paraphrasing here), "What's up with the parentheses?" really hit home
for me. To me, the parens help show the organization of the
expressions just like in mathematics.
When I heard Python being compared to Lisp, my first thought was, "Why
do you need a new version of something that already works?". Then I
found out that indentation determined how code was blocked (sorry for
the non-CS terminology). That, to me, was laughable.
Thanks for your time,
Chris.
Joe Marshall wrote:
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
Well, this is flamebait, but I'm bored, so I'll play along.
Lisp embodies some interesting ideas, but the parentheses
aren't one of them.
I do a certain amount of programming math formulas, and to
the extent that the formulas look the same on paper as in the
program, it makes my life easier. Extraneous parentheses
and prefix-only notation makes the program less comprehensible.
Parentheses are cruft. Their presence makes Lisp programs
very easy to parse automatically. So put some more effort
into the compiler, guys. If the trade off is the compiler writer's
effort versus the effort of every last programmer, you know
whose side I'm on.
Maybe I could fix up the language through clever use of macros.
So what? I have other things to do. There's only so much time in a day.
By the way, I'm not an idiot. Thanks for understanding.
Robert Dodier
Robert Dodier wrote:
> Joe Marshall wrote:
>
> > Well, I may be a few seconds early, but I'm curious to hear from the
> > newbies that are no longer using training wheels as to how awful they
> > thought parenthesis were at the beginning, how long it took them to get
> > used to them, and what they think now.
>
> Well, this is flamebait, but I'm bored, so I'll play along.
>
> Lisp embodies some interesting ideas, but the parentheses
> aren't one of them.
>
> I do a certain amount of programming math formulas, and to
> the extent that the formulas look the same on paper as in the
> program, it makes my life easier. Extraneous parentheses
> and prefix-only notation makes the program less comprehensible.
>
> Parentheses are cruft. Their presence makes Lisp programs
> very easy to parse automatically. So put some more effort
> into the compiler, guys. If the trade off is the compiler writer's
> effort versus the effort of every last programmer, you know
> whose side I'm on.
>
> Maybe I could fix up the language through clever use of macros.
> So what? I have other things to do. There's only so much time in a day.
>
> By the way, I'm not an idiot. Thanks for understanding.
You don't understand lisp though.
Lisp is a homoiconic programming language. You could easily give it
syntax, but that would rob the language of it's main strength.
If it had syntax then code and data could not take the same form and be
treated similarly. Macros would have to be very much more complicated
than they are.
Rob Thorpe wrote:
> Robert Dodier wrote:
> > By the way, I'm not an idiot. Thanks for understanding.
> You don't understand lisp though.
You can call me "grasshopper" if you like.
> Lisp is a homoiconic programming language.
> You could easily give it syntax, but that would rob the
> language of it's main strength.
>
> If it had syntax then code and data could not take
> the same form and be treated similarly.
The programming language invented for the Macsyma algebra system
has syntax (Algol-like) yet code and data are interchangeable.
There are probably other counterexamples, but I don't get around much.
> Macros would have to be very much more complicated
> than they are.
I don't know about that. In the Macsyma language foo(x) ::= ... is
more or less similar to defmacro, while buildq([x, y, z], bar(x,y,z))
is more or less similar to `(bar ,x ,y ,z) ; the variables have
to be named in a list because comma is already taken.
That's certainly more clunky, although I think "very much more
complicated" is an overstatement. Also, it's likely that Lisp
macros have greater functionality, but I don't understand
Lisp macros well enough to say just how much.
I don't mean to say I think the Macsyma language is a great
programming language -- it is somewhat peculiar -- but it
certainly works well enough to be a counterexample to the
assertions about syntax and macros.
I'm actually quite fond of the Macsyma language.
I wish it had lexical scope and a package system, though.
Hey, if anyone wants to lend a hand, stop by.
http://maxima.sf.net , http://maxima.sf.net/maximalist.html
For what it's worth,
Robert Dodier
Robert Dodier wrote:
> Rob Thorpe wrote:
>
> > Robert Dodier wrote:
> > > By the way, I'm not an idiot. Thanks for understanding.
>
> > You don't understand lisp though.
>
> You can call me "grasshopper" if you like.
?
> > Lisp is a homoiconic programming language.
> > You could easily give it syntax, but that would rob the
> > language of it's main strength.
> >
> > If it had syntax then code and data could not take
> > the same form and be treated similarly.
>
> The programming language invented for the Macsyma algebra system
> has syntax (Algol-like) yet code and data are interchangeable.
> There are probably other counterexamples, but I don't get around much.
>
> > Macros would have to be very much more complicated
> > than they are.
>
> I don't know about that. In the Macsyma language foo(x) ::= ... is
> more or less similar to defmacro, while buildq([x, y, z], bar(x,y,z))
> is more or less similar to `(bar ,x ,y ,z) ; the variables have
> to be named in a list because comma is already taken.
> That's certainly more clunky, although I think "very much more
> complicated" is an overstatement.
I'll admit at this point I don't know Macsyma.
> Also, it's likely that Lisp
> macros have greater functionality, but I don't understand
> Lisp macros well enough to say just how much.
>
> I don't mean to say I think the Macsyma language is a great
> programming language -- it is somewhat peculiar -- but it
> certainly works well enough to be a counterexample to the
> assertions about syntax and macros.
I wasn't just talking about macros. Macros are the most obvious
example of what can be done if code and data are treated regularly, but
there are others. You can write programs that load other programs in
as data, modify them and write them out for example.
The advantage of the simplicity of lists are that everything has a
similar form, for example one can write alternate versions of defmacro
or defun if you want. Most languages that offer the chance to treat
data and code interchangably make the user learn two languages. First
the user must learn the programming language itself, then the user must
learn some underlying data language on which they can perform
operations. This is what lisp avoids.
Operations with precidence are a classic problem for example, if your
langauge can accept 4 - 5 / 8 then how is this reflected in the data
langauge? If it's just represented as a string as it is in TCL then
working with it is hard, the programmer must write code to parse the
expression as the compiler would. If the data language occurs after
the parser at the level of the tree then how does the programmer know
what the tree will look like? In this case he/she has to learn another
language, that of the tree.
"Rob Thorpe" <·············@antenova.com> writes:
> Robert Dodier wrote:
>> Rob Thorpe wrote:
>>
>> > Robert Dodier wrote:
>> > > By the way, I'm not an idiot. Thanks for understanding.
>>
>> > You don't understand lisp though.
>>
>> You can call me "grasshopper" if you like.
>
> ?
What a lack of basic culture, Where where you in the 70's? :-)
http://us.imdb.com/title/tt0068093/
(Kwai Chang Caine was called Grasshopper by his Master Po).
More futurist fans would say "Padawan"...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
"Robert Dodier" <·············@gmail.com> writes:
> Parentheses are cruft. Their presence makes Lisp programs
> very easy to parse automatically. So put some more effort
> into the compiler, guys. If the trade off is the compiler writer's
> effort versus the effort of every last programmer, you know
> whose side I'm on.
In a world where only the compiler author can add new features, this
may make sense. But Lisp is all about the ordinary programmer's
ability to extend the language. So the alternatives are: make the
surface syntax simple, and thus the ordinary programmer's life easier;
or make the surface syntax complex, and make the novice's life easier
up until the point they really get the hang of the language, at which
point they join the other ordinary programmers, whose lives are much,
much harder.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Robert Dodier wrote:
> Joe Marshall wrote:
>
>
>>Well, I may be a few seconds early, but I'm curious to hear from the
>>newbies that are no longer using training wheels as to how awful they
>>thought parenthesis were at the beginning, how long it took them to get
>>used to them, and what they think now.
>
>
> Well, this is flamebait, but I'm bored, so I'll play along.
>
> Lisp embodies some interesting ideas, but the parentheses
> aren't one of them.
>
> I do a certain amount of programming math formulas, and to
> the extent that the formulas look the same on paper as in the
> program, it makes my life easier. Extraneous parentheses
> and prefix-only notation makes the program less comprehensible.
Agreed. But it is not Lisp's fault that mathematicians got the syntax
wrong. :)
>
> Parentheses are cruft. Their presence makes Lisp programs
> very easy to parse automatically. So put some more effort
> into the compiler, guys. If the trade off is the compiler writer's
> effort versus the effort of every last programmer, you know
> whose side I'm on.
John McCarthy's? He wanted to convert to conventional syntax before
shipping Lisp, but everyone liked prefix so much they somehow missed
that item on the release checklist.
I think your heavy involvement with math might be the reason for your
different mileage.
>
> Maybe I could fix up the language through clever use of macros.
> So what? I have other things to do. There's only so much time in a day.
So use the infix package someone here developed. (Sorry, I forget who.)
:)
kt
Kenny Tilton wrote:
> I think your heavy involvement with math might be the reason for your
> different mileage.
I don's think so.
Prefix notation was invented by mathematican for use in math.
http://en.wikipedia.org/wiki/Polish_notation
Regards, Szymon.
On Wed, 11 Jan 2006 08:29:49 +0100, tichy <···········@o2.pl> wrote:
> Kenny Tilton wrote:
>> I think your heavy involvement with math might be the reason for your
>> different mileage.
>
> I don's think so.
> Prefix notation was invented by mathematican for use in math.
>
> http://en.wikipedia.org/wiki/Polish_notation
>
> Regards, Szymon.
Yes.. I would argue that it is traditonal mathematical
notation that is overly cumbersome..
And in fact did on occasion back when I studied Math.
(Nevertheless I confess I sometimes use the infix module
#I(...) when implementing hairy expresions.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Robert Dodier wrote:
> Maybe I could fix up the language through clever use of macros.
> So what? I have other things to do. There's only so much time in a day.
yes, see
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
Copy this into your repl (or use it in your lisp.ini file on startup) and
you can write something like this:
'#I "2+3*(a+c*x^^(y+1)+z)"
-> (+ 2 (* 3 (+ A (* C (EXPT X (+ Y 1))) Z)))
This might be useful for mathematical expressions for easier copy-and-paste
from written formulas, but I like the prefix-only notation for the rest of
my programs, with all those parantheses :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Duane Rettig
Subject: Re: About those parenthesis....
Date:
Message-ID: <o0fynwf3ic.fsf@franz.com>
"Robert Dodier" <·············@gmail.com> writes:
> Joe Marshall wrote:
>
>> Well, I may be a few seconds early, but I'm curious to hear from the
>> newbies that are no longer using training wheels as to how awful they
>> thought parenthesis were at the beginning, how long it took them to get
>> used to them, and what they think now.
>
> Well, this is flamebait, but I'm bored, so I'll play along.
Others have already given you several answers, including a reference
to the infix package, and have answered all of your points except one:
> Lisp embodies some interesting ideas, but the parentheses
> aren't one of them.
What this tells me is that you think parentheses should not be made
into a big deal. They just aren't very interesting.
I agree.
So why are you making a big deal about them?
- Most lispers don't see the parens once they've gotten used to
dealing with them in an editor.
- almos any syntax you care for can easliy be simulated by syntax
conversion using macros, character macros, or even a parser other
than the standard read function.
So why make a big deal about something after saying that there's
no big deal?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> "Robert Dodier" <·············@gmail.com> writes:
>
>
>>Joe Marshall wrote:
>>
>>
>>>Well, I may be a few seconds early, but I'm curious to hear from the
>>>newbies that are no longer using training wheels as to how awful they
>>>thought parenthesis were at the beginning, how long it took them to get
>>>used to them, and what they think now.
>>
>>Well, this is flamebait, but I'm bored, so I'll play along.
>
>
> Others have already given you several answers, including a reference
> to the infix package, and have answered all of your points except one:
>
>
>>Lisp embodies some interesting ideas, but the parentheses
>>aren't one of them.
>
>
> What this tells me is that you think parentheses should not be made
> into a big deal. They just aren't very interesting.
>
> I agree.
>
> So why are you making a big deal about them?
I parsed "but the parentheses aren't one of [the interesting ideas]" as
"parentheses suck!", not that it is not their use is not interesting.
Aside: I am surprised you agree with what you thought was the assertion
that parentheses are not interesting. Hell, they even make editing
easier, never mind what they do for macrology.
kt
From: Duane Rettig
Subject: Re: About those parenthesis....
Date:
Message-ID: <o08xtnmzcw.fsf@franz.com>
Kenny Tilton <·············@nyc.rr.com> writes:
> Duane Rettig wrote:
>> "Robert Dodier" <·············@gmail.com> writes:
>>
>>>Joe Marshall wrote:
>>>
>>>
>>>>Well, I may be a few seconds early, but I'm curious to hear from the
>>>>newbies that are no longer using training wheels as to how awful they
>>>>thought parenthesis were at the beginning, how long it took them to get
>>>>used to them, and what they think now.
>>>
>>>Well, this is flamebait, but I'm bored, so I'll play along.
>> Others have already given you several answers, including a reference
>> to the infix package, and have answered all of your points except one:
>>
>>>Lisp embodies some interesting ideas, but the parentheses
>>>aren't one of them.
>> What this tells me is that you think parentheses should not be made
>> into a big deal. They just aren't very interesting.
>> I agree.
>> So why are you making a big deal about them?
>
> I parsed "but the parentheses aren't one of [the interesting ideas]"
> as "parentheses suck!", not that it is not their use is not
> interesting.
As did I. However, he started things out by talking about flamebait,
and being bored, so I thought I'd raise the interest level by throwing
a curve.
> Aside: I am surprised you agree with what you thought was the
> assertion that parentheses are not interesting. Hell, they even make
> editing easier, never mind what they do for macrology.
Let's talk about big noses. Do you think they are interesting?
Perhaps you have a nose fettish, and thus you do, but more likely
you're thinking to yourself right now "where could he possibly be
going with this?". Well, ok; here it is; if you are to recognize
me, you must be able to identify a large nose. However, large noses
aren't particularly interesting, are they? You may say, "but on
Arabian horses, they allow them to survive long trips in the desert".
But on the face of it [sic] they aren't much more interesting than
that...
Back On topic: Parens are syntax. Lisp tries to get you past syntax
by making the syntax disappear. Hence, uninteresting. Now, let's
talk about environments, methods, etc.
Note: this conversation is not Robert Dodier's fault - it was Joe
Marshall that started it by asking about parens, though usually it
is indeed started by naysayers. I'm just having fun with it - that's
all.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Kenny Tilton <·············@nyc.rr.com> writes:
>
>
>>Duane Rettig wrote:
>>
>>>"Robert Dodier" <·············@gmail.com> writes:
>>>
>>>
>>>>Joe Marshall wrote:
>>>>
>>>>
>>>>
>>>>>Well, I may be a few seconds early, but I'm curious to hear from the
>>>>>newbies that are no longer using training wheels as to how awful they
>>>>>thought parenthesis were at the beginning, how long it took them to get
>>>>>used to them, and what they think now.
>>>>
>>>>Well, this is flamebait, but I'm bored, so I'll play along.
>>>
>>>Others have already given you several answers, including a reference
>>>to the infix package, and have answered all of your points except one:
>>>
>>>
>>>>Lisp embodies some interesting ideas, but the parentheses
>>>>aren't one of them.
>>>
>>>What this tells me is that you think parentheses should not be made
>>>into a big deal. They just aren't very interesting.
>>>I agree.
>>>So why are you making a big deal about them?
>>
>>I parsed "but the parentheses aren't one of [the interesting ideas]"
>>as "parentheses suck!", not that it is not their use is not
>>interesting.
>
>
> As did I. However, he started things out by talking about flamebait,
> and being bored, so I thought I'd raise the interest level by throwing
> a curve.
>
>
>>Aside: I am surprised you agree with what you thought was the
>>assertion that parentheses are not interesting. Hell, they even make
>>editing easier, never mind what they do for macrology.
>
>
> Let's talk about big noses. Do you think they are interesting?
Right, one more crack about my big nose and... hang on, wrong NG and
language for that.
> Perhaps you have a nose fettish, and thus you do, but more likely
> you're thinking to yourself right now "where could he possibly be
> going with this?". Well, ok; here it is; if you are to recognize
> me, you must be able to identify a large nose. However, large noses
> aren't particularly interesting, are they? You may say, "but on
> Arabian horses, they allow them to survive long trips in the desert".
> But on the face of it [sic] they aren't much more interesting than
> that...
>
> Back On topic: Parens are syntax. Lisp tries to get you past syntax
> by making the syntax disappear. Hence, uninteresting. Now, let's
> talk about environments, methods, etc.
I once heard that real physicists had no interest in pardoxes like
Schroedinger's Cat. You are a real Lisp engineer, stuck with boring
mechanics. I am a mere dilettante, free to take a long draw on my pipe
and meditate on what mysterious cosmic law makes parentheses work better
for everything from the ridiculous (text editing) to the sublime (meta
programming).
>
> Note: this conversation is not Robert Dodier's fault - it was Joe
> Marshall that started it
yep. And can you believe he tried to drag Touretzky and Mass into this
as well?
As for noses, Life of Brian aside, I believe Laurence Sterne cannot be
left out of any useful discussion:
http://www.gifu-u.ac.jp/~masaru/TS/iii.140-159.html#nose
kt
> Duane Rettig wrote:
> > Note: this conversation is not Robert Dodier's fault - it was Joe
> > Marshall that started it
I'm just doing my little part.
Kenny Tilton wrote:
>
> yep. And can you believe he tried to drag Touretzky and Mass into this
> as well?
>
I'll cop to the latter, but I really wish I had remembered the former
as well.
Next time.
David Sletten wrote:
> Kenny Tilton wrote:
>
>>
>> Right, one more crack about my big nose and... hang on, wrong NG and
>> language for that.
>>
> 大鼻子，你会说中国话吗？
I was starting a riff on the Sermon on the Mount scene from The Life of
Brian. You know, "Romans go home!"?
Pythonistas (on c.l.python) naturally make a lot of references to the
Monty Python opus.
kenny
Kenny Tilton wrote:
> David Sletten wrote:
>
>> Kenny Tilton wrote:
>>
>>>
>>> Right, one more crack about my big nose and... hang on, wrong NG and
>>> language for that.
>>>
>> 大鼻子，你会说中国话吗？
>
>
> I was starting a riff on the Sermon on the Mount scene from The Life of
> Brian. You know, "Romans go home!"?
>
> Pythonistas (on c.l.python) naturally make a lot of references to the
> Monty Python opus.
>
> kenny
Oh, _that_ language. I thought I recalled you slipping into Chinese in
the past...
David "大卫" Sletten
Joe Marshall wrote:
> According to my timepiece, we should be hearing about how horrible the
> parenthesis are and how much more `natural' infix notation is, right...
> about.... NOW.
>
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
>
> (Extra points to those that have attempted to write a production-level
> parser for C, Java, or other such language recently.)
pwua-ha-ha... I had a feeling I knew where this was coming from.
The weird thing being that everyone takes it for granted that a
programming language (other than COBOL) should look like ~!%^&*({[.;? I
think we even had someone here recently insisting different things
should /look/ different. As reasonable sounding as it turns out to be wrong.
kenny (who has been discussing C-to-Lisp with Mr. Marshall by email)
On 2006-01-10 00:48:45 +0000, "Joe Marshall" <··········@gmail.com> said:
> According to my timepiece, we should be hearing about how horrible the
> parenthesis are and how much more `natural' infix notation is, right...
> about.... NOW.
Seriously, I hated them. They were a testament to higher forms
of intelligence I wasn't privy to. Some kind of elitism that only
those that could abstract the substance from the visual form
could really master.
And then, there was the "functional programming" thing. Something
I dreaded too. And since "functions" in math land all have parentheses,
this seemed an unscrutable perfect fit.
And then something happened: I became fluent in English (a second
language) at ... 35, This was the first time I had been able to
master anything through hard work. So far, life had been effortlessly
easy, so I just didn't see the point of forcing anything.
Now I do! Lisp was (unfortunately) at the bottom of my "to try hard
again" list, but since I decided to tackle the problem again about
6 month ago ... parentheses have ... vanished from my sight!
Now I beleive that there isn't a Parenthesis Problem. There is
only a Learning Problem. That can be overcome like all such
problems do: by studying and practicing. And when one does just
that, parentheses becone, at worst, an extremely minor annoyance,
when compared to what they afford: polyadic functions. I was
positively shocked when I discovered that all of:
CL-USER 1 > (= 1 1 1)
T
CL-USER 2 > (= 1 1 2)
NIL
CL-USER 3 > (/= 1 2 3)
T
CL-USER 4 > (/= 1 2 2)
NIL
CL-USER 5 > (< 1 2 3)
T
CL-USER 6 > (< 1 2 1)
NIL
were defined, legal and meaningful!
That beats the binary operators that infix notation had brain-washed
me to beleive were the only game in town!
You know what? Now, I _love_ parentheses! :-)
--
JFB
Joe Marshall wrote:
> According to my timepiece, we should be hearing about how horrible the
> parenthesis are and how much more `natural' infix notation is, right...
> about.... NOW.
>
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
>
> (Extra points to those that have attempted to write a production-level
> parser for C, Java, or other such language recently.)
>
> -----
>
> After this, we will discuss `stand-alone' images and whether Scheme
> programmers are somehow purer and will therefore enter Heaven in fewer
> flips of Purgatory-space than Lisp programmers. Brandon J. Van Every
> will analyze why it is impossible to program games in Lisp (he shows
> that this is a weak form of his thesis that it is impossible to program
> anything in any language). Robert Maas will give his report on the job
> market.
What? No attacks on Dave Touretzky from the Scientologists this time?
Damn...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Hello Joe,
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to
> get used to them, and what they think now.
When I learned Lisp, I thought all those parenthesis were cool. They never
bothered me, but maybe I'm weird.
This is a multi-part message in MIME format.
--------------090402040809050201050008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Joe Marshall wrote:
> According to my timepiece, we should be hearing about how horrible the
> parenthesis are and how much more `natural' infix notation is, right...
> about.... NOW.
>
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
>
> (Extra points to those that have attempted to write a production-level
> parser for C, Java, or other such language recently.)
>
> -----
>
> After this, we will discuss `stand-alone' images and whether Scheme
> programmers are somehow purer and will therefore enter Heaven in fewer
> flips of Purgatory-space than Lisp programmers. Brandon J. Van Every
> will analyze why it is impossible to program games in Lisp (he shows
> that this is a weak form of his thesis that it is impossible to program
> anything in any language). Robert Maas will give his report on the job
> market.
>
The parenthesis are merely irritating (you know the acronym) rather than
all that awful.
However, I would prefer if there were an infix notation with all of the
power that normal Lisp has. So I wrote one, but there turned out to be
little use for it. Infix notation in non-mathematical problems is only
useful for object orientation.
I haven't attempted to write a production-level parser for anything
lately, but I did attempt to expand my infix-notation macro into some
kind of language. It worked, too; the parens are a bit less annoying to
work with when infix is used.
--------------090402040809050201050008
Content-Type: text/plain;
name="verbiage.lisp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="verbiage.lisp"
(defun flatten (&rest items)
(dotimes (item (length items))
(if (listp (nth item items))
(setf items (append (subseq items 0 item) (nth item items) (subseq items (1+ item) (length items))))
)
)
items
)
(defun verbiage-atom (word)
(defun quoted-p (sym)
(and (listp sym) (equalp (car sym) 'quote)))
(cond
((or (atom word) (quoted-p word)) word)
(t (cons 'verbiage word))
)
)
(defparameter *verbiage-variables* nil "An alist of variable names and gensym'd symbols representing verbiage variables.")
(defparameter *verbiage-verbs* (list ':= '= '== '> '< '<> 'atomic
'its 'declare 'with
'if
'define-type 'define-verb 'define-verb-for
'[] 'rest-of 'flatten
'+ '- '* '/) "A list of declared/defined verbs.")
(defmacro verbiage (&rest sentences)
(destructuring-bind (subject verb &rest objects) (mapcar #'verbiage-atom sentences)
(if (not (find verb *verbiage-verbs*))
(format nil "~a is not a valid verb." verb)
(progn
(cond
((equalp verb ':=) (setf verb 'setf))
((equalp verb '=) (setf verb 'eval))
((equalp verb '==) (setf verb 'equalp))
((equalp verb '<>) (setf verb
(list 'funcall (lambda (x y) (not (equalp x y))))
))
((equalp verb 'atomic) (setf verb 'atom))
((equalp verb 'its) (progn
(setf verb (first objects))
(setf objects (cdr objects))
))
((equalp verb 'declare) (progn
(push (cons subject (gensym)) *verbiage-variables*)
(eval `(setf ,(cdr (assoc subject *verbiage-variables*)) nil))
(setf verb 'eval)
))
((equalp verb 'with) (setf verb 'cons))
((equalp verb 'if) (let ((temp subject))
(setf subject (car objects))
(setf objects (cons temp (cdr objects)))
))
((equalp verb 'define-type) (setf verb 'define-subject-type))
((equalp verb 'define-verb) (progn
(if (not (find subject *verbiage-verbs*))
(push subject *verbiage-verbs*))
(setf (car objects) (cdar objects))
(setf verb 'defun)
))
((equalp verb 'define-verb-for) (if (not (find subject *verbiage-verbs*))
(progn
(define-verb subject @objects)
(push subject *verbiage-verbs*)
)
))
((equalp verb '[]) (setf verb 'elt))
((equalp verb 'rest-of) (setf verb 'cdr))
((equalp subject nil) (progn
(setf subject (first objects))
(setf objects (cdr objects))
))
)
(if (and (symbolp subject) (cdr (assoc subject *verbiage-variables*)))
(setf subject (cdr (assoc subject *verbiage-variables*)))
)
(cond
((listp verb) `(,@verb ,subject ,@objects))
(t `(,verb ,subject ,@objects))
)
)
)
)
)
(defmacro define-verb (verb &rest objects)
`(defgeneric ,verb (subject ,@objects)))
(defmacro define-verb-for (verb subject-type objects &rest definition)
`(defmethod ,verb ((subject ,subject-type) ,@objects)
(verbiage ,@definition)
)
)
(defmacro define-subject-type (subject-type &rest slots)
`(defclass ,subject-type ()
,(mapcar #'(lambda (slot) (list slot ':accessor slot)) slots)
)
)
(defun make-verbiage (sentence)
(cons 'verbiage sentence)
)
(defmacro while (bool variables &rest body)
`(do ((result nil) ,@variables)
((not ,bool) result)
(setf result
(progn
,@body
)
)
)
)
(defun verbiage-repl ()
(let ((exit nil))
(while (not exit) ((text-line "") (stdout (make-string-output-stream)))
(format t "~a" "verbiage>")
(setf text-line (read (make-string-input-stream (format nil "(~a)" (read-line t)))))
(cond
((equalp text-line (list 'quit))
(progn
(setf exit t)
(setf *verbiage-variables* nil)
)
)
(t (prin1 (eval (make-verbiage text-line))) stdout)
)
(write-string (get-output-stream-string stdout))
(fresh-line)
)
)
t
)
--------------090402040809050201050008
Content-Type: text/plain;
name="stuff.verbiage"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="stuff.verbiage"
(load "verbiage.lisp")
(verbiage get-length define-verb (a-list)
(
0 if
(a-list == nil)
(1 + ((a-list rest-of) get-length))
))
(verbiage do-lister define-verb (items)
(
((items [] 0) with nil) if
((items get-length) == 1)
((items [] 0) with ((items rest-of) do-lister) )
))
(verbiage lister define-verb (&rest items)
(
items do-lister
))
--------------090402040809050201050008--
Zach Beane wrote:
> Eli Gottlieb <···········@gmail.com> writes:
>
>
>>The parenthesis are merely irritating (you know the acronym) rather
>>than all that awful.
>
> [snip]
>
>
>>(defun flatten (&rest items)
>> (dotimes (item (length items))
>> (if (listp (nth item items))
>> (setf items (append (subseq items 0 item) (nth item items) (subseq items (1+ item) (length items))))
>> )
>> )
>> items
>> )
>
>
> No wonder they irritate you, they're all out of place!
>
> Zach
I get irritated by "))))" and refuse to use emacs, so I do wierd paren
indentation to read them.
Eli Gottlieb wrote:
> Zach Beane wrote:
>
>> Eli Gottlieb <···········@gmail.com> writes:
>>
>>
>>> The parenthesis are merely irritating (you know the acronym) rather
>>> than all that awful.
>>
>>
>> [snip]
>>
>>
>>> (defun flatten (&rest items)
>>> (dotimes (item (length items))
>>> (if (listp (nth item items))
>>> (setf items (append (subseq items 0 item) (nth item items)
>>> (subseq items (1+ item) (length items))))
>>> )
>>> )
>>> items
>>> )
>>
>>
>>
>> No wonder they irritate you, they're all out of place!
>>
>> Zach
>
> I get irritated by "))))" and refuse to use emacs, so I do wierd paren
> indentation to read them.
There are Common Lisp IDEs on all platforms that support parantheses
properly and can be used instead of Emacs. It's highly recommended to
switch to such an editor that supports Lisp syntax, instead of fighting
it the way that you seem to fight it. Otherwise you won't get the full
benefit of Lisp syntax.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Eli Gottlieb wrote:
>
>> Zach Beane wrote:
>>
>>> Eli Gottlieb <···········@gmail.com> writes:
>>>
>>>
>>>> The parenthesis are merely irritating (you know the acronym) rather
>>>> than all that awful.
>>>
>>>
>>>
>>> [snip]
>>>
>>>
>>>> (defun flatten (&rest items)
>>>> (dotimes (item (length items))
>>>> (if (listp (nth item items))
>>>> (setf items (append (subseq items 0 item) (nth item items)
>>>> (subseq items (1+ item) (length items))))
>>>> )
>>>> )
>>>> items
>>>> )
>>>
>>>
>>>
>>>
>>> No wonder they irritate you, they're all out of place!
>>>
>>> Zach
>>
>>
>> I get irritated by "))))" and refuse to use emacs, so I do wierd paren
>> indentation to read them.
>
>
> There are Common Lisp IDEs on all platforms that support parantheses
> properly and can be used instead of Emacs. It's highly recommended to
> switch to such an editor that supports Lisp syntax, instead of fighting
> it the way that you seem to fight it. Otherwise you won't get the full
> benefit of Lisp syntax.
>
>
>
> Pascal
>
Name one that runs on Linux, is F/OSS and doesn't require emacs.
On 2006-01-11, Eli Gottlieb <···········@gmail.com> wrote:
>> There are Common Lisp IDEs on all platforms that support parantheses
>> properly and can be used instead of Emacs.
> Name one that runs on Linux, is F/OSS and doesn't require emacs.
Maybe you've heard of vim? Also:
Hemlock, Edwin, Eclipse, Jed, off the top of my head... is there really
an editor that *doesn't* support Lisp indentation and paren matching?
Adrian Kubala wrote:
> On 2006-01-11, Eli Gottlieb <···········@gmail.com> wrote:
>
>>>There are Common Lisp IDEs on all platforms that support parantheses
>>>properly and can be used instead of Emacs.
>>
>>Name one that runs on Linux, is F/OSS and doesn't require emacs.
>
>
> Maybe you've heard of vim? Also:
> Hemlock, Edwin, Eclipse, Jed, off the top of my head... is there really
> an editor that *doesn't* support Lisp indentation and paren matching?
I'm already using Vim, though I can only get highlighting of extra
ending parens to work. *Goes to read manual*.
On 2006-01-11, Eli Gottlieb <···········@gmail.com> wrote:
> I'm already using Vim, though I can only get highlighting of extra
> ending parens to work. *Goes to read manual*.
Here's my setup. In ~/.vimrc:
filetype plugin indent on
Then in ~/.vim/ftplugin/lisp.vim:
set lisp
set expandtab
set autoindent
set showmatch
set cpoptions-=m
This site has some good suggestions also:
http://cybertiggyr.com/gene/15-vim/
Adrian Kubala wrote:
> On 2006-01-11, Eli Gottlieb <···········@gmail.com> wrote:
>
>>I'm already using Vim, though I can only get highlighting of extra
>>ending parens to work. *Goes to read manual*.
>
>
> Here's my setup. In ~/.vimrc:
> filetype plugin indent on
>
> Then in ~/.vim/ftplugin/lisp.vim:
> set lisp
> set expandtab
> set autoindent
> set showmatch
> set cpoptions-=m
>
> This site has some good suggestions also:
> http://cybertiggyr.com/gene/15-vim/
That works. Thanks!
On 2006-01-11, Eli Gottlieb <···········@gmail.com> wrote:
> Adrian Kubala wrote:
>> On 2006-01-11, Eli Gottlieb <···········@gmail.com> wrote:
>>>> There are Common Lisp IDEs on all platforms that support
>>>> parantheses properly and can be used instead of Emacs.
>>>
>>> Name one that runs on Linux, is F/OSS and doesn't require emacs.
>>
>>
>> Maybe you've heard of vim? Also: Hemlock, Edwin, Eclipse, Jed, off
>> the top of my head... is there really an editor that *doesn't*
>> support Lisp indentation and paren matching?
> I'm already using Vim, though I can only get highlighting of extra
> ending parens to work. *Goes to read manual*.
See also (in no particular order):
http://cybertiggyr.com/gene/15-vim/ (article I wrote on using Vim
to edit Lisp)
http://vim.sourceforge.net/scripts/script.php?script_id=1230 (does
"rainbow highlighting" of various levels of parens)
http://vim.sourceforge.net/scripts/script.php?script_id=273 (gives a
nice menu of clickable tags for Lisp and lots of other languages)
http://vim.sourceforge.net/scripts/script.php?script_id=221 (VILisp:
automates cut-and-paste to an external Lisp)
Poke around a bit at
http://vim.sourceforge.net/scripts/script_search_results.php?keywords=lisp&script_type=&order_by=rating&direction=descending&search=search
and you might also like to monitor
http://wiki.alu.org/Perl_interface_to_SLIME
for progress.
-- Larry
p.s. Too many shameless plugs to mention. :)
Larry Clapp wrote:
> See also (in no particular order):
>
> http://cybertiggyr.com/gene/15-vim/ (article I wrote on
> using Vim to edit Lisp)
On that page, he wrote:
> Knowing about Vim's text object selection can save you
> some work. ":help text-objects" says:
>
>> This is a series of commands that can only be used
>> while in Visual mode or after an operator. The
>> commands that start with "a" select "an "object
>> including white space, the commands starting with "i"
>> select an "inner" object without white space, or just
>> the white space. Thus the "inner" commands always
>> select less text than the "a" commands.
>>
>> ab "a block" select
>> ib "inner block" select
I consider myself a pretty experienced Vim user, but I've
never happened to get more than a couple of the text objects
under my fingers, and didn't know about these two. They're
great!
--
Aaron
Eli Gottlieb wrote:
> Pascal Costanza wrote:
>
>> There are Common Lisp IDEs on all platforms that support parantheses
>> properly and can be used instead of Emacs. It's highly recommended to
>> switch to such an editor that supports Lisp syntax, instead of
>> fighting it the way that you seem to fight it. Otherwise you won't get
>> the full benefit of Lisp syntax.
>>
>> Pascal
>>
> Name one that runs on Linux, is F/OSS and doesn't require emacs.
If "F/OSS" means "free _or_ open source", you can also check out
LispWorks Personal Edition and, I think, Allegro trial edition.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> If "F/OSS" means "free _or_ open source", you can also check out
> LispWorks Personal Edition and, I think, Allegro trial edition.
This might not be the definition of "free" (beer vs. speech)
that the F/OSS acronym was meant to convey.
Mike
--
If you don't breathe, there is no air. DI Michael Wildpaner
If you don't walk, there is no earth. Ph.D. Student
If you don't speak, there is no world.
-- Navajo (Dineh) wisdom
Michael Wildpaner wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>If "F/OSS" means "free _or_ open source", you can also check out
>>LispWorks Personal Edition and, I think, Allegro trial edition.
>
> This might not be the definition of "free" (beer vs. speech)
> that the F/OSS acronym was meant to convey.
Ah, we're getting religious again... ;)
It's important to note that you can avoid a vendor lock-in by not using
the implementation-specific libraries and extensions. Fortunately,
Common Lisp is a large enough language so that you write useful programs
already in "pure" Common Lisp. Many of the libraries available for
open-source implementations of Common Lisp are also available for the
commercial implementations. Developing in a commercial IDE and
delivering with an open-source Common Lisp runtime is quite feasible.
Another nice thing about IDEs like LispWorks and Macintosh Common Lisp
(I don't know enough about Allegro on Windows to be able to comment on
that one) is that they offer both the keybindings and user interface
that you expect from a "regular" application and the Emacs keybindings.
So this offers a smooth path to a stage where you may even want to
switch to Emacs (especially if you can use nicely integrated packages
like Aquamacs that also try to behave like regular applications as far
as possible).
The danger of a vendor lock-in is by far not nearly as high as for other
languages.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Michael Wildpaner wrote:
> >>If "F/OSS" means "free _or_ open source", you can also check out
> >>LispWorks Personal Edition and, I think, Allegro trial edition.
> > This might not be the definition of "free" (beer vs. speech)
> > that the F/OSS acronym was meant to convey.
>
> Ah, we're getting religious again... ;)
Me? Can't be.
> The danger of a vendor lock-in is by far not nearly as high as for
> other languages.
That certainly is true, especially as a lot of ANSI compliance work
seems to be going on in the free Lisp implementations, and it's good
to see heavliy CLOSed code running portably on open implementations.
But whom am I talking to, as you are already a lot Closer ;)
Mike
--
If you don't breathe, there is no air. DI Michael Wildpaner
If you don't walk, there is no earth. Ph.D. Student
If you don't speak, there is no world.
-- Navajo (Dineh) wisdom
>Well, I may be a few seconds early, but I'm curious to hear from the
>newbies that are no longer using training wheels as to how awful they
>thought parenthesis were at the beginning, how long it took them to get
>used to them, and what they think now.
http://www.zvon.org/other/haskell/Outputsyntax/fixityQdeclaration_reference.html
this makes me nauseous
...oddly enough I still write a lot of pseudo code with infix syntax
but then again I also use arrows, pictures, and little cartoon
bubble-like things
I don't know what the moral significance of this is...
The first couple of weeks life was rough, typing toy functions into the
darwin terminal, but then came the LispWorks IDE, and eventually SLIME
and Emacs. Remapping #\( to #\[, Control to Caps, paren highlighting,
and C - <ret> made everything go away. Now I get kind of annoyed when
things don't have parens and proper sexps (loop?)
funny, to circumvent kruft in infix you add parens.
Nick
In article <1136854125.521522.126740
@g43g2000cwa.googlegroups.com>, ··········@gmail.com says...
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
I like parenthesis and prefix from beginning. However, I think
that usual f(x,y,z) would be better choice than (f x y z).
Majorinc wrote:
> In article <1136854125.521522.126740
> @g43g2000cwa.googlegroups.com>, ··········@gmail.com says...
>
>>Well, I may be a few seconds early, but I'm curious to hear from the
>>newbies that are no longer using training wheels as to how awful they
>>thought parenthesis were at the beginning, how long it took them to get
>>used to them, and what they think now.
>
> I like parenthesis and prefix from beginning. However, I think
> that usual f(x,y,z) would be better choice than (f x y z).
Using commas instead of whitespace would waste a character that could
otherwise be more meaningful.
Putting the operator in front of the parentheses would immediately
create ambiguities. Consider:
(defun f (x) (+ x x))
vs.
defun(f (x) +(x x))
~~~~~
Do you really think the following is easier to understand?
defun(f,(x),+(x,x))
What about lambda((x),+(x,x))?
The nice thing about Lisp's syntax is that it works pretty well for all
kinds of examples, not just for one or two (or a few).
If you start to add exceptions for special cases, you also start to lose
some of the advantages.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <···············@individual.net>, ··@p-cos.net
says...
>
> (defun f (x) (+ x x))
>
> ~~~~~
>
> Do you really think the following is easier to understand?
>
> defun(f,(x),+(x,x))
I think that they are about same, so it might be better to
conform to the old mathematical tradition.
Although these notations are clearly isomorphic, traditional
mathematical notation syntactically emphasize semantical
difference between the operator and arguments. As result, such
notation makes different *suggestions*
f(x1,...,xn) suggests importance of car and cdr; (f x1 ... xn)
does not.
a(b,c,d...) suggests indexing operators with 0 and arguments
with 1 .... (a b c d ...) suggests indexing operator with 1 and
arguments with 2 ...
f(x1,...,xn) suggests that code (as data) is labeled tree; more
general and usual data structure than unlabeled tree with only
leaf nodes labeled suggested by (f x1 ...xn).
etc.
Another small reason in favour of commas is that liberated
blanks could be used for their traditional purpose, instead of
underscores or minuses.
Majorinc, Kazimir <·······@chem.pmf.hr> wrote:
> In article <···············@individual.net>, ··@p-cos.net
> says...
> >
> > (defun f (x) (+ x x))
> >
> > ~~~~~
> >
> > Do you really think the following is easier to understand?
> >
> > defun(f,(x),+(x,x))
>
> I think that they are about same, so it might be better to
> conform to the old mathematical tradition.
>
> [..]
>
> Another small reason in favour of commas is that liberated
> blanks could be used for their traditional purpose, instead of
> underscores or minuses.
Someone once agitated a little for commas to be whitespace, so people
can make nice little delineations. (I believe it was Pitman and perhaps
others.) But then comma was sucked into backquote duty. Yesterday I
thought there was something to that idea, as the inexplicable desire to
stuff things onto one line often conflicts with readability, but c'est
la vie.
Incidentally, I was just wondering to myself why we should leave
important matters like notation to ordinary mathematicians... but then
it struck me that things like infix+ more likely come from some
businessman. (!) And it turns out Wikipedia says the first known + in
print is from a business book. [1] Some handy trivia to pull out in
case of flamewar. ;)
My only thought on this matter is that sometimes a serious programmer
must deal with concepts below the surface, which do not always resemble
the normal world's store of metaphors. When there is good reason.
[1] -- http://en.wikipedia.org/wiki/Plus_and_minus_signs
Tayssir
--
"Let's talk about the question of why people are wealthy. There is a
myth that it's a function of enormous personal attributes. [...] The
individual wealth which is generated in this economy is, in my
judgment, and I doubt that there is much that anyone could disagree
with about this, is a function of the innovative businesses which are
created as a result of federal research. But you understand that the
people who benefit from that research get it free. [...] So, if
somebody starts a software company or a biotechnology company, or even
if somebody owns a building in downtown Washington which you rent to
those people, it starts from the same place. It starts from this
incredible research activity which is going on with federal money."
-- Bill Gates Sr., 2003
http://www.taxpolicycenter.org/publications/template.cfm?PubID=900584
Tayssir John Gabbour wrote:
> Incidentally, I was just wondering to myself why we should leave
> important matters like notation to ordinary mathematicians... but then
> it struck me that things like infix+ more likely come from some
> businessman. (!) And it turns out Wikipedia says the first known + in
> print is from a business book. [1] Some handy trivia to pull out in
> case of flamewar. ;)
[...]
>
> [1] -- http://en.wikipedia.org/wiki/Plus_and_minus_signs
Hm, very interesting. Does anyone actually also happen to have a link or
reference about the history of operator position (prefix/infix/postfix)?
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Tayssir John Gabbour wrote:
>
>> Incidentally, I was just wondering to myself why we should leave
>> important matters like notation to ordinary mathematicians... but then
>> it struck me that things like infix+ more likely come from some
>> businessman. (!) And it turns out Wikipedia says the first known + in
>> print is from a business book. [1] Some handy trivia to pull out in
>> case of flamewar. ;)
Note that is says "in print", which means that the symbol have been
used earlier. See
<http://members.aol.com/jeff570/operation.html> .
which has a lot to say, but ends in:
The plus and minus symbols were in use before they appeared in print.
For example, they were painted on barrels to indicate whether or not
the barrels were full. Some have attempted to trace the minus symbol
as far back as Heron and Diophantus.
--
Jens Axel S�gaard
Pascal Costanza wrote:
> Hm, very interesting. Does anyone actually also happen to have a link or
> reference about the history of operator position (prefix/infix/postfix)?
Hi.
These articles are not very complete :(
Prefix notation was 'invented' by mathematican in 1920.
http://en.wikipedia.org/wiki/Polish_notation
http://en.wikipedia.org/wiki/Jan_%C5%81ukasiewicz
Regards, Szymon.
>>>>> "Tayssir" == Tayssir John Gabbour <···········@yahoo.com> writes:
Tayssir> Incidentally, I was just wondering to myself why we should leave
Tayssir> important matters like notation to ordinary mathematicians... but then
Tayssir> it struck me that things like infix+ more likely come from some
Tayssir> businessman. (!) And it turns out Wikipedia says the first known + in
Tayssir> print is from a business book. [1] Some handy trivia to pull out in
Tayssir> case of flamewar. ;)
There is no standard notation in mathematics! Mathematicians are very
flexible in the use of their notations, e.g. function application can be
written as f(x), f x, x f or even x^f. Normally the one that is more
convenient for the purpose at hand is the one that gets used.
Apparently the situations is different in school and in undergraduate
calculus courses - but that is not really mathematics :-)
Andreas
--
Wherever I lay my .emacs, there's my $HOME.
Andreas Eder <············@gmx.net> writes:
> There is no standard notation in mathematics! Mathematicians are very
> flexible in the use of their notations, e.g. function application can be
> written as f(x), f x, x f or even x^f.
You forgot (x)f
;)
--
(espen)
Majorinc wrote:
> > Do you really think the following is easier to understand?
> >
> > defun(f,(x),+(x,x))
>
> I think that they are about same, so it might be better to
> conform to the old mathematical tradition.
The above transcription contains a serious omission. The correct
version is this:
defun (f, x(), +(x, x))
The (x) must be rewritten as x()!
Now what do we do with this one?
(defun foo () (print "foo"))
How is that empty list () rendered into f(x) notation?
f(x, y) -> (f x y)
f(x) -> (f x)
f() -> (f)
() -> ???
You should spend some time doing Lisp programming, at least on the
order of a few thousand lines.
> Although these notations are clearly isomorphic, traditional
> mathematical notation syntactically emphasize semantical
> difference between the operator and arguments.
In Lisp, the first element of a list is sometimes just the first
element of a list, and not an operator that is elevated above its
arguments.
> As result, such
> notation makes different *suggestions*
That emphasis is adequately chieved simply by way of the operator name
being the leftmost one, or, alternately, being the one that is touching
the inside of the left parenthesis.
In this manner, the emphasis gets out of the way when it's
inappropriate. You can choose not to perceive an emphasis where it
doesn't exist.
> f(x1,...,xn) suggests importance of car and cdr; (f x1 ... xn)
> does not.
Each one of those symbols is the CAR of some cell. The x1 is CAR, and
(x2 ... xn) are CDR.
Lisp has the dot notation if you need more emphasis regarding the
distinction of CAR and CDR. You can write, instead:
(f . (x1 ... xn))
or you can even emphasise the first two elements, if that suits your
semantics:
(f1 x1 . (x2 ... xn))
> a(b,c,d...) suggests indexing operators with 0 and arguments
> with 1 .... (a b c d ...) suggests indexing operator with 1 and
> arguments with 2 ...
>
> f(x1,...,xn) suggests that code (as data) is labeled tree; more
> general and usual data structure than unlabeled tree with only
> leaf nodes labeled suggested by (f x1 ...xn).
No, a tree without labels is more general, clearly. A tree with labels
is a specialization of a tree without labels. In a tree without labels,
some of the leaves can be designated as labels by a convention. It's
the more generic substrate.
But a label is something special. In a labeled tree, you can't easily,
by a simple convention, make the labels function as ordinary leaves.
Those leaves then become special cases that permeate everywhere.
Retrieving the leftmost child means retrieving the label.
The problem with forcing labels is that not everything deserves to be
labeled.
> etc.
>
> Another small reason in favour of commas is that liberated
> blanks could be used for their traditional purpose, instead of
> underscores or minuses.
The mathematical traditional use for blanks is multiplication, not the
formation of identifier compounds.
In article <1136966614.808378.92720
@g49g2000cwa.googlegroups.com>, ········@gmail.com says...
> You should spend some time doing Lisp programming, at least on the
> order of a few thousand lines.
Buahhaha. What an asshole.
Majorinc wrote:
> In article <1136966614.808378.92720
> @g49g2000cwa.googlegroups.com>, ········@gmail.com says...
>
> > You should spend some time doing Lisp programming, at least on the
> > order of a few thousand lines.
>
> Buahhaha. What an asshole.
Aren't you the guy who wrote this just a few weeks ago?
Only advantage of Lisp macros over Lisp functions I see are
slight increase of the speed and few quotes and perhaps
arguments less. Not really much ...
Now you're ready to tell the Lisp world that f(x, y, z) syntax is it!
"Kaz Kylheku" <········@gmail.com> writes:
> Majorinc wrote:
> > In article <1136966614.808378.92720
> > @g49g2000cwa.googlegroups.com>, ········@gmail.com says...
> >
> > > You should spend some time doing Lisp programming, at least on the
> > > order of a few thousand lines.
> >
> > Buahhaha. What an asshole.
>
> Aren't you the guy who wrote this just a few weeks ago?
According to Google Groups, he is indeed the very same non-learning
incompetent.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
······@foo.com says...
> According to Google Groups, he is indeed the very same non-learning
> incompetent.
Another asshole.
Majorinc, Kazimir <·······@chem.pmf.hr> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> ······@foo.com says...
>
> > According to Google Groups, he is indeed the very same non-learning
> > incompetent.
>
> Another asshole.
Do you have any idea how sad and pathetic this is making you look?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
······@foo.com says...
> Do you have any idea how sad and pathetic this is making you look?
>
>
> /Jon
>
You got the comment you deserved, and I'm sure you know how you
deserved it. In future, you can change your way of discussion.
Or not, its up to you.
Majorinc, Kazimir <·······@chem.pmf.hr> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> ······@foo.com says...
>
> > Do you have any idea how sad and pathetic this is making you look?
> >
> >
> > /Jon
> >
>
>
> You got the comment you deserved, and I'm sure you know how you
> deserved it. In future, you can change your way of discussion.
> Or not, its up to you.
I see you don't understand this either.
But it is becoming very clear (from multiple threads) that you not
only don't understand this, but apparently don't want to, or possibly
can't.
You seem to become literally enraged when people simply point out
where and how you are wrong and positively ballistic when they make
some very good suggestions about how to fix your lack of
understanding. Indeed, you strike at these people for trying to help.
This is (imo understandably) very strange for people who obviously
know more than you in the area in question. It is also a guaranteed
way to end up being dismissed as a troll, an Internet kook, or simply
a jerk.
Obviously none of this means anything to you (except you are now
probably literally apoplectic), which is why it is sad.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
On Fri, 13 Jan 2006 19:57:35 +0100, Majorinc wrote:
> In article <··············@rigel.goldenthreadtech.com>, ······@foo.com
> says...
>
>> According to Google Groups, he is indeed the very same non-learning
>> incompetent.
>
> Another asshole.
How much should I pay you to make me an asshole, too?
I'll take this as a distinction...
--
If in doubt, enjoy it.
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Majorinc wrote:
> In article <···············@individual.net>, ··@p-cos.net
> says...
>
>
>> (defun f (x) (+ x x))
>>
>> ~~~~~
>>
>> Do you really think the following is easier to understand?
>>
>> defun(f,(x),+(x,x))
>
> I think that they are about same, so it might be better to
> conform to the old mathematical tradition.
>
> Although these notations are clearly isomorphic, traditional
> mathematical notation syntactically emphasize semantical
> difference between the operator and arguments. As result, such
> notation makes different *suggestions*
> .....
Hi.
Read this: http://en.wikipedia.org/wiki/Polish_notation
"Polish notation, also known as prefix notation,
is a method of mathematical expression.
It was created by Jan \Lukasiewicz,
mostly to _simplify_ certain mathematical proofs.
Its distinguishing feature is that it
places operators before operands. [...]"
Regards, Szymon.
Majorinc wrote:
> I like parenthesis and prefix from beginning. However, I think
> that usual f(x,y,z) would be better choice than (f x y z).
The commas don't serve any purpose, other than to add clutter. So a
better notation than f(x, y, z) is quite simply f(x y z).
I have programmed with Lisp-like semantics using the f(x,y,z) syntax.
It's ugly. The comas really are a problem. There is no satisfactory way
to format them. The syntax does not scale to argument lengths required
in Lisp programming, where long expressions have to be split across
lines.
The commas have to go. At that point, it makes sense to "castle" the
function by exchanging it with the parenthesis.
Hanging on the outside of the parenthesis, the function isn't
syntactically encapsulated. There is an ambiguity there. A
left-to-right scan, having seen only the identifier f, cannot decide
whether f is a plain term, or an operation with arguments. The scan
must continue to the next token before that can be decided. Until then,
the scanner is in a state that is a combination of two states: ``I am
parsing either a simple term, or a the beginning of a compound''. If
you put the parenthesis first, it's clear. You read a token. It's a
parenthesis: great, we have a compound. It's an identifier, so we have
a term.
The f(x y z) notation has no nice way to denote the empty list, because
the token f is needed for syntax. The notation () is a syntax error
because it has no operator on the left.
The f(x y z) notation is also very poor when it comes to subexpressions
which do not represent an operation f being applied to arguments x y z.
It assumes certain semantics: namely that the left item is elevated
above the others. This is not the case when you have syntactic
abstraction.
Consider what happens to this:
(defclass c (b1 b2 b3) ())
Let's skip the fact that we don't know what to do with the empty list
of slot definitions (). In fact, let's invent the @() notation for
that, what the hell. So we get:
defclass (c b1 (b2 b3) @())
Do you see how wrong that is? (b1 b2 b3) is just a list of base
classes. Multiple inheritance from three ancestors. This is mangled
into b1 (b2 b3) which doesn't make sense at all. b1 isn't an operator,
it's just a base class like b2 and b3.
Even when the first symbol /is/ an operator, it's not more important
than the other two symbols.
When you write (+ 1 3) to denote 4, the 4 is a result of all three
symbols acting together. Each one contributes as much to the result as
the other two. The + does not deserve any more credit than the 3 for
that result. It's the combination of these three symbols in that order,
and the surrounding broader context, that gives rise to 4.
So, in summary, f(x, y, z) is an abomination that rightfully deserves
to be cast into the lake of fire.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: About those parenthesis....
Date:
Message-ID: <87r77ex3q3.fsf@qrnik.zagroda>
"Kaz Kylheku" <········@gmail.com> writes:
>> I like parenthesis and prefix from beginning. However, I think
>> that usual f(x,y,z) would be better choice than (f x y z).
>
> The commas don't serve any purpose, other than to add clutter.
> So a better notation than f(x, y, z) is quite simply f(x y z).
The commas do serve a purpose: they avoid extra parens if arguments
are not self-delimiting, as in f(x - 1, x + 1).
> I have programmed with Lisp-like semantics using the f(x,y,z) syntax.
> It's ugly. The comas really are a problem.
Indeed they are quite ugly if the f(x,y,z) syntax is used for all
syntactic constructs.
> The f(x y z) notation is also very poor when it comes to subexpressions
> which do not represent an operation f being applied to arguments x y z.
Of course nobody in the right mind would use f(x y z) or f(x,y,z)
to denote a four-element list.
But it doesn't matter, unless you take for granted that function
application must be represented by a list consisting of the function
name followed by the arguments.
> Even when the first symbol /is/ an operator, it's not more important
> than the other two symbols.
I disagree. It's treated so much differently from the arguments
(especially in Lisp where it's not interpreted as an expression)
that this is not a valid reason for making it look like one of the
arguments. There might be other reasons, but this argument is flawed.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> "Kaz Kylheku" <········@gmail.com> writes:
>
> >> I like parenthesis and prefix from beginning. However, I think
> >> that usual f(x,y,z) would be better choice than (f x y z).
> >
> > The commas don't serve any purpose, other than to add clutter.
> > So a better notation than f(x, y, z) is quite simply f(x y z).
>
> The commas do serve a purpose: they avoid extra parens if arguments
> are not self-delimiting, as in f(x - 1, x + 1).
The above is no longer strictly prefix notation. The commas are made
necessary by the use of infix.
> > I have programmed with Lisp-like semantics using the f(x,y,z) syntax.
> > It's ugly. The comas really are a problem.
>
> Indeed they are quite ugly if the f(x,y,z) syntax is used for all
> syntactic constructs.
However, as we know, the (f x y z) syntax is very nice and workable,
even when used everywhere.
> > The f(x y z) notation is also very poor when it comes to subexpressions
> > which do not represent an operation f being applied to arguments x y z.
>
> Of course nobody in the right mind would use f(x y z) or f(x,y,z)
> to denote a four-element list.
Then some other syntax would have to be invented for lists. And of
course that syntax would be incorporated into the same phrase structure
that also generates f(x, y, z).
Thus begins the trash-heap in which syntax gets piled on top of syntax.
> But it doesn't matter, unless you take for granted that function
> application must be represented by a list consisting of the function
> name followed by the arguments.
I take it for granted that a semantic action that is made up of four
symbols will somehow be denoted by an utterance that combines those
four symbols. I don't see any reason why that utterance has to be
"non-linear" in any way because it happens to denote function
application.
The notational quadruple (f x y z) could take on an infinite variety of
semantics. The semantics of f being a function, and x y z being
evaluated argument expressions is just one tiny possibility in that
ocean. It's not even particularly that interesting. So why should the
syntax be tailored in any way to cater to that case?
If you want extra emphasis between a left and right division, you can
dedicate a symbol for that purpose, and allow its use to be optional:
(f . (x y z)) .
This is flexible enough to emphasize two (or more) elements:
(obj f . (x y z))
or to show multiple levels of emphasis:
(f . (x . (y z)))
What if the x is somehow more imporant than the y and z, but less
important than the f?
It's nice to have a reserved symbol to do that, but yet to have of the
possible insertions of that symbol mean exactly the same thing as (f x
y z).
In f(x, y, z)-type programming languages that have grown (single
dispatch) object systems, you see obj.f(x, y, z). This is just a
different manifestation of the dot.
> > Even when the first symbol /is/ an operator, it's not more important
> > than the other two symbols.
>
> I disagree. It's treated so much differently from the arguments
> (especially in Lisp where it's not interpreted as an expression)
Being treated differently doesn't make it more important. What does
differently mean, anyway?
In the expression
(- 4 1)
each of the items is treated differently from the others. If that were
not the case, then the 4 and 1 could exchange positions without
altering the result.
> that this is not a valid reason for making it look like one of the
> arguments. There might be other reasons, but this argument is flawed.
You need a reason to make it ^not^ look like the arguments, not the
other way around. It's the extra, superfluous syntactic features which
need to be justified by comparison to their simple counterparts. A
feature that isn't necessary in order to serve a requirement is mere
gold plating.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: About those parenthesis....
Date:
Message-ID: <8764oq8akw.fsf@qrnik.zagroda>
"Kaz Kylheku" <········@gmail.com> writes:
>> The commas do serve a purpose: they avoid extra parens if arguments
>> are not self-delimiting, as in f(x - 1, x + 1).
>
> The above is no longer strictly prefix notation. The commas are made
> necessary by the use of infix.
Right.
> However, as we know, the (f x y z) syntax is very nice and workable,
> even when used everywhere.
I disagree that it's nice for all kinds of expressions.
> I take it for granted that a semantic action that is made up of four
> symbols will somehow be denoted by an utterance that combines those
> four symbols. I don't see any reason why that utterance has to be
> "non-linear" in any way because it happens to denote function
> application.
A literal is an expression which denotes a given value. I don't see
any reason why literals which are lists or symbols would have to be
represented differently than literals of other types.
Of course in Lisp there is a reason: Lisp syntax has hijacked lists
and symbols for various kinds of expressions which are not literals,
so literals of these types must be escaped (quoted), while literals
of other types represent themselves. My point is that it's just an
arbitrary syntactic decision, rather than some deep consequence of
the semantics.
The most natural representation of the AST is a fixed number of types
of nodes, where each node has a fixed number of arguments with the
meaning depending on the type.
For example in a language with a Lispy semantics but a non-Lispy
syntax, the types of nodes and arguments could be as follows:
* LITERAL: value
* IDENTIFIER: symbol (and color if hygienic macros are supported)
* APPLICATION: operation; arguments
* FUNCTION: parameters; body
* LIST: elements
possibly with source location information in all nodes.
Common Lisp just chooses to encode the abstract syntax in a particular way:
- literals are encoded as themselves (except symbols and non-empty lists)
or as (QUOTE value) (all values)
- identifiers are encoded as symbols (hygienic macros are not supported)
- an application is encoded as (operation . arguments)
- a function is encoded as (FUNCTION (LAMBDA parameters . body))
- a list is encoded as (LIST . elements)
with source location information not available directly in the syntax
(an implementation could associate it with syntactic nodes externally).
It's just a syntax, not One True Syntax, nor lack of syntax.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
+---------------
| "Kaz Kylheku" <········@gmail.com> writes:
| > The commas don't serve any purpose, other than to add clutter.
| > So a better notation than f(x, y, z) is quite simply f(x y z).
|
| The commas do serve a purpose: they avoid extra parens if arguments
| are not self-delimiting, as in f(x - 1, x + 1).
+---------------
Actually, if the grammar permits, one can use a simple operator
precedence parser[1], and then violations of the "must have at least
one operator between every pair of values" rule can be taken as
being an implicit comma. The "P'Lite Scheme" infix parser I did
back in 1996 did this. It would parse this:
f x - 1 x + 1
into this:
(f (- x 1) (+ x 1))
Yes, it was a horrible hack, and did have the possibility of masking
some real user errors, but it made the syntax look more like what Tcl
[my main "competition"] accepted, especially if you left the optional
spaces out in each infix expression:
f x-1 x+1
Oh, and it *also* accepted explicit commas, too, so all of these were
legal as well: ;-} ;-}
f x - 1, x + 1
f x-1, x+1
f, x - 1, x + 1
f, x-1, x+1
+---------------
| > I have programmed with Lisp-like semantics using the f(x,y,z) syntax.
| > It's ugly. The comas really are a problem.
|
| Indeed they are quite ugly if the f(x,y,z) syntax is used for all
| syntactic constructs.
+---------------
I agree. P'Lite *didn't* support "f(x,y,z)"!! It used the Tcl "[...]"
for function call subexpressions, e.g., "y+[f x-1 x+1]*z" (which, given
operator precedence, parsed to "(+ (* (f (- x 1) (+ x 1)) z) y)".
-Rob
[1] The parser was actually recursive-descent for control structures
and simple-operator-precedence for expressions, like BLISS used.
For a language like P'Lite, this is easily accomplished simply by
giving the control/special forms very high operator precedences...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, 10 Jan 2006 16:52:04 +0100, <Majorinc> wrote:
> In article <1136854125.521522.126740
> @g43g2000cwa.googlegroups.com>, ··········@gmail.com says...
>
>
>> Well, I may be a few seconds early, but I'm curious to hear from the
>> newbies that are no longer using training wheels as to how awful they
>> thought parenthesis were at the beginning, how long it took them to get
>> used to them, and what they think now.
>
> I like parenthesis and prefix from beginning. However, I think
> that usual f(x,y,z) would be better choice than (f x y z).
I like that too.
It is not disimular to the approach mathematica uses.
This would perhaps be the best place to get a taste of how it could work.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Joe Marshall" <··········@gmail.com> writes:
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
I entered Lisp via the SICP door. I immediately liked the
parentheses. It took me a whopping 10-15 minutes to get used to them.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Joe Marshall wrote:
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
I started with SICP and Scheme, and for quite a while I preferred other
languages (like SML). Part of that might also be due to the lack of
convenient features in Scheme, though. Sometimes I found functions
longer than 5-10 lines a bit hard to read, and a COND to contain quite
lots of parentheses.
I never had any real trouble with the syntax, however (unlike my
classmates).
When I finally looked into CL years later, I simply loved it. Sometime
I might do some MLing again, but the syntax (all those parentheses and
commas in C-like notation) and indentation is just too weird over there.
I guess I won't bother.
> (Extra points to those that have attempted to write a production-level
> parser for C, Java, or other such language recently.)
Parsing in general is an unnecessary annoyance, except there are good
reasons (such as creating a text markup language; Lisp isn't too well
suited for that, as you have to "" all strings; XML is neither great at
text markup nor at semistructured data).
--
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 wrote:
> Parsing in general is an unnecessary annoyance, except there are good
> reasons (such as creating a text markup language; Lisp isn't too well
> suited for that, as you have to "" all strings;
Check out http://www.cliki.net/scribble and its derivatives at
http://www.cliki.net/Lisp%20Markup%20Languages - they work pretty well.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ulrich Hobelmann wrote:
>
>> Parsing in general is an unnecessary annoyance, except there are good
>> reasons (such as creating a text markup language; Lisp isn't too well
>> suited for that, as you have to "" all strings;
>
> Check out http://www.cliki.net/scribble and its derivatives at
> http://www.cliki.net/Lisp%20Markup%20Languages - they work pretty well.
Oh thanks, but I have my own :)
--
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
Joe Marshall <··········@gmail.com> wrote:
+---------------
| According to my timepiece, we should be hearing about how horrible
| the parenthesis are and how much more `natural' infix notation is...
+---------------
Myself, I'm happy with parens, but periodically I find myself needing
to make some little CL hack or other that I've written available to
be used by non-Lispers [usually at work], and then *WHAMMO!*, the
whole "paren thing" rears its ugly head once again. Once upon a time
I actually developed an infix dialect of Scheme [well, really just
some syntactic sugar in the reader], and it was used with some success
for a while. [Search Google Groups for "rpw3 plite scheme" for more
details/examples.] These days I'm using Common Lisp, though, and a
similar hack isn't quite as easy.
But an earlier, much less featureful hack *is* easy in CL, and it
turns out to solve almost all of the parenthephobia issues, at least
the ones I tend to run into. I called it "OPFR", for "Outer-Parentheses-
Free REPL". [Yes, yes, I need to put it up on my server. Long past time,
actually. (*blush*)]
OPFR provides a simple command-line read-eval-print loop (REPL).
The simplicity and utility of OPFR derives from the observation
that most people who are uncomfortable using normal Lisp s-exprs
are actually surprisingly accepting of an s-expr-based interface
*provided* that they are not required to manually type the outer
pair of parentheses on the "command line", *even if* any sub-expr-
essions are still in pure Lisp s-expr form!! This effect is even
stronger when the majority of the functions in the application are
provided as distinct functions or macros, so that users only seldom
require the typing of sub-expressions. [I've also found that having
a "deflex" or "def" macro for defining top-level lexical variables
is very helpful; the following assumes that's been enabled.]
This short example compares the syntaxes. First, normal Common Lisp:
> (+ 1 2)
3
> (def x 34)
X
> (def y 25)
Y
> (expt x y)
193630125104980427932766033374162714624
> (expt x (- y 12))
81138303245565435904
> (mod ** 9)
7
>
Now, exactly the same sequence of operations using OPFR syntax:
opfr> + 1 2
3
opfr> def x 34
X
opfr> def y 25
Y
opfr> expt x y
193630125104980427932766033374162714624
opfr> expt x (- y 12)
81138303245565435904
> mod ** 9
7
opfr>
The average Lisp programmer will see no significant advantage to the
OPFR syntax (and some disadvantages, such as the need to resolve the
ambiguity of a naked symbol[1]), especially since sub-expressions must
still be fully-parenthesized as in the last example above. Nevertheless,
experience with real users over more than a decade has shown that the
acceptance of the OPFR syntax to the average user is *enormously*
greater than the "pure" Lisp s-expr. Go figure.
-Rob
[1] For compatibility with Tcl and other interfaces the user might
be used to, OPFR calls a naked symbol as a "command" function if
it's FBOUNDP, else it's treated as a variable whose value is to
be printed. Conversely, if the user types a form *with* the outer
parens supplied [as is all too frequent by accident when Lisp users
type at an OPFR!], it strips the "extra" level of parens. This
almost always "does the right thing".
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
>But an earlier, much less featureful hack *is* easy in CL, and it
>turns out to solve almost all of the parenthephobia issues, at least
>the ones I tend to run into. I called it "OPFR", for "Outer-Parentheses-
>Free REPL". [Yes, yes, I need to put it up on my server. Long past time,
>actually. (*blush*)]
[...snip...]
>Now, exactly the same sequence of operations using OPFR syntax:
>
> opfr> + 1 2
> 3
> opfr> def x 34
> X
> opfr> def y 25
> Y
> opfr> expt x y
> 193630125104980427932766033374162714624
> opfr> expt x (- y 12)
> 81138303245565435904
> > mod ** 9
> 7
> opfr>
Cool. It reminds me of something... but I don't know what though...
(defvar *tab* " "
"use this instead of a #\tab))
(defvar *buffer* (make-string-output-stream))
(defun exit-repl ()
:exit-this-ridiculous-thing)
(defun reader (input expr-depth line-depth)
(let ((tab? (search *tab* input :test 'string=)))
(cond ((string= input "") (write-string (make-string (1+
expr-depth) :initial-element #\)) *buffer*)
(if (eq (princ (eval (read-from-string
(get-output-stream-string *buffer*))))
:exit-this-ridiculous-thing)
'done
(%repl)))
(tab? (reader (subseq input (length *tab*))
expr-depth
(1+ line-depth)))
((> expr-depth line-depth) (write-char #\) *buffer*)
(reader input (1- expr-depth)
line-depth))
((= expr-depth line-depth) (write-string "(" *buffer*)
(write-string input *buffer*)
(princ "... ")
(reader (read-line) (1+ expr-depth) 0))
((< expr-depth line-depth) (write-string " (" *buffer*)
(reader input (1+ expr-depth)
line-depth))
(t '(what did you do?)))))
(defun %repl ()
(fresh-line)
(princ ">>> ")
(get-output-stream-string *buffer*)
(let ((input (read-line)))
(reader input 0 0)))
(defun repl ()
(fresh-line)
(princ "TYPE EXIT-REPL TO QUIT")
(%repl))
;;;;;;;;;;;;;;;;;;;;;;
CL-USER> (repl)
TYPE EXIT-REPL TO QUIT
>>> if t
... quote true
... quote false
...
TRUE
>>> loop for x from 1 to 10 collect x
...
(1 2 3 4 5 6 7 8 9 10)
>>> exit-repl
...
EXIT-THIS-RIDICULOUS-THING
DONE
CL-USER>
ahah, I know now!
It's Dylan!
jk
;-)
hrm I couldn't write
>>> if t
... 'true
... 'false
I guess this is a testament to the amount of semantics packed into such
a simple schema of homogenous delimiters.
> Nevertheless,
>experience with real users over more than a decade has shown that the
>acceptance of the OPFR syntax to the average user is *enormously*
>greater than the "pure" Lisp s-expr. Go figure.
Perhaps parens infer a necessitated demarkation to someone used to
infix syntax? (thus, when encasing the outer-most expression, they
imply some sort of a dependent clause or single object instead of an
independent expression...)
Nick
On 2006-01-11 08:19:21 -0500, ········@gmail.com said:
>
>> Nevertheless,
>> experience with real users over more than a decade has shown that the
>> acceptance of the OPFR syntax to the average user is *enormously*
>> greater than the "pure" Lisp s-expr. Go figure.
>
> Perhaps parens infer a necessitated demarkation to someone used to
> infix syntax? (thus, when encasing the outer-most expression, they
> imply some sort of a dependent clause or single object instead of an
> independent expression...)
what nick said. Users are more comfortable with what they are used to,
and what naive users are used to is ordinary written text. In ordinary
writing one never starts a sentence with a parenthetical remark, but
it's perfectly alright to include one (or more). So Rob's OPFR makes
users comfortable by resembling the syntax of ordinary writing wrt the
use of parens.
<········@gmail.com> wrote:
+---------------
| Rob Warnock wrote:
| >But an earlier, much less featureful hack *is* easy in CL...
| > opfr> expt x y
| > 193630125104980427932766033374162714624
| > opfr> expt x (- y 12)
| > 81138303245565435904
| > > mod ** 9
| > 7
| > opfr>
|
| Cool. It reminds me of something... but I don't know what though...
...
| ahah, I know now!
|
| It's Dylan!
+---------------
Well, uh, yes, sorta. ;-} Except Dylan v.2 used infix for
subexpressions, didn't it?
+---------------
| hrm I couldn't write
| >>> if t
| ... 'true
| ... 'false
| I guess this is a testament to the amount of semantics packed into such
| a simple schema of homogenous delimiters.
+---------------
I got around that by stealing the "escape newline with \" hack
from Tcl:
opfr> if t \
'true \
'false
TRUE
opfr> loop for x from 1 to 10 collect x
(1 2 3 4 5 6 7 8 9 10)
opfr> loop for x from 1 to 10 \
collect x
(1 2 3 4 5 6 7 8 9 10)
opfr> loop for x from 1 to 10 \
and y = (expt 1 x) \
collect (cons x y)
((1 . 1) (2 . 1) (3 . 1) (4 . 1) (5 . 1) (6 . 1) (7 . 1) (8 . 1)
(9 . 1) (10 . 1))
opfr>
Ugly, but as you noted, once you give up simple parens all *kinds*
of cruft creeps in... ;-}
+---------------
| > Nevertheless, experience with real users over more than a decade
| > has shown that theacceptance of the OPFR syntax to the average user
| > is *enormously*greater than the "pure" Lisp s-expr. Go figure.
|
| Perhaps parens infer a necessitated demarkation to someone used to
| infix syntax? (thus, when encasing the outer-most expression, they
| imply some sort of a dependent clause or single object instead of an
| independent expression...)
+---------------
I dunno. What I do know is that people who would tilt up their noses
or gag or run screaming from the room and refuse to use a tool that
made you type this:
> (ecc-dump)
...[lots of chatter]...
> (ecc-clear)
> (ecc-scan 0 #x200000)
> (mem-fill (+ bar1 #x100) #x100 0)
>
had no objections at all to typing this:
> ecc-dump
...[lots of chatter]...
> ecc-clear
> ecc-scan 0 0x200000
> mem-fill (+ base-reg-1 0x100) 0x100 0
>
So guess which one I gave them? ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
>>It's Dylan!
>Well, uh, yes, sorta. ;-} Except Dylan v.2 used infix for
>subexpressions, didn't it?
actually I was trying to draw contrast to my example's likeness to
Python. as usual my attempt at humour failed ;-)
>I got around that by stealing the "escape newline with \" hack
>from Tcl:
>
> opfr> if t \
> 'true \
> 'false
[snip]
>Ugly, but as you noted, once you give up simple parens all *kinds*
>of cruft creeps in... ;-}
I was thinking about this problem last night. It doesn't sound like cpu
time is a big issue for your users (as opposed to the amount typing
they have to do and the scarcity of parenthesis in the content they
have to type). Perhaps some sort of a trial-and-error parsing strategy
wouldn't be too outrageous to consider
(defvar *tab* " ")
(defvar *buffer* (make-string-output-stream))
(defun repl ()
(format t "Type exit to exit~%~%")
(let ((*error-output* nil))
(do ()
(nil)
(fresh-line)
(princ ">>> ")
(when (eq (%repl nil (read-line)) :exit) (return 'done)))))
(defun repl ()
(format t "Type exit to exit~%~%")
(let ((*error-output* nil))
(do ()
(nil)
(fresh-line)
(princ ">>> ")
(when (eq (%repl nil (read-line)) :exit) (return 'done)))))
(defun %repl (input line)
(cond ((string-equal line "")(with-open-paren-reader input))
((string-equal line "exit")(return-from %repl :exit))
(t (let ((tab? (search *tab* line)))
(cond (tab? (%repl input (subseq line (length *tab*))))
(t (princ "... ")
(%repl (cons :maybe-close-paren
(cons line
(cons :maybe-open-paren
input)))
(read-line))))))))
(defun with-open-paren-reader (input)
(labels ((%with-open-paren-reader (input accum)
(cond ((null input) (if (eq (with-close-paren-reader accum)
:return)
(return-from with-open-paren-reader :return)))
((eq (car input) :maybe-open-paren) (%with-open-paren-reader
(cdr input) (cons "(" accum))
(%with-open-paren-reader
(cdr input) (cons " " accum)))
(t (%with-open-paren-reader (cdr input) (cons (car input)
accum))))))
(%with-open-paren-reader input nil)))
(defun with-close-paren-reader (input)
(labels ((%with-close-paren-reader (input accum depth max-depth
print-depth)
(cond ((> depth max-depth) (%with-close-paren-reader input
accum depth (1+ max-depth) (1+ print-depth)))
((null input) (when (eq (%eval (reverse accum)) :return)
(return-from with-close-paren-reader :return)))
((eq (car input) :maybe-close-paren) (%with-close-paren-reader
(cdr input) (cons " " accum) depth max-depth print-depth)
(if (= print-depth 0)
(%with-close-paren-reader (cdr input) (cons ")" accum) 0
max-depth max-depth)
(%with-close-paren-reader input (cons ")" accum) depth
max-depth (1- print-depth))))
(t (%with-close-paren-reader (cdr input) (cons (car input)
accum) depth max-depth print-depth)))))
(%with-close-paren-reader input nil 1 1 1)))
(defun %eval (accum)
(map nil #'(lambda (x) (write-string x *buffer*)) accum)
(let ((string (string-right-trim " " (get-output-stream-string
*buffer*))))
(multiple-value-bind (read-string n)
(handler-case (read-from-string string) (error () :error))
(unless (eq read-string :error)
(let ((eval? (handler-case (eval read-string)
(error () :error))))
(unless (or (null (string= (subseq string n) ""))
(eq eval? :error))
(prin1 eval?)
:return))))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CL-USER> (repl)
Type exit to exit
>>> + 4 5
...
9
>>> (+ 4 5)
...
9
>>> +
... 4
... 5
...
9
>>> 6
...
6
>>> if t
... :true
... :false
...
:TRUE
>>> if t
... quote ok
... quote nope
...
OK
>>> loop for x from 1 to 10
... collect x
...
(1 2 3 4 5 6 7 8 9 10)
>>> exit
DONE
CL-USER>
this makes a tree of all the possible states that could be deduced by
the parser and evals them until one doesn't signal an error and uses
the last non whitespace char of the input string (I kept getting the
last command entered into the repl for "+ 4 5" and had no idea wtf was
going on)
you could of course add a restraint system to manipulate the order in
which nodes are evaluated based on statistical probability or a simple
contextual analysis, but I don't really see what the point would be
Nick
········@gmail.com writes:
> I was thinking about this problem last night. It doesn't sound like cpu
> time is a big issue for your users (as opposed to the amount typing
> they have to do and the scarcity of parenthesis in the content they
> have to type). Perhaps some sort of a trial-and-error parsing strategy
> wouldn't be too outrageous to consider
> [...]
> this makes a tree of all the possible states that could be deduced by
> the parser and evals them until one doesn't signal an error and uses
> the last non whitespace char of the input string (I kept getting the
> last command entered into the repl for "+ 4 5" and had no idea wtf was
> going on)
>
> you could of course add a restraint system to manipulate the order in
> which nodes are evaluated based on statistical probability or a simple
> contextual analysis, but I don't really see what the point would be
>>> setq x 1
...
1
>>> if zerop decf x print 2 print 3
...
>>> x
...
1
>>> (if (zerop (decf x (print 2))) (print 3))
...
2 NIL
>>> x
...
-1
>>> setq x 1
... 1
>>> (if (zerop (decf x)) (print 2) (print 3))
...
2 2
>>> x
...
0
>>>
How does it interpret "if zerop decf x print 2 print 3" ???
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
I wrote:
> this makes a tree of all the possible states that could be deduced by
> the parser and evals them until one doesn't signal an error and uses
> the last non whitespace char of the input string...
then pascal wrote:
+----------
|>>> setq x 1
|...
|1
|>>> if zerop decf x print 2 print 3
|...
|>>> x
|...
|1
|>>> (if (zerop (decf x (print 2))) (print 3))
|...
|2 NIL
|>>> x
|...
|-1
|>>> setq x 1
|... 1
|>>> (if (zerop (decf x)) (print 2) (print 3))
|...
|2 2
+----------
ok, I omitted a lot. let me rephrase that... It doesn't create a tree
based on all the possible ways to delineate combinations of atoms with
parenthesis, it only looks at newlines[1].
It parses up the tree from the tail end and diverges at nodes that may
or may not be open parenthesis (:maybe-open-paren) then parses back
down the tree from each leaf and diverges again at :maybe-close-paren
into as many states as there are open parenthesis to close
If you add the following line of code
(format t "ERROR: ~A" (reverse input))
after
(%with-open-paren-reader input nil)
at the end of the with-open-paren-reader defun, making
...
(%with-open-paren-reader input nil)
(format t "ERROR: ~A" (reverse input))))
you can get some error output and see what's going on
>>> + 4 5
...
9
>>> + 4 #\g
...
ERROR: (MAYBE-OPEN-PAREN + 4 #\g MAYBE-CLOSE-PAREN)
>>> if zerop decf x print 2 print 3
...
ERROR: (MAYBE-OPEN-PAREN if zerop decf x print 2 print 3
MAYBE-CLOSE-PAREN)
to match the results of these lines (if (zerop (decf x (print 2)))
(print 3)) or (if (zerop (decf x)) (print 2) (print 3)) you could
>>> (setq x 1)
...
1
>>> if (zerop (decf x (print 2)))
... print 3
...
2 NIL
>>> (setq x 1)
...
1
>>> if (zerop (decf x))
... print 2
... print 3
...
2 NIL
So I guess the purpose of this could best defined as a layer over the
reader to infer possible syntax constructs delineated by newlines, and
a layer over eval to find the right combination of following and
ignoring those rules
Nick
[1] on looking over my own code I see that *tab* really serves no
purpose. I think I originally intended it to infer nested expressions
but ended up being unnecessary...
<········@gmail.com> wrote:
+---------------
| So I guess the purpose of this could best defined as a layer over
| the reader to infer possible syntax constructs delineated by newlines,
| and a layer over eval to find the right combination of following and
| ignoring those rules
+---------------
Uh... I think I'll stick with my much simpler original OPFR, thanks. ;-}
It has the virtue of being very simple to code *and* having behavior
that's extremely predictable by the human user [being pure CL except
for the outer parens].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> Uh... I think I'll stick with my much simpler original OPFR, thanks. ;-}
> It has the virtue of being very simple to code *and* having behavior
> that's extremely predictable by the human user [being pure CL except
> for the outer parens].
Are you saying I missed the O.C. for nothing?!?!?!?! jk, I was just
wasting time (also I don't watch tv)
;-)
Nick
Rob Warnock wrote:
> I dunno. What I do know is that people who would tilt up their noses
> or gag or run screaming from the room and refuse to use a tool that
> made you type this:
>
> > (ecc-dump)
> ...[lots of chatter]...
> > (ecc-clear)
> > (ecc-scan 0 #x200000)
> > (mem-fill (+ bar1 #x100) #x100 0)
> >
>
> had no objections at all to typing this:
>
> > ecc-dump
> ...[lots of chatter]...
> > ecc-clear
> > ecc-scan 0 0x200000
> > mem-fill (+ base-reg-1 0x100) 0x100 0
> >
>
> So guess which one I gave them? ;-} ;-}
I would have given them a sedative. Geez.
But if you can fool some of the people all of the time.....
From: Robert Uhl
Subject: Re: About those parenthesis....
Date:
Message-ID: <m3lkxlrno9.fsf@4dv.net>
····@rpw3.org (Rob Warnock) writes:
>
> I dunno. What I do know is that people who would tilt up their noses
> or gag or run screaming from the room and refuse to use a tool that
> made you type this:
>
> > (ecc-dump)
> ...[lots of chatter]...
> > (ecc-clear)
> > (ecc-scan 0 #x200000)
> > (mem-fill (+ bar1 #x100) #x100 0)
> >
>
> had no objections at all to typing this:
>
> > ecc-dump
> ...[lots of chatter]...
> > ecc-clear
> > ecc-scan 0 0x200000
> > mem-fill (+ base-reg-1 0x100) 0x100 0
> >
That makes perfect sense to me--given that in such a situation the user
must constantly type enclosing parentheses, he naturally wishes that the
computer would infer their presence. Also, the latter interface looks
near-identical to dealing with a Unix or DOS shell: command-name
followed by arguments, some of which can substitute the results of other
commands.
As a general rule, making the user do work doable by a computer is a Bad
Thing; also being similar to a familiar interface is a Good Thing.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The one pervading evil of democracy is the tyranny of the majority, or
rather of that party, not always the majority, that succeeds, by force
or fraud, in carrying elections. --Lord Acton
Robert Uhl wrote:
> As a general rule, making the user do work doable by a computer is a Bad
> Thing; also being similar to a familiar interface is a Good Thing.
As a general rule, people can't do precedence.
-andy
····@rpw3.org (Rob Warnock) writes:
> experience with real users over more than a decade has shown that
> the acceptance of the OPFR syntax to the average user is
> *enormously* greater than the "pure" Lisp s-expr. Go figure.
not hard to figure at all: the existence of "special" rules (like "no
parens needed, *except* for nested expressions!") tells the user
"look, it's obvious that the author had to make an effort to make this
convenient". syntactic warts just have to mean warm fuzzies -- if you
must pay a cognitive price, it must be for convenience, right? ergo,
a warty syntax is *obviously* more convenient than a completely
regular one.
rationalizing the world away for fun and profit,
--m
--
newsgroup volume is a measure of discontent. -- Erik Naggum
····@rpw3.org (Rob Warnock) writes:
[stuff deleted]
> But an earlier, much less featureful hack *is* easy in CL, and it
> turns out to solve almost all of the parenthephobia issues, at least
> the ones I tend to run into. I called it "OPFR", for "Outer-Parentheses-
> Free REPL". [Yes, yes, I need to put it up on my server. Long past time,
> actually. (*blush*)]
If you try to pronounce OPFR as a word in German language you get
OPFER which is /victim/ in English language. Now, imagine how that
produced a real good laugh on my side!
Which is, besides the real value of OPFR, the only good thing of this
long thread about parens IMHO.
Cheers,
Frank
Frank Goenninger DG1SBG wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
> [stuff deleted]
>
>>But an earlier, much less featureful hack *is* easy in CL, and it
>>turns out to solve almost all of the parenthephobia issues, at least
>>the ones I tend to run into. I called it "OPFR", for "Outer-Parentheses-
>>Free REPL". [Yes, yes, I need to put it up on my server. Long past time,
>>actually. (*blush*)]
>
>
> If you try to pronounce OPFR as a word in German language you get
> OPFER which is /victim/ in English language. Now, imagine how that
> produced a real good laugh on my side!
>
> Which is, besides the real value of OPFR, the only good thing of this
> long thread about parens IMHO.
You did not like the bit about Arabs' horses' noses?
kenny
Kenny Tilton <·············@nyc.rr.com> writes:
> Frank Goenninger DG1SBG wrote:
>> ····@rpw3.org (Rob Warnock) writes:
>> [stuff deleted]
>>
>>>But an earlier, much less featureful hack *is* easy in CL, and it
>>>turns out to solve almost all of the parenthephobia issues, at least
>>>the ones I tend to run into. I called it "OPFR", for "Outer-Parentheses-
>>>Free REPL". [Yes, yes, I need to put it up on my server. Long past time,
>>>actually. (*blush*)]
>> If you try to pronounce OPFR as a word in German language you get
>> OPFER which is /victim/ in English language. Now, imagine how that
>> produced a real good laugh on my side!
>> Which is, besides the real value of OPFR, the only good thing of
>> this
>> long thread about parens IMHO.
>
> You did not like the bit about Arabs' horses' noses?
>
> kenny
I did <g>. But I sense I did not get the full joke, somehow. Or?
Frank
Joe Marshall wrote:
> Well, I may be a few seconds early, but I'm curious to hear from the
> newbies that are no longer using training wheels as to how awful they
> thought parenthesis were at the beginning, how long it took them to get
> used to them, and what they think now.
Actually, I never thought much of them. Being something of a language
nut, I've seen (and programmed to various levels) APL, SNOBOL, COBOL,
FORTRAN, RPG, FORTH, C, BASIC... I always just thought if that's what
the designers wanted, so be it. After all, there are stranger
languages out there - and I thought the same there, too.
If someone wanted to complain that this or that language was
write-only, I'd just like to point them at an RPG printout on plain
unruled paper and see what they think....