From: Klaus Schilling
Subject: Re: Lisp is a Write-Only like Perl or Forth
Date:
Message-ID: <87hck9si3n.fsf@web.de>
Pillsy <·········@gmail.com> writes:
>
> Not at all. It's just Scheme. I think CL is generally a little more
> readable than Scheme,
only if one refrains from foolish junk like LOOP
and similar humbug can CL be made more readable than scheme
Klaus Schilling
Klaus Schilling wrote:
> Pillsy <·········@gmail.com> writes:
>> Not at all. It's just Scheme. I think CL is generally a little more
>> readable than Scheme,
>
> only if one refrains from foolish junk like LOOP
> and similar humbug can CL be made more readable than scheme
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/
On 30 out, 06:57, Pascal Costanza <····@p-cos.net> wrote:
> Klaus Schilling wrote:
> > only if one refrains from foolish junk like LOOP
> > and similar humbug can CL be made more readable than scheme
>
> 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.
namekuseijin <············@gmail.com> writes:
> On 30 out, 06:57, Pascal Costanza <····@p-cos.net> wrote:
>> Klaus Schilling wrote:
>> > only if one refrains from foolish junk like LOOP
>> > and similar humbug can CL be made more readable than scheme
>>
>> 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.
Man, don't you just waste bandwidth like hell. Why post the same stuff
in two threads of the same NG? And no, I'm not interested in getting
an answer to this.
--
Frank Goenninger
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On 2007-10-30 09:20:55 -0400, namekuseijin <············@gmail.com> said:
> don't fast forward at all and you'll see it's actually criticizing the
> loose and vague loop facility in CL.
Not exactly. He says that CL loop is useful, and common lispers get
real benefit from it. He says that he thinks the scope semantics of it
need to be more rigorously defined.
Finally, and most importantly in-re Pascal's post, he says that
tail-recursive scheme style loops are a poor choice becuase of their
lack of modularity, and the need to explictily state the various
bindings to be updated in the right order at the end of the loop.
On 30 out, 21:37, Raffael Cavallaro
> tail-recursive scheme style loops are a poor choice becuase of their
> lack of modularity,
lack of modularity in function definitions?!
> and the need to explictily state the various
> bindings to be updated in the right order at the end of the loop.
that's a function call. It sure needs that you pass the right
arguments in the right order.
On 4 Nov, 13:44, namekuseijin <············@gmail.com> wrote:
> On 30 out, 21:37, Raffael Cavallaro
>
> > tail-recursive scheme style loops are a poor choice becuase of their
> > lack of modularity,
>
> lack of modularity in function definitions?!
Yup. You're confusing what you want to do with how you want to do it,
and this means that every time you want to do something a little
different you have to write out how you're going to do it again.
I know you think you're arguing against the evils of imperative
coding, but you're not. All the simple looping macros in CL dotimes,
dolist, they're just syntactic sugar for higher order functions. Take
dotimes, if we define:
{defun dotimes-helper(fn current limit)
(unless (= current limit)
(funcall fn current)
(dotimes-helper fn (1+ current) limit)))
then (dotimes (x lim) code) can be seen as just shorthand for:
(dotimes-helper (lambda(x)code) 0 lim)
The more complicated macros like loop and do are just a short way to
express lexical binding and call a HoF, and HoFs are always going to
be a better, more modular, choice than implementing the same looping
construct by hand every time you want to walk over an array or a list.
On 4 nov, 14:13, Chris Russell <·····················@gmail.com>
wrote:
> Yup. You're confusing what you want to do with how you want to do it,
I'm not confused about it: the exact purpose of functional
programming is putting you into thinking about *what* rather than
*how*.
> I know you think you're arguing against the evils of imperative
> coding, but you're not. All the simple looping macros in CL dotimes,
> dolist, they're just syntactic sugar for higher order functions.
I know that. And Scheme has "do". And the more general named let.
But once you start using those, there you are, back into imperative
thinking-mode again, having to mentally sorting out the details of
when the bindings take effect etc.
> The more complicated macros like loop and do are just a short way to
> express lexical binding and call a HoF, and HoFs are always going to
> be a better, more modular, choice than implementing the same looping
> construct by hand every time you want to walk over an array or a list.
no, they are just as modular (since they are the same), but perhaps
more convenient.
On 4 Nov, 16:32, namekuseijin <············@gmail.com> wrote:
> On 4 nov, 14:13, Chris Russell <·····················@gmail.com>
> wrote:
>
> > Yup. You're confusing what you want to do with how you want to do it,
>
> I'm not confused about it: the exact purpose of functional
> programming is putting you into thinking about *what* rather than
> *how*.
Well if that's true, performing an explicit recursive descent down a
list means you are failing to think functionally.
> > The more complicated macros like loop and do are just a short way to
> > express lexical binding and call a HoF, and HoFs are always going to
> > be a better, more modular, choice than implementing the same looping
> > construct by hand every time you want to walk over an array or a list.
>
> no, they are just as modular (since they are the same), but perhaps
> more convenient.
Of course not.
Write a function that walks down a list and creates another list which
has 1+ the value of each item on it.
Using HoFs you get:
(defun 1+list (list)
(mapcar (lambda(x)(1+ x)) list))
Using recursion you get this:
(defun 1+list (list &optional acc)
(if list (1+list (rest list) (cons (1+(first list)) acc))
(nreverse acc)))
Now in the first one, as what you want to do is decoupled from how you
want to do it, you can easily edit the function so that it produces a
list from any sequence.
(defun 1+list (list)
(map 'list (lambda(x)(1+ x)) list))
or a vector from any sequence.
(defun 1+list (list)
(map 'vector (lambda(x)(1+ x)) list))
You just can't do this with the recursive example, where what you want
to do is explicitly intertwined with what you expect the data
structure to be.
This decoupling of code and data structure makes the use of HoFs and
loops much more modular than explicit recursion.
On 4 nov, 15:24, Chris Russell <·····················@gmail.com>
wrote:
> On 4 Nov, 16:32, namekuseijin <············@gmail.com> wrote:> On 4 nov, 14:13, Chris Russell <·····················@gmail.com>
> > I'm not confused about it: the exact purpose of functional
> > programming is putting you into thinking about *what* rather than
> > *how*.
>
> Well if that's true, performing an explicit recursive descent down a
> list means you are failing to think functionally.
recursion is a consequence of stating *what* you want, that is, the
values you want at each step. It helps you think declaratively.
> Using HoFs you get:
> (defun 1+list (list)
> (mapcar (lambda(x)(1+ x)) list))
>
> Using recursion you get this:
> (defun 1+list (list &optional acc)
> (if list (1+list (rest list) (cons (1+(first list)) acc))
> (nreverse acc)))
>
> Now in the first one, as what you want to do is decoupled from how you
> want to do it, you can easily edit the function so that it produces a
> You just can't do this with the recursive example, where what you want
> to do is explicitly intertwined with what you expect the data
> structure to be.
>
> This decoupling of code and data structure makes the use of HoFs and
> loops much more modular than explicit recursion.
Funny your example uses a general-purpose recursively-defined HoF. Of
course reusing general-purpose code will always make things smaller
and convenient. I'm greateful, though, that you didn't go the loop
way...
The problem of "decoupling" in your example is not so much about
decoupling as it is about, again, convenience. Reusing code should be
the goal of every programmer and things like HoFs and recursion make
it much easier (as well as dynamic typing). Don't misunderstand me:
I use as much fold, map, filter and others as I do single-shot
recursive loops for specific, non-general functions...
and BTW, I find it odd that one should need to explicitely feed the
type of the sequence for CL's map function, a dynamic language! It
exposes a huge flaw in Lisp languages: despite all CL's name slots or
whatever, no true overloading for function names means that, yes,
there should be some editing in your recursive example just to rename
certain parts to other similar functions for either list or vector.
In modern statically-typed functional languages, thanks to function
overloading, pattern matching and polymorphic types, functions like
those are really, really generic. Thus, recursive definitions work
like in heaven. sorry if I sound froggy.
Context: Lisp's higher-order functions such as map, and their
dependence on the structure of what is being mapped over.
namekuseijin wrote:
> In modern statically-typed functional languages, thanks to function
> overloading, pattern matching and polymorphic types, functions like
> those are really, really generic. Thus, recursive definitions work
> like in heaven. sorry if I sound froggy.
Knee-jerk thoughts:
1) Lisp's map and friends could have been defined using CLOS generic
functions; this would have achieved true polymorphism at the possible
cost of reduced speed. Likewise typep could have been used to index
into a list of known types. Probably the correct fix would be for map
and friends to themselves be defined as generic functions so users can
customize them for different structures. But this doesn't really
buy much (see #3 below).
2) Statically typed languages (e.g. caml, C++) generally achieve their
"polymorphism" by doing compile-time analysis to generate different
code depending on what type is being mapped. It looks polymorphic to
the user (a good thing), but its really just selecting between
different type-specific backends (not necessarily bad). In Lisp, its
roughly the difference between map being a function or a macro (#3).
3) Map isn't useful outside of certain predefined patterns; where it
really matters, loop and related macros already provide a standard
interface with greatly enhanced flexibility. For example, how would
you extend map to collect the results into an arbitrary container?
Alternatively, how could (map #'f a b) be extended to take two entries
from the A for each entry from B, so we can call (f A1 A2 B) or (f A1
B A2)?
Conclusion: these static recursive functions aren't functions at all;
they're macros (in Lisp terminology).
- Daniel
On 4 nov, 23:59, D Herring <········@at.tentpost.dot.com> wrote:
> 2) Statically typed languages (e.g. caml, C++) generally achieve their
> "polymorphism" by doing compile-time analysis to generate different
> code depending on what type is being mapped. It looks polymorphic to
> the user (a good thing), but its really just selecting between
> different type-specific backends (not necessarily bad).
yes, and the point is?... of course there's some low-level dispatch
somewhere. The good thing here is that this low-level dispatch is
chosen before runtime and performance is saved.
besides, no macros won't work: you can't pass macros (not macro
calls) as arguments to HoFs...
namekuseijin wrote:
> On 4 nov, 23:59, D Herring <········@at.tentpost.dot.com> wrote:
>> 2) Statically typed languages (e.g. caml, C++) generally achieve their
>> "polymorphism" by doing compile-time analysis to generate different
>> code depending on what type is being mapped. It looks polymorphic to
>> the user (a good thing), but its really just selecting between
>> different type-specific backends (not necessarily bad).
>
> yes, and the point is?... of course there's some low-level dispatch
> somewhere. The good thing here is that this low-level dispatch is
> chosen before runtime and performance is saved.
The point? Lisp lets one *modify running systems*. Compile-time
dispatch will require a recompile whenever something changes. A truly
polymorphic (e.g. CLOS) call would get the update automatically. Lisp
lets one change things after "runtime" begins; this leads to stronger
restrictions on what optimizations a "polymorphic function" can make.
> besides, no macros won't work: you can't pass macros (not macro
> calls) as arguments to HoFs...
Why not? Macros can expand other macros... You just have to keep all
the macroexpansion (a ~ compile-time thing) in front of the actual
functions (which only evaluate their arguments at runtime). Think
"higher-order macro" instead of merely "higher-order function" (which
in static languages are really macros).
- Daniel
On 5 nov, 05:10, D Herring <········@at.tentpost.dot.com> wrote:
> The point? Lisp lets one *modify running systems*. Compile-time
> dispatch will require a recompile whenever something changes. A truly
> polymorphic (e.g. CLOS) call would get the update automatically. Lisp
> lets one change things after "runtime" begins; this leads to stronger
> restrictions on what optimizations a "polymorphic function" can make.
>
> > besides, no macros won't work: you can't pass macros (not macro
> > calls) as arguments to HoFs...
>
> Why not? Macros can expand other macros... You just have to keep all
> the macroexpansion (a ~ compile-time thing) in front of the actual
> functions (which only evaluate their arguments at runtime). Think
> "higher-order macro" instead of merely "higher-order function" (which
> in static languages are really macros).
ok, points taken.
On 5 Nov, 01:21, namekuseijin <············@gmail.com> wrote:
> Funny your example uses a general-purpose recursively-defined HoF. Of
> course reusing general-purpose code will always make things smaller
> and convenient. I'm greateful, though, that you didn't go the loop
> way...
There's no need for any of the map functions to be defined
recursively.
Also, as you said the examples would work equally well, if I were
switching between dotimes and dolist, and changing from working with
the first n numbers to an arbitrary sequence, simply by altering 4
letters of the code.
> The problem of "decoupling" in your example is not so much about
> decoupling as it is about, again, convenience. Reusing code should be
> the goal of every programmer and things like HoFs and recursion make
> it much easier (as well as dynamic typing). Don't misunderstand me:
> I use as much fold, map, filter and others as I do single-shot
> recursive loops for specific, non-general functions...
>
Code reuse is nice, but if that's all you want you could get the same
effect just by cutting and pasting.
The point of the examples is not that that they are short but that
it's easy to alter the program to fit with your changing requirements,
without touching the majority of the code.
> and BTW, I find it odd that one should need to explicitely feed the
> type of the sequence for CL's map function, a dynamic language! It
> exposes a huge flaw in Lisp languages: despite all CL's name slots or
> whatever, no true overloading for function names means that, yes,
> there should be some editing in your recursive example just to rename
> certain parts to other similar functions for either list or vector.
You don't specify the input type of sequence with map. You specify the
output type, which is a requirement both in dynamic languages and in
DWIM languages that rely on implicit typing.
I'd love to see this language that lets you write a simple recursive
function that ignores the difference between a list and a vector. Does
it try to resize the vector on every iteration, or take O(n^2) to
traverse a list?
On 5 nov, 00:13, Chris Russell <·····················@gmail.com>
wrote:
> There's no need for any of the map functions to be defined
> recursively.
unless if functions is all you got.
> Code reuse is nice, but if that's all you want you could get the same
> effect just by cutting and pasting.
yes, with double the effort.
> The point of the examples is not that that they are short but that
> it's easy to alter the program to fit with your changing requirements,
> without touching the majority of the code.
yes, like I said, general-purpose code has that effect.
> You don't specify the input type of sequence with map. You specify the
> output type, which is a requirement both in dynamic languages and in
> DWIM languages that rely on implicit typing.
hmm, didn't know about that. the only map I knew from CL so far was
the old mapcar
> I'd love to see this language that lets you write a simple recursive
> function that ignores the difference between a list and a vector. Does
> it try to resize the vector on every iteration, or take O(n^2) to
> traverse a list?
they are both sequences with their particular iterators (which in some
cases can happen to share the same name). Not terribly difficult to
imagine, but I'm gonna have my rest now... bye.
On 5 Nov, 04:55, namekuseijin <············@gmail.com> wrote:
> On 5 nov, 00:13, Chris Russell <·····················@gmail.com>
> > The point of the examples is not that that they are short but that
> > it's easy to alter the program to fit with your changing requirements,
> > without touching the majority of the code.
>
> yes, like I said, general-purpose code has that effect.
So you agree that the general-purpose code is more modular then?
> > I'd love to see this language that lets you write a simple recursive
> > function that ignores the difference between a list and a vector. Does
> > it try to resize the vector on every iteration, or take O(n^2) to
> > traverse a list?
That works, but its bizarre that you worry about getting stuck in
"imperative thinking-mode" and recommend using iterators at the same
time.
On 6 nov, 00:21, Chris Russell <·····················@gmail.com>
wrote:
> So you agree that the general-purpose code is more modular then?
relutantly, yes. :P
> That works, but its bizarre that you worry about getting stuck in
> "imperative thinking-mode" and recommend using iterators at the same
> time.
Every complex data structure begs for an iterator. It's not like you
can't iterate over them in a functional manner: you just need to
provide the previous iteration to the iterator.
namekuseijin wrote:
> On 30 out, 06:57, Pascal Costanza <····@p-cos.net> wrote:
>
>>Klaus Schilling wrote:
>>
>>>only if one refrains from foolish junk like LOOP
>>>and similar humbug can CL be made more readable than scheme
>>
>>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 ...
Hear a nice tribute to the guy for whom they threw the DanFest, and
nothing at all that would support...
> ...see it's actually criticizing the
> loose and vague loop facility in CL.
>
No, he says loop works great for CL programmers, but that Scheme has
this other aesthetic about theoretical soundness and that it is really
hard even to produce a loop package that satisfies that aesthetic.
Actually, there might be something suitable in there for the Scheme
tombstone.
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: Holger Schauer
Subject: Re: Lisp is a Write-Only like Perl or Forth
Date:
Message-ID: <yxzwst36m7b.fsf@gmx.de>
On 5171 September 1993, Klaus Schilling wrote:
> Pillsy <·········@gmail.com> writes:
>> Not at all. It's just Scheme. I think CL is generally a little more
>> readable than Scheme,
> only if one refrains from foolish junk like LOOP
> and similar humbug can CL be made more readable than scheme
Hey Glaus, I thought you've gone lost. Well, obviously the trolls have
moved on from the linux groups to the lisp groups, but at least you're
still consistent -- IIRC, your Guile faible was already your most
prominent topic when haunting the German linux groups several years
ago. How comes Guile still hasn't made both Perl (his favorite target
then) and CL irrelevant?
Holger, (gnus-summary-lower-score -1000)
Fup2: poster
--
--- http://hillview.bugwriter.net/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
51: Version x.5
Mit neuen Icons! (Kristian K�hntopp)