Hello, all....
I'm stuck on a bit of a problem: I need to write an implode function -
takes '(H e l l o) and gives back 'Hello. and I need to write an explode
function - takes 'Hello and returns '(H e l l o)
can anyone offer any tips? Thanks a lot!
Josh
From: Michael Tuchman
Subject: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <wkbtngfp6u.fsf@orsi.com>
** flame on** This thread (symbol implosion/explosion) has appeared
numerous times in the past month, and I for one am getting a little
weary of seeing it yet again. The last version of the FAQ I saw was
August 1997. Perhaps we need an update?
Or at least now that we have dejanews, I hope people will search it
before posting yet another version of the same old stuff.
** flame off
That's my $.02
From: Kent M Pitman
Subject: Re: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <sfw90ikhwi9.fsf@world.std.com>
Michael Tuchman <·····@orsi.com> writes:
> ** flame on** This thread (symbol implosion/explosion) has appeared
> numerous times in the past month, and I for one am getting a little
> weary of seeing it yet again. The last version of the FAQ I saw was
> August 1997. Perhaps we need an update? [...]
> ** flame off
I agree completely. Here's my proposed text. I'm posting it here
in case anyone wants to suggest refinements, but I'm not tracking the
refinements. The faq-trackers (are you listening, barmar? :-) can
do that.
Q: How do I implement the functions EXPLODE or IMPLODE, which turn
an object into a list of characters and vice versa, respectively?
A: There are no known valid uses for EXPLODE in modern code.
You are probably working with obsolete teaching material of some kind.
If you are working with new teaching materials from an active class,
then you should almost certainly not be looking things up in a FAQ
since looking up a solution defeats the learning process.
Consing a list of characters is a practice that went the way of the
dinosaur in 1984 with the death of MACLISP and the release of
Common Lisp to supersede it.
MACLISP (1970's) had neither strings nor character objects, and so
had the function EXPLODE as a crude way of talking about the printed
representation of an object as a list of integer character codes
or interned symbols (crudely representing characters). The IMPLODE
function was an inverse which produced a symbol from the `characters';
there was also a READLIST function which simulated the action of
the reader using such a list of `characters'.
For well over a decade, the practice has been to use strings to
represent printed representations of objects. The functions
PRIN1-TO-STRING, PRINC-TO-STRING, READ-FROM-STRING, and INTERN
are the approximate conceptual successors to EXPLODE, EXPLODEC,
READLIST, and IMPLODE, respectively, although their arguments and
return values are very different now that Lisps have strings
to use instead of lists of characters.
Note that MACLISP is not to be confused with any Lisp for the
Macintosh. MACLISP, so named because it arose as part of
Project MAC at MIT, ran on the PDP-10 and Multics machines.
These were large, room-sized machines (the smallest PDP-10,
after years of refinement was the size of a normal kitchen
refrigerator and most before it were 5 to 10 times the size).
Q: Is it appropriate to send mail to comp.lang.lisp asking for help
with Lisp homework?
A: In general, no.
It is definitely NOT ok to post saying "Can someone tell me how
to do <whatever>?" The newsgroups do not exist for this purpose.
If you EVER send mail about any homework problem, it is your
ethical obligation to identify that you are doing so since
asking someone for help with homework without identifying your
request as homework might be interpreted as cheating.
The only circumstance in which you should ever even consider
sending mail to comp.lang.lisp or another public forum asking
for help is where you have (a) identified in the post that
you are asking for help with homework, (b) included a partial
result as proof you have made an attempt on your own, and
(c) exhausted all other avenues for getting help through your
school, class, instructor, etc.
You should be aware at all times that all newsgroups are archived
and that for the rest of your life, everywhere you go, and most
notably at places you might later apply for a job, people will
trivially be able to instantly call up records of everything you
ever say to a newsgroup, so if you try to "cheat" or even just
"not put in a good effort first", this fact will be part of
the permanent record that could haunt you forever. This is
reason for caution about virtually anything you say on a
newgroup. But especially things that make you look unethical
or lazy are bad ways to start your career.
From: Josh Gardner
Subject: Re: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <36241603.4D65147@dowco.com>
--------------46E50D759F1628A55A50B62C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Q: Is it appropriate to send mail to comp.lang.lisp asking for help
> with Lisp homework?
>
> A: In general, no.
>
Sorry! But thanks for setting me straight on this.
> The only circumstance in which you should ever even consider
> sending mail to comp.lang.lisp or another public forum asking
> for help is where you have (a) identified in the post that
> you are asking for help with homework, (b) included a partial
> result as proof you have made an attempt on your own, and
> (c) exhausted all other avenues for getting help through your
> school, class, instructor, etc.
>
Well, I did identify part (a), and as for b and c, I spent time working out
my own solution. In retrospect, I should have inculded in my original posting
that I was merely looking for some ideas on how to write implode and explode,
and not a complete solution. So, I duly apologize to anyone I may have
inconvenienced, offended, etc. Hindsight is always 20/20.
Thanks to those who gave examples illustrating use of coerce, becuase I was
trying to use concatenate-strings, and it wasn't working like I hoped.
Josh
--------------46E50D759F1628A55A50B62C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<BR>
<BLOCKQUOTE TYPE=CITE>Q: Is it appropriate to send mail to comp.lang.lisp
asking for help
<BR> with Lisp homework?
<P>A: In general, no.
<BR> </BLOCKQUOTE>
Sorry! But thanks for setting me straight on this.
<BLOCKQUOTE TYPE=CITE> The only circumstance in which you should
ever even consider
<BR> sending mail to comp.lang.lisp or another public forum
asking
<BR> for help is where you have (a) identified in the post
that
<BR> you are asking for help with homework, (b) included a
partial
<BR> result as proof you have made an attempt on your own,
and
<BR> (c) exhausted all other avenues for getting help through
your
<BR> school, class, instructor, etc.
<BR> </BLOCKQUOTE>
Well, I did identify part (a), and as for b and c, I spent time working
out my own solution. In retrospect, I should have inculded in my original
posting that I was merely looking for some <B>ideas</B> on how to write
implode and explode, <B>and not a complete solution.</B> So, I duly apologize
to anyone I may have inconvenienced, offended, etc. Hindsight is always
20/20.
<P>Thanks to those who gave examples illustrating use of coerce, becuase
I was trying to use concatenate-strings, and it wasn't working like I hoped.
<P>Josh
<BR> </HTML>
--------------46E50D759F1628A55A50B62C--
From: Kent M Pitman
Subject: Re: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <sfwd87vpsr1.fsf@world.std.com>
Josh Gardner <·····@dowco.com> writes:
> > Q: Is it appropriate to send mail to comp.lang.lisp asking for help
> > with Lisp homework?
> >
> > A: In general, no.
Just to be clear, this was just my opinion offered for comment.
It might be that others agree with me, but we'll have to see.
It certainly is true that newsgroups are a "free speech" forum
that no one owns, so technically it's hard (and maybe inappropriate)
to legislate content. But we'll see what others say.
> Sorry! But thanks for setting me straight on this.
Actually didn't mean you to take the comment personally. I was really
speaking generally in response to the whole class of queries of this
kind we've gotten. And anyway, absent some well-published theory of
etiquette, it's of course less obvious to students what the situation
is, and so even if it's becoming the consensus that this should be
done only conservatively, you shouldn't feel like you've transgressed
awfully... and it may not be that my opinion is the only one.
> > The only circumstance in which you should ever even consider
> > sending mail to comp.lang.lisp or another public forum asking
> > for help is where you have (a) identified in the post that
> > you are asking for help with homework, (b) included a partial
> > result as proof you have made an attempt on your own, and
> > (c) exhausted all other avenues for getting help through your
> > school, class, instructor, etc.
> >
>
> Well, I did identify part (a), and as for b and c, I spent time working out
> my own solution. In retrospect, I should have inculded in my original posting
> that I was merely looking for some ideas on how to write implode and explode,
> and not a complete solution. So, I duly apologize to anyone I may have
> inconvenienced, offended, etc. Hindsight is always 20/20.
Right. And retroactive rules aren't fair, so don't fuss over it too
much. My proposed FAQ response was intended to cover the general
class of all problems we've had; I wasn't really speaking to you
specifically (though I'm glad you responded so that I could clarify this).
Btw, I don't think the issue is one of being inconvenienced or offended.
People here love to help others and this is a great source of answers where
you really need help. We like Lisp and we like helping others get started.
It's just that it puts us in our own "ethical bind" trying to figure out
what to say to someone about homework. We don't know what you already are
supposed to know and what part is new, etc. Whenever a student asks an
obvious "homework question", you can always feel the nervous pause by
people unsure of how to respond so as to balance all the elements.
> Thanks to those who gave examples illustrating use of coerce, becuase I was
> trying to use concatenate-strings, and it wasn't working like I hoped.
Glad you managed to muddle through and hope you hang in there and
don't feel too pounced upon just because you got used in discussion as
a prototype instance of a more general issue for us.
From: Josh Gardner
Subject: Re: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <362553C7.AFB59604@dowco.com>
Kent M Pitman wrote:
> Actually didn't mean you to take the comment personally. I was really
> speaking generally in response to the whole class of queries of this
> kind we've gotten. And anyway, absent some well-published theory of
> etiquette, it's of course less obvious to students what the situation
> is, and so even if it's becoming the consensus that this should be
> done only conservatively, you shouldn't feel like you've transgressed
> awfully... and it may not be that my opinion is the only one.
>
Sure, no harm done.
> Right. And retroactive rules aren't fair, so don't fuss over it too
> much. My proposed FAQ response was intended to cover the general
> class of all problems we've had; I wasn't really speaking to you
> specifically (though I'm glad you responded so that I could clarify this).
>
> Btw, I don't think the issue is one of being inconvenienced or offended.
> People here love to help others and this is a great source of answers where
> you really need help. We like Lisp and we like helping others get started.
> It's just that it puts us in our own "ethical bind" trying to figure out
> what to say to someone about homework. We don't know what you already are
> supposed to know and what part is new, etc. Whenever a student asks an
> obvious "homework question", you can always feel the nervous pause by
> people unsure of how to respond so as to balance all the elements.
>
Well, I'm glad that we both see the ethical issue clearly here, and I can
definately see where you are coming from here, I've had similar experience with
fellow students and email messages - how to respond so as not to actually give out
a free answer, yet still try to remain helpful?
> > Thanks to those who gave examples illustrating use of coerce, becuase I was
> > trying to use concatenate-strings, and it wasn't working like I hoped.
>
> Glad you managed to muddle through and hope you hang in there and
> don't feel too pounced upon just because you got used in discussion as
> a prototype instance of a more general issue for us.
No problem, and thanks for the reply to the reply!
Josh
From: Bill Newman
Subject: Re: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <wnewmanF0vIBu.Gtn@netcom.com>
Kent M Pitman (······@world.std.com) wrote:
: Michael Tuchman <·····@orsi.com> writes:
: > ** flame on** This thread (symbol implosion/explosion) has appeared
: > numerous times in the past month, and I for one am getting a little
: > weary of seeing it yet again. The last version of the FAQ I saw was
: > August 1997. Perhaps we need an update? [...]
: > ** flame off
: I agree completely. Here's my proposed text. I'm posting it here
: in case anyone wants to suggest refinements, but I'm not tracking the
: refinements. The faq-trackers (are you listening, barmar? :-) can
: do that.
: Q: How do I implement the functions EXPLODE or IMPLODE, which turn
: an object into a list of characters and vice versa, respectively?
: A: There are no known valid uses for EXPLODE in modern code.
: You are probably working with obsolete teaching material of some kind.
: If you are working with new teaching materials from an active class,
: then you should almost certainly not be looking things up in a FAQ
: since looking up a solution defeats the learning process.
I'd suggest adding a nod to the idea that reinventing the wheel is not
a good way to solve problems outside a classroom environment. Maybe
something like
If you are working on an exercise for a class, you should
probably not be asking for solutions on a newsgroup. [I realize
that this overlaps with Kent's next proposed FAQ.] Doing exercises
to gain familiarity with a system is perhaps the one time in your
programming career when it's beneficial to spend your time
reinventing the wheel.
(When I learned programming long ago there was very little publicly
available code to learn from. Later, the situation changed, but it
took me a while to realize that with abundant examples of prior art,
"a week in the lab can save an hour in the library" applies not just
to high-level algorithms but to low-level idioms and tricks, too. I
wish I'd realized it earlier, and I'm concerned that some programmers
and instructors haven't realized it yet.)
Bill Newman
From: rusty craine
Subject: Re: Let's update the FAQ: (Re: How to write implode and explode?)
Date:
Message-ID: <70332i$4kv$1@excalibur.flash.net>
Till I found comp.lang.lisp, I thought I was the only lisp programmer left.
I have used lisp in a very Forth-like (and unlisp-like) way to drive digital
interfaces to devices, even other computers. Usually there is a stack
(list) that is pop'ed or push'ed with an instruction, a destination, and
byte value...still very unlisp-like. I started reading the news group a few
months back. When I saw the concise, elegant code snippets from (i guess)
some of the best lisp programmers there are, it made me want to push my
envelope a little (maybe alot). I went to a local university to see what
books they had on lisp and if there was a bright young graduate student I
could hire to tutor me in *lisplike* lisp. .....there were only 4 books on
lisp and not even a course on lisp much less a tutor. The last time one of
the lisp books was checked out was in 1994......
I am not sure what this news group (or any other) are for.....but if I find
a student (or old fart like me) interested in lisp, I will indeed point said
person to this news group.
I have found this news group very helpful, educational, somewhat inspiring,
and most of the time all with a sense of humor (not to mention a liberal
dose of irony:).
Maybe, just maybe, it would be in the best interest of lisp to inspire a
would be "help with home work" interlocutor. If my area is an example
(Texas), get very far from Rice or UT and lisp is a lonely endeavor. t'is
ashame though, ya can make lisp into so many different tools for so many
different tasks.
btw...if i were to get *flamed* on a topic, that topic would the never
ending quest for freeware.
A _Fountain Head_ capitalist
Rusty
* Josh Gardner <·····@dowco.com>
| I'm stuck on a bit of a problem: I need to write an implode function -
| takes '(H e l l o) and gives back 'Hello. and I need to write an explode
| function - takes 'Hello and returns '(H e l l o)
OK, so it's probably homework, yet here's what I'd do, but I'm certain
that you won't be allowed to hand this in, anyway, so it's safe to give
you this "answer".
(defun explode (symbol)
(map 'list (lambda (character) (intern (string character) #.*package*))
(symbol-name symbol)))
(defun implode (list)
(intern (map 'string #'character list) #.*package*))
#:Erik
Erik Naggum <····@naggum.no> writes:
> ... #.*package* ...
Gack. You have got to be kidding. Why on earth would you wire in the package?
Hmmm. I guess you must be assuming you're writing a utility for a single
module that depends on the current package even if called by someone else;
but if you were writing a general-purpose version to export to others to
use, this would be a bad assumption. In that case, this design would
cause someone to have to replicate your definition making one copy of this
function for each package. At that point, you almost ought to write
(defun implode-maker (package) #'(lambda (chars) ...))
Also, as to the use of #., I know it says you can externalize a
package, which pretty much you have to be in order to dump interned
symbols, but this makes me queasy for some reason. Maybe just because
I grew up in an era when this kind of thing didn't work. Maybe for
some deeper philosophical reason I'm not able to articulate. But ick
either way, even though I can't defend my reason.
I'd write:
(defvar *my-package* *package*)
and then *my-package* rather than #.*package*.
Incidentally, as another stylistic matter that is similarly not required
by the language but is probably influenced by my having read about Brian
Smith's 3LISP long ago and not quite being able to get that out of my
mind, I don't really like seeing random constants unquoted, and I'd
prefer '#.*package* if you were going to do that.
JMO, FWIW.
* Kent M Pitman <······@world.std.com>
| Gack. You have got to be kidding. Why on earth would you wire in the
| package?
because I thought it was a relatively innocuous obfuscation well suited
to make it more obviously useless as homework because it wouldn't destroy
the entire solution or obscure the principle. however, this sounds like
a really lame excuse after your elaborate chide, so I've learned my
lesson today, too: it isn't innocuous at all, and I shouldn't play with
syntactic fire. (but note that I _did_ quote "answer".)
#:Erik
Erik Naggum <····@naggum.no> writes:
> * Kent M Pitman <······@world.std.com>
> | Gack. You have got to be kidding. Why on earth would you wire in the
> | package?
>
> because I thought it was a relatively innocuous obfuscation well
> suited to make it more obviously useless as homework because it
> wouldn't destroy the entire solution or obscure the principle.
> however, this sounds like a really lame excuse after your
> elaborate chide, so I've learned my lesson today, too: it isn't
> innocuous at all, and I shouldn't play with syntactic fire. (but
> note that I _did_ quote "answer".)
oh, darn. i was rather looking forward to your having some sort of
justification for it... well, maybe it's just as well you didn't.
(actually, it did occur to me that you were being obscure, and you
had done well, but i just didn't realize that element of it was part
of your sinister plan.)
incidentally, elaborating slightly on the issue of quotation,
which was only a peripheral issue here, but is still interesting
in its own right:
as i recall, and my memory might be wrong, the decision to make all
objects self-eval was made less out of a desire to encourage people to
make them be literal objects and more out of a desire to--well, i
didn't hear it articulated that way at the time, but now that i think
about it in retrospect it seems this way--to keep "objects" from
masquerading as "special forms" since it was popular at the time for
people to insist that there should be an EVAL method for an object and
people wanted objects to eval to all kinds oof things. in effect,
this would have caused a situation where code-walkers got stumped by
objects whose nature they didn't understand, and we'd just stomped out
fexprs, which allowed opaque user-control of evaluation, so it would
be the same idea over again in another form. by saying all objects
self-eval, we were really saying that eval is not the right place to
experiment with extending the language--not because it's not useful,
but because it defies comprehension by program-understanding-systems,
not the least of which is the human brain.
shortly (matter of a day or two, i expect) i'll put the text of my
1980 paper "special forms in lisp" online, and it will offer, i think,
an interesting window into life at that time. i wrote it just as the
tide was turning against fexprs, and subsequent to that time, fexprs
died out. i just finished hand-typing it back in and marking it up in
html (having lost the original online version, at least "temporarily")
and am busy proofreading it. it's weird to look back on something
done that long ago--i could feel with each word as i typed it back in
how my feelings about that had changed. (and hopefully my writing
style has improved, too.) but lisp terminology was a lot more sloppy
back then and it comes through in the paper. i'll post when it's
available.
In article <···············@world.std.com> (15-Oct-1998), I wrote:
> shortly (matter of a day or two, i expect) i'll put the text of my
> 1980 paper "special forms in lisp" online, and it will offer, i think,
> an interesting window into life at that time. i wrote it just as the
> tide was turning against fexprs, and subsequent to that time, fexprs
> died out. i just finished hand-typing it back in and marking it up in
> html (having lost the original online version, at least "temporarily")
> and am busy proofreading it. it's weird to look back on something
> done that long ago--i could feel with each word as i typed it back in
> how my feelings about that had changed. (and hopefully my writing
> style has improved, too.) but lisp terminology was a lot more sloppy
> back then and it comes through in the paper. i'll post when it's
> available.
Ok, it's available.
I added a new "Miscellaneous Technical Papers" section to my page
http://world.std.com/~pitman/publications.html
Remember: The new papers I just added are historical in nature
(1979-1980) and are not descriptive of Lisp today. They're
primarily of interest to people who want a more detailed look
at this old MACLISP dialect I and a few others periodically
refer to.
In article <·················@dowco.com> , Josh Gardner <·····@dowco.com>
wrote:
>Hello, all....
>
>I'm stuck on a bit of a problem: I need to write an implode function -
>takes '(H e l l o) and gives back 'Hello. and I need to write an explode
>function - takes 'Hello and returns '(H e l l o)
>
>can anyone offer any tips? Thanks a lot!
>
>Josh
>
I'm curious as to why you'd use these transformations. Usually, this
request is better satisfied with existing sequence and/or symbol operations.
Implode and explode are rarely seen outside of homework exercises...
---
David B. Lamkins <http://www.teleport.com/~dlamkins/>
David B. Lamkins wrote:
> In article <·················@dowco.com> , Josh Gardner <·····@dowco.com>
> wrote:
>
> >Hello, all....
> >
> >I'm stuck on a bit of a problem: I need to write an implode function -
> >takes '(H e l l o) and gives back 'Hello. and I need to write an explode
> >function - takes 'Hello and returns '(H e l l o)
> >
> >can anyone offer any tips? Thanks a lot!
> >
> >Josh
> >
>
> I'm curious as to why you'd use these transformations. Usually, this
> request is better satisfied with existing sequence and/or symbol operations.
> Implode and explode are rarely seen outside of homework exercises...
>
Yep, it is a homework assignment... I'm just curious as to how to actually do
it..I'm kinda stuck.
Thanks!
Josh
In article <·················@dowco.com>,
Josh Gardner <·····@dowco.com> wrote:
>I'm stuck on a bit of a problem: I need to write an implode function -
>takes '(H e l l o) and gives back 'Hello. and I need to write an explode
>function - takes 'Hello and returns '(H e l l o)
(defun implode (list)
(read-from-string
(coerce 'string
(mapcar #'(lambda (sym) (char (symbol-name sym) 0))))))
(defun explode (expr)
(coerce 'list (prin1-to-string expr)))
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Marc Dzaebel
Subject: Re: How to write implode and explode?
Date:
Message-ID: <3623320C.30EE2662@rose.de>
Barry Margolin wrote:
> (defun implode (list)
> (read-from-string
> (coerce 'string
> ))))
>
> (defun explode (expr)
> (coerce 'list (prin1-to-string expr)))
Some syntax faults in the above: Here is my view
(defun implode(x)(read-from-string(coerce x'string)))
(defun explode(expr)(coerce(prin1-to-string expr)'list))
(explode 'hJ) -> (#\h #\j)
(implode(explode '|hJ|)) -> '|hJ|
(implode(explode #(this is a vector))) -> #(this is a vector)
(implode(explode '(1 2 3))) -> (1 2 3)
In my view your teacher made a fault in requireing a
symbol-list rather than a character list. It's
obviously inadequate to further coerce character
to symbols and back again. this will allocate a lot
of wasted space. However if you want your symbol-list
here it is:
(defun explode(e)
(mapcar #'(lambda(x)(intern(string x)))
(coerce(prin1-to-string e)'list)))
(defun implode(l)
(read-from-string
(coerce(mapcar #'(lambda(s)(char(symbol-name s)0))l)'string)))
(explode '(1 2 3)) -> (|(| |1| | | |2| | | |3| |)|)
(implode *) -> (1 2 3)
(implode(explode '|hJ|)) -> '|hJ|
Marc Dzaebel
* Marc Dzaebel wrote:
> (defun implode(x)(read-from-string(coerce x'string)))
> (defun explode(expr)(coerce(prin1-to-string expr)'list))
I don't mean to be rude to anyone here, especially as it's clear that
the original question was a homework problem (so I may be falling into
a hole as everyone else is trying to give a not-too-good answer), but
this kind of answer ties in rather well with my earlier post on
another thread:
I wrote:
Unfortunately my experience of the way Lisp (CL specifically) is
often taught is that these kind of disciplines are not stressed at
all, but that tends to be because it's taught in an environment
where any kind of engineering considerations are regarded as
entirely trivial and worthless compared to the noble goal of
publishing papers (:).
So what's wrong with the answers given here? Well, first of all, this
is using the IO facilities of the language to do data-type
conversion: that's the moral equivalent of printing to a file and
reading it back, and it's a pretty bad sign.
If we assume for a minute that this is actually the best way to do
something like this in CL, then is this actually a reasonable
implementation. No, it isn't, and not only is it not reasonable it's
not *safe*. Consider the following:
(implode '(#\# #\. #\( #\E #\X #\T #\: #\Q #\U #\I #\T #\)))
What happens if you evaluate this in CMUCL? Not good news. Even if
you wrap WITH-STANDARD-IO-SYNTAX around the form and bind *READ-EVAL*
to NIL, you still have no idea what the type of the result actually
*is*. It could be a list, or, worse, it could be an error. So to get
this anything like reliable we need to check the result type and
perhaps signal an error or something, and we need to be willing to
catch errors too.
So Lisp is a pretty rubbish language if we have to do all that stuff
to make our programs reliable, and even if we do it's pretty slow. We
wouldn't have to do all that stuff in a decent language like C++,
would we?
Well:
(defun implode (l)
(loop with s = (make-string (length l))
for i upfrom 0
for e in l
do (etypecase e
(character
(setf (aref s i) e)))
finally (return (intern s))))
Seems to work quite well (and, for CMUCL it's about 4x as fast and a
third as consy). LOOP-phobes can rewrite it using some other
iteration construct, efficiency nerds can reimplement it not to need
two traversals of the list.
I have seen many examples of Lisp code in real use written by people
with years of experience that does things that are considerably worse
than this, and I find that frightening, frankly.
--tim
From: Marc Dzaebel
Subject: Re: How to write implode and explode?
Date:
Message-ID: <36238A88.141C8DB6@rose.de>
Tim Bradshaw wrote:
>
> * Marc Dzaebel wrote:
>
> > (defun implode(x)(read-from-string(coerce x'string)))
> > (defun explode(expr)(coerce(prin1-to-string expr)'list))
>
> I don't mean to be rude to anyone here, especially as it's clear that
> the original question was a homework problem (so I may be falling into
> a hole as everyone else is trying to give a not-too-good answer), but
> this kind of answer ties in rather well with my earlier post on
> another thread:
>
> I wrote:
>
> Unfortunately my experience of the way Lisp (CL specifically) is
> often taught is that these kind of disciplines are not stressed at
> all, but that tends to be because it's taught in an environment
> where any kind of engineering considerations are regarded as
> entirely trivial and worthless compared to the noble goal of
> publishing papers (:).
Sorry, could you be more precise? I tried but still don't
understand your point.
> So what's wrong with the answers given here? Well, first of all, this
> is using the IO facilities of the language to do data-type
> conversion: that's the moral equivalent of printing to a file and
> reading it back, and it's a pretty bad sign.
Sorry, the LISP-reader is in a way a very universal data-type
converter. I used his strength to be '*safer"' regarding different
types of conversion. I don't think it's a good idea to reimplement
the reader for a very limmitted set of types. This is very
error prone in my view. (implode(explode 42)) will result in
the symbol |42| in your realisation. So what would you do
for Input-Output consistency? Reimplement the reader? I think
it's easier to tell people to consider the known reader
constraints rather than restricting the input for implode/explode
to a special hard to understand subset of types.
What if you defined several macro-characters for your own
data types as constructors. You will have to reimplement
the construction for implode, do you? Finally (IMHO) this
would lead to much more confusion than the read-solution,
however, our aims seems to be the same!
> If we assume for a minute that this is actually the best way to do
> something like this in CL, then is this actually a reasonable
> implementation. No, it isn't, and not only is it not reasonable it's
> not *safe*. Consider the following:
>
> (implode '(#\# #\. #\( #\E #\X #\T #\: #\Q #\U #\I #\T #\)))
The read concept translates (implode '(#\1)) -> 1
the make-string concept: (implode '(#\1)) -> '|1|
So which one would you like?
> What happens if you evaluate this in CMUCL? Not good news. Even if
> you wrap WITH-STANDARD-IO-SYNTAX around the form and bind *READ-EVAL*
> to NIL, you still have no idea what the type of the result actually
> *is*.
> Well:
> (defun implode (l)
> (loop with s = (make-string (length l))
> for i upfrom 0
> for e in l
> do (etypecase e
> (character
> (setf (aref s i) e)))
> finally (return (intern s))))
If your problem is to translate a character list to
a symbol I would rather prefer:
(defun implode(l)(intern(coerce l'string)))
By the way I don't understand why to check that items
in the list are character while not checking that L is
a list (in your definition).
If your problem is to write a general implode and explode
function (which I assumed) the read-solution is probably
more adequate.
Marc
* Marc Dzaebel wrote:
>> I wrote:
>>
>> Unfortunately my experience of the way Lisp (CL specifically) is
>> often taught is that these kind of disciplines are not stressed at
>> all, but that tends to be because it's taught in an environment
>> where any kind of engineering considerations are regarded as
>> entirely trivial and worthless compared to the noble goal of
>> publishing papers (:).
> Sorry, could you be more precise? I tried but still don't
> understand your point.
My point is that Lisp tends to be taught in a heavily `academic'
environment, where people think that it is very important to be able
to understand the theory of things, but have absolutely no regard for
the practice, and in fact regard people who are interested in the
practice as essentially droids with no interesting skills and no
intellectual capacity.
This attitude is obviously incredibly stupid, since it's just obvious
that the practice of programming, especially for large (choose your
definition of large) systems, is extremely intellectually demanding,
and that its something that can be taught to some extent in the same
way that, say, mechanical engineering is. And it's important that
people have these engineering skills, if we don't want our large
systems to be buggy inefficient junk.
There is an argument that there are really two disciplines --
`theoretical computer science', which is really a kind of mathematics,
and `software engineering' which is involved with engineering
programs. And of course no one in a university (at least not in this
one!) wants to do the engineering stuff, because those people wear
anoraks and don't get invited to parties.
But this argument is wrong. Here's a story that shows why. I was
once an undergraduate doing a physics degree. I was pretty good at
the subject, and I was being picked out by the staff as one of the
people who should do a Ph.D, and who possibly could have a career as
an academic theoretical physicist. It's hard to argue that
theoretical physics is some kind of anoraky engineering discipline:
it's definitely a subject in the first rank of serious sciences.
Maths, specifically various kinds of differential equations, is the
language of physics, and you need to get very good at solving and
manipulating equations. Unfortunately, I was both reasonably good at
this stuff, and very lazy. So I didn't practice that much, I just did
my marked exercises and didn't bother spending the hundreds or
thousands of hours that less lazy people spent going through the
unmarked examples. This was a fatal mistake -- by the time I started
my Ph.D I was enormously less fluent than other people in this
`low-level' stuff, so even though I could understand the concepts, I
couldn't keep up, and I couldn't get results like other people
could. And I discovered Unix at about this time, and never made it as
a physicist.
The point of all this is that you can't do any kind of meaningful work
in physics unless you are *totally* fluent at manipulating hairy
differential equations. And I suggest that you also can't do any
reasonable work in `theoretical computer science' unless you are
*totally* fluent at programming, and have a deep understanding of the
engineering aspects of the discipline. This seems to be a contentious
view, at least in the UK, but I think that's more because `computer
scientists' have chips on their shoulders about not being engineers
than anything else. It certainly is not contentious in other fields
-- consider music for instance where even extremely gifted musicians
will expect to practice things like scales for several hours every
day.
So that's what I was trying to get at, I think. You need to take
engineering concerns seriously.
> Sorry, the LISP-reader is in a way a very universal data-type
> converter. I used his strength to be '*safer"' regarding different
> types of conversion. I don't think it's a good idea to reimplement
> the reader for a very limmitted set of types. This is very
> error prone in my view. (implode(explode 42)) will result in
> the symbol |42| in your realisation. So what would you do
> for Input-Output consistency? Reimplement the reader? I think
> it's easier to tell people to consider the known reader
> constraints rather than restricting the input for implode/explode
> to a special hard to understand subset of types.
If I wanted the reader and all that gives me, I'd use it. If I want
IMPLODE, which takes a list of characters and makes a symbol, I won't
use it, because it's very hard to write IMPLODE with the I/O system in
a way that isn't error-prone, very inefficient, accepts all sorts of
arguments and produces all sorts of results that it should not do, and
is also willfully obscure in the way that languages like perl are.
And if I was teaching a class in CL (which I have done) I'd be worried
if someone gave me that answer (I'd actually be a bit worried about a
course that asked for IMPLODE in any case, as others have mentioned.).
> The read concept translates (implode '(#\1)) -> 1
> the make-string concept: (implode '(#\1)) -> '|1|
> So which one would you like?
The second one is what IMPLODE is meant to do (at least according to
Chine Nual, I don't have a maclisp manual), so I'd like that.
> If your problem is to translate a character list to
> a symbol I would rather prefer:
> (defun implode(l)(intern(coerce l'string)))
That seems like a reasonable way of doing it too, and perhaps I should
have written that. I guess the (minor) problem with that is that I'd
have to look at the manual to find out what could be coerced to what,
so I could know where this thing would work and not, and what checks I
might need to put in to prevent it accepting arguments or producing
results that I might not expect (these are the sort of problems that
the I/O-based one has in spades). With my version it's clear what it
does by inspection (the not-checking for a list was really a bug,
because I typed it in without thinking...).
--tim
From: Marc Dzaebel
Subject: Re: How to write implode and explode?
Date:
Message-ID: <3624CB07.FA7AA8D0@rose.de>
Hi Tim,
thank you for the clarification. I think we're close together
in what we think about what to learn first. I
developed the aim to know at least about the tools I use.
An other insight was to see that, up to now, it's always
necessary to have an impression of what your language really
does.
I did not know that the standard interpretation of implode
is to produce a symbol. Also you're right with respect
to the performance of read. So the decisive part is the
actual requirement but in a general case it would certainly
be nice to have the input/output equivalence
(implode(explode X))=X if this wouldn't cost so much ;-)
Yours, Marc
In article <···············@todday.aiai.ed.ac.uk>,
Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>If I wanted the reader and all that gives me, I'd use it. If I want
>IMPLODE, which takes a list of characters and makes a symbol,
Except that's not what IMPLODE did. Maclisp didn't originally have strings
or characters. To represent characters we used symbols with single
character names; to represent strings we used lists of characters. IMPLODE
and EXPLODE were the equivalents of READ-FROM-STRING and PRIN1-TO-STRING
for this representation. (I think there may also have been EXPLODEC that
was equivalent to PRINC-TO-STRING, but I don't remember for sure.)
Were there other dialects of Lisp where IMPLODE only created symbols?
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
In article <···············@todday.aiai.ed.ac.uk>,
Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>* Marc Dzaebel wrote:
>
>> (defun implode(x)(read-from-string(coerce x'string)))
>> (defun explode(expr)(coerce(prin1-to-string expr)'list))
>
>I don't mean to be rude to anyone here, especially as it's clear that
>the original question was a homework problem (so I may be falling into
>a hole as everyone else is trying to give a not-too-good answer), but
>this kind of answer ties in rather well with my earlier post on
>another thread:
>
>I wrote:
>
> Unfortunately my experience of the way Lisp (CL specifically) is
> often taught is that these kind of disciplines are not stressed at
> all, but that tends to be because it's taught in an environment
> where any kind of engineering considerations are regarded as
> entirely trivial and worthless compared to the noble goal of
> publishing papers (:).
>
Could you mention which disciplines? Heck, could you tell me what
languages are normally taught with appropriate programming disciplines?
As far as engineering considerations go: you're wrong. The academic
Common Lisp folks I've worked with generally know what a machine cycle
is worth (not much, but hardly negligible in quantity). One of the most
commonly recommended books (Norvig's) is very strong on ways to speed
up programs, and carefully transforms programs to make them
"industrial-strength". I haven't seen anything as good in any book
on any other programming language.
>So what's wrong with the answers given here? Well, first of all, this
>is using the IO facilities of the language to do data-type
>conversion: that's the moral equivalent of printing to a file and
>reading it back, and it's a pretty bad sign.
>
No, it doesn't do actual I/O.
Can we agree that C is used to do real work in the real world? Go over
to the comp.lang.c FAQ and look for the question on "itoa" - the best
way to convert an integer into a string. The answer given is
"sprintf", which is the equivalent of (format nil ...). Something
like prin1-to-string does the formatting, but not the long, drawn-out
electromechanical stuff.
>If we assume for a minute that this is actually the best way to do
>something like this in CL, then is this actually a reasonable
>implementation. No, it isn't, and not only is it not reasonable it's
>not *safe*. Consider the following:
>
Could you tell me which languages do emphasize safety? Hint: C and
C++ programs normally have memory problems, and in these and Java there's
no provision for checking integer overflow. Common Lisp is the safest
language I'm familiar with.
>Well:
>
> (defun implode (l)
> (loop with s = (make-string (length l))
> for i upfrom 0
> for e in l
> do (etypecase e
> (character
> (setf (aref s i) e)))
> finally (return (intern s))))
>
>Seems to work quite well (and, for CMUCL it's about 4x as fast and a
>third as consy). LOOP-phobes can rewrite it using some other
>iteration construct, efficiency nerds can reimplement it not to need
>two traversals of the list.
>
Ah, so you have taken something considerably safer than most C++
programs but acceptably fast, and transformed it into something
even safer and faster. Very good. It's less intelligible in this
form, but much better than the C++ program I've got compiling right
now (no, I didn't write it, nor would I have in that form).
>I have seen many examples of Lisp code in real use written by people
>with years of experience that does things that are considerably worse
>than this, and I find that frightening, frankly.
>
Not nearly as frightening as the C/C++/COBOL/Pascal/whatever code
I've seen in real use written by people with years of experience,
I would guess.
You seem to be comparing average programmers using Lisp with real
good software engineers using C++. In the real world, it isn't like
that. You may work with truly good C++ folks and unimpressive Lisp
folks, but that has nothing to do with the language per se, or even
the most common culture surrounding the language.
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
* David Thornley wrote:
>>
>> Unfortunately my experience of the way Lisp (CL specifically) is
>> often taught is that these kind of disciplines are not stressed at
>> all, but that tends to be because it's taught in an environment
>> where any kind of engineering considerations are regarded as
>> entirely trivial and worthless compared to the noble goal of
>> publishing papers (:).
>>
> Could you mention which disciplines? Heck, could you tell me what
> languages are normally taught with appropriate programming
> disciplines?
I don't know that any are. Computer science teaching is pretty fouled
up, at least in my experience (which is UK-only). Clearly a course
which is asking for IMPLODE is also pretty antique too, so I suspect
it's not only in the UK!
> As far as engineering considerations go: you're wrong. The academic
> Common Lisp folks I've worked with generally know what a machine cycle
> is worth (not much, but hardly negligible in quantity). One of the most
> commonly recommended books (Norvig's) is very strong on ways to speed
> up programs, and carefully transforms programs to make them
> "industrial-strength". I haven't seen anything as good in any book
> on any other programming language.
Yes, CL people are good at engineering. AI people (in the UK) are
often *much* worse, and regard engineering as beneath them, and they
teach CL courses, and that is the group I was getting at specifically,
though there are other groups.
(And not even all CL people are as good as they might be, specifically
with regard to the kind of issues that implode brings up. I have at
least 4 separate patches to systems (some of them commercial) I've
used which generate symbols via (format nil "~A-blah-blah" s), which
is a complete nightmare if you ever change the value of *PRINT-CASE*.)
>> So what's wrong with the answers given here? Well, first of all, this
>> is using the IO facilities of the language to do data-type
>> conversion: that's the moral equivalent of printing to a file and
>> reading it back, and it's a pretty bad sign.
>>
> No, it doesn't do actual I/O.
It does however use the IO facilities, namely the printer, as I said.
> Can we agree that C is used to do real work in the real world? Go over
> to the comp.lang.c FAQ and look for the question on "itoa" - the best
> way to convert an integer into a string. The answer given is
> "sprintf", which is the equivalent of (format nil ...). Something
> like prin1-to-string does the formatting, but not the long, drawn-out
> electromechanical stuff.
> Could you tell me which languages do emphasize safety? Hint: C and
> C++ programs normally have memory problems, and in these and Java there's
> no provision for checking integer overflow. Common Lisp is the safest
> language I'm familiar with.
Yes, C/C++ are worse. Did I say they was better? Being better than
C/C++, especially being better than the typical styles used in those
languages, is not really a challenge.
>>
> Ah, so you have taken something considerably safer than most C++
> programs but acceptably fast, and transformed it into something
> even safer and faster. Very good. It's less intelligible in this
> form, but much better than the C++ program I've got compiling right
> now (no, I didn't write it, nor would I have in that form).
The original wasn't safer, or if it was then it was a case of being
safer than a 10 pound lump of plutonium. The original version could
*delete files* if you gave it the right input! In fact it could do
anything that the Lisp system it was running in could do. That is not
safe!
I find it interesting that you find my version less intelligible.
It allocates a string, then loops over a list of characters and stuffs
them into it, then interns a symbol. I don't find that hard to understand.
>>
> Not nearly as frightening as the C/C++/COBOL/Pascal/whatever code
> I've seen in real use written by people with years of experience,
> I would guess.
Again, better than very bad indeed is not the same as good.
> You seem to be comparing average programmers using Lisp with real
> good software engineers using C++. In the real world, it isn't like
> that. You may work with truly good C++ folks and unimpressive Lisp
> folks, but that has nothing to do with the language per se, or even
> the most common culture surrounding the language.
I was not intending to compare Lisp with C++! I in fact work with very
good Lisp people and rather less good (or less experienced) C++
people. But there clearly is a culture in which Lisp is taught where
engineering concerns are not taken seriously. I work close to that
culture, and I've seen the results, and they make grim reading.
--tim
In article <···············@todday.aiai.ed.ac.uk>,
Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>* David Thornley wrote:
>>>
>>> Unfortunately my experience of the way Lisp (CL specifically) is
>>> often taught is that these kind of disciplines are not stressed at
>>>
>> Could you mention which disciplines? Heck, could you tell me what
>> languages are normally taught with appropriate programming
>> disciplines?
>
>I don't know that any are. Computer science teaching is pretty fouled
>up, at least in my experience (which is UK-only). Clearly a course
>which is asking for IMPLODE is also pretty antique too, so I suspect
>it's not only in the UK!
>
I tend to make a distinction between computer science (whose teaching
is generally rather fouled-up) and software engineering (often well-
taught, but generally not taught to everybody). It seems to me that
most of the demand should be for software engineers, and so employers
ask for computer science graduates. Then, of course, the people who are
in computer science to get a decent job get upset when we try to
teach them some computer science.
I suspect this would be largely true of any new science with a lot
of commercial applications, and that we'll get things settled down
into a real science. I don't think it'll be in my lifetime.
>> As far as engineering considerations go: you're wrong. The academic
>> Common Lisp folks I've worked with generally know what a machine cycle
>> is worth (not much, but hardly negligible in quantity). One of the most
>
>Yes, CL people are good at engineering. AI people (in the UK) are
>often *much* worse, and regard engineering as beneath them, and they
>teach CL courses, and that is the group I was getting at specifically,
>though there are other groups.
>
The people I was hanging around with were AI. I don't know whether
they're typical AI people.
>(And not even all CL people are as good as they might be, specifically
>with regard to the kind of issues that implode brings up. I have at
>least 4 separate patches to systems (some of them commercial) I've
>used which generate symbols via (format nil "~A-blah-blah" s), which
>is a complete nightmare if you ever change the value of *PRINT-CASE*.)
>
Hmmmm. Too much C-thinking? sprintf() is just sprintf(), and it
doesn't matter what sort of environment variables you've set. It
would seem safer to me to (defmacro
with-standard-environment-variables....
>>> So what's wrong with the answers given here? Well, first of all, this
>>> is using the IO facilities of the language to do data-type
>>>
>> No, it doesn't do actual I/O.
>
>It does however use the IO facilities, namely the printer, as I said.
>
In my experience, the really expensive part of I/O is the part involved
in talking to the disk drive (or whatever), not the part that formats
it into something readable. As I said before, sprintf() is a
commonly recommended way to convert numbers into strings in C, which
is much the same as (format nil ...). Note that the recommendation
was not fprintf() and fscanf(). The operations will generally be
plenty fast if only formatting and no actual I/O is done.
>> Could you tell me which languages do emphasize safety? Hint: C and
>> C++ programs normally have memory problems, and in these and Java there's
>> no provision for checking integer overflow. Common Lisp is the safest
>> language I'm familiar with.
>
>Yes, C/C++ are worse. Did I say they was better? Being better than
>C/C++, especially being better than the typical styles used in those
>languages, is not really a challenge.
>
OK, you don't like the safety of Common Lisp. I, personally, don't
think a language could get much safer without being B&D or seriously
interfering with productivity. I once looked at a Pascal compiler
with integrated editor that wouldn't let me make a syntax mistake;
it insisted on keeping the program syntactically correct at all times.
It was one of the most annoying pieces of junk I've ever worked with
that didn't involve COBOL.
>>>
>> Ah, so you have taken something considerably safer than most C++
>> programs but acceptably fast, and transformed it into something
>> even safer and faster. Very good. It's less intelligible in this
>> form, but much better than the C++ program I've got compiling right
>> now (no, I didn't write it, nor would I have in that form).
>
>The original wasn't safer, or if it was then it was a case of being
>safer than a 10 pound lump of plutonium. The original version could
>*delete files* if you gave it the right input! In fact it could do
>anything that the Lisp system it was running in could do. That is not
>safe!
>
Your claim was that it was unsafe because the Lisp reader was unsafe,
since it would execute on read. Is that in fact an inherent
characteristic of Common Lisp, or is that an implementation sort of
thing? I know that it's possible to set up a reader macro that
will execute-on-read, but I don't remember it being mandatory to set
it up that way. (I'm not considering the standard reader macros like
quote, since they're well-defined and mostly harmless.)
If it isn't mandatory that the read part of the read-eval-print loop
delete files by default, then you're arguing with implementation
decisions.
Note that it's very easy to hose memory in C programs, and that
literally anything can happen once the memory is hosed. The
difference is that it's harder to set up the memory hose
for a specific effect.
>I find it interesting that you find my version less intelligible.
>It allocates a string, then loops over a list of characters and stuffs
>them into it, then interns a symbol. I don't find that hard to understand.
>
The original version said what it was doing in overall terms, making
two transformations. Your version would be considered perfectly
understandable in C, where there are in general fewer general
transformations. In Lisp, applying a couple of standard transformations
is much more readable than making a loop and doing things in the loop
and processing the output.
>>>
>> Not nearly as frightening as the C/C++/COBOL/Pascal/whatever code
>> I've seen in real use written by people with years of experience,
>> I would guess.
>
>Again, better than very bad indeed is not the same as good.
>
I'm trying to understand your point. You started out saying that
Lisp was generally taught without proper emphasis on engineering
or discipline or whatever, and that a certain program was an
example thereof. The program was unsafe in certain implementations
when abused in a certain way, and otherwise was generally good.
Are you saying that the teaching of computer languages in general
is hosed up (in which case this isn't really relevant to
comp.lang.lisp), or are you saying that the teaching of Lisp is
hosed up (in which case I want to know relative to what)?
To put it another way, if I were to claim that Lisp is taught as
well, on the hole, as any other computer language, and that Lisp
is one of the safest languages for getting actual work done,
could you find grounds to disagree with me?
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-