Topic: Question 37

[MP]

Question for the LISPERS.

Suppose you needed to pen a couple padding functions that take a string and right or left pad it with n specified characters.

You might code it like this (naming after antiquated basic equivalents):

RSET:

Code: [Select]

(defun rset ( text padding maxlen )
    (substr
        (   (lambda ( )
                (while 
                    (<
                        (strlen (setq padding (strcat padding padding)))
                        maxlen
                    )
                )
                (setq text (strcat padding text))                               
            )
        )
        (- (strlen text) (1- maxlen))
    )
)
Example:

Code: [Select]

(rset "text" " " 10)

==> "      text"
LSET:

Code: [Select]

(defun lset ( text padding maxlen )
    (substr
        (   (lambda ( )
                (while 
                    (<
                        (strlen (setq padding (strcat padding padding)))
                        maxlen
                    )
                )
                (strcat text padding)
            )
        )
        1
        maxlen
    )
)
Example:

Code: [Select]

(lset "text" " " 10)

==> "text      "
Then you notice there is duplicated logic, so you distil the functions by writing an auxiliary function:

SETAUX:

Code: [Select]

(defun setaux ( padding maxlen )
    (while 
        (<
            (strlen (setq padding (strcat padding padding)))
            maxlen
        )
    )
    padding
)
RSET:

Code: [Select]

(defun rset ( text padding maxlen )
    (substr
        (setq text
            (strcat
                (setaux padding maxlen)
                text
            )
        )                               
        (- (strlen text) (1- maxlen))
    )
)
LSET:

Code: [Select]

(defun lset ( text padding maxlen )
    (substr
        (strcat text (setaux padding maxlen))
        1
        maxlen
    )
)
You're thinking it looks pretty good but then you realize, at least theoretically, that it demonstrates poor coding practice.
 
What poor coding practice do the rewritten functions demonstrate?

What would that practice be called?

On the other hand you realize they also demonstrate good coding practice.

What good coding practice do the rewritten functions demonstrate?

What would that practice be called?

Kerry, please hold off responding to this one, at least for a bit.

[Kerry]

Time to exercise the wetware < the stuff between the ears>

[whdjr]

Question for the LISPERS.

Suppose you needed to pen a couple padding functions that take a string and right or left pad it with n specified characters.

You might code it like this (naming after antiquated basic equivalents):

What poor coding practice do the rewritten functions demonstrate?

Answer:  Haven't figured this one out yet.  Maybe doing more than one thing in a function.

What good coding practice do the rewritten functions demonstrate?

Answer:  You have one function doing one thing.

[Mark]

Hint: the word 'padding'

[Chuck Gabriel]

I would say that it is good that you used named abstractions and bad that the names chosen aren't particulary expressive.

Some people would say that it is bad that your functions have side effects (i.e. they modify their arguments).

[whdjr]

I did think it was kind of odd how 'lset' added characters to the right side and 'rset' added characters to the left side.

It must be a Canadian thing!

[MP]

I did think it was kind of odd how 'lset' added characters to the right side and 'rset' added characters to the left side.

It must be a Canadian thing!

Perhaps the vb/vba help was authored by a canuck!

Nudge: Read up on lset/rest vb/vba functions.

[MP]

I would say that it is good that you used named abstractions and bad that the names chosen aren't particulary expressive.

Some people would say that it is bad that your functions have side effects (i.e. they modify their arguments).

Agree on both counts, particularly the latter.

[MP]

Answer: You have one function doing one thing.

Usually that's a very good thing in my book.

Why might it not be?

[Kerry]

Why might it not be?

passing an abundance of variables back and forwards can be unkind to your performance.

It's interesting that the OOP concepts of abstraction and obfuscation have snuck in.

[MP]

... and while not generally a lisper's concern, if considering software architecture as a science -- what about cohesion / coupling issues?

[LE]

As I mentioned, I am not a programmer....

But I would use for the auxiliary function something like this:

Code: [Select]

(defun setaux  (padding maxlen / str)
  (setq str "")
  (repeat maxlen (setq str (strcat str padding)))
  str)

And now that heard today about turbo pascal - not here.... here is a translation of ins v1.5 (insert)

Code: [Select]

(defun ins  (src tgt inx)
  (if (/= inx 0)
    (strcat (substr tgt 1 (1- inx)) src (substr tgt inx))
    (eval tgt)))

(defun ins_str (src tgt inx)
  (if (/= inx 0)
    (strcat (substr tgt 1 (1- inx)) src (substr tgt inx))
    (eval tgt)))

(defun pos_str (subcad cad / cnt)
  (setq cnt 1)
  (while
    (and (/= subcad (substr cad cnt (strlen subcad)))
(< cnt (strlen cad)))
     (setq cnt (1+ cnt)))
  (if (= subcad (substr cad cnt (strlen subcad)))
    (eval cnt)
    (eval 0)))

And the answer is................................................ ?

[LE]

and also would avoid the re-write of var "text"

Code: [Select]

(defun rset ( text padding maxlen )
    (substr
        (setq text
            (strcat
                (setaux padding maxlen)
                text
            )
        )                               
        (- (strlen text) (1- maxlen))
    )
)

I never had changed the value of an argument on my functions.... as far I remember....

[Chuck Gabriel]

...
I never had changed the value of an argument on my functions.... as far I remember....

I try to avoid it in lisp programs, but there was a time when I considered anything fair game as long as it got the job done.

However, it is a very common paradigm in some languages, particularly VB(A).  As long as it is clearly documented, I don't see a problem with it.

[Kerry]

As I mentioned, I am not a programmer....
 ...

Luis this may lose something in translation ..

I was raised on a farm. One of our neighbours was an Irishman who has a good turn of phrase < and a lovely daughter >.
2 of his expressions have stayed in my menory.

I was always in a hurry, and he'd say to me "Take your hurry, boy."

The other expression is fairly common.
"Boy, If it quacks like a duck, chances are it waddles"  taken by me to mean that things are what they are, irrespective of what we call them.

As I mentioned, I am not a programmer....
 ...

Perhaps you mean you are not formally trained. .. I'm not, and few of us are.

QUACK.  

[Chuck Gabriel]

Yeah.  You won't find the word Bozo anywhere in my resume, but it doesn't change the facts.

[Kerry]

hehehehe,
now, THAT'S funny ..

[LE]

Perhaps you mean you are not formally trained. .. I'm not, and few of us are.
QUACK.  

 

[LE]

Yeah.  You won't find the word Bozo anywhere in my resume, but it doesn't change the facts.

I am reading my resume... right now.... just to make sure.....

[CAB]

and also would avoid the re-write of var "text"

I never had changed the value of an argument on my functions.... as far I remember....

Not sure I understand (battling the flu)
But the 'text' var in the subroutine is a local var & has no effect on the 'text' var in the calling routine.
So why would you avoid change the argument?

[LE]

Code: [Select]

(defun rset ( text padding maxlen )
    (substr
        (setq text
            (strcat
                (setaux padding maxlen)
                text
            )
        )                               
        (- (strlen text) (1- maxlen))
    )
)

Here..... get well!

[Kerry]

So why would you avoid change the argument?

From a purist perspective, which doesn't always seem relevant with Lisp ...

Variable typing and naming is generally considered critical to computer language debugging.

.. but debugging is more than just finding errors after they present themselves, it's also a proactive process to test the flow and integrity of your routine.

One mechanisn for doing this involves the investigation of variable values and testing them against preproven values.

A more consistant strategy for doing this can be determined if the variable values are assigned in more than a seemingly whimsical manner. < sorry, thats my sense of humor taking over>   

 

[added: Does that sound like , as jonesy would say, pretentious nonsense ]

[CAB]

[added: Does that sound like , as jonesy would say, pretentious nonsense ]

Yes, but I see your point.

[LE]

Question for the LISPERS.

No solution .... still ?

[CAB]

Kerry
How ironic, I was just doing some modifications to my TextInsert Routine & that very thing
bit me in the butt. he he he
Looking back through my older code I sure need to re write most of it.
Who has the time to go back though, until it breaks.