From: ········@gmail.com
Subject: Learning Lisp in Linux?
Date: 
Message-ID: <1190504965.402907.183180@19g2000hsx.googlegroups.com>
I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
and the Practical Common Lisp by Peter Seibel (free webpages I
downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
but have never used SLIME or ilisp before (the ilisp package is
currently broken in Debian testing release). Any tips on getting
started:

1) learning lisp
2) learning lisp in linux/emacs

Thanks!
Lisp 9000

From: ···············@gmail.com
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1190542318.357181.295870@y42g2000hsy.googlegroups.com>
On Sep 23, 12:49 am, ·········@gmail.com" <········@gmail.com> wrote:

> Any tips on getting started:
>
> 1) learning lisp

ABLE (http://phil.nullable.eu/)

> 2) learning lisp in linux/emacs

SLIME (http://common-lisp.net/project/slime/)

--
Phil, http://phil.nullable.eu/
From: John Thingstad
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <op.ty29n51ypqzri1@pandora.upc.no>
P� Sun, 23 Sep 2007 01:49:25 +0200, skrev ········@gmail.com  
<········@gmail.com>:

> I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:
>
> 1) learning lisp
> 2) learning lisp in linux/emacs
>
> Thanks!
> Lisp 9000
>

How about LispInABox and SBCL/CLISP?
Configuring SLIME can be somewhat of a pain.
Avoid GCL as it isn't fully ANSI compatible and will probaly  
frustrate/confuse you whan you try to get third pary libaries to work.
From: Alex Mizrahi
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <46f78dbf$0$90272$14726298@news.sunsite.dk>
(message (Hello 'John)
(you :wrote  :on '(Sun, 23 Sep 2007 06:05:55 +0200))
(

 JT> Configuring SLIME can be somewhat of a pain.

since when writing three-four lines into config is a pain?

if _that_ is pain, then it's probably better to stop learning programming 
languages -- they say some programs consist of hundreds, and even thousands 
of lines! that would definitely by unimaginable pain..

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"Hanging In The Balance Of Deceit And Blasphemy") 
From: David Golden
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <qyMJi.22240$j7.399711@news.indigo.ie>
Alex Mizrahi wrote:

> (message (Hello 'John)
> (you :wrote  :on '(Sun, 23 Sep 2007 06:05:55 +0200))
> (
> 
>  JT> Configuring SLIME can be somewhat of a pain.
> 
> since when writing three-four lines into config is a pain?

Probably when they split slime into core and contribs.  I'm still
not 100% I've got those three-four lines right (because what is "right"
seemed to change rapidly recently owing to the split, last I checked
the only place it was documented apart from inspecting the source was
in posts to  slime-devel (though that might have changed by now,
granted)).
From: John Thingstad
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <op.ty5mdtjmpqzri1@pandora.upc.no>
P� Mon, 24 Sep 2007 12:13:18 +0200, skrev Alex Mizrahi  
<········@users.sourceforge.net>:

> (message (Hello 'John)
> (you :wrote  :on '(Sun, 23 Sep 2007 06:05:55 +0200))
> (
>
>  JT> Configuring SLIME can be somewhat of a pain.
>
> since when writing three-four lines into config is a pain?
>
> if _that_ is pain, then it's probably better to stop learning programming
> languages -- they say some programs consist of hundreds, and even  
> thousands
> of lines! that would definitely by unimaginable pain..
>
> )
> (With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
> "Hanging In The Balance Of Deceit And Blasphemy")
>
>

It's a pain if you don't already know Emacs. For one thing.. What file? If  
you are only one user perhaps .emacs. But for several users  
site-start.lisp might be better. What about font lock? Want Emacs or  
Windows key mapping. Typewriter mode? what fill coulumn? Is the default  
emacs window big enough? Did you set up the printer right? Perhaps  
nxml-mode, CSS mode, javascript-mode for web developement. Does spell  
checking work? Do you launch the right browser? ... ... My site-start file  
is several hundred lines.. (It's more of a pain under Windows)
From: Alex Mizrahi
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <46f8bc3d$0$90274$14726298@news.sunsite.dk>
(message (Hello 'John)
(you :wrote  :on '(Mon, 24 Sep 2007 12:35:43 +0200))
(

 JT> It's a pain if you don't already know Emacs. For one thing.. What file?
 JT> If  you are only one user perhaps .emacs.

and how you can be more than one user?
if you want to enable SLIME for several users, this is probably quite 
unusual environment, and you are a sysadmin.

 JT> (It's more of a pain under Windows)

ok, i dunno.. i have XEmacs under Windows.
i's quite obvious which file to open -- there's "Open Init file" button.
so i've opened it and wrote lines like that:

(add-to-list 'load-path "h:/lisp/slime-new3/slime")
(require 'slime)
(add-hook 'lisp-mode-hook (lambda () (slime-mode t)))
(add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t)))
(setq inferior-lisp-program "clisp")

and that freaking just worked well. i know they use (slime-setup) nowadays, 
but it just worked that time..
i've then also defined some other dialects.
hyperspec:

(setq common-lisp-hyperspec-root "file:///C:/TEXTS/hyperspec/HyperSpec/")
(setq common-lisp-hyperspec-symbol-table 
"C:/TEXTS/hyperspec/HyperSpec/Data/Map_Sym.txt")

and some improvements:

(paren-set-mode 'blink-paren)
(setq lisp-indent-function 'common-lisp-indent-function)

and that's quite all -- at that point i was quite satisfied with XEmacs.
my experience is vastly from Windows editors, so i've surprised that it has 
quite sane keybindings just like i was used to.

 JT>  But for several users site-start.lisp might be better. What about font
 JT> lock? Want Emacs or Windows key mapping. Typewriter mode? what fill
 JT> coulumn? Is the default emacs window big enough? Did you set up the
 JT> printer right? Perhaps nxml-mode, CSS mode, javascript-mode for web
 JT> developement. Does spell checking work? Do you launch the right
 JT> browser? ... ... My site-start file  is several hundred lines..

mine is 25 lines. if you _like_ that much customizations, why are you 
complaining?

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"Hanging In The Balance Of Deceit And Blasphemy") 
From: John Thingstad
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <op.ty7fmsy2pqzri1@pandora.upc.no>
P� Tue, 25 Sep 2007 09:43:55 +0200, skrev Alex Mizrahi  
<········@users.sourceforge.net>:

It is not that unusual. I normally work as a restricted user, but  
sometimes I need to do administrative tasks like changing the Apache  
config and I like emacs to work the same way.

>
> mine is 25 lines. if you _like_ that much customizations, why are you
> complaining?
>

It is not a pain because I have build up my .emacs file over 20 years. It  
has suvived 3 operating systems and 7 computers. If I were to loose it I  
would despair..
From: Tim X
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87d4w3a6nm.fsf@lion.rapttech.com.au>
"John Thingstad" <··············@chello.no> writes:

> På Tue, 25 Sep 2007 09:43:55 +0200, skrev Alex Mizrahi
> <········@users.sourceforge.net>:
>
> It is not that unusual. I normally work as a restricted user, but
> sometimes I need to do administrative tasks like changing the Apache
> config and I like emacs to work the same way.

Then use your normal emacs. Through the use of tramp (now bundled as part
of emacs), you can edit files owned by anyone using the sudo or su tramp
methods and likewise, you can execute commands as another user using the
same method. No need to start another emacs as a different user - all you
need is to know the password or have sudo configured.

I think it is misleading to claim that emacs is a pain to configure because
it gives those unfamiliar with it the impression that you *have* to go
through this painful configuration. The reality (as shown by Alex's point
where he mentions his config is 25 lines), is that you are not required to
go through this extended configuration just to use the editor. In fact,
rather than seeing this as a negative, I see it as one of emacs'
strengths. You can use it in a very basic minimal configuration and you
will get a lot of great functionality. However, unlike many other systems,
you also have the power to change and tweak that configuration, largely
limited only by your imagination and knowledge of elisp. If you want to run
a heavily customized version, yes, you will likely have to do quite a lot
of elisp and its likely to be time consuming and even frustrating at times,
but at least you have th eoption *and* your not forced to do it. 

I cannot think of a single powerful piece of software that is as extensive
in its customization as emacs that doesn't require a complex process to
achieve that customization and for CL programmers, at least it is a lisp
like configuration and not some half baked weird arse vendor configuration
scripting language that is usually buggy and inconsistent in its operation.

Tim



-- 
tcross (at) rapttech dot com dot au
From: samantha
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193390034.018833.166250@y27g2000pre.googlegroups.com>
On Sep 24, 3:35 am, "John Thingstad" <··············@chello.no> wrote:
>
> It's a pain if you don't already know Emacs. For one thing.. What file? If
> you are only one user perhaps .emacs.

Problem at hand is one user.

>But for several users
> site-start.lisp might be better. What about font lock?

What about it?  Has little to do with elementary set up and is on in
most standard modes anyway for most recent emacsen.

>Want Emacs or
> Windows key mapping.

Windows key mapping in Linux and Emacs?  What are you, a masochist?

>Typewriter mode? what fill coulumn?

Irrelevant to the primary query.

>Is the default
> emacs window big enough? Did you set up the printer right?

Irrelevant as not specific to the problem.

>Perhaps
> nxml-mode, CSS mode, javascript-mode for web developement. Does spell
> checking work? Do you launch the right browser? ... ... My site-start file
> is several hundred lines.. (It's more of a pain under Windows)

And more irrelevant stuff to the problem except for the browser thing
for docs.  It is easy to find the right config for that to match your
browser with a few moments googling.

One thing lisp is not currently is tremendously user friendly.  But
setting up a emacs/slime environment is pretty easy.
From: Carlo Capocasa
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <fd8efp$8di$1@registered.motzarella.org>
> if _that_ is pain, then it's probably better to stop learning programming 
> languages -- they say some programs consist of hundreds, and even thousands 
> of lines! that would definitely by unimaginable pain..

It's a matter of which pain is worth it.

Carlo
From: gavino
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193245644.895616.141890@z24g2000prh.googlegroups.com>
On Sep 22, 9:05 pm, "John Thingstad" <··············@chello.no> wrote:
> P� Sun, 23 Sep 2007 01:49:25 +0200, skrev ········@gmail.com
> <········@gmail.com>:
>
> > I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> > and the Practical Common Lisp by Peter Seibel (free webpages I
> > downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> > but have never used SLIME or ilisp before (the ilisp package is
> > currently broken in Debian testing release). Any tips on getting
> > started:
>
> > 1) learning lisp
> > 2) learning lisp in linux/emacs
>
> > Thanks!
> > Lisp 9000
>
> How about LispInABox and SBCL/CLISP?
> Configuring SLIME can be somewhat of a pain.
> Avoid GCL as it isn't fully ANSI compatible and will probaly
> frustrate/confuse you whan you try to get third pary libaries to work.

slime is simple to get going with emacs:
http://wiki.archlinux.org/index.php/Slime
the important parts are placing the .emacs file in your users (example
bob) home dir and pointing it to your lisp (here sbcl) and slime
itself (where you unpacked it /slime)
Then fire up emacs and go alt-x, slime will be loaded, and bam!
automatic indentation etc.
alt-p beings back last typed command
From: ··········@gmail.com
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1190577687.990469.94420@w3g2000hsg.googlegroups.com>
On Sep 22, 7:49 pm, ·········@gmail.com" <········@gmail.com> wrote:
> I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:
>
> 1) learning lisp
> 2) learning lisp in linux/emacs
>
> Thanks!
> Lisp 9000

I got Lisp, SLIME, & XEmacs running on Debian without much trouble. I
installed the Debian SLIME package, then added the following 3 lines
to my "init.el" file to get it running with SBCL:

(setq inferior-lisp-program "/usr/bin/sbcl")
(require 'slime)
(slime-setup)

Run slime by typing "meta-x slime"

SLIME gives you an interactive Lisp prompt and provides hints on
function & macro usage in the minibuffer for any .lisp source files
you have open.

Ben
From: Carlo Capocasa
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <fd6dh3$80a$1@registered.motzarella.org>
Just started out with Lisp as well and I documented my experience in

> 1) learning lisp

without

> 2) learning lisp in linux/emacs

.

Well, linux yes, emacs no :)

The post's name is: 'How To Learn Lisp (rev.2) '. If you decide to
read it and would like to help me out you can give me some feedback,
I need to know whether I'm useful and/or bearable to read.

Carlo
From: Alberto Riva
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <fd7ctc$n03m$1@usenet.osg.ufl.edu>
········@gmail.com wrote:
> I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:
> 
> 1) learning lisp

Very easy, just read, understand and execute the following:

(with-open-book (pcl "Practical Common Lisp")
   (loop
     (when (book-finished-p pcl)
       (return))
     (read-page pcl)
     (goto-next-page pcl)))
From: gavino
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1190678758.921380.251000@19g2000hsx.googlegroups.com>
On Sep 22, 4:49 pm, ·········@gmail.com" <········@gmail.com> wrote:
> I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:
>
> 1) learning lisp
> 2) learning lisp in linux/emacs
>
> Thanks!
> Lisp 9000

http://wiki.archlinux.org/index.php/Slime

I wrote this to get linux+emacs+slime up and going.
The details of how to save your work and restore I am currently
reading up on.  Please anyone feel free to throw in 2 cents on howto
save your home brew functions and definitions on disk, and howto load
them for the next programming day.
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <S8zTi.125$TO4.55@newsfe12.lga>
········@gmail.com wrote:
> I want to learn Lisp in Linux.

I like it when people build cages around themselves.

> I have the ANSI Lisp book (hardcopy)

Graham?

> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded).

That'll teach him.

> I have CLISP, gcl, sbcl, and cmucl installed.

Whoa, your Lisp is bigger than my Lisp.

> I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:
> 
> 1) learning lisp

Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop 
for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".

> 2) learning lisp in linux/emacs

Take down the cage.

> 
> Thanks!

Premature?

kzo

* My memory in old age is weak, there may be a decent ACL IDE free trial 
for Linux. The LW trial would be a solid alternative, not sure if theirs 
runs on all OSes or what. k

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: OMouse
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193200594.961936.276570@k35g2000prh.googlegroups.com>
On Oct 23, 11:40 pm, Ken Tilton <···········@optonline.net> wrote:
> Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
> for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".

Delete ACL free trial and Vista. Buy a killer Symbolics Genera machine
for $???. Use the operating system/development environment. To learn
Lisp, not "Lisp on C-based garbage".
From: Frank Goenninger DG1SBG
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <lz3aw1ni4h.fsf@pcsde001.de.goenninger.net>
Ken Tilton <···········@optonline.net> writes:

> ········@gmail.com wrote:
>> I want to learn Lisp in Linux.
>> I have CLISP, gcl, sbcl, and cmucl installed.
>
> Whoa, your Lisp is bigger than my Lisp.

Shows some true dedication from the OP. Installing all of them at
least requires solid Googling and trying for a week.

>
>> I use emacs
>> but have never used SLIME or ilisp before (the ilisp package is
>> currently broken in Debian testing release). Any tips on getting
>> started:
>>
>> 1) learning lisp
>
> Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
> for  $450. 

Bad advice, really. The OP will spent all his time getting Shita to
work having no time to learn Lisp. But hey, one newbie less there on
c.l.l ;-)

> Use ACL free trial. To learn Lisp, not "Lisp in X".

I'd rather say: Learn Lisp while you enjoy a Lisp IDE on Mac OS X.
What is the result of joy squared? ;-)

>
>> 2) learning lisp in linux/emacs
>
> Take down the cage.
>
>>
>> Thanks!
>
> Premature?
>
> kzo
>
> * My memory in old age is weak, there may be a decent ACL IDE free
> trial for Linux. The LW trial would be a solid alternative, not sure
> if theirs runs on all OSes or what. k

Now that I have seen (and used) LW PE and ACL EE I'd say they are on par for
attractiveness to a newbie.

Wishing you a not too deep learning curve... Oh, I see it's lisp9000
... S/he has been around some time already...

Frank

-- 

  Frank Goenninger

  frgo(at)mac(dot)com

  "Don't ask me! I haven't been reading comp.lang.lisp long enough to 
  really know ..."
From: Brian Adkins
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193240153.053346.188640@t8g2000prg.googlegroups.com>
On Oct 23, 11:40 pm, Ken Tilton <···········@optonline.net> wrote:
> ········@gmail.com wrote:
> > I want to learn Lisp in Linux.
> Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
> for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".

Nice one :) But even if you don't want newbies around, I hardly think
sending him off on a wild goose chase of working on a virus & spyware
infested, memory leaking, license monitoring, reboot loving excuse for
an operating system is fair. How about a little temperance.
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <9NKTi.553$xV3.223@newsfe12.lga>
Brian Adkins wrote:
> On Oct 23, 11:40 pm, Ken Tilton <···········@optonline.net> wrote:
> 
>>········@gmail.com wrote:
>>
>>>I want to learn Lisp in Linux.
>>
>>Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
>>for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".
> 
> 
> Nice one :) But even if you don't want newbies around, I hardly think
> sending him off on a wild goose chase of working on a virus & spyware
> infested, memory leaking, license monitoring, reboot loving excuse for
> an operating system is fair. How about a little temperance.
> 

The AllegroCL installer apparently fixes all that.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87k5pa3lrv.fsf@geddis.org>
Ken Tilton <···········@optonline.net> wrote on Tue, 23 Oct 2007:
> Buy a killer Vista laptop for $450.

Really?  Where can I get me one of those?
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Writing about music is like dancing about architecture.
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <z99Ui.6945$qt4.2131@newsfe12.lga>
Don Geddis wrote:
> Ken Tilton <···········@optonline.net> wrote on Tue, 23 Oct 2007:
> 
>>Buy a killer Vista laptop for $450.
> 
> 
> Really?  Where can I get me one of those?

<cough> OK, not "killer". Well, unless you grade on a curve going back a 
few years. I forget, it was either Office Depot or the minigrocery at my 
gas station.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Jay Belanger
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <m3tzoeygln.fsf@gmail.com>
Ken Tilton <···········@optonline.net> writes:
...
> Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
> for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".

That may be your ideal setup, but it doesn't make it right for everyone.

> Take down the cage.

He just shouldn't let you put one up around him in the first place.
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <dl9Ui.6947$qt4.5093@newsfe12.lga>
Jay Belanger wrote:
> Ken Tilton <···········@optonline.net> writes:
> ...
> 
>>Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
>>for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".
> 
> 
> That may be your ideal setup, but it doesn't make it right for everyone.

I realize other people prefer other environments, they are just 
mistaken. My ideal setup happens to be the best, hands down.

> 
> 
>>Take down the cage.
> 
> 
> He just shouldn't let you put one up around him in the first place.

By suggesting a massively great development environment?

Anyway, you seem to be taking me seriously, don't, hat was just my 
scenery-chewing way of letting folks know the best way to learn Lisp is 
to first get the ideal stack, which will include the ACL IDE. But that 
runs on x86 Linux as well*, so the win32 bit was just trying to also 
save the sod from that productivity sink. (I'm doing it again, don't bite.)

ken

* Anybody (Franzers included) able to compare with the win32 product? kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Jay Belanger
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <m3odemy9ug.fsf@gmail.com>
Ken Tilton <···········@optonline.net> writes:
...
> I realize other people prefer other environments, they are just
> mistaken.  My ideal setup happens to be the best, hands down.

You're clearly deluded.

>>>Take down the cage.
>>
>> He just shouldn't let you put one up around him in the first place.
>
> By suggesting a massively great development environment?

No, by suggesting Vista.  
By trying to cage him in your preference.

> Anyway, you seem to be taking me seriously, don't,

And conversely, then.
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <BUbUi.6825$yU7.5188@newsfe12.lga>
Jay Belanger wrote:
> Ken Tilton <···········@optonline.net> writes:
> ...
> 
>>I realize other people prefer other environments, they are just
>>mistaken.  My ideal setup happens to be the best, hands down.
> 

Wow, I am really out on a limb there. It would be pretty easy to take me 
down by naming a superior or even near equal environment. Or you could 
back down in the face of my confidence and resort to, I don't know, 
name-calling?

> You're clearly deluded.

Understood.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87640sqx8n.fsf@web.de>
Ken Tilton <···········@optonline.net> writes:
>
> Wow, I am really out on a limb there. It would be pretty easy to take
> me down by naming a superior or even near equal environment.
The GNU Emacs is vastly superior to any enviornment,
as denied by fools only.

Klaus Schilling
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <iYYUi.789$Yo3.10@newsfe12.lga>
Klaus Schilling wrote:
> Ken Tilton <···········@optonline.net> writes:
> 
>>Wow, I am really out on a limb there. It would be pretty easy to take
>>me down by naming a superior or even near equal environment.
> 
> The GNU Emacs is vastly superior to any enviornment,
> as denied by fools only.
> 
> Klaus Schilling

We have to start a new survey for Schemers trying to sneak into the 
Common Lisp fold from the Scheme failed experiment ... ah, there ya go:

    The Cul de Sac Backed Out Of to Lisp

Responses will be notable for their brevity compared to RtL responses.

kzo

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193582701.677417.162450@v3g2000hsg.googlegroups.com>
On 28 out, 07:51, Ken Tilton <···········@optonline.net> wrote:
> We have to start a new survey for Schemers trying to sneak into the
> Common Lisp fold from the Scheme failed experiment ...

Common Lisp is all but a bunch of old Lisp implementations got
together with a few bits of the then newer Scheme thrown in.

> Responses will be notable for their brevity compared to RtL responses.

sure they will:  Scheme is all about minimalism after all.
From: OMouse
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193583862.782169.295690@57g2000hsv.googlegroups.com>
On Oct 28, 10:45 am, namekuseijin <············@gmail.com> wrote:
> On 28 out, 07:51, Ken Tilton <···········@optonline.net> wrote:
>
> > We have to start a new survey for Schemers trying to sneak into the
> > Common Lisp fold from the Scheme failed experiment ...
>
> Common Lisp is all but a bunch of old Lisp implementations got
> together with a few bits of the then newer Scheme thrown in.
>
> > Responses will be notable for their brevity compared to RtL responses.
>
> sure they will:  Scheme is all about minimalism after all.

I think you meant:
 Scm, smll
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <we3Vi.87$FZ5.68@newsfe12.lga>
namekuseijin wrote:
> On 28 out, 07:51, Ken Tilton <···········@optonline.net> wrote:
> 
>>We have to start a new survey for Schemers trying to sneak into the
>>Common Lisp fold from the Scheme failed experiment ...
> 
> 
> Common Lisp is all but a bunch of old Lisp implementations got
> together with a few bits of the then newer Scheme thrown in.
> 
> 
>>Responses will be notable for their brevity compared to RtL responses.
> 
> 
> sure they will:  Scheme is all about minimalism after all.

Cool, you almost got the reference.

:)

kzo

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87bqajdmjy.fsf@web.de>
namekuseijin <············@gmail.com> writes:
>
> sure they will:  Scheme is all about minimalism after all.

Minimalism is absolutely necessary, which explains the absurdity of LOOP etc. which is avoided by true lisp programmers

           Klaus Schilling
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5ooa1nFnv5iuU2@mid.individual.net>
Klaus Schilling wrote:
> namekuseijin <············@gmail.com> writes:
>> sure they will:  Scheme is all about minimalism after all.
> 
> Minimalism is absolutely necessary, which explains the absurdity of LOOP etc. which is avoided by true lisp programmers

http://video.google.com/videoplay?docid=-3704713569771882785&hl=en

(Fast forward to 4:40 if you don't have time.)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193750291.938706.308720@o3g2000hsb.googlegroups.com>
On 30 out, 06:58, Pascal Costanza <····@p-cos.net> wrote:
> > Minimalism is absolutely necessary, which explains the absurdity of LOOP etc. which is avoided by true lisp programmers
>
> http://video.google.com/videoplay?docid=-3704713569771882785&hl=en
>
> (Fast forward to 4:40 if you don't have time.)

don't fast forward at all and you'll see it's actually criticizing the
loose and vague loop facility in CL.
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5ooqbhFmkfiqU1@mid.individual.net>
namekuseijin wrote:
> On 30 out, 06:58, Pascal Costanza <····@p-cos.net> wrote:
>>> Minimalism is absolutely necessary, which explains the absurdity of LOOP etc. which is avoided by true lisp programmers
>> http://video.google.com/videoplay?docid=-3704713569771882785&hl=en
>>
>> (Fast forward to 4:40 if you don't have time.)
> 
> don't fast forward at all and you'll see it's actually criticizing the
> loose and vague loop facility in CL.

The criticism of CL's LOOP comes after 4:40, you won't miss anything 
about his discussion of loop and iteration constructs if you fast forward.

The discussion about which iteration construct is the 'best' one and 
which ones have flaws or not is a different discussion than whether you 
want a high-level iteration at all in the first place. Olin Shivers is 
clearly in favor of high-level iteration constructs, and he makes some 
very good points there. (Essentially, programming with tail recursion is 
like programming in assembly language.)

I am not aware of any iteration construct that is 'perfect', including 
Olin Shivers's proposal.

LOOP works very well in practice (for me and for a considerable number 
of others) and has the distinct advantage that it comes with every 
Common Lisp implementation.

Klaus's position is arguable in some contexts, but he shouldn't present 
his personal subjective opinion as absolute truth.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: ···············@gmail.com
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193754558.746206.83250@50g2000hsm.googlegroups.com>
On 30 Oct, 13:36, Pascal Costanza <····@p-cos.net> wrote:

> The discussion about which iteration construct is the 'best' one and
> which ones have flaws or not is a different discussion than whether you
> want a high-level iteration at all in the first place. Olin Shivers is
> clearly in favor of high-level iteration constructs, and he makes some
> very good points there. (Essentially, programming with tail recursion is
> like programming in assembly language.)

Yep. To me one of the great achievements of programming languages is
to plot a course between the high level (allowing the programmer to
think in the problem domain) and the low level (making it easier for
the CPU). Loop naturally models both the high level behavior (I want
to loop!) and presumably the low level implementation (branching
instructions). Mutable data arguments aside, I've never understood why
recursion is better for looping as this seems further away from both
goals.

--
Phil
http://phil.nullable.eu/
From: George Neuner
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <prjei3ditj4mot4kec3r3v1u6drvb7vb7g@4ax.com>
On Tue, 30 Oct 2007 07:29:18 -0700, ···············@gmail.com wrote:

>On 30 Oct, 13:36, Pascal Costanza <····@p-cos.net> wrote:
>
>> The discussion about which iteration construct is the 'best' one and
>> which ones have flaws or not is a different discussion than whether you
>> want a high-level iteration at all in the first place. Olin Shivers is
>> clearly in favor of high-level iteration constructs, and he makes some
>> very good points there. (Essentially, programming with tail recursion is
>> like programming in assembly language.)
>
>Yep. To me one of the great achievements of programming languages is
>to plot a course between the high level (allowing the programmer to
>think in the problem domain) and the low level (making it easier for
>the CPU). Loop naturally models both the high level behavior (I want
>to loop!) and presumably the low level implementation (branching
>instructions). Mutable data arguments aside, I've never understood why
>recursion is better for looping as this seems further away from both
>goals.

It's not that recursion has any benefit for the CPU, it's that
recursive code is easier to prove correct than an imperative loop that
updates multiple values each iteration - in simple cases you can just
look at the recursive code and see that it is correct.

Except for performance reasons - speed, excessive stack use, etc. - it
makes some odd sense to write recursive code instead of loops wherever
possible.  Using recursion where a loop construct is available is
often rejected on the grounds that it is not idiomatic, but the result
is frequently easier to understand later.

George
--
for email reply remove "/" from address
From: ···············@gmail.com
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193765237.609510.14060@k79g2000hse.googlegroups.com>
On 30 Oct, 15:55, George Neuner <·········@/comcast.net> wrote:
> On Tue, 30 Oct 2007 07:29:18 -0700, ···············@gmail.com wrote:

> >Yep. To me one of the great achievements of programming languages is
> >to plot a course between the high level (allowing the programmer to
> >think in the problem domain) and the low level (making it easier for
> >the CPU). Loop naturally models both the high level behavior (I want
> >to loop!) and presumably the low level implementation (branching
> >instructions). Mutable data arguments aside, I've never understood why
> >recursion is better for looping as this seems further away from both
> >goals.
>
> It's not that recursion has any benefit for the CPU

Yes that's what I said :-)

> it's that
> recursive code is easier to prove correct than an imperative loop that
> updates multiple values each iteration - in simple cases you can just
> look at the recursive code and see that it is correct.

If you read what I wrote, I did say "Mutable data arguments aside"
specifically because this is the argument that is *always* presented
for not using iteration.

> Except for performance reasons - speed, excessive stack use, etc. - it
> makes some odd sense to write recursive code instead of loops wherever
> possible.  Using recursion where a loop construct is available is
> often rejected on the grounds that it is not idiomatic, but the result
> is frequently easier to understand later.

If a programmer is unable to handle loop variables correctly then I
think they'll have even more trouble keeping track of a stack!

--
Phil
http://phil.nullable.eu/
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5op3efFn0q97U1@mid.individual.net>
George Neuner wrote:
> On Tue, 30 Oct 2007 07:29:18 -0700, ···············@gmail.com wrote:
> 
>> On 30 Oct, 13:36, Pascal Costanza <····@p-cos.net> wrote:
>>
>>> The discussion about which iteration construct is the 'best' one and
>>> which ones have flaws or not is a different discussion than whether you
>>> want a high-level iteration at all in the first place. Olin Shivers is
>>> clearly in favor of high-level iteration constructs, and he makes some
>>> very good points there. (Essentially, programming with tail recursion is
>>> like programming in assembly language.)
>> Yep. To me one of the great achievements of programming languages is
>> to plot a course between the high level (allowing the programmer to
>> think in the problem domain) and the low level (making it easier for
>> the CPU). Loop naturally models both the high level behavior (I want
>> to loop!) and presumably the low level implementation (branching
>> instructions). Mutable data arguments aside, I've never understood why
>> recursion is better for looping as this seems further away from both
>> goals.
> 
> It's not that recursion has any benefit for the CPU, it's that
> recursive code is easier to prove correct than an imperative loop that
> updates multiple values each iteration - in simple cases you can just
> look at the recursive code and see that it is correct.
> 
> Except for performance reasons - speed, excessive stack use, etc. - it
> makes some odd sense to write recursive code instead of loops wherever
> possible.  Using recursion where a loop construct is available is
> often rejected on the grounds that it is not idiomatic, but the result
> is frequently easier to understand later.

I disagree. See my other posting with the property list example.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193771971.559632.75260@22g2000hsm.googlegroups.com>
On 30 out, 13:55, George Neuner <·········@/comcast.net> wrote:
> Except for performance reasons - speed, excessive stack use, etc. - it

this is misleading:  tail-calls don't grow the stack absolutely and
are don't incurr on performance penalties either.  At least in
implementations providing proper tail-call optimization, like all
Scheme and other functional languages implementations are required.

Funny CLers are unaware of that.  It was Guy Steele's Master thesis.

> Using recursion where a loop construct is available is
> often rejected on the grounds that it is not idiomatic, but the result
> is frequently easier to understand later.

it's very easy to understand once people get over the obsession for
minutia control by means of control variables and become more open to
declarative, functional programming...
From: George Neuner
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <uh4fi3pcmd1e6ito432d33ij9h2nla6qdn@4ax.com>
On Tue, 30 Oct 2007 19:19:31 -0000, namekuseijin
<············@gmail.com> wrote:

>On 30 out, 13:55, George Neuner <·········@/comcast.net> wrote:
>> Except for performance reasons - speed, excessive stack use, etc. - it
>
>this is misleading:  tail-calls don't grow the stack absolutely and
>are don't incurr on performance penalties either.  At least in
>implementations providing proper tail-call optimization, like all
>Scheme and other functional languages implementations are required.

No Shit!  It's amazing how absolutely any statement regarding
recursion and stacks can always be construed to mean the poster is
unaware of Scheme.

For your edification, it is also possible to write recursive code in
languages that don't optimize tail recursion.  It's even useful.


>Funny CLers are unaware of that.  It was Guy Steele's Master thesis.
>
>> Using recursion where a loop construct is available is
>> often rejected on the grounds that it is not idiomatic, but the result
>> is frequently easier to understand later.
>
>it's very easy to understand once people get over the obsession for
>minutia control by means of control variables and become more open to
>declarative, functional programming...

In case you didn't notice, I was arguing IN FAVOR of recursion.

George
--
for email reply remove "/" from address
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193792306.681623.310410@o38g2000hse.googlegroups.com>
On 30 out, 18:30, George Neuner <·········@/comcast.net> wrote:
> For your edification, it is also possible to write recursive code in
> languages that don't optimize tail recursion.  It's even useful.

It's useful but rarely used because people don't want to blow the
stack in the middle of some important user application.  In the end,
it's just a possibility without much use, just like in C.

So, they become used to writing in imperative, control-freak style
full of state/control variables.  Even mathematicians!

> >> Using recursion where a loop construct is available is
> >> often rejected on the grounds that it is not idiomatic, but the result
> >> is frequently easier to understand later.
>
> >it's very easy to understand once people get over the obsession for
> >minutia control by means of control variables and become more open to
> >declarative, functional programming...
>
> In case you didn't notice, I was arguing IN FAVOR of recursion.

in case you didn't notice, I was agreeing with you.
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <877il16edw.fsf@web.de>
···············@gmail.com writes:
> Yep. To me one of the great achievements of programming languages is
> to plot a course between the high level (allowing the programmer to
> think in the problem domain) and the low level (making it easier for
> the CPU). Loop naturally models both the high level behavior (I want
> to loop!)

no, it's DO that does that.


Klaus Schilling
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193754119.986100.321620@y42g2000hsy.googlegroups.com>
On 30 out, 11:36, Pascal Costanza <····@p-cos.net> wrote:
> very good points there. (Essentially, programming with tail recursion is
> like programming in assembly language.)

does this look like assembly?

(define (! n)
  (let loop ((x n) (r 1))
    (if (zero? x) r
      (loop (- x 1) (* x r)))))

Looks like just another function call to me.  Tail recursion is
nothing like black magic:  it's just the natural way to do recursion
in a functional language without concerns for stack size.  In
implementations supporting tail-call optimization, that is.

I think you misleaded tail-recursion with continuations.
Continuations are effectivelly comparable to parametrized GOTOs:
pretty assembly, but still far higher level...

The example also shows why you don't need loop constructs in Scheme
(excepts perhaps as syntax sugar).  Besides, all trivial iterations
can be easily done with do -- which is just a macro over tail-
recursive calls.  But named let allows for greater flexibility.
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5oov7nFnvrl8U1@mid.individual.net>
namekuseijin wrote:
> On 30 out, 11:36, Pascal Costanza <····@p-cos.net> wrote:
>> very good points there. (Essentially, programming with tail recursion is
>> like programming in assembly language.)
> 
> does this look like assembly?
> 
> (define (! n)
>   (let loop ((x n) (r 1))
>     (if (zero? x) r
>       (loop (- x 1) (* x r)))))

More so than this:

(defun bang (n)
   (loop for x from 1 to n
         for r = 1 then (* x r)
         finally (return r)))

> Looks like just another function call to me.  Tail recursion is
> nothing like black magic:  it's just the natural way to do recursion
> in a functional language without concerns for stack size.  In
> implementations supporting tail-call optimization, that is.
> 
> I think you misleaded tail-recursion with continuations.

No, I don't.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Giorgos Keramidas
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <877ikta3hi.fsf@kobe.laptop>
On Tue, 30 Oct 2007 16:00:04 +0100, Pascal Costanza <··@p-cos.net> wrote:
> namekuseijin wrote:
>> On 30 out, 11:36, Pascal Costanza <····@p-cos.net> wrote:
>>> very good points there. (Essentially, programming with tail recursion is
>>> like programming in assembly language.)
>>
>> does this look like assembly?
>>
>> (define (! n)
>>   (let loop ((x n) (r 1))
>>     (if (zero? x) r
>>       (loop (- x 1) (* x r)))))
>
> More so than this:
>
> (defun bang (n)
>   (loop for x from 1 to n
>         for r = 1 then (* x r)
>         finally (return r)))

The Lisp version also happens to have less bugs (c.f. (! -1)).

The Scheme version can be 'fixed' of course, but the fact that a trivial
buglet like this managed to sneak into the original post is probably a
hint why higher-level constructs are nice :-)
From: Nicolas Neuss
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87ejfcfxq0.fsf@ma-patru.mathematik.uni-karlsruhe.de>
namekuseijin <············@gmail.com> writes:

> On 30 out, 11:36, Pascal Costanza <····@p-cos.net> wrote:
>> very good points there. (Essentially, programming with tail recursion is
>> like programming in assembly language.)
>
> does this look like assembly?
>
> (define (! n)
>   (let loop ((x n) (r 1))
>     (if (zero? x) r
>       (loop (- x 1) (* x r)))))

Yes, it does compared with

(defun factorial (n)
  (loop for n from 1 upto n
        and f = 1 then (* f n)
        finally (return f)))

And note that I have been a Scheme programmer for many years.

Nicolas
From: Edi Weitz
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <uk5p4hbua.fsf@agharta.de>
On Tue, 30 Oct 2007 16:06:47 +0100, Nicolas Neuss <·····@ma-patru.mathematik.uni-karlsruhe.de> wrote:

> And note that I have been a Scheme programmer for many years.

  Die sch�rfsten Kritiker der Elche
  waren fr�her selber welche.

                     F.W. Bernstein
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193769662.441242.320620@19g2000hsx.googlegroups.com>
On 30 out, 13:06, Nicolas Neuss <·····@ma-patru.mathematik.uni-
karlsruhe.de> wrote:
> namekuseijin <············@gmail.com> writes:
> > On 30 out, 11:36, Pascal Costanza <····@p-cos.net> wrote:
> >> very good points there. (Essentially, programming with tail recursion is
> >> like programming in assembly language.)
>
> > does this look like assembly?
>
> > (define (! n)
> >   (let loop ((x n) (r 1))
> >     (if (zero? x) r
> >       (loop (- x 1) (* x r)))))
>
> Yes, it does compared with
>
> (defun factorial (n)
>   (loop for n from 1 upto n
>         and f = 1 then (* f n)
>         finally (return f)))

some people have problems thinking in a declarative, recursive
manner.  I accept that.

at least you realized the bang was for the factorial mathematical
notation...
From: Alexander Schmolck
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <yfshck8e57h.fsf@gmail.com>
namekuseijin <············@gmail.com> writes:

> On 30 out, 13:06, Nicolas Neuss <·····@ma-patru.mathematik.uni-
> karlsruhe.de> wrote:
>> namekuseijin <············@gmail.com> writes:
>> > On 30 out, 11:36, Pascal Costanza <····@p-cos.net> wrote:
>> >> very good points there. (Essentially, programming with tail recursion is
>> >> like programming in assembly language.)
>>
>> > does this look like assembly?
>>
>> > (define (! n)
>> >   (let loop ((x n) (r 1))
>> >     (if (zero? x) r
>> >       (loop (- x 1) (* x r)))))
>>
>> Yes, it does compared with
>>
>> (defun factorial (n)
>>   (loop for n from 1 upto n
>>         and f = 1 then (* f n)
>>         finally (return f)))
>
> some people have problems thinking in a declarative, recursive
> manner.  I accept that.

Indeed, like most habilitated research mathematicians Nicolas presumably never
even heard of the concept of recursion. Luckily he participates in usenet
discussions where he can be schooled by anonymous but highly qualified experts
like yourself.

> at least you realized the bang was for the factorial mathematical
> notation...

I think you're being too generous here -- in all likelihood he just asked in
another newsgroup and ·······@hotmail.com told him.

'as
From: Nicolas Neuss
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <878x5ke5d0.fsf@ma-patru.mathematik.uni-karlsruhe.de>
namekuseijin <············@gmail.com> writes:

> at least you realized the bang was for the factorial mathematical
> notation...

Do you want to tell us that Scheme does postfix notation now?  Or did you
want to show us with your bang that your factorial has side-effects?  With
you trolls one never can be sure how empty your brain really is...
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87zly02k50.fsf@geddis.org>
namekuseijin <············@gmail.com> wrote on Tue, 30 Oct 2007:
> Tail recursion is nothing like black magic: it's just the natural way to do
> recursion in a functional language without concerns for stack size.

Sure, super.

Now tell me why any kind of recursion is "the natural way" to express
iteration.  Like WHILE or DOLIST or MAPCAR.  How does reformulating these
things into a recursive algorithm improve anything?

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
The ground is my ocean, I'm the shark, and most people don't even know how to
swim.  -- RCJ Machado brothers, describing Gracie Jiu-Jitsu
From: Carl Taylor
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <%ZQVi.37514$kj1.17843@bgtnsc04-news.ops.worldnet.att.net>
"Don Geddis" <···@geddis.org> wrote in message ···················@geddis.org...
> namekuseijin <············@gmail.com> wrote on Tue, 30 Oct 2007:
>> Tail recursion is nothing like black magic: it's just the natural way to do
>> recursion in a functional language without concerns for stack size.
>
> Sure, super.
>
> Now tell me why any kind of recursion is "the natural way" to express
> iteration.  Like WHILE or DOLIST or MAPCAR.  How does reformulating these
> things into a recursive algorithm improve anything?

Let's not forget the little unnatural mindbenders like:

;;;======================
;;; From *PAIP* page 31.
;;;======================

(defun atomprint (exp &optional (depth 0))
  (if (atom exp)
      (format t "~&atom: ~3,,,@A - depth ~D" exp depth)
    (dolist (element exp)
      (atomprint element (1+ depth)))))


;;;======================
;;; From *ACL* page 293.
;;;======================

(defun get-nesting-depth (in-list)
  (if (atom in-list)
      0
    (1+ (apply #'max (mapcar #'get-nesting-depth in-list)))))



Carl Taylor
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193806393.046828.229330@k79g2000hse.googlegroups.com>
On 30 out, 22:38, Don Geddis <····@geddis.org> wrote:
> Now tell me why any kind of recursion is "the natural way" to express
> iteration.  Like WHILE or DOLIST or MAPCAR.

this is as natural...
(let loop ((i 0))
  (if (< i 10)
    (let ()
      (display i)
      (loop (+ 1 i)))))

...an imperative construct as one can in a functional expression.

in Scheme and other functional languages these are all but syntatic
sugar to tail-recursive calls underneath (except for map, which is
really just another cons).  They need to, since there is nothing but
functions in there.

>  How does reformulating these
> things into a recursive algorithm improve anything?

in CL they surely won't improve anything.  In Scheme and other
functional languages they improve users being able to design naturally
recursive solutions recursively without fear of stack overflows and to
schew the evil imperative paradigm in favor of more modern approaches
of software development by means of side-effect free functions being
composed together.
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5oqot3Fnthr9U1@mid.individual.net>
namekuseijin wrote:

>>  How does reformulating these
>> things into a recursive algorithm improve anything?
> 
> in CL they surely won't improve anything.  In Scheme and other
> functional languages they improve users being able to design naturally
> recursive solutions recursively without fear of stack overflows and to
> schew the evil imperative paradigm in favor of more modern approaches
> of software development by means of side-effect free functions being
> composed together.

You sound like a frog.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Leandro Rios
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <47286b13$0$1348$834e42db@reader.greatnowhere.com>
Pascal Costanza escribi�:
> namekuseijin wrote:
> 
>>>  How does reformulating these
>>> things into a recursive algorithm improve anything?
>>
>> in CL they surely won't improve anything.  In Scheme and other
>> functional languages they improve users being able to design naturally
>> recursive solutions recursively without fear of stack overflows and to
>> schew the evil imperative paradigm in favor of more modern approaches
>> of software development by means of side-effect free functions being
>> composed together.
> 
> You sound like a frog.
> 
> 
> Pascal
> 

I was about to say the same thing.

Leandro
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193842496.094524.181370@z9g2000hsf.googlegroups.com>
On 31 out, 05:24, Pascal Costanza <····@p-cos.net> wrote:
> You sound like a frog.

whatever.
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87lk9jz0qc.fsf@geddis.org>
namekuseijin <············@gmail.com> wrote on Wed, 31 Oct 2007:
> On 30 out, 22:38, Don Geddis <····@geddis.org> wrote:
>> Now tell me why any kind of recursion is "the natural way" to express
>> iteration.  Like WHILE or DOLIST or MAPCAR.
>
> this is as natural...
> ...an imperative construct as one can in a functional expression.

But back up another level: what is the benefit of only using functional
expressions?

If the real algorithm is naturally imperative, your example may be the most
natural possible expression in a functional style.  But there is an even MORE
natural expression in a straight imperative style.  But what benefit have you
gained by obfuscating the code in order to reformulate it in a functional
style?

>> How does reformulating these things into a recursive algorithm improve
>> anything?
>
> In Scheme and other functional languages they improve users being able to
> design naturally recursive solutions recursively without fear of stack
> overflows

Don't forget: we're talking about naturally _iterative_ algorithms, which
are being rewritten into a recursive style.  You haven't provided any benefit
for this rewriting.

There are other algorithms were are indeed naturally recursive.  And Common
Lisp programmers generally write those algorithms in a recursive style.

But CL programmers tend to write iterative algorithms in an iterative style.
I'm still waiting for you to explain why a recursive style should be used
for _all_ these algorithms.

> and to schew the evil imperative paradigm in favor of more modern
> approaches of software development by means of side-effect free functions
> being composed together.

Tell me more about this "evil" paradigm.  Sounds productive and fun!

(Or, if you want to try to be serious: eliminate your argumentative words
like "evil" and "modern", and just calmly explain the ACTUAL BENEFITS that a
programmer will see by adopting your suggested approach.)

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Patriotism is supporting your country all the time, and your government when
it deserves it.  -- Mark Twain
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193858989.919420.307150@19g2000hsx.googlegroups.com>
On 31 out, 14:51, Don Geddis <····@geddis.org> wrote:
> But back up another level: what is the benefit of only using functional
> expressions?

The benefit is declarative, easily verifiable programming, away from
the traps of side-effects everywhere and from the low-level Von
Neumann model.

> But what benefit have you
> gained by obfuscating the code in order to reformulate it in a functional
> style?

You shouldn't reformulate imperative code in functional style:  you
should instead focus on declarative, recursive, easily-verifiable
functional code.

It's sad that one of the first-functional languages in the world is
ridden nowadays by imperative constructs and an obsession with low-
level details and performance...

> Don't forget: we're talking about naturally _iterative_ algorithms, which
> are being rewritten into a recursive style.  You haven't provided any benefit
> for this rewriting.

the benefit is for flexible functional languages which don't need to
provide builtin fixed syntax for iterative loops.  You shouldn't
rewrite CL or C++ though.

> There are other algorithms were are indeed naturally recursive.  And Common
> Lisp programmers generally write those algorithms in a recursive style.

not nearly as much when you have the loop facility and mentality.

> But CL programmers tend to write iterative algorithms in an iterative style.

Use higher-order functions to iterate, like fold, map, filter etc.  Or
comprehensions...

> I'm still waiting for you to explain why a recursive style should be used
> for _all_ these algorithms.

Because imperative programming is a frequent source of obscure bugs,
due to out-of-control usage of mutation and its side-effects...
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87ejf9vkwr.fsf@geddis.org>
namekuseijin <············@gmail.com> wrote on Wed, 31 Oct 2007:
> On 31 out, 14:51, Don Geddis <····@geddis.org> wrote:
>> But back up another level: what is the benefit of only using functional
>> expressions?
>
> The benefit is declarative, easily verifiable programming

So you're going to bet it all on verification?  That's why Scheme is superior?

I hate to tell you, but Scheme (or any "modern" functional programming
language) is a _long_ way from a real declarative programming language.
If you really think this is such a huge benefit, you ought to head more into
Prolog, or the other logic programming languages in that direction.

Alas, experience has shown that automatic program verification is of only
minor benefit for real programmers solving real problems.

Like static typing, many Common Lisp programmers find that the additional
restrictions put on the programmer are too high a cost to pay for the minor
benefits that can then be automatically derived by the compilers.

> away from the traps of side-effects everywhere and from the low-level Von
> Neumann model.

Really, if you're going to keep talking about this, you need to learn how to
express your thoughts objectively.  Iteration is not the same as the "Von
Neumann model", nor are either of those concepts necessaily "low-level" just
because you assert it.

> It's sad that one of the first-functional languages in the world is ridden
> nowadays by imperative constructs and an obsession with low- level details
> and performance...

We're not talking about low-level details or performance at all.  Haven't you
been paying attention?  The point is that high-level iteration constructs are
often the most natural formal translation of a mental algorithm.  The burden
is on you to show that there is some benefit to be gained by having the
programmer do an _additional_ burden of reformulating the algorithm into a
recursive style.

This has nothing to do with low-level, nor with performance.  It has to do
with saving the programmer effort and thus making them more productive.
High-level iteration constructs do that.  Requiring only recursive solutions
requires additional programmer effort.

>> There are other algorithms were are indeed naturally recursive.  And Common
>> Lisp programmers generally write those algorithms in a recursive style.
>
> not nearly as much when you have the loop facility and mentality.

On the contrary: CL programmer use recursion exactly when it is appropriate,
and not otherwise.  They have a nice toolbox to work with, and can find the
right tool for each problem.

It is you who have only a hammer, and see the entire world as nothing but
nails.

>> I'm still waiting for you to explain why a recursive style should be used
>> for _all_ these algorithms.
>
> Because imperative programming is a frequent source of obscure bugs,
> due to out-of-control usage of mutation and its side-effects...

Evidence?  This is certainly not the experience of Common Lisp programmers.
Perhaps your assumptions about a style different from your own are greatly
mistaken.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Calvin: People think it must be fun to be a super genius, but they don't
	realize how hard it is to put up with all the idiots in the world.
Hobbes: Isn't your pants' zipper supposed to be in the front?
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87sl3owywj.fsf@web.de>
Don Geddis <···@geddis.org> writes:
>
> So you're going to bet it all on verification?  
> That's why Scheme is superior?
>

it has nothing to do with scheme, for almost any version of Lisp,
including CL, allows for such a style of programming,
and decent programmers program in this style and not in
the bloated LOOP style imposed upon us by fascist standard committees

> I hate to tell you, but Scheme (or any "modern" functional programming
> language) is a _long_ way from a real declarative programming language.

that's not relevant, declarative progeamming is possible in scheme,
that's all that counts

> If you really think this is such a huge benefit, you ought to head more into
> Prolog, or the other logic programming languages in that direction.

their syntax is clumsy and infixish, thus holds no water,
unlike that of languages based on  S-Expressions
>
> Alas, experience has shown that automatic program verification is of only
> minor benefit for real programmers solving real problems.

reality is corrupt and degenerate.
It's absolutely necessary to reach for Pythagorean-Platonic ideals.

>
> We're not talking about low-level details or performance at all.  Haven't you
> been paying attention?  The point is that high-level iteration constructs are
> often the most natural formal translation of a mental algorithm. 

no, they are never anywhere near natural and elegant,
as opposed to recursive algorithms


> The burden
> is on you to show that there is some benefit to be gained by having the
> programmer do an _additional_ burden of reformulating the algorithm into a
> recursive style.
>
it's not a burden, but a deliverance.
Burden is imposed by iteration and clumsy constructs like LOOP



> This has nothing to do with low-level, nor with performance.  It has to do
> with saving the programmer effort and thus making them more productive.


no, it imposes the effort of rewriting an elegant recursive algorithm
in a clumsy iterative manner that is obscured by the ugly syntax of
constructs like LOOP. Whereas with DO, it's almost straightforward to
translate a tail recursive algorithm in an iterative manner on
systems that don't efficiently recognise tail recursion.

> High-level iteration constructs do that.

no, they obfuscate problems in an ugly, clumsy, unreadable mannewr.

>  Requiring only recursive solutions
> requires additional programmer effort.
>


no, it reduces the effort of programmers to a minimum

>
> On the contrary: CL programmer use recursion exactly when it is appropriate,

recursion is always appropriate, just sometimes inefficient

          Klaus Schilling
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87hck3hvl0.fsf@geddis.org>
Klaus Schilling <···············@web.de> wrote on Fri, 02 Nov 2007:
> decent programmers program in this style and not in the bloated LOOP style
> imposed upon us by fascist standard committees

How is having LOOP as an alternative, an "imposition"?  The ANSI CL standard
doesn't _require_ anyone to use LOOP.  It merely permits it, if desired.
How can you possibly call that "imposed"?

Any CL code written with LOOP, could be easily written (more verbosely and
less clearly) without it.  LOOP is never necessary.

LOOP is merely helpful and desired.  But not necessary.

> that's not relevant, declarative progeamming is possible in scheme,
> that's all that counts

Uh, no it isn't.  You must not understand what declarative programming is
really about.

Here's how you write a declarative sort routine:
        Input is a list (X_1 ... X_n)
        Output is a list (Y_1 ... Y_n)
        Where every X_i appears once and only once as some Y_j
        And for all i,j: if i<j then Y_i < Y_j
That's it.  That's the declarative code.

A _real_ declarative programming language would make that code
machine-executable with no further human input.

Good luck getting that done in Scheme.

>> If you really think this is such a huge benefit, you ought to head more into
>> Prolog, or the other logic programming languages in that direction.
>
> their syntax is clumsy and infixish, thus holds no water, unlike that of
> languages based on S-Expressions

You appear to be ignorant of logic programming.  I spent a few years using
one that was embedded in Lisp, based on s-expressions and prefix notation.
If that's your only concern, it's not hard to find a lisp-like REAL
declarative programming language.

>> Alas, experience has shown that automatic program verification is of only
>> minor benefit for real programmers solving real problems.
>
> reality is corrupt and degenerate.
> It's absolutely necessary to reach for Pythagorean-Platonic ideals.

Ah.  My mistake.  I thought the point of programming languages was to deliver
valuable programs to end users.  You, apparently, don't.

So why are you commenting on this thread?  Everybody else is trying to write
programs that do useful stuff.  All their comments assume that context.  If
you don't care about doing useful stuff, should it be any surprise that your
intuitions differ from theirs?

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
"What has the study of biology taught you about the Creator, Dr. Haldane?"
JBS Haldane: "I'm not sure, but he seems to be inordinately fond of beetles."
From: George Neuner
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1biti3p53o4vkiokbhccjf75lncsvecgaq@4ax.com>
On Fri, 02 Nov 2007 14:38:20 +0100, Klaus Schilling
<···············@web.de> wrote:

>Don Geddis <···@geddis.org> writes:
>>
>> If you really think [declarative programming] is such a huge benefit,
>> you ought to head more into Prolog, or the other logic programming 
>> languages in that direction.
>
>their syntax is clumsy and infixish, thus holds no water,
>unlike that of languages based on  S-Expressions

The last time I checked, Prolog's syntax was prefix ... math and a few
control procedures can be called using infix notation, but that is
just sugar: e.g., the binary addition procedure is "+( A, B, C )"
which computes C=A+B (or A=C-B or B=C-A, depending on how you call
it).

George
--
for email reply remove "/" from address
From: Giorgos Keramidas
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87k5oovrqe.fsf@kobe.laptop>
On Fri, 02 Nov 2007 14:38:20 +0100, Klaus Schilling <···············@web.de> wrote:
>> On the contrary: CL programmer use recursion exactly when it is
>> appropriate,
>
> recursion is always appropriate, just sometimes inefficient

Isn't that a self-contradiction when 'efficiency' is the goal?
I wouldn't put too much weight in that sort of 'always'.
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1194798296.179505.154980@v2g2000hsf.googlegroups.com>
On 11 nov, 11:25, Giorgos Keramidas <········@ceid.upatras.gr> wrote:
> On Fri, 02 Nov 2007 14:38:20 +0100, Klaus Schilling <···············@web.de> wrote:
> >> On the contrary: CL programmer use recursion exactly when it is
> >> appropriate,
>
> > recursion is always appropriate, just sometimes inefficient
>
> Isn't that a self-contradiction when 'efficiency' is the goal?
> I wouldn't put too much weight in that sort of 'always'.

recursion isn't inefficient at all when tail-call-optimized.
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <877il32hit.fsf@web.de>
Don Geddis <···@geddis.org> writes:
>
> Don't forget: we're talking about naturally _iterative_ algorithms

there's no such thing. all iterative algorithms are just
sophisticated wrappers over recursive algorithms.

Klaus Schilling
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87ir4lvldd.fsf@geddis.org>
Klaus Schilling <···············@web.de> wrote on Wed, 31 Oct 2007:
> Don Geddis <···@geddis.org> writes:
>> Don't forget: we're talking about naturally _iterative_ algorithms
>
> there's no such thing. all iterative algorithms are just sophisticated
> wrappers over recursive algorithms.

Please justify your wild assertion.

Let's take a simple, concrete example.  I've got a list of numbers, and I
want a new list where each number in the new list is one more than the
corresponding number in the old list.  So: add one to each number in the list.

So I express this naturally as
        (mapcar #'1+ '(3 4 5 6))
or even
        (loop for n in '(3 4 5 6) collect (1+ n))

Seems pretty straightforward, matches the original problem domain, matches the
natural description of the algorithm in English.  Doesn't seem especially
"sophisticated", to use your description.

Now please explain how ANY recursive solution to this problem is in ANY way
superior to solutions I wrote above.  Explain what is so complicated or
"sophisticated" about the simple code above.  Explain how this apparently
iterative algorithm is somehow "naturally" recursive.  Explain why a recursive
version of it is better in ANY concrete way.

Not some abstract, potential benefit.  Give me an actual, real benefit that
a programmer could see by rewriting the code in a recursive style.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Have you ever wondered if taxation without representation was cheaper?
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5otsdmFok7efU1@mid.individual.net>
Klaus Schilling wrote:
> Don Geddis <···@geddis.org> writes:
>> Don't forget: we're talking about naturally _iterative_ algorithms
> 
> there's no such thing. all iterative algorithms are just
> sophisticated wrappers over recursive algorithms.

...and all recursive algorithms are sophisticated wrappers over machine 
code.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: John Thingstad
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <op.t0145bj3ut4oq5@pandora.alfanett.no>
P� Wed, 31 Oct 2007 01:38:35 +0100, skrev Don Geddis <···@geddis.org>:

> namekuseijin <············@gmail.com> wrote on Tue, 30 Oct 2007:
>> Tail recursion is nothing like black magic: it's just the natural way  
>> to do
>> recursion in a functional language without concerns for stack size.
>
> Sure, super.
>
> Now tell me why any kind of recursion is "the natural way" to express
> iteration.  Like WHILE or DOLIST or MAPCAR.  How does reformulating these
> things into a recursive algorithm improve anything?
>
>         -- Don
> _______________________________________________________________________________
> Don Geddis                  http://don.geddis.org/                
> ···@geddis.org
> The ground is my ocean, I'm the shark, and most people don't even know  
> how to
> swim.  -- RCJ Machado brothers, describing Gracie Jiu-Jitsu

It is anatural way of finding the loop invariants.
See "verifiable programing"

-- 
Sendt med Operas revolusjonerende e-postprogram: http://www.opera.com/mail/
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87mytz316p.fsf@web.de>
Don Geddis <···@geddis.org> writes:
>
> Now tell me why any kind of recursion is "the natural way" to express
> iteration. 


recursuion is always the proper way to express iteration, just ineffixient
in certain cases

    Klaus Schilling
From: Kamen TOMOV
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <uzly0r7u7.fsf@cybuild.com>
On Tue, Oct 30 2007, Pascal Costanza wrote:

> ...
> The discussion about which iteration construct is the 'best' one and
> which ones have flaws or not is a different discussion than whether
> you want a high-level iteration at all in the first place. Olin
> Shivers is clearly in favor of high-level iteration constructs, and
> he makes some very good points there. 

Wheather the iteration is high level or not so much does not always
matter.

> (Essentially, programming with tail recursion is like programming in
> assembly language.)

This sounds like everything in the assembly language is bad. That's
not the case, but even if it were, this is an overstatement. For
example I haven't heard of a thing like scope in assembler (unless we
consider code segments a scope, but even then we can jump wherever we
want), whereas the scope is clear when using recursion.

> I am not aware of any iteration construct that is 'perfect', including
> Olin Shivers's proposal.

That's why I use not only loop but also map and recursion. Got to try
iterate some day.

-- 
�����
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5op027Fnp85iU1@mid.individual.net>
Kamen TOMOV wrote:
> On Tue, Oct 30 2007, Pascal Costanza wrote:
> 
>> ...
>> The discussion about which iteration construct is the 'best' one and
>> which ones have flaws or not is a different discussion than whether
>> you want a high-level iteration at all in the first place. Olin
>> Shivers is clearly in favor of high-level iteration constructs, and
>> he makes some very good points there. 
> 
> Whether the iteration is high level or not so much does not always
> matter.

Sure.

>> (Essentially, programming with tail recursion is like programming in
>> assembly language.)
> 
> This sounds like everything in the assembly language is bad. That's
> not the case, but even if it were, this is an overstatement. For
> example I haven't heard of a thing like scope in assembler (unless we
> consider code segments a scope, but even then we can jump wherever we
> want), whereas the scope is clear when using recursion.

Sorry, I should have said "feels like programming in assembly language."

No, assembly language is not always bad. But:

Expressing iterations in terms of tail recursion feels like assembly 
language because instead of expressing things close to the problem 
domain, I have to deconstruct what I actually want to say and 
reconstruct it in terms of simple (simplistic) low-level constructs. By 
the time I have done that, I don't see the forest from the trees anymore.

With high-level languages, I can stay closer to the problem domain.

Here is a nice example using loop:

(loop for (key value) on property-list by #'cddr
       unless (member key excluded-keys)
       append (list key value)) ; [1]

This simple loop expression removes some properties from a property list.

Here is the same thing expressed recursively:

(let loop ((property-list property-list) (result '()))
   (cond ((null? property-list) (reverse result)) ; [2]
         ((member (car property-list) excluded-keys)
          (loop (cddr property-list) result))
         (else (loop (cddr property-list)
                     (cons (car property-list)
                       (cons (cadr property-list)
                         result))))))

There is no way you can convince me that the recursive version is easier 
to read and understand.

>> I am not aware of any iteration construct that is 'perfect', including
>> Olin Shivers's proposal.
> 
> That's why I use not only loop but also map and recursion. Got to try
> iterate some day.

I agree. Purity is not a worthwhile goal per se. Always use what works 
best for the case at hand.


Pascal


[1] You should actually say nconc instead of append here.
[2] This should be reverse!, if available.

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193770865.691843.186010@50g2000hsm.googlegroups.com>
On 30 out, 13:14, Pascal Costanza <····@p-cos.net> wrote:
> Expressing iterations in terms of tail recursion feels like assembly
> language because instead of expressing things close to the problem
> domain, I have to deconstruct what I actually want to say and
> reconstruct it in terms of simple (simplistic) low-level constructs.

All languages are like that, including CL.  Isn't that why macros are
so great?  To adapt the language to the task at hand?  So, why are you
nitpicking at this particular language feature?

I'm not advocating tail-recursion instead of specialized iteration
mechanisms closer to the problem domain.  I'm just saying tail-
recursion code isn't anywhere as low-level as you're making it up to
be.

> Here is a nice example using loop:
>
> (loop for (key value) on property-list by #'cddr
>        unless (member key excluded-keys)
>        append (list key value)) ; [1]
>
> This simple loop expression removes some properties from a property list.
>
> Here is the same thing expressed recursively:
>
> (let loop ((property-list property-list) (result '()))
>    (cond ((null? property-list) (reverse result)) ; [2]
>          ((member (car property-list) excluded-keys)
>           (loop (cddr property-list) result))
>          (else (loop (cddr property-list)
>                      (cons (car property-list)
>                        (cons (cadr property-list)
>                          result))))))

mine is better (can't stand CLers verbosity):

(define (filter excluded-keys property-list)
    (reverse
     (let loop ((ls property-list) (r '()))
       (if (null? ls) r
           (let ((key (car ls)) (value (cadr ls)))
             (if (member key excluded-keys) (loop (cddr ls) r)
                 (loop (cddr ls) (cons (list key value) r))))))))

as in
(filter '(b c) '(a 1 b 2 b 3 c 4 d 5 c 6))

Certainly not as convenient as a high-level specialized macro, but
hardly low-level at all.  You can clearly see the bindings and what
the function returns for each condition.

> I agree. Purity is not a worthwhile goal per se. Always use what works
> best for the case at hand.

It's not the case for purity, it's the fact that tail-recursion is
absolutely necessary in functional languages:  you build specialized
iteration constructs out of tail calls instead of having fixed syntax
in the core of the language for that (for, while etc)...

and for tail-recursion you need the tail-call optimization provided by
the implementation or else your stack will blow up.
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <874pg83yy0.fsf@geddis.org>
namekuseijin <············@gmail.com> wrote on Tue, 30 Oct 2007:
> you build specialized iteration constructs out of tail calls instead of
> having fixed syntax in the core of the language for that (for, while
> etc)...

But surely, if what you want is WHILE, it's awfully helpful to have it as a
standard part of the language.  What benefit is there to the programmer to
only providing minimal constructs, making them create WHILE themselves first,
and only then being able to use it?

As to the "fixed syntax", that problem is easily fixed by the language
allowing users to construct syntax as capable as all the built-in syntax.
Like, for example, Common Lisp's macros.

Then you get BOTH the convenient built-in high-level iteration constructs
when you want them, as well as the flexibility to build new rare ones if they
happen to come up.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
The only thing necessary for the triumph of evil is for good men to do nothing.
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193802382.849980.300170@57g2000hsv.googlegroups.com>
On 30 out, 22:33, Don Geddis <····@geddis.org> wrote:
> > you build specialized iteration constructs out of tail calls instead of
> > having fixed syntax in the core of the language for that (for, while
> > etc)...
>
> But surely, if what you want is WHILE, it's awfully helpful to have it as a
> standard part of the language.  What benefit is there to the programmer to
> only providing minimal constructs, making them create WHILE themselves first,
> and only then being able to use it?

I don't think you understand:  there *are* syntatic sugar in most
functional languages standards for specialized iteration constructs,
like DO in Scheme.  They *are* however, just macros for tail-recursive
functions underneath.

> As to the "fixed syntax", that problem is easily fixed by the language
> allowing users to construct syntax as capable as all the built-in syntax.
> Like, for example, Common Lisp's macros.

I don't think so.  CL is not properly tail-recursive.  If you build
macro loop constructs out of functions, you may incur in stack
overflow.  You'll need to use the builtin, fixed loop construct.
Also, new kinds of control structures are not of much use without
continuations...
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5opf8bFnn9kdU1@mid.individual.net>
namekuseijin wrote:
> On 30 out, 13:14, Pascal Costanza <····@p-cos.net> wrote:
>> Expressing iterations in terms of tail recursion feels like assembly
>> language because instead of expressing things close to the problem
>> domain, I have to deconstruct what I actually want to say and
>> reconstruct it in terms of simple (simplistic) low-level constructs.
> 
> All languages are like that, including CL.  Isn't that why macros are
> so great?  To adapt the language to the task at hand?  So, why are you
> nitpicking at this particular language feature?

I am not nitpicking at this feature. I am just saying that the 
minimalists are wrong.

> I'm not advocating tail-recursion instead of specialized iteration
> mechanisms closer to the problem domain.  I'm just saying tail-
> recursion code isn't anywhere as low-level as you're making it up to
> be.

It actually is, and your posting below shows it very nicely.

>> Here is a nice example using loop:
>>
>> (loop for (key value) on property-list by #'cddr
>>        unless (member key excluded-keys)
>>        append (list key value)) ; [1]

As a function:

(defun filter (excluded-keys property-list)
   (loop for (key value) on property-list by #'cddr
         unless (member key excluded-keys)
         nconc (list key value)))

 > (filter '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))
(A 1 B 2 B 3)

The result is a correct property list.

>> This simple loop expression removes some properties from a property list.
>>
>> Here is the same thing expressed recursively:
>>
>> (let loop ((property-list property-list) (result '()))
>>    (cond ((null? property-list) (reverse result)) ; [2]
>>          ((member (car property-list) excluded-keys)
>>           (loop (cddr property-list) result))
>>          (else (loop (cddr property-list)
>>                      (cons (car property-list)
>>                        (cons (cadr property-list)
>>                          result))))))
> 
> mine is better (can't stand CLers verbosity):
> 
> (define (filter excluded-keys property-list)
>     (reverse
>      (let loop ((ls property-list) (r '()))
>        (if (null? ls) r
>            (let ((key (car ls)) (value (cadr ls)))
>              (if (member key excluded-keys) (loop (cddr ls) r)
>                  (loop (cddr ls) (cons (list key value) r))))))))
> 
> as in
> (filter '(b c) '(a 1 b 2 b 3 c 4 d 5 c 6))

Both Scheme versions so far are incorrect, because they don't produce 
correct property lists as results. Mine changes property keys and values 
(due to the call to reverse), and yours produces an association list 
instead of a property list as a result.

So much for not seeing the forest from the trees. (I didn't 
intentionally include a bug in my original Scheme version, I have tested 
it only just now, along with the other versions.)

Here is a correct tail-recursive version:

(define (filter excluded-keys property-list)
   (let loop ((property-list property-list) (result '()))
     (if (null? property-list) result
       (let ((key (car property-list)) (value (cadr property-list)))
         (if (memv key excluded-keys)
           (loop (cddr property-list) result)
           (loop (cddr property-list)
                 (append result (list key value))))))))

Still far too verbose.

And due to the use of append in the last line not very efficient. 
Something like append! doesn't help much - it would cons less, but the 
loop would still have to traverse the result list over and over again, 
which is something that is optimized away in Common Lisp's loop construct.

That's another advantage of high-level iteration constructs (and 
high-level language constructs in general): They actually provide better 
opportunities to optimize code, something that you don't regularly want 
to do in your own code, just because the only constructs offered by your 
language are too low-level to provide enough (declarative!) information 
about what is actually going on in your algorithms.

>> Purity is not a worthwhile goal per se. Always use what works
>> best for the case at hand.
> 
> It's not the case for purity, it's the fact that tail-recursion is
> absolutely necessary in functional languages:  you build specialized
> iteration constructs out of tail calls instead of having fixed syntax
> in the core of the language for that (for, while etc)...
> 
> and for tail-recursion you need the tail-call optimization provided by
> the implementation or else your stack will blow up.

Sure, that's all known, but irrelevant to the discussion at hand.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193782313.353514.221150@y42g2000hsy.googlegroups.com>
On Oct 30, 8:33 pm, Pascal Costanza <····@p-cos.net> wrote:
> namekuseijin wrote:
> > On 30 out, 13:14, Pascal Costanza <····@p-cos.net> wrote:
> >> Expressing iterations in terms of tail recursion feels like assembly
> >> language because instead of expressing things close to the problem
> >> domain, I have to deconstruct what I actually want to say and
> >> reconstruct it in terms of simple (simplistic) low-level constructs.
>
> > All languages are like that, including CL.  Isn't that why macros are
> > so great?  To adapt the language to the task at hand?  So, why are you
> > nitpicking at this particular language feature?
>
> I am not nitpicking at this feature. I am just saying that the
> minimalists are wrong.
>
> > I'm not advocating tail-recursion instead of specialized iteration
> > mechanisms closer to the problem domain.  I'm just saying tail-
> > recursion code isn't anywhere as low-level as you're making it up to
> > be.
>
> It actually is, and your posting below shows it very nicely.
>
> >> Here is a nice example using loop:
>
> >> (loop for (key value) on property-list by #'cddr
> >>        unless (member key excluded-keys)
> >>        append (list key value)) ; [1]
>
> As a function:
>
> (defun filter (excluded-keys property-list)
>    (loop for (key value) on property-list by #'cddr
>          unless (member key excluded-keys)
>          nconc (list key value)))
>
>  > (filter '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))
> (A 1 B 2 B 3)
>
> The result is a correct property list.
>
>
>
> >> This simple loop expression removes some properties from a property list.
>
> >> Here is the same thing expressed recursively:
>
> >> (let loop ((property-list property-list) (result '()))
> >>    (cond ((null? property-list) (reverse result)) ; [2]
> >>          ((member (car property-list) excluded-keys)
> >>           (loop (cddr property-list) result))
> >>          (else (loop (cddr property-list)
> >>                      (cons (car property-list)
> >>                        (cons (cadr property-list)
> >>                          result))))))
>
> > mine is better (can't stand CLers verbosity):
>
> > (define (filter excluded-keys property-list)
> >     (reverse
> >      (let loop ((ls property-list) (r '()))
> >        (if (null? ls) r
> >            (let ((key (car ls)) (value (cadr ls)))
> >              (if (member key excluded-keys) (loop (cddr ls) r)
> >                  (loop (cddr ls) (cons (list key value) r))))))))
>
> > as in
> > (filter '(b c) '(a 1 b 2 b 3 c 4 d 5 c 6))
>
> Both Scheme versions so far are incorrect, because they don't produce
> correct property lists as results. Mine changes property keys and values
> (due to the call to reverse), and yours produces an association list
> instead of a property list as a result.
>
> So much for not seeing the forest from the trees. (I didn't
> intentionally include a bug in my original Scheme version, I have tested
> it only just now, along with the other versions.)
>
> Here is a correct tail-recursive version:
>
> (define (filter excluded-keys property-list)
>    (let loop ((property-list property-list) (result '()))
>      (if (null? property-list) result
>        (let ((key (car property-list)) (value (cadr property-list)))
>          (if (memv key excluded-keys)
>            (loop (cddr property-list) result)
>            (loop (cddr property-list)
>                  (append result (list key value))))))))
>
> Still far too verbose.
>
> And due to the use of append in the last line not very efficient.
> Something like append! doesn't help much - it would cons less, but the
> loop would still have to traverse the result list over and over again,
> which is something that is optimized away in Common Lisp's loop construct.
>
> That's another advantage of high-level iteration constructs (and
> high-level language constructs in general): They actually provide better
> opportunities to optimize code, something that you don't regularly want
> to do in your own code, just because the only constructs offered by your
> language are too low-level to provide enough (declarative!) information
> about what is actually going on in your algorithms.

Not concise as loop but not too shabby.
Also a little bit faster than loop & with ~15% less consing:
(defun rec (exc lst &optional res)
  (cond ((endp lst) res)
        ((member (car lst) exc)
         (rec exc (cddr lst) res))
        (t (rec exc (cddr lst)
                (nconc res (list (car lst) (cadr lst)))))))
(defun test (fn)
  (dotimes (i 10000000)
    (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))

Three of them compiled (filter , rec & test) median from 3 runs
CG-USER(13): (time (test #'rec))
; cpu time (non-gc) 19,970 msec user, 110 msec system
; cpu time (gc)     4,700 msec user, 10 msec system
; cpu time (total)  24,670 msec user, 120 msec system
; real time  25,029 msec
; space allocation:
;  60,002,394 cons cells, 61,920 other bytes, 1,280 static bytes
NIL
CG-USER(17):  (time (test #'filter))
; cpu time (non-gc) 21,320 msec user, 80 msec system
; cpu time (gc)     5,180 msec user, 30 msec system
; cpu time (total)  26,500 msec user, 110 msec system
; real time  26,794 msec
; space allocation:
;  70,003,039 cons cells, 66,016 other bytes, 1,408 static bytes
NIL

cheers
Slobodan
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5oq296Fo5eugU2@mid.individual.net>
Slobodan Blazeski wrote:

> (defun test (fn)
>   (dotimes (i 10000000)
>     (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))
> 
> Three of them compiled (filter , rec & test) median from 3 runs
> CG-USER(13): (time (test #'rec))
> ; cpu time (non-gc) 19,970 msec user, 110 msec system
> ; cpu time (gc)     4,700 msec user, 10 msec system
> ; cpu time (total)  24,670 msec user, 120 msec system
> ; real time  25,029 msec
> ; space allocation:
> ;  60,002,394 cons cells, 61,920 other bytes, 1,280 static bytes
> NIL
> CG-USER(17):  (time (test #'filter))
> ; cpu time (non-gc) 21,320 msec user, 80 msec system
> ; cpu time (gc)     5,180 msec user, 30 msec system
> ; cpu time (total)  26,500 msec user, 110 msec system
> ; real time  26,794 msec
> ; space allocation:
> ;  70,003,039 cons cells, 66,016 other bytes, 1,408 static bytes
> NIL

That's hardly a good benchmark. The test parameters should vary in 
length, and you should especially also try much longer property lists.

Also expressing the test function as a higher-order function where the 
function to be tested is passed as a first-class value is suspicious. 
There is a good chance that what you want to measure gets lost in the 
noise of function call overhead (but I am only speculating here).


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193829838.133384.222730@o80g2000hse.googlegroups.com>
On Oct 30, 5:58 pm, Pascal Costanza <····@p-cos.net> wrote:
> Slobodan Blazeski wrote:
> > (defun test (fn)
> >   (dotimes (i 10000000)
> >     (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))
>
> > Three of them compiled (filter , rec & test) median from 3 runs
> > CG-USER(13): (time (test #'rec))
> > ; cpu time (non-gc) 19,970 msec user, 110 msec system
> > ; cpu time (gc)     4,700 msec user, 10 msec system
> > ; cpu time (total)  24,670 msec user, 120 msec system
> > ; real time  25,029 msec
> > ; space allocation:
> > ;  60,002,394 cons cells, 61,920 other bytes, 1,280 static bytes
> > NIL
> > CG-USER(17):  (time (test #'filter))
> > ; cpu time (non-gc) 21,320 msec user, 80 msec system
> > ; cpu time (gc)     5,180 msec user, 30 msec system
> > ; cpu time (total)  26,500 msec user, 110 msec system
> > ; real time  26,794 msec
> > ; space allocation:
> > ;  70,003,039 cons cells, 66,016 other bytes, 1,408 static bytes
> > NIL
>
> That's hardly a good benchmark. The test parameters should vary in
> length, and you should especially also try much longer property lists.
>
> Also expressing the test function as a higher-order function where the
> function to be tested is passed as a first-class value is suspicious.
> There is a good chance that what you want to measure gets lost in the
> noise of function call overhead (but I am only speculating here).
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/

Ok , let's try this:
(defconstant +property-list+
    '(a 1 b 2 b 3 c 4 d 5 c 6 a 1 r 2 b 3 c 4 j 5 c 6 a 1 b 2 u 3 c 4
l 5 l 6))

(defconstant +excluded-keys+ '(c d j r))

(defun test-filter (n)
  (dotimes (i n)
    (filter +excluded-keys+ +property-list+)))

(defun test-rec (n)
  (dotimes (i n)
    (rec +excluded-keys+ +property-list+)))
Everything is compiled, median from 3 runs:
CG-USER(10): (time (test-filter 1000000))
; cpu time (non-gc) 6,060 msec user, 0 msec system
; cpu time (gc)     1,772 msec user, 0 msec system
; cpu time (total)  7,832 msec user, 0 msec system
; real time  7,901 msec
; space allocation:
;  21,000,083 cons cells, 88 other bytes, 0 static bytes
NIL
CG-USER(11): (time (test-rec 1000000))
; cpu time (non-gc) 6,948 msec user, 10 msec system
; cpu time (gc)     1,674 msec user, 0 msec system
; cpu time (total)  8,622 msec user, 10 msec system
; real time  8,733 msec
; space allocation:
;  20,000,085 cons cells, 56 other bytes, 0 static bytes
NIL
Beside being prettier you're solution is faster while mine conses
less.
Just for the record I like specialized iteration constructs like
iterate and series, but loop feels unlispy to me, some day I might get
used to it but not now.

cheers
Slobodan
From: Thomas F. Burdick
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193825369.291061.286730@y27g2000pre.googlegroups.com>
On Oct 30, 11:11 pm, Slobodan Blazeski <·················@gmail.com>
wrote:

> Not concise as loop but not too shabby.

Considering that readability was the original question, I'd say this
function is a disaster.

> Also a little bit faster than loop & with ~15% less consing:
>
> (defun rec (exc lst &optional res)
>   (cond ((endp lst) res)
>         ((member (car lst) exc)
>          (rec exc (cddr lst) res))
>         (t (rec exc (cddr lst)
>                 (nconc res (list (car lst) (cadr lst)))))))

Shlemiel, you were having enough trouble painting fences.  If you want
to move into software, you really need to read those algorithms and
data structures books we were talking about.

> (defun test (fn)
>   (dotimes (i 10000000)
>     (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))

Not bad, you get your kopek; now what happens on day two?
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193830371.730150.226160@57g2000hsv.googlegroups.com>
On Oct 31, 3:09 am, "Thomas F. Burdick" <········@gmail.com> wrote:
> On Oct 30, 11:11 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > Not concise as loop but not too shabby.
>
> Considering that readability was the original question, I'd say this
> function is a disaster.
>
> > Also a little bit faster than loop & with ~15% less consing:
>
> > (defun rec (exc lst &optional res)
> >   (cond ((endp lst) res)
> >         ((member (car lst) exc)
> >          (rec exc (cddr lst) res))
> >         (t (rec exc (cddr lst)
> >                 (nconc res (list (car lst) (cadr lst)))))))
>
> Shlemiel, you were having enough trouble painting fences.  If you want
> to move into software, you really need to read those algorithms and
> data structures books we were talking about.
>
> > (defun test (fn)
> >   (dotimes (i 10000000)
> >     (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))
>
> Not bad, you get your kopek; now what happens on day two?


Thank you for your insults, now would you please submit your tail-
recursive solution and show me how it should be done?

cheers
Slobodan

BTW The joke was really funny :) for those who never heard it like me
here it is:

    Shlemiel gets a job as a street painter, painting the dotted lines
down the middle of the road. On the first day he takes a can of paint
out to the road and finishes 300 yards of the road. "That's pretty
good!" says his boss, "you're a fast worker!" and pays him a kopeck.

    The next day Shlemiel only gets 150 yards done. "Well, that's not
nearly as good as yesterday, but you're still a fast worker. 150 yards
is respectable," and pays him a kopeck.

    The next day Shlemiel paints 30 yards of the road. "Only 30!"
shouts his boss. "That's unacceptable! On the first day you did ten
times that much work! What's going on?"

    "I can't help it," says Shlemiel. "Every day I get farther and
farther away from the paint can!"
copy pasted from http://www.joelonsoftware.com/articles/fog0000000319.html
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193842304.062571.262060@22g2000hsm.googlegroups.com>
On 31 out, 09:32, Slobodan Blazeski <·················@gmail.com>
wrote:
> Thank you for your insults, now would you please submit your tail-
> recursive solution and show me how it should be done?

BTW, yours was nice.  pity CL doesn't require tail-call optimizations.

> BTW The joke was really funny :) for those who never heard it like me
> here it is:

yes, it was very good! :)

the guys even got as far as discussing the metrics! :)
http://discuss.fogcreek.com/techInterview/default.asp?cmd=show&ixPost=153
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193847386.678418.7510@i13g2000prf.googlegroups.com>
On Oct 31, 3:51 pm, namekuseijin <············@gmail.com> wrote:
> On 31 out, 09:32, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > Thank you for your insults, now would you please submit your tail-
> > recursive solution and show me how it should be done?
>
> BTW, yours was nice.
Thank you. I got an idea of declaring result as &optional to avoid
using let or introducing auxilary function, global or local. Small
hack probably but even small hacks makes me feel good for a day.

> pity CL doesn't require tail-call optimizations.
Standard doesn't require it but all compilers seems to implement it
anyway.

>
> > BTW The joke was really funny :) for those who never heard it like me
> > here it is:
>
> yes, it was very good! :)
>
> the guys even got as far as discussing the metrics! :)http://discuss.fogcreek.com/techInterview/default.asp?cmd=show&ixPost...

Spolsky has a bad opinion about lisp family, but beside that he's
writings are funny.

cheers
Slobodan
From: Thomas F. Burdick
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193914820.314774.283910@57g2000hsv.googlegroups.com>
On Oct 31, 12:32 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Oct 31, 3:09 am, "Thomas F. Burdick" <········@gmail.com> wrote:
>
> > On Oct 30, 11:11 pm, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > Not concise as loop but not too shabby.
>
> > Considering that readability was the original question, I'd say this
> > function is a disaster.
>
> > > Also a little bit faster than loop & with ~15% less consing:
>
> > > (defun rec (exc lst &optional res)
> > >   (cond ((endp lst) res)
> > >         ((member (car lst) exc)
> > >          (rec exc (cddr lst) res))
> > >         (t (rec exc (cddr lst)
> > >                 (nconc res (list (car lst) (cadr lst)))))))
>
> > Shlemiel, you were having enough trouble painting fences.  If you want
> > to move into software, you really need to read those algorithms and
> > data structures books we were talking about.
>
> > > (defun test (fn)
> > >   (dotimes (i 10000000)
> > >     (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))
>
> > Not bad, you get your kopek; now what happens on day two?
>
> Thank you for your insults

(a) if you're going to be on usenet, grow thicker skin.  I didn't say
a thing about *you*.

(b) seriously, I phrased it as a joke, but if you don't see how you
implemented a Shlemiel the painter algorithm, you're in trouble.

> now would you please submit your tail-recursive solution
> and show me how it should be done?

You seem to be confused about who is the student here.  But I'm
feeling indulgent right now.  See if you can't come up with a test
function where the dotimes only repeats 10 times, but yet Pascal's
solution takes several seconds.  Now try yours.

To fix it, first: FOR THE LOVE OF DOG, spell your damn variable names
out fully.  "res" and "lst" are not reasonable in CL.

Then: write a version where Shlemiel takes his paint bucket with him,
but walks the length of the fence twice.

Finally: write a version where Shlemiel walks the length of the fence
once.  This one gets him paid two kopeks :-)

> BTW The joke was really funny

Shlemiel jokes are generally pretty good.  This one has the added
value of being a very evocative mnemonic for a class of exponential
algorithms for which there is no excuse.

>     Shlemiel gets a job as a street painter

The version I know has Shlemiel painting fences, but anything
inherently linear works.
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193922631.264880.54030@d55g2000hsg.googlegroups.com>
Thomas F. Burdick wrote:
> On Oct 31, 12:32 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
> > On Oct 31, 3:09 am, "Thomas F. Burdick" <········@gmail.com> wrote:
> >
> > > On Oct 30, 11:11 pm, Slobodan Blazeski <·················@gmail.com>
> > > wrote:
> >
> > > > Not concise as loop but not too shabby.
> >
> > > Considering that readability was the original question, I'd say this
> > > function is a disaster.
> >
> > > > Also a little bit faster than loop & with ~15% less consing:
> >
> > > > (defun rec (exc lst &optional res)
> > > >   (cond ((endp lst) res)
> > > >         ((member (car lst) exc)
> > > >          (rec exc (cddr lst) res))
> > > >         (t (rec exc (cddr lst)
> > > >                 (nconc res (list (car lst) (cadr lst)))))))
> >
> > > Shlemiel, you were having enough trouble painting fences.  If you want
> > > to move into software, you really need to read those algorithms and
> > > data structures books we were talking about.
> >
> > > > (defun test (fn)
> > > >   (dotimes (i 10000000)
> > > >     (funcall fn '(c d) '(a 1 b 2 b 3 c 4 d 5 c 6))))
> >
> > > Not bad, you get your kopek; now what happens on day two?
> >
> > Thank you for your insults
>
> (a) if you're going to be on usenet, grow thicker skin.  I didn't say
> a thing about *you*.

Don't worry about that, it's nearly impossible for me to get insulted
on the usenet.
I only feel bad when somebody points at something I screwed up, and
after few seconds of bad feelings I realize that such person actually
helped me learn something, so I either accept it or at least consider
it . Afterwards I feel just fine.
>
> (b) seriously, I phrased it as a joke, but if you don't see how you
> implemented a Shlemiel the painter algorithm, you're in trouble.
No I don't see it, I bring my  bucket as tail-recursion with me , If
you want to help me understand what are you talking about show me how
it should be done the right way. Code please.
>
> > now would you please submit your tail-recursive solution
> > and show me how it should be done?
>
> You seem to be confused about who is the student here.  But I'm
> feeling indulgent right now.  See if you can't come up with a test
> function where the dotimes only repeats 10 times, but yet Pascal's
> solution takes several seconds.  Now try yours.
What do you mean, dotimes is only in a testing  function , it could be
rewritten like
(defun test-filter (n)
  (loop (if (zerop (decf n))
            (return)
          (filter +excluded-keys+ +property-list+))))

Or using tagbody or whatever construct you want . They are both
compiled-function-p same as two constants. The results
are about the same, Pascal solution is faster but it's consing
more .Though differences are very small.
So LOOP haters could use tail-recursive solution and don't worry about
performance. Pascal solution is something that I would choose to use.
CG-USER(10):  (time (test-rec 1000000))
; cpu time (non-gc) 6,910 msec user, 50 msec system
; cpu time (gc)     1,470 msec user, 10 msec system
; cpu time (total)  8,380 msec user, 60 msec system
; real time  8,484 msec
; space allocation:
;  20,000,060 cons cells, 20,592 other bytes, 416 static bytes
NIL
CG-USER(11):
CG-USER(11):  (time (test-filter 1000000))
; cpu time (non-gc) 6,070 msec user, 40 msec system
; cpu time (gc)     1,620 msec user, 0 msec system
; cpu time (total)  7,690 msec user, 40 msec system
; real time  8,303 msec
; space allocation:
;  21,001,444 cons cells, 23,760 other bytes, 608 static bytes
NIL
>
> To fix it, first: FOR THE LOVE OF DOG, spell your damn variable names
> out fully.  "res" and "lst" are not reasonable in CL.

That's matter of style , very-long-and -descriptive-names are good but
sometimes saving space makes  code more readable.
(defun recursive (excluded-keys property-list &optional result)
   (cond ((endp property-list) result)
         ((member (car property-list) excluded-keys)
          (recursive excluded-keys (cddr property-list) result))
         (t (recursive excluded-keys (cddr property-list)
                       (nconc result (list (car property-list)
                                           (cadr property-list)))))))
>
> Then: write a version where Shlemiel takes his paint bucket with him,
> but walks the length of the fence twice.
>
> Finally: write a version where Shlemiel walks the length of the fence
> once.  This one gets him paid two kopeks :-)
>
> > BTW The joke was really funny
>
> Shlemiel jokes are generally pretty good.  This one has the added
> value of being a very evocative mnemonic for a class of exponential
> algorithms for which there is no excuse.
>
> >     Shlemiel gets a job as a street painter
>
> The version I know has Shlemiel painting fences, but anything
> inherently linear works.
From: Thomas F. Burdick
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1194004201.127208.63430@19g2000hsx.googlegroups.com>
On Nov 1, 2:10 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> Thomas F. Burdick wrote:
>
> > (b) seriously, I phrased it as a joke, but if you don't see how you
> > implemented a Shlemiel the painter algorithm, you're in trouble.
>
> No I don't see it, I bring my  bucket as tail-recursion with me,

You're in trouble :-)

> If you want to help me understand what are you talking about show me how
> it should be done the right way. Code please.

Okay, here's a more idiomatic loop version (same performance, but more
readable -- I guess Pascal's only a first-degree loop blackbelt), a
version of your function with more idiomatic variable names, and some
testing code:

(defun filter-loop (excluded plist)
   (loop for (key value) on plist by #'cddr
         unless (member key excluded)
         collect key and collect value))

(defun filter-tr (excluded plist &optional result)
  (cond ((endp plist) result)
        ((member (car plist) excluded)
         (filter-tr excluded (cddr plist) result))
        (t (rec excluded (cddr plist)
                (nconc result (list (car plist) (cadr plist)))))))

(defun symbol-iterator ()
  (let ((length 1)
        (alphabet "ABCDEFGHIJKLMNOPQRSTUVWXYZ")
        (i 0))
    (labels ((gen ()
               (if (>= i (length alphabet))
                   (progn (incf length)
                          (when (> length 10) (setf length 1))
                          (setf i 0)
                          (gen))
                   (prog1 (intern
                           (make-string
                            length :initial-element (char alphabet
i)))
                     (incf i)))))
      #'gen)))

(defun generate-plist (length)
  (loop with iter = (symbol-iterator)
        with nums = (quote #1=(1 2 3 4 5 6 7 8 9 10 . #1#))
        for i in nums
        repeat length
        for symbol = (funcall iter)
        collect symbol collect i))

(defun test-run (fun plist)
  (loop repeat 10 do (funcall fun '(a b) plist)))

(defparameter *plist* (generate-plist 10000))

Now, try

  (time (test-run #'filter-loop *plist*))

and

  (time (test-run #'filter-tr *plist*))

Go ahead and add two or three more zeros in the call to generate-
plist, and see what happens with filter-loop.  You should try
increasing the size of *plist* much less drastically for filter-tr.

Shlemiel's bucket in this case is the end of the list RESULT.  The
traditional solution to this problem is to make one final (linear)
pass over the result list.  That is, instead of:

  (cond ((endp plist) result)

you'd write:

  (cond ((endp plist) (nreverse result))

and of course make the associated changes to the function.

Oh, and just FYI, in terms of readability, destructuring-bind is
really your friend here.  A more readable version of your function
would be:

(defun filter-tr (excluded plist &optional result)
  (if (endp plist)
      result
      (destructuring-bind (key val . rest) plist
        (if (member key excluded)
            (filter-tr excluded rest result)
            (filter-tr excluded rest (nconc result (list key
val)))))))

It still implements a Shlemiel the painter algorithm, though.

> That's matter of style , very-long-and -descriptive-names are good but
> sometimes saving space makes  code more readable.

They don't have to be very-long-names, in fact those can sometimes get
in the way of readability.  But removing vowels is just silly, and
leaves your reader having to guess at what word you meant.  Short
words, reasonable, accepted and/or consistent abbreviations, and of
course the classic suite of one-letter variable names, are good and
concise.

Especially if you find yourself interested in the more schemey/
functional end of CL, get Graham's book(s).  He writes very stylish,
if idiosyncratic, code.  You won't learn LOOP from him (Seibel's is
the only book that really covers it), but you will learn a nice mental
model concerning macros, little tricks like AIF, and more interesting
things, like the compiling-to-a-network-of-closures trick that is the
reason that CL-PPCRE out-performs Perl's regular expressions.

Anyhow, I certainly hope you get by now how your code was reenacting
Shlemiel's putzish ways.  So back to fixing the code, you still need
to:

> > Then: write a version where Shlemiel takes his paint bucket with him,
> > but walks the length of the fence twice.
>
> > Finally: write a version where Shlemiel walks the length of the fence
> > once.  This one gets him paid two kopeks :-)
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1194026839.906983.118610@22g2000hsm.googlegroups.com>
On Nov 2, 4:50 am, "Thomas F. Burdick" <········@gmail.com> wrote:
> On Nov 1, 2:10 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > Thomas F. Burdick wrote:
>
> > > (b) seriously, I phrased it as a joke, but if you don't see how you
> > > implemented a Shlemiel the painter algorithm, you're in trouble.
>
> > No I don't see it, I bring my  bucket as tail-recursion with me,
>
> You're in trouble :-)
>
> > If you want to help me understand what are you talking about show me how
> > it should be done the right way. Code please.
>
> Okay, here's a more idiomatic loop version (same performance, but more
> readable -- I guess Pascal's only a first-degree loop blackbelt), a
> version of your function with more idiomatic variable names, and some
> testing code:
>
> (defun filter-loop (excluded plist)
>    (loop for (key value) on plist by #'cddr
>          unless (member key excluded)
>          collect key and collect value))
>
> (defun filter-tr (excluded plist &optional result)
>   (cond ((endp plist) result)
>         ((member (car plist) excluded)
>          (filter-tr excluded (cddr plist) result))
>         (t (rec excluded (cddr plist)
>                 (nconc result (list (car plist) (cadr plist)))))))
>
> (defun symbol-iterator ()
>   (let ((length 1)
>         (alphabet "ABCDEFGHIJKLMNOPQRSTUVWXYZ")
>         (i 0))
>     (labels ((gen ()
>                (if (>= i (length alphabet))
>                    (progn (incf length)
>                           (when (> length 10) (setf length 1))
>                           (setf i 0)
>                           (gen))
>                    (prog1 (intern
>                            (make-string
>                             length :initial-element (char alphabet
> i)))
>                      (incf i)))))
>       #'gen)))
>
> (defun generate-plist (length)
>   (loop with iter = (symbol-iterator)
>         with nums = (quote #1=(1 2 3 4 5 6 7 8 9 10 . #1#))
>         for i in nums
>         repeat length
>         for symbol = (funcall iter)
>         collect symbol collect i))
>
> (defun test-run (fun plist)
>   (loop repeat 10 do (funcall fun '(a b) plist)))
>
> (defparameter *plist* (generate-plist 10000))
>
> Now, try
>
>   (time (test-run #'filter-loop *plist*))
>
> and
>
>   (time (test-run #'filter-tr *plist*))
>
> Go ahead and add two or three more zeros in the call to generate-
> plist, and see what happens with filter-loop.  You should try
> increasing the size of *plist* much less drastically for filter-tr.
>
> Shlemiel's bucket in this case is the end of the list RESULT.  The
> traditional solution to this problem is to make one final (linear)
> pass over the result list.  That is, instead of:
>
>   (cond ((endp plist) result)
>
> you'd write:
>
>   (cond ((endp plist) (nreverse result))
>
> and of course make the associated changes to the function.
That's exactly how I wrote it at first, but then I rewrote it to avoid
using nreverse,
making my solution shorter without thinking about performance.
>
> Oh, and just FYI, in terms of readability, destructuring-bind is
> really your friend here.  A more readable version of your function
> would be:
>
> (defun filter-tr (excluded plist &optional result)
>   (if (endp plist)
>       result
>       (destructuring-bind (key val . rest) plist
>         (if (member key excluded)
>             (filter-tr excluded rest result)
>             (filter-tr excluded rest (nconc result (list key
> val)))))))
>
> It still implements a Shlemiel the painter algorithm, though.
>
> > That's matter of style , very-long-and -descriptive-names are good but
> > sometimes saving space makes  code more readable.
>
> They don't have to be very-long-names, in fact those can sometimes get
> in the way of readability.  But removing vowels is just silly, and
> leaves your reader having to guess at what word you meant.  Short
> words, reasonable, accepted and/or consistent abbreviations, and of
> course the classic suite of one-letter variable names, are good and
> concise.
>
> Especially if you find yourself interested in the more schemey/
> functional end of CL, get Graham's book(s).  He writes very stylish,
> if idiosyncratic, code.  You won't learn LOOP from him (Seibel's is
> the only book that really covers it), but you will learn a nice mental
> model concerning macros, little tricks like AIF, and more interesting
> things, like the compiling-to-a-network-of-closures trick that is the
> reason that CL-PPCRE out-performs Perl's regular expressions.
>
> Anyhow, I certainly hope you get by now how your code was reenacting
> Shlemiel's putzish ways.  So back to fixing the code, you still need
> to:

Thanks for the good tips, I've already went through ACL and on lisp,
but learning and mastering  are two different things. Unless I feel
need to use some technique in my code I can not really appreciate it
nor truly understand it. Several months ago I didn't even used CLOS.
Books are good but practice is too.

cheers
Slobodan
>
> > > Then: write a version where Shlemiel takes his paint bucket with him,
> > > but walks the length of the fence twice.
>
> > > Finally: write a version where Shlemiel walks the length of the fence
> > > once.  This one gets him paid two kopeks :-)
From: Raffael Cavallaro
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <2007110301325850073-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-10-30 15:33:31 -0400, Pascal Costanza <··@p-cos.net> said:

> Here is a correct tail-recursive version:
> 
> (define (filter excluded-keys property-list)
>    (let loop ((property-list property-list) (result '()))
>      (if (null? property-list) result
>        (let ((key (car property-list)) (value (cadr property-list)))
>          (if (memv key excluded-keys)
>            (loop (cddr property-list) result)
>            (loop (cddr property-list)
>                  (append result (list key value))))))))
> 
> Still far too verbose.

Which, (as I'm sure you know since you first pointed to Olin Shivers' 
video), is exactly his criticism of named let as an iteration construct 
- it's fine for compilers and macros to emit stuff like this, but crazy 
for human programmers to have to write it by hand. 
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87bqabrbxl.fsf@web.de>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:

>
> Which, (as I'm sure you know since you first pointed to Olin Shivers'
> video), is exactly his criticism of named let as an iteration
> construct - it's fine for compilers and macros to emit stuff like
> this, but crazy for human programmers to have to write it by hand.

No, it's very simple for decent programmers to write by hand,
as opposed to bloated illegible constructs like LOOP.
Only sadomasochist programmers prefer the LOOP version.

Klaus Schilling
From: Raffael Cavallaro
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <200711031340148930-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2007-11-03 04:05:42 -0400, Klaus Schilling <···············@web.de> said:

> No, it's very simple for decent programmers to write by hand,
> as opposed to bloated illegible constructs like LOOP.

No one said we *couldn't* write it by hand, only that we have the good 
sense to let macros do it for us.

> Only sadomasochist programmers prefer the LOOP version.

But Klaus, tell us what you *really* think.


(in case you're not familiar with that colloquialism, you do realize 
that you've become a parody of your own position, right?)
From: Kamen TOMOV
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <upryw6pyy.fsf@cybuild.com>
On Tue, Oct 30 2007, Pascal Costanza wrote:

> Expressing iterations in terms of tail recursion feels like assembly
> language because instead of expressing things close to the problem
> domain, I have to deconstruct what I actually want to say and
> reconstruct it in terms of simple (simplistic) low-level
> constructs. By the time I have done that, I don't see the forest
> from the trees anymore.

I know what you mean. Perhaps the moment one starts thinking of
reconstruction he should restart using a high level construct.

> I agree. Purity is not a worthwhile goal per se. Always use what
> works best for the case at hand.

Yeah, one can start using Lisp without loop and proceed until he
reaches certain problem. This way the language would look minimalistic
to him in the beginning, but eventually he would feel its
extensibility.

-- 
�����
From: Marco Antoniotti
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193739275.083756.44910@57g2000hsv.googlegroups.com>
On Oct 28, 9:14 pm, Klaus Schilling <···············@web.de> wrote:
> namekuseijin <············@gmail.com> writes:
>
> > sure they will:  Scheme is all about minimalism after all.
>
> Minimalism is absolutely necessary, which explains the absurdity of LOOP etc. which is avoided by true lisp programmers
>
>            Klaus Schilling

I am a true (Common) Lisp programmer and I use LOOP when needed.  The
problem with LOOP is that its "extensibility" is not standardized.

Cheers

Marco

BTW.  I also like and eat quiche.
From: Frank Goenninger DG1SBG
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <lzwst46gzl.fsf@de.goenninger.net>
Marco Antoniotti <·······@gmail.com> writes:

> On Oct 28, 9:14 pm, Klaus Schilling <···············@web.de> wrote:
>> namekuseijin <············@gmail.com> writes:
>>
>> > sure they will:  Scheme is all about minimalism after all.
>>
>> Minimalism is absolutely necessary, which explains the absurdity of LOOP etc. which is avoided by true lisp programmers
>>
>>            Klaus Schilling
>
> I am a true (Common) Lisp programmer and I use LOOP when needed.  The
> problem with LOOP is that its "extensibility" is not standardized.

Klaus is enjoying his private little obession with LOOP. Makes him
close to being a troll.

> Cheers
>
> Marco
>
> BTW.  I also like and eat quiche.

Mmmmh - that and a good beer. Makes for a very pleasant lunch or
dinner.

Frank

-- 

  Frank Goenninger

  frgo(at)mac(dot)com

  "Don't ask me! I haven't been reading comp.lang.lisp long enough to 
  really know ..."
From: Edi Weitz
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <uwst4ubg8.fsf@agharta.de>
On Tue, 30 Oct 2007 11:20:46 +0100, Frank Goenninger DG1SBG <·············@nomail.org> wrote:

> Klaus is enjoying his private little obession with LOOP. Makes him
> close to being a troll.

Why only close?  From his recent postings I can't see any relevant
difference between him and the other trolls.

Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <871wbcadsy.fsf@web.de>
Edi Weitz <········@agharta.de> writes:

> On Tue, 30 Oct 2007 11:20:46 +0100, Frank Goenninger DG1SBG <·············@nomail.org> wrote:
>
>> Klaus is enjoying his private little obession with LOOP. Makes him
>> close to being a troll.
>
> Why only close?  From his recent postings I can't see any relevant
> difference between him and the other trolls.

all lies. trolls are those who try to force people 
into using the non-lispish construct LOOP 
instead of the lispish construct DO

        Klaus Schilling
From: Damien Kick
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <13j2g0ot3cmku8f@corp.supernews.com>
Edi Weitz wrote:
> On Tue, 30 Oct 2007 11:20:46 +0100, Frank Goenninger DG1SBG <·············@nomail.org> wrote:
> 
>> Klaus is enjoying his private little obession with LOOP. Makes him
>> close to being a troll.
> 
> Why only close?  From his recent postings I can't see any relevant
> difference between him and the other trolls.

The difference between him and other trolls is stylistic.  Everything he 
writes resembles an aphorism in its terseness only without expressing a 
general truth or wise observation often in a clever way.  They're like 
little fortune cookie writs of bombastic assertion.  This is Klaus.  I 
am your waiter.  You will enjoy your sandwich now.
From: Don Geddis
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <873avij7b6.fsf@geddis.org>
Damien Kick <·····@earthlink.net> wrote on Tue, 06 Nov 2007:
> This is Klaus.  I am your waiter.  You will enjoy your sandwich now.

        A Bolshevik speaker promised his audience "come the revolution, we
        will all eat strawberries and cream."  "But I don't like strawberries
        and cream," responded a listener.  "Come the revolution we will ALL
        eat strawberries and cream!," the Bolshevik intoned.

        -- Butler Shaffer

_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
Sometimes you get in on the ground floor just as the elevator stops working.
	-- "Real Life Adventures", 10/5/2006
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1194463157.538588.23470@y42g2000hsy.googlegroups.com>
On 7 nov, 15:26, Don Geddis <····@geddis.org> wrote:
>         A Bolshevik speaker promised his audience "come the revolution, we
>         will all eat strawberries and cream."  "But I don't like strawberries
>         and cream," responded a listener.  "Come the revolution we will ALL
>         eat strawberries and cream!," the Bolshevik intoned.
>
>         -- Butler Shaffer

at least the man who didn't like strawberries was happy after the
revolution... :P
From: John Thingstad
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <op.t00blplrut4oq5@pandora.alfanett.no>
P� Tue, 30 Oct 2007 11:14:35 +0100, skrev Marco Antoniotti  
<·······@gmail.com>:

> On Oct 28, 9:14 pm, Klaus Schilling <···············@web.de> wrote:
>> namekuseijin <············@gmail.com> writes:
>>
>> > sure they will:  Scheme is all about minimalism after all.
>>
>> Minimalism is absolutely necessary, which explains the absurdity of  
>> LOOP etc. which is avoided by true lisp programmers
>>
>>            Klaus Schilling
>
> I am a true (Common) Lisp programmer and I use LOOP when needed.  The
> problem with LOOP is that its "extensibility" is not standardized.
>

Which is why I (and others) prefer iterate instead.
http://common-lisp.net/project/iterate/

-- 
Sendt med Operas revolusjonerende e-postprogram: http://www.opera.com/mail/
From: Marco Antoniotti
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193742985.447622.316260@v3g2000hsg.googlegroups.com>
On Oct 30, 12:02 pm, "John Thingstad" <·······@online.no> wrote:
> P� Tue, 30 Oct 2007 11:14:35 +0100, skrev Marco Antoniotti  
> <·······@gmail.com>:
>
> > On Oct 28, 9:14 pm, Klaus Schilling <···············@web.de> wrote:
> >> namekuseijin <············@gmail.com> writes:
>
> >> > sure they will:  Scheme is all about minimalism after all.
>
> >> Minimalism is absolutely necessary, which explains the absurdity of  
> >> LOOP etc. which is avoided by true lisp programmers
>
> >>            Klaus Schilling
>
> > I am a true (Common) Lisp programmer and I use LOOP when needed.  The
> > problem with LOOP is that its "extensibility" is not standardized.
>
> Which is why I (and others) prefer iterate instead.http://common-lisp.net/project/iterate/
>

Yep.  But ITERATE extensibility is not all that well defined either.
I tried to play with it for (shameless plug!) CL-ENUMERATIONS (http://
common-lisp.net/project/cl-enumeration/)

The macros:

defclause
defclause-driver
defmacro-driver
defmacro-clause
defclause-sequence

in ITERATE are not all that documented.
I would welcome a better piece of documentation about these features.

Cheers

--
Marco
From: Pascal Costanza
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <5ooinlFnnvj1U1@mid.individual.net>
John Thingstad wrote:
> P� Tue, 30 Oct 2007 11:14:35 +0100, skrev Marco Antoniotti 
> <·······@gmail.com>:
> 
>> On Oct 28, 9:14 pm, Klaus Schilling <···············@web.de> wrote:
>>> namekuseijin <············@gmail.com> writes:
>>>
>>> > sure they will:  Scheme is all about minimalism after all.
>>>
>>> Minimalism is absolutely necessary, which explains the absurdity of 
>>> LOOP etc. which is avoided by true lisp programmers
>>>
>>>            Klaus Schilling
>>
>> I am a true (Common) Lisp programmer and I use LOOP when needed.  The
>> problem with LOOP is that its "extensibility" is not standardized.
>>
> 
> Which is why I (and others) prefer iterate instead.
> http://common-lisp.net/project/iterate/

That's a different kind of discussion. Klaus seems to be opposed to 
_any_ kind of high-level iteration construct.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: OMouse
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193583768.939825.184900@50g2000hsm.googlegroups.com>
On Oct 28, 5:51 am, Ken Tilton <···········@optonline.net> wrote:
> Klaus Schilling wrote:
> > Ken Tilton <···········@optonline.net> writes:
>
> >>Wow, I am really out on a limb there. It would be pretty easy to take
> >>me down by naming a superior or even near equal environment.
>
> > The GNU Emacs is vastly superior to any enviornment,
> > as denied by fools only.
>
> > Klaus Schilling
>
> We have to start a new survey for Schemers trying to sneak into the
> Common Lisp fold from the Scheme failed experiment ... ah, there ya go:

Sorry but I can't hear you, I'm reading through the Scheme language
specification for the 123901287387th time in a row! LA LA LA, it's
only 50 pages (R5RS that is, R6RS is the red-headed step child at the
moment).

Of course now you have to reply that it's 50 pages because Schemers
have ADD or AD/HD, or are academics that generalize everything and
never get real work done.

Patiently waiting for an intriguing and hilarious response,
Rudolfo lah
From: George Neuner
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <9h7di3lkl1b5ui34t0a9sba39kf3jnsl6i@4ax.com>
On Sun, 28 Oct 2007 13:11:23 -0400, Ken Tilton
<···········@optonline.net> wrote:

>
>
>OMouse wrote:
>> On Oct 28, 5:51 am, Ken Tilton <···········@optonline.net> wrote:
>> 
>>>Klaus Schilling wrote:
>>>
>>>>Ken Tilton <···········@optonline.net> writes:
>>>
>>>>>Wow, I am really out on a limb there. It would be pretty easy to take
>>>>>me down by naming a superior or even near equal environment.
>>>
>>>>The GNU Emacs is vastly superior to any enviornment,
>>>>as denied by fools only.
>>>
>>>>Klaus Schilling
>>>
>>>We have to start a new survey for Schemers trying to sneak into the
>>>Common Lisp fold from the Scheme failed experiment ... ah, there ya go:
>> 
>> 
>> Sorry but I can't hear you, I'm reading through the Scheme language
>> specification for the 123901287387th time in a row! LA LA LA, it's
>> only 50 pages (R5RS that is, R6RS is the red-headed step child at the
>> moment).
>
>Hey, you almost got the reference, too!
>
>> 
>> Of course now you have to reply that it's 50 pages because Schemers
>> have ADD or AD/HD, or are academics that generalize everything and
>> never get real work done.
>> 
>> Patiently waiting for an intriguing and hilarious response,
>> Rudolfo lah
>> 
>
>Actually, I am way too saddened (but not surprised) by the density of 
>this latest wave of trolls, too dull to recognize a screamingly obvious 
>reference to the sneering remark somewhere Schemily prominent about the 
>Scheme spec being shorter than the CL spec's index. Lispers (we own the 
>name now) have long wanted greater mindshare, and I have long warned 
>them of the human dregs that would follow. You are commended for proving 
>The Kenny right again, tho my infallibility must be getting tedious in 
>its own right, and for occasioning a reprise of the best line of 2007 
>and possibly the century, in reply to R6's bloating up to hundreds of 
>pages -- anyone got the reference? Not me:
>
>"It's going to be tough coming up with an index that big."
>
>Priceless.
>
>kzo

This whole "let's weigh standards" argument is getting very old.  I've
used a dozen languages in 25 years of programming and the last time I
used a programming environment (for any language) that offered only
what was in the language standard and no more was in, let's see ...
NEVER!

The portability issue is also largely a red herring.  It would seem
that a large standard would make lots of code more portable, but the
reality is that real world programs spend a great deal of time
operating beyond the standard functionality of the language that
produced them.  The functionality of the OS, the user libraries, the
hardware, etc. - none of it covered by the language standard.  Porting
any significant, real world program requires a lot of work regardless
of the language it's written in.

It's also a fiction that all language implementations follow their
standard exactly and that the bugs in the various implementations are
portable.

George
--
for email reply remove "/" from address
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <iZyVi.930$2T3.872@newsfe12.lga>
George Neuner wrote:
> On Sun, 28 Oct 2007 13:11:23 -0400, Ken Tilton
> <···········@optonline.net> wrote:
> 
> 
>>
>>OMouse wrote:
>>
>>>On Oct 28, 5:51 am, Ken Tilton <···········@optonline.net> wrote:
>>>
>>>
>>>>Klaus Schilling wrote:
>>>>
>>>>
>>>>>Ken Tilton <···········@optonline.net> writes:
>>>>
>>>>>>Wow, I am really out on a limb there. It would be pretty easy to take
>>>>>>me down by naming a superior or even near equal environment.
>>>>
>>>>>The GNU Emacs is vastly superior to any enviornment,
>>>>>as denied by fools only.
>>>>
>>>>>Klaus Schilling
>>>>
>>>>We have to start a new survey for Schemers trying to sneak into the
>>>>Common Lisp fold from the Scheme failed experiment ... ah, there ya go:
>>>
>>>
>>>Sorry but I can't hear you, I'm reading through the Scheme language
>>>specification for the 123901287387th time in a row! LA LA LA, it's
>>>only 50 pages (R5RS that is, R6RS is the red-headed step child at the
>>>moment).
>>
>>Hey, you almost got the reference, too!
>>
>>
>>>Of course now you have to reply that it's 50 pages because Schemers
>>>have ADD or AD/HD, or are academics that generalize everything and
>>>never get real work done.
>>>
>>>Patiently waiting for an intriguing and hilarious response,
>>>Rudolfo lah
>>>
>>
>>Actually, I am way too saddened (but not surprised) by the density of 
>>this latest wave of trolls, too dull to recognize a screamingly obvious 
>>reference to the sneering remark somewhere Schemily prominent about the 
>>Scheme spec being shorter than the CL spec's index. Lispers (we own the 
>>name now) have long wanted greater mindshare, and I have long warned 
>>them of the human dregs that would follow. You are commended for proving 
>>The Kenny right again, tho my infallibility must be getting tedious in 
>>its own right, and for occasioning a reprise of the best line of 2007 
>>and possibly the century, in reply to R6's bloating up to hundreds of 
>>pages -- anyone got the reference? Not me:
>>
>>"It's going to be tough coming up with an index that big."
>>
>>Priceless.
>>
>>kzo
> 
> 
> This whole "let's weigh standards" argument is getting very old.

You are confused. The Scheme fools started it and paraded it around as 
this Great Thing About Scheme, a measure of their obsession with The 
Wrong Thing when it came to language design.

We're just trying to top each other's index-spec jokes, though I must 
say I retired from that competition after reading the above mot.

>  I've
> used a dozen languages in 25 years of programming and the last time I
> used a programming environment (for any language) that offered only
> what was in the language standard and no more was in, let's see ...
> NEVER!

Irrelevant. Assiduously avoid the proprietary stuff. Use external C libs 
for that funtionality. This is fine for CL cuz ya still get a thousand 
pages of functionality, not so fine for Schemers who end up with a big 
napkinful of functionality.

> 
> The portability issue is also largely a red herring.  It would seem
> that a large standard would make lots of code more portable, but the
> reality is that real world programs spend a great deal of time
> operating beyond the standard functionality of the language that
> produced them.

Can you say "good C libraries that are portable"? Sher ya can. Cello 
uses Tcl, Tk, GraphicsMagick, FreeType, OpenGl, OpenAL and I always 
forget one. Their portability becomes my portability.

>  The functionality of the OS, the user libraries, the
> hardware, etc. - none of it covered by the language standard.

The above libraries are each their own standard. If I need to hit you 
over the head with a hammer: pick good such libraries that are nicely 
portable and consistent, drive them with a thousand-page language.


>  Porting
> any significant, real world program requires a lot of work regardless
> of the language it's written in.

Here you are right. The 24-48 hours need to change both operating system 
and Lisp implementation really make me grind my teeth. Of course most of 
the pain comes from having also to switch IDEs, because Franz does not 
seem to be as good at developing portable software as His Kennyness.

And now something less ironic for the hard of thinking: "a lot of work"? 
PWUAHAHAHAHAHHAHAHAHAHHAA! I have also ported a pure C application 
between (direction forgotten) Symantec C++ and CodeWarrior C++, same OS, 
no libraries, and it was hell, living hell, for a solid week.

> 
> It's also a fiction that all language implementations follow their
> standard exactly and that the bugs in the various implementations are
> portable.

Oh, golly, if I had realized you had never even ported one line of Lisp 
between Lisp implementations I would not have been so hard on you. Of 
course you have no way of knowing you are spewing nonsense.

The lessons I take from porting huge hairy applications you have never 
dreamed of developing between OS /and/ Lisp implementation is "thank 
god!!!!! for standards" which (you are simply dead wrong) folks adhere 
to beautifully. What I see is that (you are right about the wrong thing) 
where there is no standard, boom!, who knows what you will get? FFI 
being the poster child, which is why I backed a Google SoC propject to 
go UFFI one better: CFFI.

kzo

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193743415.337641.80260@22g2000hsm.googlegroups.com>
On 30 out, 03:05, Ken Tilton <···········@optonline.net> wrote:
> Irrelevant. Assiduously avoid the proprietary stuff. Use external C libs
> for that funtionality. This is fine for CL cuz ya still get a thousand
> pages of functionality, not so fine for Schemers who end up with a big
> napkinful of functionality.

neither the long CL standard spec nor the short Scheme ones (pre-R6RS)
provide FFI.

Both languages implementations provide that.  your point?...
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <cpIVi.883$So6.1@newsfe12.lga>
namekuseijin wrote:
> On 30 out, 03:05, Ken Tilton <···········@optonline.net> wrote:
> 
>>Irrelevant. Assiduously avoid the proprietary stuff. Use external C libs
>>for that funtionality. This is fine for CL cuz ya still get a thousand
>>pages of functionality, not so fine for Schemers who end up with a big
>>napkinful of functionality.
> 
> 
> neither the long CL standard spec nor the short Scheme ones (pre-R6RS)
> provide FFI.
> 
> Both languages implementations provide that.  your point?...
> 

That thanks to CFFI (and to some degree before that UFFI) the OW 
(Original Whiner) was wrong, one can build huge portable applications in 
CL. Now before you go stupid on me, yes, Scheme can do a CFFI, but then 
you are still left with just the pure Scheme as portable, which is where 
all this started: Scheme's small spec is a bug, not a feature.

kt


-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: George Neuner
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <r1hei31hnbitokoq962o2c64hackc00kgq@4ax.com>
On Tue, 30 Oct 2007 01:05:01 -0400, Ken Tilton
<···········@optonline.net> wrote:

>George Neuner wrote:
>> 
>> This whole "let's weigh standards" argument is getting very old.
>
>You are confused. The Scheme fools started it and paraded it around as 
>this Great Thing About Scheme, a measure of their obsession with The 
>Wrong Thing when it came to language design.

I don't care who started it - it's ridiculous viewed from either
direction.


>We're just trying to top each other's index-spec jokes, though I must 
>say I retired from that competition after reading the above mot.
>
>>  I've
>> used a dozen languages in 25 years of programming and the last time I
>> used a programming environment (for any language) that offered only
>> what was in the language standard and no more was in, let's see ...
>> NEVER!
>
>Irrelevant. Assiduously avoid the proprietary stuff. Use external C libs 
>for that funtionality. This is fine for CL cuz ya still get a thousand 
>pages of functionality, not so fine for Schemers who end up with a big 
>napkinful of functionality.

What makes you think C libs are portable?  I've had to rehost hundreds
of thousands of lines of library code in my former life as an embedded
systems programmer.  Damn few libraries are actually written to be
portable.


>> The portability issue is also largely a red herring.  It would seem
>> that a large standard would make lots of code more portable, but the
>> reality is that real world programs spend a great deal of time
>> operating beyond the standard functionality of the language that
>> produced them.
>
>Can you say "good C libraries that are portable"? Sher ya can. Cello 
>uses Tcl, Tk, GraphicsMagick, FreeType, OpenGl, OpenAL and I always 
>forget one. Their portability becomes my portability.

Your favorite libs are not available everywhere.  And don't assume
that because you can find binaries for the couple of popular platforms
you target that the libraries are portable.  Have you actually ported
them anywhere?


>>  The functionality of the OS, the user libraries, the
>> hardware, etc. - none of it covered by the language standard.
>
>The above libraries are each their own standard. 

Ad hoc, implementation defined standards.  Kind of pale beside your
beloved 1000 page CL standard.


>If I need to hit you 
>over the head with a hammer: pick good such libraries that are nicely 
>portable and consistent, drive them with a thousand-page language.
>
>> Porting
>> any significant, real world program requires a lot of work regardless
>> of the language it's written in.
>
>Here you are right. The 24-48 hours need to change both operating system 
>and Lisp implementation really make me grind my teeth. Of course most of 
>the pain comes from having also to switch IDEs, because Franz does not 
>seem to be as good at developing portable software as His Kennyness.
>
>And now something less ironic for the hard of thinking: "a lot of work"? 
>PWUAHAHAHAHAHHAHAHAHAHHAA! I have also ported a pure C application 
>between (direction forgotten) Symantec C++ and CodeWarrior C++, same OS, 
>no libraries, and it was hell, living hell, for a solid week.
>
>> It's also a fiction that all language implementations follow their
>> standard exactly and that the bugs in the various implementations are
>> portable.
>
>Oh, golly, if I had realized you had never even ported one line of Lisp 
>between Lisp implementations I would not have been so hard on you. Of 
>course you have no way of knowing you are spewing nonsense.

Now you're just being nasty.  You don't have clue two what I have or
haven't done.  Insult me all you want, it might even raise my opinion
of you.


>The lessons I take from porting huge hairy applications you have never 
>dreamed of developing between OS /and/ Lisp implementation is "thank 
>god!!!!! for standards" which (you are simply dead wrong) folks adhere 
>to beautifully. What I see is that (you are right about the wrong thing) 
>where there is no standard, boom!, who knows what you will get? FFI 
>being the poster child, which is why I backed a Google SoC propject to 
>go UFFI one better: CFFI.
>
>kzo

Hey Kenny, when did you take up KaZOo?

George
--
for email reply remove "/" from address
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <uVIVi.1601$965.831@newsfe12.lga>
George Neuner wrote:
> On Tue, 30 Oct 2007 01:05:01 -0400, Ken Tilton
> <···········@optonline.net> wrote:
> 
> 
>>George Neuner wrote:
>>
>>>This whole "let's weigh standards" argument is getting very old.
>>
>>You are confused. The Scheme fools started it and paraded it around as 
>>this Great Thing About Scheme, a measure of their obsession with The 
>>Wrong Thing when it came to language design.
> 
> 
> I don't care who started it - it's ridiculous viewed from either
> direction.

I have never considered ridiculous to be an objection to a good flamewar.

> 
> 
> 
>>We're just trying to top each other's index-spec jokes, though I must 
>>say I retired from that competition after reading the above mot.
>>
>>
>>> I've
>>>used a dozen languages in 25 years of programming and the last time I
>>>used a programming environment (for any language) that offered only
>>>what was in the language standard and no more was in, let's see ...
>>>NEVER!
>>
>>Irrelevant. Assiduously avoid the proprietary stuff. Use external C libs 
>>for that funtionality. This is fine for CL cuz ya still get a thousand 
>>pages of functionality, not so fine for Schemers who end up with a big 
>>napkinful of functionality.
> 
> 
> What makes you think C libs are portable?

What makes you think you have stopped beating your wife?

>  I've had to rehost hundreds
> of thousands of lines of library code in my former life as an embedded
> systems programmer.  Damn few libraries are actually written to be
> portable.

Well if you were actually trying to write an application instead of just 
pissing around on Usenet you would likely find, when you decide to go 
looking for X, that an actively maintained portable C library exists to 
do X (with some other Open Source fairy doing all the work to keep them 
current). You'll probably even find an installer for windows.


>>>The portability issue is also largely a red herring.  It would seem
>>>that a large standard would make lots of code more portable, but the
>>>reality is that real world programs spend a great deal of time
>>>operating beyond the standard functionality of the language that
>>>produced them.
>>
>>Can you say "good C libraries that are portable"? Sher ya can. Cello 
>>uses Tcl, Tk, GraphicsMagick, FreeType, OpenGl, OpenAL and I always 
>>forget one. Their portability becomes my portability.
> 
> 
> Your favorite libs are not available everywhere.  And don't assume
> that because you can find binaries for the couple of popular platforms
> you target that the libraries are portable.  Have you actually ported
> them anywhere?

What? GraphicsMagick doesn't run on Palm Pilot?! I guess I am lucky, I 
just need OS X and Win32, tho I usually get lotsa other platforms for free,

> 
> 
> 
>>> The functionality of the OS, the user libraries, the
>>>hardware, etc. - none of it covered by the language standard.
>>
>>The above libraries are each their own standard. 
> 
> 
> Ad hoc, implementation defined standards.  Kind of pale beside your
> beloved 1000 page CL standard.

You are confused. I want to change Lisps and OSes painlessly, not 
image-processing or audio libraries.


> 
> 
> 
>>If I need to hit you 
>>over the head with a hammer: pick good such libraries that are nicely 
>>portable and consistent, drive them with a thousand-page language.
>>
>>
>>>Porting
>>>any significant, real world program requires a lot of work regardless
>>>of the language it's written in.
>>
>>Here you are right. The 24-48 hours need to change both operating system 
>>and Lisp implementation really make me grind my teeth. Of course most of 
>>the pain comes from having also to switch IDEs, because Franz does not 
>>seem to be as good at developing portable software as His Kennyness.
>>
>>And now something less ironic for the hard of thinking: "a lot of work"? 
>>PWUAHAHAHAHAHHAHAHAHAHHAA! I have also ported a pure C application 
>>between (direction forgotten) Symantec C++ and CodeWarrior C++, same OS, 
>>no libraries, and it was hell, living hell, for a solid week.
>>
>>
>>>It's also a fiction that all language implementations follow their
>>>standard exactly and that the bugs in the various implementations are
>>>portable.
>>
>>Oh, golly, if I had realized you had never even ported one line of Lisp 
>>between Lisp implementations I would not have been so hard on you. Of 
>>course you have no way of knowing you are spewing nonsense.
> 
> 
> Now you're just being nasty.  You don't have clue two what I have or
> haven't done.

Don't be silly, I have a tremendous clue: you said a problem with CL 
portability is that the implementations do not follow the standard 
exactly, so I know you have not been porting Lisp between CLs.

>  Insult me all you want, it might even raise my opinion
> of you.

I guess I was right... well, I might have been wrong. Maybe you have 
ported lots of Lisp between CLs and realized, Oh, sh*t, Kenny is right, 
it is amazingly easy. So you are right, I might be wrong about how you 
are wrong, there are two ways you could be clueless and I failed to 
consider the less likely or you never would have said anything so dumb 
in the first place.

kt
From: George Neuner
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <0b5fi3pkeucd68n3u387qr927gjg0jf1qc@4ax.com>
On Tue, 30 Oct 2007 12:23:37 -0400, Ken Tilton
<···········@optonline.net> wrote:

>>>George Neuner wrote:
>>>
>>>>Porting
>>>>any significant, real world program requires a lot of work regardless
>>>>of the language it's written in.
>>>
>>>>It's also a fiction that all language implementations follow their
>>>>standard exactly and that the bugs in the various implementations are
>>>>portable.
>>>
>>>Oh, golly, if I had realized you had never even ported one line of Lisp 
>>>between Lisp implementations I would not have been so hard on you. Of 
>>>course you have no way of knowing you are spewing nonsense.
>> 
>> Now you're just being nasty.  You don't have clue two what I have or
>> haven't done.
>
>Don't be silly, I have a tremendous clue: you said a problem with CL 
>portability is that the implementations do not follow the standard 
>exactly, so I know you have not been porting Lisp between CLs.

I see you're dyslexic.  Implementation issues are an inherent problem
of big standards: the more interacting specifications, the more likely
an implementation will screw up something and the less likely all
implementations will agree on what to screw up.  

>>  Insult me all you want, it might even raise my opinion
>> of you.
>
>I guess I was right... well, I might have been wrong. Maybe you have 
>ported lots of Lisp between CLs and realized, Oh, sh*t, Kenny is right, 
>it is amazingly easy. So you are right, I might be wrong about how you 
>are wrong, there are two ways you could be clueless and I failed to 
>consider the less likely or you never would have said anything so dumb 
>in the first place.
>
>kt

Now you got it.

George
--
for email reply remove "/" from address
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <XWMVi.1145$2T3.542@newsfe12.lga>
George Neuner wrote:
> On Tue, 30 Oct 2007 12:23:37 -0400, Ken Tilton
> <···········@optonline.net> wrote:
> 
> 
>>>>George Neuner wrote:
>>>>
>>>>
>>>>>Porting
>>>>>any significant, real world program requires a lot of work regardless
>>>>>of the language it's written in.
>>>>
>>>>>It's also a fiction that all language implementations follow their
>>>>>standard exactly and that the bugs in the various implementations are
>>>>>portable.
>>>>
>>>>Oh, golly, if I had realized you had never even ported one line of Lisp 
>>>>between Lisp implementations I would not have been so hard on you. Of 
>>>>course you have no way of knowing you are spewing nonsense.
>>>
>>>Now you're just being nasty.  You don't have clue two what I have or
>>>haven't done.
>>
>>Don't be silly, I have a tremendous clue: you said a problem with CL 
>>portability is that the implementations do not follow the standard 
>>exactly, so I know you have not been porting Lisp between CLs.
> 
> 
> I see you're dyslexic.  Implementation issues are an inherent problem
> of big standards: the more interacting specifications, the more likely
> an implementation will screw up something and the less likely all
> implementations will agree on what to screw up.  

I am sure all the Lisp vendors and maintainers are embarrassed by your 
praise, but I would caution them that you do not actually program in 
Lisp so you might not actually be complimenting them, you might be 
falling back in desperation on some /possible/ parallel universe in 
which the CL MegaSpec made conformance impossible and the damn thing 
never caught on.

Of course I could be wrong again, maybe you do program in Lisp and 
realize, Holy sh*t, kenny is right, my implementation always does match 
the CLHS, and instead are just parading a hobgoblin of a concern around 
to avoid admitting I am right.

Left as an exercise is determining now the possible number of 
combinations you have of being wrong in this thread.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193771489.005573.184250@y42g2000hsy.googlegroups.com>
On 30 out, 13:30, George Neuner <·········@/comcast.net> wrote:
> What makes you think C libs are portable?  I've had to rehost hundreds
> of thousands of lines of library code in my former life as an embedded
> systems programmer.  Damn few libraries are actually written to be
> portable.

all the libraries he listed are very much portable and able to run in
most hardware/OSes (at least the most popular anyway).

That's the power of open-source software:  the source is there and
there always will be someone eager to modify it and put it to run in
his favorite platform, even M$ Windows.

> >The above libraries are each their own standard.
>
> Ad hoc, implementation defined standards.  Kind of pale beside your
> beloved 1000 page CL standard.

I shall agree with that wholeheartidly.  He's proud of the huge old
tome but relying on  calling of external libs via a non-standard FFI
convention just like any Schemer could do themselves while restricting
themselves to a much nicer, more flexible and cruftless core language
defined in a small standard.

> Hey Kenny, when did you take up KaZOo?

that was mean, but I was actually wondering myself what that could
possibly mean... :)
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <kNMVi.1140$2T3.859@newsfe12.lga>
namekuseijin wrote:
> On 30 out, 13:30, George Neuner <·········@/comcast.net> wrote:
> 
>>What makes you think C libs are portable?  I've had to rehost hundreds
>>of thousands of lines of library code in my former life as an embedded
>>systems programmer.  Damn few libraries are actually written to be
>>portable.
> 
> 
> all the libraries he listed are very much portable and able to run in
> most hardware/OSes (at least the most popular anyway).
> 
> That's the power of open-source software:  the source is there and
> there always will be someone eager to modify it and put it to run in
> his favorite platform, even M$ Windows.
> 
> 
>>>The above libraries are each their own standard.
>>
>>Ad hoc, implementation defined standards.  Kind of pale beside your
>>beloved 1000 page CL standard.
> 
> 
> I shall agree with that wholeheartidly.  He's proud of the huge old
> tome but relying on  calling of external libs

You agree because you are just thinking in terms of debating and not 
making an intellectually honest attempt to keep in mind the issues at 
hand. I need to be OS independent to maximize my market and attract 
contributors to my o/s projects, and I need to be Lisp implementation 
independent to avoid getting locked into Franz royalties and also to 
attract o/s partners. An image lib being a one-implementation standard 
presents zero problems as you would realize if you thought about 
application development instead of how to look daft on Usenet.

btw, a good developer would not be bothered even by a decision to swap 
out GraphicsMagick for something else, because the deets of the lib 
would be wrapped in a low-level internal application API that would 
likely survive mostly intact any library change. That would not be the 
case only where the application relied massively on GM specifics, but 
then that application must be one intended to script GM, and a switch to 
something else then becomes Inconceivable.

> via a non-standard FFI
> convention 

If you have a bug report for CFFI, you should make it to the maintainers.


> that was mean, but I was actually wondering myself what that could
> possibly mean... :)
> 

Possibly that I am the third born son, hence Kenzo, hence kzo?

kxo left as an exercise.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Kamen TOMOV
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <u640n5z1n.fsf@cybuild.com>
On Tue, Oct 30 2007, Ken Tilton wrote:

> Irrelevant. Assiduously avoid the proprietary stuff. Use external C
> libs for that funtionality. 

Poor proprietors, what'd they have for dinner? Is Kenny switching not
only to Jaba, but also to open source?

I sense much fear among programmers, clouded their future is.

-- 
�����
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <tt%Vi.9$ZK6.5@newsfe10.lga>
Kamen TOMOV wrote:
> On Tue, Oct 30 2007, Ken Tilton wrote:
> 
> 
>>Irrelevant. Assiduously avoid the proprietary stuff. Use external C
>>libs for that funtionality. 
> 
> 
> Poor proprietors, what'd they have for dinner?

RMS fooled some of the people for all time, and all of the people for no 
time. They'll do fine dining on the little people who need support and 
are smart enough to pay for it, and geniuses like me who see the value 
in the proprietary tools and overall quality product.

> Is Kenny switching not
> only to Jaba, but also to open source?

Switching? Somebody gonna help this guy find my THREE FRICKIN CLNET 
PROJECTS?!!! I realize they are quite OLD!!!!!!!!!!!!!

> 
> I sense much fear among programmers, clouded their future is.
> 

Killfile time to resurrect I sense is it the.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Kamen TOMOV
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <usl3rjsgu.fsf@cybuild.com>
On Wed, Oct 31 2007, Ken Tilton wrote:

> Kamen TOMOV wrote:
>> On Tue, Oct 30 2007, Ken Tilton wrote:
>>
>>
>>>Irrelevant. Assiduously avoid the proprietary stuff. Use external C
>>> libs for that funtionality. 
>>
>>
>> Poor proprietors, what'd they have for dinner?
>
> RMS fooled some of the people for all time, and all of the people
> for no time. They'll do fine dining on the little people who need
> support and are smart enough to pay for it, and geniuses like me who
> see the value in the proprietary tools and overall quality product.

Does seeing their value mean avoiding them?

>> Is Kenny switching not only to Jaba, but also to open source?
>
> Switching? Somebody gonna help this guy find my THREE FRICKIN CLNET
> PROJECTS?!!! I realize they are quite OLD!!!!!!!!!!!!!

It's not about your projects (respect on them), but about you
switching from using the so called proprietrary software to using open
source. Not that I care, it is just related to your former remark.

>> I sense much fear among programmers, clouded their future is.
>>
>
> Killfile time to resurrect I sense is it the.

hahahaha

-- 
�����
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <qW0Wi.17$ZK6.13@newsfe10.lga>
Kamen TOMOV wrote:
> On Wed, Oct 31 2007, Ken Tilton wrote:
> 
> 
>>Kamen TOMOV wrote:
>>
>>>On Tue, Oct 30 2007, Ken Tilton wrote:
>>>
>>>
>>>
>>>>Irrelevant. Assiduously avoid the proprietary stuff. Use external C
>>>>libs for that funtionality. 
>>>
>>>
>>>Poor proprietors, what'd they have for dinner?
>>
>>RMS fooled some of the people for all time, and all of the people
>>for no time. They'll do fine dining on the little people who need
>>support and are smart enough to pay for it, and geniuses like me who
>>see the value in the proprietary tools and overall quality product.
> 
> 
> Does seeing their value mean avoiding them?

Silly wabbit, it means not getting locked in so I can leave so I can 
stay because they will cut me a better deal because I can leave oh why 
oh why do I even try with you people???

> 
> 
>>>Is Kenny switching not only to Jaba, but also to open source?
>>
>>Switching? Somebody gonna help this guy find my THREE FRICKIN CLNET
>>PROJECTS?!!! I realize they are quite OLD!!!!!!!!!!!!!
> 
> 
> It's not about your projects (respect on them), but about you
> switching from using the so called proprietrary software to using open
> source. Not that I care, it is just related to your former remark.

Switch, switch... you use that word so much, I do not think it means 
what you think it means. I /started/ Cello on Freeglut inter alia, 
switched to o/s Tcl/Tk when FrankG got the Togl thingy working for me.

And you seem still not to get the secret of blending proprietary and 
o/s, but I most certainly give up on ever explaining it.

kxo

-- 
http://www.theoryyalgebra.com/

"In the morning, hear the Way;
  in the evening, die content!"
                     -- Confucius
From: Klaus Schilling
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87bqaf2i3i.fsf@web.de>
Ken Tilton <···········@optonline.net> writes:
>
> RMS fooled some of the people for all time,

all humbug, Stallman doesn't fool people,
as opposed to demagogues like Gates.

> value in the proprietary tools and overall quality product.
>
there's  less than zero value in proprietary tools

        Klaus Schilling
From: Frank Goenninger DG1SBG
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <lzlk9neg7d.fsf@pcsde001.de.goenninger.net>
Klaus Schilling <···············@web.de> writes:

> Ken Tilton <···········@optonline.net> writes:
>>
>> Wow, I am really out on a limb there. It would be pretty easy to take
>> me down by naming a superior or even near equal environment.
> The GNU Emacs is vastly superior to any enviornment,
> as denied by fools only.
>
> Klaus Schilling

Hm - well, no. I have been using Emacs for more than 15 years for
professional (as in /earning money/) code writing and now Slime for
Lisp development for more than 4 years. I just recently switched to an
integrated IDE environment because of just one important feature I am
still missing in the Emacs/Slime combo: a STEPPER. Yes, I know I could
write an interface in Emacs or Slime or whatever to my Lisp
implementation's stepper but I want to write my application and not
built my tools first. True, this is only my opinion and experience but
I have been an Emacs defender myself for years so ... 

Just my 0.02 EUR. 

Frank

-- 

  Frank Goenninger

  frgo(at)mac(dot)com

  "Don't ask me! I haven't been reading comp.lang.lisp long enough to 
  really know ..."
From: Tobias C. Rittweiler
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <87ir4rv9y9.fsf@freebits.de>
Frank Goenninger DG1SBG <·············@nomail.org> writes:

> I just recently switched to an integrated IDE environment because of
> just one important feature I am still missing in the Emacs/Slime
> combo: a STEPPER. Yes, I know I could write an interface in Emacs or
> Slime or whatever to my Lisp implementation's stepper but I want to
> write my application and not built my tools first.

Actually Slime provides a stepper facility, with SBCL being the only
backend supporting it at the moment. Unfortunately, the number of people
understanding how to use it, is probably less than you could count up
with one hand. :-)

  -T. (Who doesn't know how to use it either.)
From: samantha
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193390460.435711.277750@e9g2000prf.googlegroups.com>
On Oct 23, 8:40 pm, Ken Tilton <···········@optonline.net> wrote:

> > 1) learning lisp
>
> Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
> for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".
>
> > 2) learning lisp in linux/emacs
>
> Take down the cage.

Learning lisp in a crippled baby version of a proprietary partially
locked down lisp on a totally locked down proprietary bloated OS
running on a seriously under powered cheap box is how you "take down
the cage"?  Really? Doesn't sound like a lot of fun to me.
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <BUkUi.724$2J.45@newsfe13.lga>
samantha wrote:
> On Oct 23, 8:40 pm, Ken Tilton <···········@optonline.net> wrote:
> 
> 
>>>1) learning lisp
>>
>>Delete CLisp, gcl, sbcl, cmucl, and Linux*. Buy a killer Vista laptop
>>for  $450. Use ACL free trial. To learn Lisp, not "Lisp in X".
>>
>>
>>>2) learning lisp in linux/emacs
>>
>>Take down the cage.
> 
> 
> Learning lisp in a crippled baby version of a proprietary partially
> locked down lisp...

You score majot points for disclosing up front that you know nothing 
about the free trials for LW and ACL.

> ...on a totally locked down proprietary bloated OS
> running on a seriously under powered cheap box...

Under-powered? For learning Lisp? Are you also trying to tell us you do 
not know what can be bought for $450? It would be easier to understand 
you if we took that stick out of your mouth, but we're afraid you'll 
bite your tongue off in this anti-commercial god forbid anyone make a 
buck what's wrong with food stamps to each according to big brother will 
decide frenzy of yours.

> is how you "take down
> the cage"?  Really? Doesn't sound like a lot of fun to me.
> 

Fun is the look on the faces of EMacs/Slimers watching me use the ACL 
IDE. What's that line about sufficiently advanced technology and magic?

I propose we Do the Right Thing, stop fighting each other, and storm the 
Franz offices and beat a $199 version of ACL with IDE for Max OS X out 
of them, AG and AC and other stuff extra. I think you'll be able to use 
your food stamps for a Lisp environment.

kxo

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: namekuseijin
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193422075.328429.11970@19g2000hsx.googlegroups.com>
On 26 out, 10:17, Ken Tilton <···········@optonline.net> wrote:
> Fun is the look on the faces of EMacs/Slimers watching me use the ACL
> IDE. What's that line about sufficiently advanced technology and magic?

now I understand why c.l.l is ridden with snotty, uninviting people
living in a time cage where Common Lisp is the supreme evolutionary
step of Lisp and is used only by highend enterprises who think open-
source software is for hippies...
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <WvsUi.252$Tw.165@newsfe14.lga>
namekuseijin wrote:
> On 26 out, 10:17, Ken Tilton <···········@optonline.net> wrote:
> 
>>Fun is the look on the faces of EMacs/Slimers watching me use the ACL
>>IDE. What's that line about sufficiently advanced technology and magic?
> 
> 
> now I understand why c.l.l is ridden with snotty, uninviting people
> living in a time cage where Common Lisp is the supreme evolutionary
> step of Lisp and is used only by highend enterprises who think open-
> source software is for hippies...
> 

Finally someone who makes sense!

kenny

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Frank Goenninger DG1SBG
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <lz640teqqn.fsf@de.goenninger.net>
Ken Tilton <···········@optonline.net> writes:

> I propose we Do the Right Thing, stop fighting each other, and storm
> the Franz offices and beat a $199 version of ACL with IDE for Max OS X
> out of them, AG and AC and other stuff extra. 

Right. I could use some help here - Franz as of yet only said "We're
considering it." I'd really really love to see such a version out Real
Soon Now!

Franz -  PLEASE!

Frank

-- 

  Frank Goenninger

  frgo(at)mac(dot)com

  "Don't ask me! I haven't been reading comp.lang.lisp long enough to 
  really know ..."
From: Ken Tilton
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <mLpUi.3725$gk2.490@newsfe24.lga>
Frank Goenninger DG1SBG wrote:
> Ken Tilton <···········@optonline.net> writes:
> 
> 
>>I propose we Do the Right Thing, stop fighting each other, and storm
>>the Franz offices and beat a $199 version of ACL with IDE for Max OS X
>>out of them, AG and AC and other stuff extra. 
> 
> 
> Right. I could use some help here - Franz as of yet only said "We're
> considering it." I'd really really love to see such a version out Real
> Soon Now!
> 

I imagine the plethora of options on the Mac is a bit of a damper on 
their enthusiasm, never mind the tiny share to begin with -- tho I must 
say Lisp conferences look like Apple Stores from a distance.

kt

-- 
http://www.theoryyalgebra.com/

"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
                                                   - Bob Uecker
From: Slobodan Blazeski
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193215302.057875.25700@q5g2000prf.googlegroups.com>
On Sep 23, 1:49 am, ·········@gmail.com" <········@gmail.com> wrote:
> I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:
>
> 1) learning lisp
> 2) learning lisp in linux/emacs
>
> Thanks!
> Lisp 9000


http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9d0080bd3be9ddea/
9e0ab129d28fb21b?lnk=st&q=shameless+#9e0ab129d28fb21b

Slobodan
From: ·······@eurogaran.com
Subject: Re: Learning Lisp in Linux?
Date: 
Message-ID: <1193988767.448060.55630@o80g2000hse.googlegroups.com>
On Sep 23, 12:49 am, ·········@gmail.com" <········@gmail.com> wrote:
> I want to learn Lisp in Linux. I have the ANSI Lisp book (hardcopy)
> and the Practical Common Lisp by Peter Seibel (free webpages I
> downloaded). I have CLISP, gcl, sbcl, and cmucl installed. I use emacs
> but have never used SLIME or ilisp before (the ilisp package is
> currently broken in Debian testing release). Any tips on getting
> started:

If you have a Linux/Unix background and can understand spanish,
try http://www.eurogaran.com/downloads/lisp/lisp-pretutorial-es.txt