I'm learning Lisp. As part of an exercise I'm writing removeText.
I have two questions about it. First, is there a Common Lisp function
that I've overlooked that would do this for me? And second, how would you
write this function?
Here are my tests for removeText:
(deftest test-removeText-that-never-occurs ()
(check (equal (removeText "no such" "from this") "from this")))
(deftest test-removeText-from-beginning ()
(check (equal (removeText "this " "this text") "text")))
(deftest test-removeText ()
(check (equal (removeText "this " "this text has this more times")
"text has more times")))
(deftest test-removeText-at-end ()
(check (equal (removeText "ending" "this ending")
"this ")))
And here's the code:
(defun removeText (aTextToRemove aText)
(let
((aResultText "")
(aTextLength (length aText))
(aSearchLength (length aTextToRemove)))
(do
((anIndex 0 (1+ anIndex))
(aSearchLimit (1+ (- aTextLength aSearchLength))))
((equal anIndex aTextLength) aResultText)
(setq aNewText (subseq aText anIndex (1+ anIndex)))
(if (< anIndex aSearchLimit)
(if (equal aTextToRemove
(subseq aText anIndex (+ anIndex aSearchLength)))
(progn
(setq anIndex (1- (+ anIndex aSearchLength)))
(setq aNewText ""))))
(setq aResultText
(concatenate 'string
aResultText
aNewText)))))
Thanks!
David B. Ellis wrote:
> I'm learning Lisp. As part of an exercise I'm writing removeText.
>
> I have two questions about it. First, is there a Common Lisp function
> that I've overlooked that would do this for me?
Search would save you a lot of trouble.
And second, how would you
> write this function?
(defun remove-text (src tgt &aux (tgt-len (length tgt)))
(do ((x (search tgt src)(search tgt src :start2 x)))
((not x) src)
(setq src (concatenate 'string
(subseq src 0 x)
(subseq src (+ x tgt-len))))))
btw, I am a big fan of camelCase, but I am Satan. The Lisp Faithful will
savage you for it. Otherwise your code is fine. You might want to try
revising it to take advantage of search and see how it comes out.
kenny
>
> Here are my tests for removeText:
>
> (deftest test-removeText-that-never-occurs ()
> (check (equal (removeText "no such" "from this") "from this")))
>
> (deftest test-removeText-from-beginning ()
> (check (equal (removeText "this " "this text") "text")))
>
> (deftest test-removeText ()
> (check (equal (removeText "this " "this text has this more times")
> "text has more times")))
>
> (deftest test-removeText-at-end ()
> (check (equal (removeText "ending" "this ending")
> "this ")))
>
> And here's the code:
>
> (defun removeText (aTextToRemove aText)
> (let
> ((aResultText "")
> (aTextLength (length aText))
> (aSearchLength (length aTextToRemove)))
>
> (do
> ((anIndex 0 (1+ anIndex))
> (aSearchLimit (1+ (- aTextLength aSearchLength))))
>
> ((equal anIndex aTextLength) aResultText)
>
> (setq aNewText (subseq aText anIndex (1+ anIndex)))
> (if (< anIndex aSearchLimit)
> (if (equal aTextToRemove
> (subseq aText anIndex (+ anIndex aSearchLength)))
> (progn
> (setq anIndex (1- (+ anIndex aSearchLength)))
> (setq aNewText ""))))
>
> (setq aResultText
> (concatenate 'string
> aResultText
> aNewText)))))
>
> Thanks!
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·························@twister.nyc.rr.com...
>
>
> David B. Ellis wrote:
>
>> I'm learning Lisp. As part of an exercise I'm writing removeText.
>>
>> I have two questions about it. First, is there a Common Lisp function
>> that I've overlooked that would do this for me?
>
> Search would save you a lot of trouble.
>
> And second, how would you
>> write this function?
>
> (defun remove-text (src tgt &aux (tgt-len (length tgt)))
> (do ((x (search tgt src)(search tgt src :start2 x)))
> ((not x) src)
> (setq src (concatenate 'string
> (subseq src 0 x)
> (subseq src (+ x tgt-len))))))
IMCO (In My Correct Opinion :) &aux should not be recommended to newbies. I
don't see any good reason to use it in any new code save generated code.
Why not LET?
That is a big ditto for DO but that is a personal opinion rather than a
correct opinion...
(gee, it's so much easier to criticize code contributions than actually make
any! Thanks, Kenny)
> btw, I am a big fan of camelCase, but I am Satan. The Lisp Faithful will
> savage you for it.
And rightly so (now where's my deluxe bag of "stoning" rocks...)
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·························@twister.nyc.rr.com...
>
>>
>>David B. Ellis wrote:
>>
>>
>>>I'm learning Lisp. As part of an exercise I'm writing removeText.
>>>
>>>I have two questions about it. First, is there a Common Lisp function
>>>that I've overlooked that would do this for me?
>>
>>Search would save you a lot of trouble.
>>
>> And second, how would you
>>
>>>write this function?
>>
>>(defun remove-text (src tgt &aux (tgt-len (length tgt)))
>> (do ((x (search tgt src)(search tgt src :start2 x)))
>> ((not x) src)
>> (setq src (concatenate 'string
>> (subseq src 0 x)
>> (subseq src (+ x tgt-len))))))
>
>
> IMCO (In My Correct Opinion :) &aux should not be recommended to newbies...
> Why not LET?
Why not &aux?
Why not let?
This isn't an argument!
'Tis!
'Tisn't!
'Tis!
'Tisn't!
'Time's up.
'That wasn't five minutes!
'Twas.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> >>(defun remove-text (src tgt &aux (tgt-len (length tgt)))
> >> (do ((x (search tgt src)(search tgt src :start2 x)))
> >> ((not x) src)
> >> (setq src (concatenate 'string
> >> (subseq src 0 x)
> >> (subseq src (+ x tgt-len))))))
> > IMCO (In My Correct Opinion :) &aux should not be recommended to
> > newbies...
> > Why not LET?
>
> Why not &aux?
> Why not let?
But how &AUX came to be?
Aux variables are not arguments, so why should they be declared in the
argument list?
(Personally, I object to their use)
--
__Pascal Bourguignon__ http://www.informatimago.com/
To vote Democrat or Republican, it's like changing of cabin in the Titanic.
From: Christopher C. Stacy
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <ubrfidvsz.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
>
> But how &AUX came to be?
> Aux variables are not arguments, so why should they
> be declared in the argument list?
Lisp didn't have a LET form: local variables were just those declared
in a LAMBDA binding. If you wanted to establish any local binding
countour, you had to write a LAMBDA expression. A dialect of Lisp
called MDL ("Muddle") invented lambda-list keywords, including &AUX
for designating local variables. This made it into Lisp Machine Lisp,
where it was just a convenience for not having to write a LET.
Christopher C. Stacy wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>>But how &AUX came to be?
>>Aux variables are not arguments, so why should they
>>be declared in the argument list?
Here, I will invent a reason: Because they can reference only arguments
and preceding &aux variables for any derivation. In which case there is
a nice self-documenting quality to having them up there in Auxland.
>
>
> ...This made it into Lisp Machine Lisp,
> where it was just a convenience for not having to write a LET.
Check. This is why I have my bif ("binding if") and bwhen macros:
(bif (tgt (something-to-shoot))
(aim-at tgt)
(turn 90))
Use them allll the time.
You know, &aux is part of the frickin' language. It does work
beautifully in the example that started this Monty Python sketch.
Methinks a huge burden of disproof falls on those who would censor it.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Tue, 05 Oct 2004 01:14:27 +0000, Kenny Tilton wrote:
> You know, &aux is part of the frickin' language. It does work
> beautifully in the example that started this Monty Python sketch.
> Methinks a huge burden of disproof falls on those who would censor it.
I'm a relative newbie when it comes to CL, but I hate &aux. One use of
the parameter list of a function is to document the function's interface
to the outside world (e.g. in SLIME, after I type in the name of a
function, I get to see it's parameter list). I think it's horrible to
clutter that documentation with the local variables of the function.
Disclaimer: I come to CL by way of Scheme, and running as fast as I can
from Java, so maybe I value purity and cleanliness higher than others do.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <·······@abstractnonsense.com> writes:
> On Tue, 05 Oct 2004 01:14:27 +0000, Kenny Tilton wrote:
>
>> You know, &aux is part of the frickin' language. It does work
>> beautifully in the example that started this Monty Python sketch.
>> Methinks a huge burden of disproof falls on those who would censor it.
>
> I'm a relative newbie when it comes to CL, but I hate &aux. One use of
> the parameter list of a function is to document the function's interface
> to the outside world (e.g. in SLIME, after I type in the name of a
> function, I get to see it's parameter list). I think it's horrible to
> clutter that documentation with the local variables of the function.
Here's another one pro &aux: I've found it very convenient when
changing a local variable to a formal parameter and vice versa, for
example, only three letters need to change to switch between
(defun foo (x &aux (y init)) ...)
and
(defun foo (x &key (y init)) ...)
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
William Bland wrote:
> On Tue, 05 Oct 2004 01:14:27 +0000, Kenny Tilton wrote:
>
>
>>You know, &aux is part of the frickin' language. It does work
>>beautifully in the example that started this Monty Python sketch.
>>Methinks a huge burden of disproof falls on those who would censor it.
>
>
> I'm a relative newbie when it comes to CL, but I hate &aux. One use of
> the parameter list of a function is to document the function's interface
> to the outside world (e.g. in SLIME, after I type in the name of a
> function, I get to see it's parameter list). I think it's horrible to
> clutter that documentation with the local variables of the function.
Well that is substantive at least. But my IDE (AllegroCL) does not show
the &aux variables, and even if it did I do not think it would bother
me, so... bzzzt! :)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Check. This is why I have my bif ("binding if") and bwhen macros:
>
> (bif (tgt (something-to-shoot))
> (aim-at tgt)
> (turn 90))
>
> Use them allll the time.
why not :
(aif (something-to-shoot)
(aim-at it)
(turn 90) )
Christophe Turle.
Christophe Turle wrote:
> why not :
>
> (aif (something-to-shoot)
> (aim-at it)
> (turn 90) )
...because of the danger of accidental name capture:
(aif (something-to-shoot)
(aif (something-to-possess)
(aim-at it) ;; which one?
...
...)
Pascal
P.S.: Not a good reason for macro hygiene because this can also happen
as a result of manual refactoring. Just a sidenote... ;)
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@f1node01.rhrz.uni-bonn.de...
> Christophe Turle wrote:
>
> > why not :
> >
> > (aif (something-to-shoot)
> > (aim-at it)
> > (turn 90) )
>
> ...because of the danger of accidental name capture:
>
> (aif (something-to-shoot)
> (aif (something-to-possess)
> (aim-at it) ;; which one?
intuitively the last one : (something-to-possess)
> ...
> ...)
Note that your example is different from mine. In my example the 'aif' works
and is cleaner so why
don't use it ?
But i will check the case where aim-at is a macro expanding into a form
using an aif too.
In that case, it is the same example which may run into trouble...
Christophe Turle.
"Christophe Turle" <······@nospam.com> a �crit dans le message de
·····························@news.free.fr...
>
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@f1node01.rhrz.uni-bonn.de...
> > Christophe Turle wrote:
> >
> > > why not :
> > >
> > > (aif (something-to-shoot)
> > > (aim-at it)
> > > (turn 90) )
> >
> > ...because of the danger of accidental name capture:
> >
> > (aif (something-to-shoot)
> > (aif (something-to-possess)
> > (aim-at it) ;; which one?
>
> intuitively the last one : (something-to-possess)
>
> > ...
> > ...)
>
> Note that your example is different from mine. In my example the 'aif'
works
> and is cleaner so why
> don't use it ?
>
> But i will check the case where aim-at is a macro expanding into a form
> using an aif too.
> In that case, it is the same example which may run into trouble...
(defmacro aim-at (target)
`(awhen (weapon)
(fire :with it
:on ,target) ))
(defun weapon () 'gun)
(defun something-to-shoot () 'alien)
(defun fire (&key with on)
(format t "bang on ~a with ~a !!!" on with) )
> (awhen (something-to-shoot) (aim-at it))
bang on GUN with GUN !!!
aarghh !
Is the probleme coming from awhen ? no, it's coming from the macro. If we
define macros this way it works :
(defmacro aim-at (target)
(let ((m-target (gensym)))
`(let ((,m-target ,target))
(awhen (weapon)
(fire :with it
:on ,m-target )))))
[37]> (macroexpand-1 '(aim-at it))
(LET ((#:G759 IT)) (AWHEN (WEAPON) (FIRE :WITH IT :ON #:G759))) ;
T
[39]> (awhen (something-to-shoot) (aim-at it))
bang on ALIEN with GUN !!!
The problem is that now the macro's definition is ugly !
We have to transform :
(defmacro aim-at (target)
`(awhen (weapon)
(fire :with it
:on ,target) ))
in :
(defmacro aim-at (target)
(let ((m-target (gensym)))
`(let ((,m-target ,target))
(awhen (weapon)
(fire :with it
:on ,m-target )))))
I have to look at this more deeply ...
Christophe Turle.
"Christophe Turle" <······@nospam.com> a �crit dans le message de
····························@news.free.fr...
>
> "Christophe Turle" <······@nospam.com> a �crit dans le message de
> ·····························@news.free.fr...
> >
> > "Pascal Costanza" <········@web.de> a �crit dans le message de
> > ·················@f1node01.rhrz.uni-bonn.de...
> > > Christophe Turle wrote:
> > >
> > > > why not :
> > > >
> > > > (aif (something-to-shoot)
> > > > (aim-at it)
> > > > (turn 90) )
> > >
> > > ...because of the danger of accidental name capture:
> > >
> > > (aif (something-to-shoot)
> > > (aif (something-to-possess)
> > > (aim-at it) ;; which one?
> >
> > intuitively the last one : (something-to-possess)
> >
> > > ...
> > > ...)
> >
> > Note that your example is different from mine. In my example the 'aif'
> works
> > and is cleaner so why
> > don't use it ?
> >
> > But i will check the case where aim-at is a macro expanding into a form
> > using an aif too.
> > In that case, it is the same example which may run into trouble...
>
>
> (defmacro aim-at (target)
> `(awhen (weapon)
> (fire :with it
> :on ,target) ))
>
> (defun weapon () 'gun)
>
> (defun something-to-shoot () 'alien)
>
> (defun fire (&key with on)
> (format t "bang on ~a with ~a !!!" on with) )
>
>
> > (awhen (something-to-shoot) (aim-at it))
> bang on GUN with GUN !!!
>
> aarghh !
>
> Is the probleme coming from awhen ? no, it's coming from the macro. If we
> define macros this way it works :
>
> (defmacro aim-at (target)
> (let ((m-target (gensym)))
> `(let ((,m-target ,target))
> (awhen (weapon)
> (fire :with it
> :on ,m-target )))))
>
> [37]> (macroexpand-1 '(aim-at it))
> (LET ((#:G759 IT)) (AWHEN (WEAPON) (FIRE :WITH IT :ON #:G759))) ;
> T
>
> [39]> (awhen (something-to-shoot) (aim-at it))
> bang on ALIEN with GUN !!!
>
>
> The problem is that now the macro's definition is ugly !
>
> We have to transform :
>
> (defmacro aim-at (target)
> `(awhen (weapon)
> (fire :with it
> :on ,target) ))
>
> in :
>
> (defmacro aim-at (target)
> (let ((m-target (gensym)))
> `(let ((,m-target ,target))
> (awhen (weapon)
> (fire :with it
> :on ,m-target )))))
>
>
> I have to look at this more deeply ...
a form much closer :
(defmacro aim-at (target)
(let ((p-target target)
(target (gensym) ))
`(let ((,target ,p-target))
(awhen (weapon)
(fire :with it
:on ,target )))))
But i think it's a bad direction. Here, the good solution is :
(defun aim-at (target)
(awhen (weapon)
(fire :with it
:on target )))
It doesn't solve the macro's problem. But i suspect the problem just arise
from bad macro use ...
So i will just look for any evidence of the contrary and just go on using
anaphoric macros.
In any case this problem is not solved by using bwhen ;-)
Christophe Turle.
From: Matthew Danish
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <87d5zu1riy.fsf@mapcar.org>
"Christophe Turle" <······@nospam.com> writes:
> In any case this problem is not solved by using bwhen ;-)
Sure it is (assuming you need a macro solution). Your problem is that
you are trying to use the same variable, IT, for two different
bindings.
(defmacro aim-at (target)
(let ((weapon (gensym)))
`(bwhen (,weapon (weapon))
(fire :with ,weapon :on ,target))))
or just
(defmacro aim-at (target)
(let ((weapon (gensym)))
`(let ((,weapon (weapon)))
(when ,weapon (fire :with ,weapon :on ,target)))))
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
"Matthew Danish" <··········@cmu.edu> a �crit dans le message de
···················@mapcar.org...
> "Christophe Turle" <······@nospam.com> writes:
> > In any case this problem is not solved by using bwhen ;-)
>
> Sure it is (assuming you need a macro solution). Your problem is that
> you are trying to use the same variable, IT, for two different
> bindings.
>
> (defmacro aim-at (target)
> (let ((weapon (gensym)))
> `(bwhen (,weapon (weapon))
> (fire :with ,weapon :on ,target))))
Not really you are using a combination of let/bwhen not bwhen alone ;-)
But yes it works, even if i'm not satisfied with this solution.
> or just
>
> (defmacro aim-at (target)
> (let ((weapon (gensym)))
> `(let ((,weapon (weapon)))
> (when ,weapon (fire :with ,weapon :on ,target)))))
>
just ? it is ugly with the two 'let'. three lines instead of one.
Christophe Turle.
From: Matthew Danish
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <878yai1h3z.fsf@mapcar.org>
"Christophe Turle" <······@nospam.com> writes:
> "Matthew Danish" <··········@cmu.edu> a �crit dans le message de
> ···················@mapcar.org...
> > (defmacro aim-at (target)
> > (let ((weapon (gensym)))
> > `(bwhen (,weapon (weapon))
> > (fire :with ,weapon :on ,target))))
>
> Not really you are using a combination of let/bwhen not bwhen alone ;-)
You need to be more careful when examining macros. If you look
closely, you'll notice that there is a ` before the BWHEN form. The
LET operates in the macro, but the BWHEN is part of the returned
value.
> > or just
> >
> > (defmacro aim-at (target)
> > (let ((weapon (gensym)))
> > `(let ((,weapon (weapon)))
> > (when ,weapon (fire :with ,weapon :on ,target)))))
> >
>
> just ? it is ugly with the two 'let'. three lines instead of one.
Yes, `just' because it uses fewer operators than the previous
implementation. The BWHEN will just expand into a LET and a WHEN just
like this, anyhow. Also, once again, one of the LETs is part of the
macro, but the other one is part of the returned source code value.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
"Matthew Danish" <··········@cmu.edu> a �crit dans le message de
···················@mapcar.org...
> "Christophe Turle" <······@nospam.com> writes:
> > "Matthew Danish" <··········@cmu.edu> a �crit dans le message de
> > ···················@mapcar.org...
> > > (defmacro aim-at (target)
> > > (let ((weapon (gensym)))
> > > `(bwhen (,weapon (weapon))
> > > (fire :with ,weapon :on ,target))))
> >
> > Not really you are using a combination of let/bwhen not bwhen alone ;-)
>
> You need to be more careful when examining macros. If you look
> closely, you'll notice that there is a ` before the BWHEN form. The
> LET operates in the macro, but the BWHEN is part of the returned
> value.
My point was not what will be in the expanded form. I just noticed that when
we write the program we have to think at the 'let' AND the 'bwhen'. So your
mind have to remember the combination not just bwhen.
But in this case, the 'let' form is just the application of the well known
practice to avoid variables capture.
So, i agree with this form.
> > > or just
> > >
> > > (defmacro aim-at (target)
> > > (let ((weapon (gensym)))
> > > `(let ((,weapon (weapon)))
> > > (when ,weapon (fire :with ,weapon :on ,target)))))
> > >
> >
> > just ? it is ugly with the two 'let'. three lines instead of one.
>
> Yes, `just' because it uses fewer operators than the previous
> implementation.
> The BWHEN will just expand into a LET and a WHEN just
> like this, anyhow.
Even little abstractions are a gain.
(defmacro aim-at (target)
(let ((weapon (gensym)))
`(bwhen (,weapon (weapon)) (fire :with ,weapon :on ,target)) ))
This form is really cleaner than yours.
> Also, once again, one of the LETs is part of the
> macro, but the other one is part of the returned source code value.
So, ok for the first 'let', not for the second one.
Christophe Turle.
Christophe Turle wrote:
> It doesn't solve the macro's problem. But i suspect the problem just arise
> from bad macro use ...
>
> So i will just look for any evidence of the contrary and just go on using
> anaphoric macros.
It's not a macro problem. Your code may first look like this:
(aif (something-to-shoot)
(aim-at it))
And then later on, because of refactoring, like that:
(aif (something-to-shoot)
(aif (something-to-possess)
(aim-at it)))
No macro involved here. In such a simple toy example, the problem is
easy to spot and correct. In larger real-world cases maybe not.
I am not arguing against anaphoric macros. CALL-NEXT-METHOD and
LOOP-FINISH are good examples of automatically generated definitions.
It's just that you have to be aware of the problem, and sometimes it's
better not to use anaphora.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@f1node01.rhrz.uni-bonn.de...
> Christophe Turle wrote:
>
> > It doesn't solve the macro's problem. But i suspect the problem just
arise
> > from bad macro use ...
> >
> > So i will just look for any evidence of the contrary and just go on
using
> > anaphoric macros.
>
> It's not a macro problem. Your code may first look like this:
>
> (aif (something-to-shoot)
> (aim-at it))
>
> And then later on, because of refactoring, like that:
>
> (aif (something-to-shoot)
> (aif (something-to-possess)
> (aim-at it)))
>
> No macro involved here. In such a simple toy example, the problem is
> easy to spot and correct. In larger real-world cases maybe not.
And why ? because the code will be longer ? If it is the case this means the
code needs more refactoring. All function/macro should be clear enough for
you to be full confident about them.
By contrast, macros/functions used in your code should be used without
knowing their body. And it was not the case there.
> I am not arguing against anaphoric macros. CALL-NEXT-METHOD and
> LOOP-FINISH are good examples of automatically generated definitions.
> It's just that you have to be aware of the problem, and sometimes it's
> better not to use anaphora.
ok.
Christophe Turle.
Christophe Turle wrote:
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@f1node01.rhrz.uni-bonn.de...
>>In such a simple toy example, the problem is
>>easy to spot and correct. In larger real-world cases maybe not.
>
> And why ? because the code will be longer ?
Exactly.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@newsreader2.netcologne.de...
>
> Christophe Turle wrote:
>
> > "Pascal Costanza" <········@web.de> a �crit dans le message de
> > ·················@f1node01.rhrz.uni-bonn.de...
>
> >>In such a simple toy example, the problem is
> >>easy to spot and correct. In larger real-world cases maybe not.
> >
> > And why ? because the code will be longer ?
>
> Exactly.
You cut my answer saying that in this case the code needs refactoring again.
Code should be simple enough to be understood easily. If it's not the case,
this is a sign that the code is not good enough.
I don't want to argue here. Just to be sure which point we see differently.
Christophe Turle.
Christophe Turle wrote:
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@newsreader2.netcologne.de...
>
>>Christophe Turle wrote:
>>
>>>"Pascal Costanza" <········@web.de> a �crit dans le message de
>>>·················@f1node01.rhrz.uni-bonn.de...
>>
>>>>In such a simple toy example, the problem is
>>>>easy to spot and correct. In larger real-world cases maybe not.
>>>
>>>And why ? because the code will be longer ?
>>
>>Exactly.
>
> You cut my answer saying that in this case the code needs refactoring again.
I hope you don't think that this wasn't intended as a kind of censorship. ;)
> Code should be simple enough to be understood easily. If it's not the case,
> this is a sign that the code is not good enough.
This depends. There are two different, indepedent responses here.
a) Code shouldn't be simpler than necessary. Some problems are
inherently complex and the code should reflect that, or else it is in
danger of getting oversimplified.
b) Even if code is simple, this is usually only the end result. At least
in my personal experience, code is quite hairy most of the time until I
find the striking elegant solution when everything falls into place.
Most languages are optimized to give the end result especially elegant
aesthetic qualities. However most of the time during development, code
is incorrect and inelegant, and IMHO it's more important how well a
language supports you while that's the case.
Of course, this still leaves room for many different approaches and
language features, but I think that Common Lisp is especially
well-suited in that regard. But it also seems to me that an overuse of
anaphoric macros, especially with non-distinctive names, is a bad idea
because of b).
> I don't want to argue here. Just to be sure which point we see differently.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@f1node01.rhrz.uni-bonn.de...
> Christophe Turle wrote:
>
> > "Pascal Costanza" <········@web.de> a �crit dans le message de
> > ·················@newsreader2.netcologne.de...
> >
> >>Christophe Turle wrote:
> >>
> >>>"Pascal Costanza" <········@web.de> a �crit dans le message de
> >>>·················@f1node01.rhrz.uni-bonn.de...
> >>
> >>>>In such a simple toy example, the problem is
> >>>>easy to spot and correct. In larger real-world cases maybe not.
> >>>
> >>>And why ? because the code will be longer ?
> >>
> >>Exactly.
> >
> > You cut my answer saying that in this case the code needs refactoring
again.
>
> I hope you don't think that this wasn't intended as a kind of censorship.
;)
nop ;-)
> > Code should be simple enough to be understood easily. If it's not the
case,
> > this is a sign that the code is not good enough.
>
> This depends. There are two different, indepedent responses here.
>
> a) Code shouldn't be simpler than necessary.
hum ...
> Some problems are inherently complex and the code should reflect that or
else it is in danger of getting oversimplified.
Code should reflect the domain complexity but the expression of the problem
should be as simple as possible.
> b) Even if code is simple, this is usually only the end result. At least
> in my personal experience, code is quite hairy most of the time until I
> find the striking elegant solution when everything falls into place.
> Most languages are optimized to give the end result especially elegant
> aesthetic qualities. However most of the time during development, code
> is incorrect and inelegant, and IMHO it's more important how well a
> language supports you while that's the case.
so we agree that the road is to simplify code.
> Of course, this still leaves room for many different approaches and
> language features, but I think that Common Lisp is especially
> well-suited in that regard. But it also seems to me that an overuse of
> anaphoric macros, especially with non-distinctive names, is a bad idea
> because of b).
why a bad idea ? Because bugs appear ? Isnt'it a good thing to have your
program shout that you have made a mistake ?
I like programming dangerously. Bugs come sooner, and your app becomes
safer.
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
Christophe Turle wrote:
> "Pascal Costanza" <········@web.de> a �crit dans le message de
> ·················@f1node01.rhrz.uni-bonn.de...
[...]
>>b) Even if code is simple, this is usually only the end result. At least
>>in my personal experience, code is quite hairy most of the time until I
>>find the striking elegant solution when everything falls into place.
>>Most languages are optimized to give the end result especially elegant
>>aesthetic qualities. However most of the time during development, code
>>is incorrect and inelegant, and IMHO it's more important how well a
>>language supports you while that's the case.
>
> so we agree that the road is to simplify code.
Yep.
>>Of course, this still leaves room for many different approaches and
>>language features, but I think that Common Lisp is especially
>>well-suited in that regard. But it also seems to me that an overuse of
>>anaphoric macros, especially with non-distinctive names, is a bad idea
>>because of b).
>
> why a bad idea ? Because bugs appear ? Isnt'it a good thing to have your
> program shout that you have made a mistake ?
Careful, that reasoning gives you static typing. ;-)
I think the danger with anaphora is that they get unintended bindings
that survive for some time, and only later give rise to observably wrong
behavior. Then you'll have the problem of finding the cause of such a
problem.
Of course, I don't have empirical data to back my claim, so I may be wrong.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> ...because of the danger of accidental name capture:
>
> (aif (something-to-shoot)
> (aif (something-to-possess)
> (aim-at it) ;; which one?
> ...
> ...)
(aif (something-to-shoot)
(aif (something-to-possess)
(aim-at this it)
(aim-at the other one) ;-)
...
...)
> P.S.: Not a good reason for macro hygiene because this can also happen
> as a result of manual refactoring. Just a sidenote... ;)
--
__Pascal Bourguignon__ http://www.informatimago.com/
To vote Democrat or Republican, it's like changing of cabin in the Titanic.
Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> (aif (something-to-shoot)
> (aif (something-to-possess)
> (aim-at it) ;; which one?
> ...
> ...)
You always hurt
The one you love...
From: Christopher C. Stacy
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <uy8iii2i6.fsf@news.dtpq.com>
···············@yahoo.com (Mark McConnell) writes:
> Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> > (aif (something-to-shoot)
> > (aif (something-to-possess)
> > (aim-at it) ;; which one?
> > ...
> > ...)
>
> You always hurt
> The one you love...
Darling, if I broke your code last night...
Christophe Turle wrote:
>>Check. This is why I have my bif ("binding if") and bwhen macros:
>>
>>(bif (tgt (something-to-shoot))
>> (aim-at tgt)
>> (turn 90))
>>
>>Use them allll the time.
>
>
> why not :
>
> (aif (something-to-shoot)
> (aim-at it)
> (turn 90) )
Nothing wrong with that. But now one is not saving much compared to bif,
and one is losing the self-documenting quality of having a custom-named
variable in bigger wadges of code where references to IT would not be so
near its derivation. But, again, I see nothing wrong with AIF.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"Christophe Turle" <······@nospam.com> writes:
> [...]
> (aif (something-to-shoot)
> (aim-at it)
> (turn 90) )
"'[...] and even Stigand, the patriotic archbishop of Canterbury,
found it advisable---'"
"Found _what_?" said the Duck.
"Found _it_," the Mouse replied rather crossly: "of course you
know what 'it' means."
"I know what 'it' means well enough, when _I_ find a thing," said
the Duck: "it's generally a frog, or a worm. The question is,
what did the archbishop find?"
[Lewis Carroll, _Alice's Adventures in Wonderland_, Chapter III]
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: Christophe Turle
Subject: Re: [OT] the meaning of "it" (Ex: History of the &AUX hack? Was: Re: removeText)
Date:
Message-ID: <4164f048$0$761$636a15ce@news.free.fr>
"Vassil Nikolov" <········@poboxes.com> a �crit dans le message de
······················@janus.vassil.nikolov.names...
> "Christophe Turle" <······@nospam.com> writes:
>
> > [...]
> > (aif (something-to-shoot)
> > (aim-at it)
> > (turn 90) )
>
> "'[...] and even Stigand, the patriotic archbishop of Canterbury,
> found it advisable---'"
>
> "Found _what_?" said the Duck.
>
> "Found _it_," the Mouse replied rather crossly: "of course you
> know what 'it' means."
>
> "I know what 'it' means well enough, when _I_ find a thing," said
> the Duck: "it's generally a frog, or a worm. The question is,
> what did the archbishop find?"
>
> [Lewis Carroll, _Alice's Adventures in Wonderland_, Chapter III]
>
> ---Vassil.
Does it mean that 'It' is not worth using in English for you ?
^^
cool in fact ;-) no ? if yes, why don't use it in CL ? Thus i agree we
should only use it when it adds clarity and not ambiguity.
Christophe turle.
From: Joe Marshall
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <lleljnp4.fsf@ccs.neu.edu>
Pascal Bourguignon <····@mouse-potato.com> writes:
> But how &AUX came to be?
>
> (Personally, I object to their use)
They are occasionally necessary in DEFSTRUCT constructors.
From: Peter Seibel
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <m31xgdvtyn.fsf@javamonkey.com>
Joe Marshall <···@ccs.neu.edu> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> But how &AUX came to be?
>>
>> (Personally, I object to their use)
>
> They are occasionally necessary in DEFSTRUCT constructors.
But then you gotta ask yourself, do you really want to be writing
DEFSTRUCT constructors. ;-)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Joe Marshall
Subject: Re: History of the &AUX hack? Was: Re: removeText
Date:
Message-ID: <zn305310.fsf@ccs.neu.edu>
Peter Seibel <·····@javamonkey.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> Pascal Bourguignon <····@mouse-potato.com> writes:
>>
>>> But how &AUX came to be?
>>>
>>> (Personally, I object to their use)
>>
>> They are occasionally necessary in DEFSTRUCT constructors.
>
> But then you gotta ask yourself, do you really want to be writing
> DEFSTRUCT constructors. ;-)
Not often, but sometimes....
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······························@twister.nyc.rr.com...
> Coby Beck wrote:
>> IMCO (In My Correct Opinion :) &aux should not be recommended to
>> newbies...
>> Why not LET?
>
> Why not &aux?
It is rather uncommonly used.
It is extra syntax to learn that provides nothing you can't have in the
usual way of introducing local variables.
It exposes internal implementation in the function's interface.
> Why not let?
Yes, why not?
> This isn't an argument!
Why should it be? There is nothing wrong with discussing style choices.
> 'Tis!
> 'Tisn't!
> 'Tis!
> 'Tisn't!
> 'Time's up.
> 'That wasn't five minutes!
> 'Twas.
Sorry, "Contradiction" is down the hall! ;)
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<····················@twister.nyc.rr.com>...
> David B. Ellis wrote:
>
> > I'm learning Lisp. As part of an exercise I'm writing removeText.
> >
> > I have two questions about it. First, is there a Common Lisp function
> > that I've overlooked that would do this for me?
>
> Search would save you a lot of trouble.
>
> And second, how would you
> > write this function?
>
> (defun remove-text (src tgt &aux (tgt-len (length tgt)))
> (do ((x (search tgt src)(search tgt src :start2 x)))
> ((not x) src)
> (setq src (concatenate 'string
> (subseq src 0 x)
> (subseq src (+ x tgt-len))))))
>
> btw, I am a big fan of camelCase, but I am Satan. The Lisp Faithful will
> savage you for it. Otherwise your code is fine. You might want to try
> revising it to take advantage of search and see how it comes out.
>
> kenny
>
>
>
Thanks for your suggestions. Here's what I ended up with:
(defun remove-text (text-to-remove text)
(let
((remove-length (length text-to-remove)))
(do
((i
(search text-to-remove text)
(search text-to-remove text :start2 i)))
((not i) text)
(setq text (concatenate 'string
(subseq text 0 i)
(subseq text (+ i remove-length)))))))
David B. Ellis wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<····················@twister.nyc.rr.com>...
>
>>David B. Ellis wrote:
>>
>>
>>>I'm learning Lisp. As part of an exercise I'm writing removeText.
>>>
>>>I have two questions about it. First, is there a Common Lisp function
>>>that I've overlooked that would do this for me?
>>
>>Search would save you a lot of trouble.
>>
>> And second, how would you
>>
>>>write this function?
>>
>>(defun remove-text (src tgt &aux (tgt-len (length tgt)))
>> (do ((x (search tgt src)(search tgt src :start2 x)))
>> ((not x) src)
>> (setq src (concatenate 'string
>> (subseq src 0 x)
>> (subseq src (+ x tgt-len))))))
>>
>>btw, I am a big fan of camelCase, but I am Satan. The Lisp Faithful will
>>savage you for it. Otherwise your code is fine. You might want to try
>>revising it to take advantage of search and see how it comes out.
>>
>>kenny
>>
>>
>>
>
>
> Thanks for your suggestions. Here's what I ended up with:
>
> (defun remove-text (text-to-remove text)
> (let
> ((remove-length (length text-to-remove)))
>
> (do
> ((i
> (search text-to-remove text)
> (search text-to-remove text :start2 i)))
>
> ((not i) text)
>
> (setq text (concatenate 'string
> (subseq text 0 i)
> (subseq text (+ i remove-length)))))))
Cool. Now here is a version using loop:
(defun remove-text (text-to-remove text)
(loop with remove-length = (length text-to-remove)
for i = (search text-to-remove text)
then (search text-to-remove text :start2 i)
while i
do (setq text (concatenate 'string
(subseq text 0 i)
(subseq text (+ i remove-length))))
finally (return text)))
Uglier, but easier to type once one gets the hang of loop.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Cool. Now here is a version using loop:
>
> (defun remove-text (text-to-remove text)
> (loop with remove-length = (length text-to-remove)
> for i = (search text-to-remove text)
> then (search text-to-remove text :start2 i)
> while i
> do (setq text (concatenate 'string
> (subseq text 0 i)
> (subseq text (+ i remove-length))))
> finally (return text)))
Just to point out a useful LOOP idiom, here's another way:
(defun remove-text (text-to-remove text)
(with-output-to-string (s)
(loop
with remove-length = (length text-to-remove)
for prev-end = 0 then (+ start remove-length)
for start = (search text-to-remove text :start2 prev-end)
do (write-string text s :start prev-end :end start)
while start)))
The idiom is using prev-end as the argument to :start2 to avoid having
to duplicate the call to SEARCH, once with :start2 and once without.
Also, though I didn't profile it, I suspect that this version should
be more efficient is it doesn't have to make as many intermediate
strings.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp