i'm starting a yahoo group for learning python. Each day, a tip of
python will be shown, with the perl equivalent. For those of you
perlers who always wanted to learn python, this is suitable. (i started
it because i always wanted to switch to python but too lazy and always
falling back to a lang i am an expert at, but frustrated constantly by
its inanities and incompetences.)
to subscribe, go to:
http://groups.yahoo.com/group/perl-python/
i'll cross post to comp.lang.perl.misc and comp.lang.python.
If you spot mistakes, feel free to correct or discourse here.
if you are a perl expert and wanted to learn python, i believe after a
month of this list we'll be python experts. This serves us as a means
to cross the Rubicon.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Xah Lee wrote:
> if you are a perl expert and wanted to learn python, i believe after a
> month of this list we'll be python experts. This serves us as a means
> to cross the Rubicon.
Bad news. That is not the Rubicon. That is the Mississippi* into which
you are about to wade.
kt
* The Mississippi twists and meanders so much that you can cross it and
end up on the same side.
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Dear Kenny,
if you are so interested, i wonder if you'd enjoy writing a follow up
daily on how it is done in a lisp?
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Xah Lee wrote:
> Dear Kenny,
>
> if you are so interested, i wonder if you'd enjoy writing a follow up
> daily on how it is done in a lisp?
Thank you for welcoming Lisp entries into your journal.
<duck> Unfortunately, I do not know Perl or Python so it would be more
than a little work for me and I am quite busy actually programming in
Lisp these days. <\duck> But!
I will assign one of the many Lisp rug-rats crawling all over c.l.l. to
this task, as a great way for them to transition from Perl (some of them
must know Perl) to Common Lisp. (Since your content will likewise be
sorted appropriately for a transition from Perl to Python.) Let's see...
...you! Over there! You know Perl. Do the Lisp versions for this:
http://groups.yahoo.com/group/perl-python/
Note to Xah: work on your blanket marketing skills. I had to scroll back
a few messages because your reply to me did not include:
http://groups.yahoo.com/group/perl-python/
I ended up at your Web page. Nice new pix!
http://xahlee.org/PageTwo_dir/Personal_dir/mi_pixra.html
It is a pleasure having a face to associate with The Great Xah. But I
was looking for:
http://groups.yahoo.com/group/perl-python/
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
(message (Hello 'Kenny)
(you :wrote :on '(Tue, 11 Jan 2005 23:31:57 GMT))
(
KT> ...you! Over there! You know Perl. Do the Lisp versions for this:
KT> http://groups.yahoo.com/group/perl-python/
i want cpp-clisp and clisp-scheme!
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "People, who lust for the Feel of keys on their fingertips (c)
Inity"))
Kenny Tilton wrote:
> [ ... ]
>
> I will assign one of the many Lisp rug-rats crawling all over c.l.l. to
> this task, as a great way for them to transition from Perl (some of them
> must know Perl) to Common Lisp. (Since your content will likewise be
> sorted appropriately for a transition from Perl to Python.) Let's see...
>
> ...you! Over there! You know Perl. Do the Lisp versions for this:
>
> http://groups.yahoo.com/group/perl-python/
Sir, Yes Sir!
I tried to post at yahoo groups, but for some reason it does not want to
work (database errors). so, here is the common lisp version of the
latest posting :
http://groups.yahoo.com/group/perl-python/message/4
Please feel free to tear it apart, optimize it to hell, suggest i choose
another language etc.
--- Re: 20050110: string join, extract, length ---
Here is the examples in common lisp. I do plan to do some more, and then
compile a "moving from perl/python to common lisp" document, as
everybody seems to be doing this lately.
;;; Strings (and infact all sequences) are concatenated using CONCATENATE.
CL-USER> (defparameter a-string (concatenate 'string "this" " that"))
A-STRING
CL-USER> a-string
"this that"
;;; If you were going to do a lot of string concatenation you'd
probably want a quick macro, if only to make things a terse as in the
other languages (if you're into that kind of thing)
CL-USER> (defmacro str+ (&body body)
`(concatenate 'string ,@body))
STR+
CL-USER> (str+ a-string "and the other thing")
"this that and the other thing"
;;; as for the mulitplication of strings (is this taking polymorphism a
little far?) Common Lisp offers nothing quite like it (that i know
about), but it's not hard to write.
;;; my first instinct was to use recursion, so i tossed together a quick
one:
CL-USER> (defun str*-recursive (count string)
(when (> count 0)
(setf string
(str+ string (str*-recursive (decf count) string)))))
STR*-RECURSIVE
CL-USER> (str*-recursive 5 a-string)
"this thatthis thatthis thatthis thatthis that"
;;; however, it's not tail recursive, so we run out of stack space
quickly. if you are only planning to multiply a string a few times, this
is fine. I could make it tail-recursive, but Tail call elimination may
not me implemented in all Common Lisp environments. Using a loop is
probably better.
CL-USER> (defun str*-loop (count string &aux (acc ""))
(loop repeat count
do (setf acc
(str+ acc string))
finally (return acc)))
STR*-LOOP
CL-USER> (str*-loop 5 a-string)
"this thatthis thatthis thatthis thatthis that"
;;; finally, sebseq is used to get substrings (and can be used with all
sequences)
CL-USER> (subseq a-string 3 6)
"s t"
;;; it doesn't do the negative end bit like python/perl , but it's
trivial to come up with a perl style subseq :
CL-USER> (defun psubseq (string offset &optional (end nil))
(subseq string offset
(if (and (integerp end)(> 0 end))
(+ end (length string))
end)))
PSUBSEQ
CL-USER> (psubseq a-string 3 -2)
"s th"
;;; and the length of a string (sequence) is discovered using the LENGTH
function (go figure).
CL-USER> (length a-string)
9
------------------------------
more to come when/if i get the time.
drewc
drewc wrote:
> Kenny Tilton wrote:
>
>> [ ... ]
>>
>> I will assign one of the many Lisp rug-rats crawling all over c.l.l.
>> to this task, as a great way for them to transition from Perl (some of
>> them must know Perl) to Common Lisp. (Since your content will likewise
>> be sorted appropriately for a transition from Perl to Python.) Let's
>> see...
>>
>> ...you! Over there! You know Perl. Do the Lisp versions for this:
>>
>> http://groups.yahoo.com/group/perl-python/
>
>
> Sir, Yes Sir!
At ease, soldier.
>
> I tried to post at yahoo groups, but for some reason it does not want to
> work (database errors).
Xah, know anything on this?
>... so, here is the common lisp version of the
> latest posting :
>
> http://groups.yahoo.com/group/perl-python/message/4
>
> Please feel free to tear it apart, optimize it to hell, suggest i choose
> another language etc.
>
> --- Re: 20050110: string join, extract, length ---
>
> Here is the examples in common lisp. I do plan to do some more, and then
> compile a "moving from perl/python to common lisp" document, as
> everybody seems to be doing this lately.
>
> ;;; Strings (and infact all sequences) are concatenated using CONCATENATE.
>
> CL-USER> (defparameter a-string (concatenate 'string "this" " that"))
> A-STRING
> CL-USER> a-string
> "this that"
>
> ;;; If you were going to do a lot of string concatenation you'd
> probably want a quick macro, if only to make things a terse as in the
> other languages (if you're into that kind of thing)
>
> CL-USER> (defmacro str+ (&body body)
> `(concatenate 'string ,@body))
<tearapart>why is this a macro instead of a function?<\tearapart>
> STR+
> CL-USER> (str+ a-string "and the other thing")
> "this that and the other thing"
>
> ;;; as for the mulitplication of strings (is this taking polymorphism a
> little far?) Common Lisp offers nothing quite like it (that i know
> about), but it's not hard to write.
>
> ;;; my first instinct was to use recursion, so i tossed together a quick
> one:
>
> CL-USER> (defun str*-recursive (count string)
> (when (> count 0)
> (setf string
> (str+ string (str*-recursive (decf count) string)))))
> STR*-RECURSIVE
>
> CL-USER> (str*-recursive 5 a-string)
> "this thatthis thatthis thatthis thatthis that"
>
> ;;; however, it's not tail recursive, so we run out of stack space
> quickly. if you are only planning to multiply a string a few times, this
> is fine. I could make it tail-recursive, but Tail call elimination may
> not me implemented in all Common Lisp environments. Using a loop is
> probably better.
>
> CL-USER> (defun str*-loop (count string &aux (acc ""))
> (loop repeat count
> do (setf acc
> (str+ acc string))
> finally (return acc)))
> STR*-LOOP
>
> CL-USER> (str*-loop 5 a-string)
> "this thatthis thatthis thatthis thatthis that"
>
> ;;; finally, sebseq is used to get substrings (and can be used with all
> sequences)
>
> CL-USER> (subseq a-string 3 6)
> "s t"
>
> ;;; it doesn't do the negative end bit like python/perl , but it's
> trivial to come up with a perl style subseq :
>
> CL-USER> (defun psubseq (string offset &optional (end nil))
> (subseq string offset
> (if (and (integerp end)(> 0 end))
> (+ end (length string))
> end)))
> PSUBSEQ
>
> CL-USER> (psubseq a-string 3 -2)
> "s th"
>
> ;;; and the length of a string (sequence) is discovered using the LENGTH
> function (go figure).
>
> CL-USER> (length a-string)
> 9
>
>
> ------------------------------
>
> more to come when/if i get the time.
well done, trooper. smoke 'em if you got 'em.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> drewc wrote:
>
[ ... ]
>>
>> ;;; If you were going to do a lot of string concatenation you'd
>> probably want a quick macro, if only to make things a terse as in the
>> other languages (if you're into that kind of thing)
>>
>> CL-USER> (defmacro str+ (&body body)
>> `(concatenate 'string ,@body))
>
>
> <tearapart>why is this a macro instead of a function?<\tearapart>
Because i couldn't figure out how to do it as a function really (i'm
knee deep in SQL today, and we all know how slow context switches can be).
i tried (defun str+ (&rest rest) ...
but here i got lost. REST is list, and i need to flatten it as
CONCATENATE needs strings as arguments. Can you enlighten me on how to
do this and still be as efficient as the macro?
>
>
> well done, trooper. smoke 'em if you got 'em.
Sir.... Yes Sir!
right after i finish this query.
drewc
>
> kt
>
On Wed, 12 Jan 2005 09:10:29 GMT, drewc <·····@rift.com> wrote:
> i tried (defun str+ (&rest rest) ...
>
> but here i got lost. REST is list, and i need to flatten it as
> CONCATENATE needs strings as arguments. Can you enlighten me on how
> to do this and still be as efficient as the macro?
Look up APPLY in the ANSI standard.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 12 Jan 2005 09:10:29 GMT, drewc <·····@rift.com> wrote:
>
>
>>i tried (defun str+ (&rest rest) ...
>>
>>but here i got lost. REST is list, and i need to flatten it as
>>CONCATENATE needs strings as arguments. Can you enlighten me on how
>>to do this and still be as efficient as the macro?
>
>
> Look up APPLY in the ANSI standard.
>
(defun str+ (&rest rest)
(apply #'concatenate 'string rest))
Thanks... there is a lot of places where that is going to come in handy.
much better than the macro!
drewc
> Edi.
>
drewc <·····@rift.com> wrote:
+---------------
| > Look up APPLY in the ANSI standard.
|
| (defun str+ (&rest rest)
| (apply #'concatenate 'string rest))
|
| Thanks... there is a lot of places where that is
| going to come in handy. much better than the macro!
+---------------
But beware of CALL-ARGUMENTS-LIMIT and/or LAMBDA-PARAMETERS-LIMIT...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
drewc wrote:
> Kenny Tilton wrote:
>
>>
>>
>> drewc wrote:
>>
>
> [ ... ]
>
>>>
>>> ;;; If you were going to do a lot of string concatenation you'd
>>> probably want a quick macro, if only to make things a terse as in the
>>> other languages (if you're into that kind of thing)
>>>
>>> CL-USER> (defmacro str+ (&body body)
>>> `(concatenate 'string ,@body))
>>
>>
>>
>> <tearapart>why is this a macro instead of a function?<\tearapart>
>
>
> Because i couldn't figure out how to do it as a function really (i'm
> knee deep in SQL today, and we all know how slow context switches can be).
>
> i tried (defun str+ (&rest rest) ...
>
> but here i got lost. REST is list, and i need to flatten it as
> CONCATENATE needs strings as arguments. Can you enlighten me on how to
> do this and still be as efficient as the macro?
Edi has already pointed out APPLY. Two things, tho.
(1) You said "as efficient as the macro". Are you worried about the list
created to hold the &rest arg happening at runtime instead of compile time?
(2) I just noticed you used &body in the macro version. Use &body to
bind code, &rest for an expected list of other things. &body is just a
hint to pretty-printers, which will arrange code differently than a list
of anything else (ie, yeah, code is a list, too).
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> drewc wrote:
>
>> Kenny Tilton wrote:
>>
>>>
>>>
>>> drewc wrote:
>>>
>>
>> [ ... ]
>>
>>>>
>>>> ;;; If you were going to do a lot of string concatenation you'd
>>>> probably want a quick macro, if only to make things a terse as in
>>>> the other languages (if you're into that kind of thing)
>>>>
>>>> CL-USER> (defmacro str+ (&body body)
>>>> `(concatenate 'string ,@body))
>>>
>>>
>>>
>>>
>>> <tearapart>why is this a macro instead of a function?<\tearapart>
>>
>>
>>
>> Because i couldn't figure out how to do it as a function really (i'm
>> knee deep in SQL today, and we all know how slow context switches can
>> be).
>>
>> i tried (defun str+ (&rest rest) ...
>>
>> but here i got lost. REST is list, and i need to flatten it as
>> CONCATENATE needs strings as arguments. Can you enlighten me on how to
>> do this and still be as efficient as the macro?
>
>
> Edi has already pointed out APPLY. Two things, tho.
>
> (1) You said "as efficient as the macro". Are you worried about the list
> created to hold the &rest arg happening at runtime instead of compile time?
I didn't know about APPLY, so any solution i had would CONS a bit. Since
i wanted to use str+ to implement str*, I wanted to avoid that.
>
> (2) I just noticed you used &body in the macro version. Use &body to
> bind code, &rest for an expected list of other things. &body is just a
> hint to pretty-printers, which will arrange code differently than a list
> of anything else (ie, yeah, code is a list, too).
Hrm. I've always used &body in macros, just because it always seemed for
clear to me that i want the 'body' of the macro, not the 'rest' of the
arguments. probably a bad habit I picked up somewhere. Are there any
other reasons, besides the pretty printer, why one would choose &body
over &rest?
drewc
>
> kt
>
drewc wrote:
> Kenny Tilton wrote:
>
>>
>>
>> drewc wrote:
>>
>>> Kenny Tilton wrote:
>>>
>>>>
>>>>
>>>> drewc wrote:
>>>>
>>>
>>> [ ... ]
>>>
>>>>>
>>>>> ;;; If you were going to do a lot of string concatenation you'd
>>>>> probably want a quick macro, if only to make things a terse as in
>>>>> the other languages (if you're into that kind of thing)
>>>>>
>>>>> CL-USER> (defmacro str+ (&body body)
>>>>> `(concatenate 'string ,@body))
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> <tearapart>why is this a macro instead of a function?<\tearapart>
>>>
>>>
>>>
>>>
>>> Because i couldn't figure out how to do it as a function really (i'm
>>> knee deep in SQL today, and we all know how slow context switches can
>>> be).
>>>
>>> i tried (defun str+ (&rest rest) ...
>>>
>>> but here i got lost. REST is list, and i need to flatten it as
>>> CONCATENATE needs strings as arguments. Can you enlighten me on how
>>> to do this and still be as efficient as the macro?
>>
>>
>>
>> Edi has already pointed out APPLY. Two things, tho.
>>
>> (1) You said "as efficient as the macro". Are you worried about the
>> list created to hold the &rest arg happening at runtime instead of
>> compile time?
>
>
> I didn't know about APPLY, so any solution i had would CONS a bit. Since
> i wanted to use str+ to implement str*, I wanted to avoid that.
>
>>
>> (2) I just noticed you used &body in the macro version. Use &body to
>> bind code, &rest for an expected list of other things. &body is just a
>> hint to pretty-printers, which will arrange code differently than a
>> list of anything else (ie, yeah, code is a list, too).
>
>
> Hrm. I've always used &body in macros, just because it always seemed for
> clear to me that i want the 'body' of the macro, not the 'rest' of the
> arguments. probably a bad habit I picked up somewhere. Are there any
> other reasons, besides the pretty printer, why one would choose &body
> over &rest?
clhs 3.4.4: "&body is identical in function to &rest, but it can be used
to inform certain output-formatting and editing functions that the
remainder of the form is treated as a body, and should be indented
accordingly."
As for not wanting to use &rest when /all/ arguments are being
collected, well, good to see someone taking names seriously. <g>
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> drewc wrote:
>
>> Kenny Tilton wrote:
>>
>>>
>>>
>>> drewc wrote:
>>>
>>>> Kenny Tilton wrote:
>>>>
>>>>>
>>>>>
>>>>> drewc wrote:
>>>>>
>>>>
>>>> [ ... ]
>>>>
>>>>>>
>>>>>> ;;; If you were going to do a lot of string concatenation you'd
>>>>>> probably want a quick macro, if only to make things a terse as in
>>>>>> the other languages (if you're into that kind of thing)
>>>>>>
>>>>>> CL-USER> (defmacro str+ (&body body)
>>>>>> `(concatenate 'string ,@body))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <tearapart>why is this a macro instead of a function?<\tearapart>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Because i couldn't figure out how to do it as a function really (i'm
>>>> knee deep in SQL today, and we all know how slow context switches
>>>> can be).
>>>>
>>>> i tried (defun str+ (&rest rest) ...
>>>>
>>>> but here i got lost. REST is list, and i need to flatten it as
>>>> CONCATENATE needs strings as arguments. Can you enlighten me on how
>>>> to do this and still be as efficient as the macro?
>>>
>>>
>>>
>>>
>>> Edi has already pointed out APPLY. Two things, tho.
>>>
>>> (1) You said "as efficient as the macro". Are you worried about the
>>> list created to hold the &rest arg happening at runtime instead of
>>> compile time?
>>
>>
>>
>> I didn't know about APPLY, so any solution i had would CONS a bit.
>> Since i wanted to use str+ to implement str*, I wanted to avoid that.
>>
>>>
>>> (2) I just noticed you used &body in the macro version. Use &body to
>>> bind code, &rest for an expected list of other things. &body is just
>>> a hint to pretty-printers, which will arrange code differently than a
>>> list of anything else (ie, yeah, code is a list, too).
>>
>>
>>
>> Hrm. I've always used &body in macros, just because it always seemed
>> for clear to me that i want the 'body' of the macro, not the 'rest' of
>> the arguments. probably a bad habit I picked up somewhere. Are there
>> any other reasons, besides the pretty printer, why one would choose
>> &body over &rest?
>
>
> clhs 3.4.4: "&body is identical in function to &rest, but it can be used
> to inform certain output-formatting and editing functions that the
> remainder of the form is treated as a body, and should be indented
> accordingly."
>
> As for not wanting to use &rest when /all/ arguments are being
> collected, well, good to see someone taking names seriously. <g>
well, is it not you who propounds that the very act of naming something
can help give you insight into its purpose? Some of us listen ;)
still not using cells though ... one of these days.
drewc
>
> kt
>
>
drewc <·····@rift.com> writes:
> Kenny Tilton wrote:
>> Edi has already pointed out APPLY. Two things, tho.
>> (1) You said "as efficient as the macro". Are you worried about the
>> list created to hold the &rest arg happening at runtime instead of
>> compile time?
>
> I didn't know about APPLY, so any solution i had would CONS a bit. Since
> i wanted to use str+ to implement str*, I wanted to avoid that.
Declaim the function INLINE and the list won't need to be created in an
implementation that cares about speed.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Tue, 11 Jan 2005 13:41:50 -0800, Xah Lee wrote:
> Dear Kenny,
>
> if you are so interested,
He probably isn't _too_ interested - maybe more in why this
ended up in comp.lang.lisp.
> i wonder if you'd enjoy writing a follow up
> daily on how it is done in a lisp?
What, string quoting? (to picl just one of your "expert"
topics :-)
> i started
> it because i always wanted to switch to python but too lazy and always
> falling back to a lang i am an expert at, but frustrated constantly by
> its inanities and incompetences.
Whoa! You're the first person i know who claims expert-ness for
him/herself. I'm looking forward to your entries about moving from
perl's module/namespace model to python's. A short explanation of
python's local vs. global variable scope would be helpful as well
(and an expert opinion on how to mimic perl's "my" "our" "your" (?)
in python).
Cheers RalfD
> Xah
> ···@xahlee.org
> http://xahlee.org/PageTwo_dir/more.html
[snip]
Please drop comp.lang.c from this thread. It's probably off-topic in
comp.lang.lisp and comp.lang.scheme as well, but I'm not familiar with
the conventions there.
--
Keith Thompson (The_Other_Keith) ·····@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
it is rather too bad seeing a bunch of lispers clowning about it.
one could have indeed started such a daily tip that would be useful and
instigate learning.
anyway, there used to be comp.lang.java.*, but the whole group sees
gone. Does anyone know what happens to it?
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Xah Lee wrote:
> it is rather too bad seeing a bunch of lispers clowning about it.
There is nothing wrong with humor, and humor does not entail disrespect.
> one could have indeed started such a daily tip that would be useful and
> instigate learning.
Projects like these succeed if their founders stick with them until they
themselves have put in enough content to generate interest and pick up
new contributors and grow even more until they become self-sustaining.
Also, steady marketing is necessary to achieve mindshare.
What you might do is continue the effort, frequently appearing on a
python group to ask questions, always advertising your site and its
noble purpose.
You might also ask around to see if folks like the design of those
pages. I myself could not quite make out at what I was looking.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
+ Kenny Tilton <·······@nyc.rr.com>:
| There is nothing wrong with humor
Yes, there is!
(Oops, sorry, I thought this was c.l.py.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow