Append strings and variables

[samifox]

Hi

In some places in my code I want to print out the value of a veriable appended to a string such as

(printc “the value of dx is: ” + dx) 

How?

 

 

Thanks

Shay

[dbroada]

long time since I've used LISP but I think you need STRCAT (string concatenation)

[BlackBox]

1+ for STRCAT

 

The "+" operator used here is applicable in C# (perhaps also in ARX?), for example this written in LISP:

 

(setq foo "Bowties")
(princ (strcat "\n** " foo " are cool ** "))

 

... Is written in C# as:

 

string foo = "Bowties";
ed.WriteMessage("\n** " + foo + " are cool ** ");

 

... Or as:

 

string foo = "Bowties";
ed.WriteMessage("\n** {0} are cool ** ", foo);

[Stefan BMR]

(princ (strcat "\nThe value of dx is " (vl-princ-to-string dx)))

[samifox]

seems like i need a utility function here...

to looonnng

[Stefan BMR]

seems like i need a utility function here...

to looonnng

 

(defun princ_val (x)
 (princ
   (strcat
     "\nThe value of "
     (vl-symbol-name x)
     " is "
     (vl-princ-to-string (eval x))
     )
   )
 (princ)
 )

Usage (note the quote):

_$ (setq a 2 b "ABC" c '(1 2 3))
(1 2 3)
_$ (princ_val 'a)

The value of A is 2
_$ (princ_val 'b)

The value of B is ABC
_$ (princ_val 'c)

The value of C is (1 2 3)
_$ (princ_val 'd)

The value of D is nil
_$ 

[Lee Mac]

Or:

(defun _prin1 ( *sym* )
   (print *sym*)
   (princ "= ")
   (prin1 (eval *sym*))
   (princ)
)

_$ (setq a 2 b "ABC" c '(1 2 3))
(1 2 3)
_$ (_prin1 'a)

A = 2
_$ (_prin1 'b)

B = "ABC"
_$ (_prin1 'c)

C = (1 2 3)

@Stefan, be careful with (princ_val 'x)

 

In response to the OP's question:

(princ "\nThe value of dx is: ")
(prin1 dx)

[Stefan BMR]

@Stefan, be careful with (princ_val 'x)

 

Ahh yes, of course, I know for sure I tried something like this before, but I forgot about this issue.

[neophoible]

Might not mapcar be used here?

 

  (mapcar 'princ '(“the value of dx is: ” dx))

Or as a utility

(defun MPrint (list_to_print)
 (mapcar 'princ list_to_print)
 (princ)
)

I won't argue about length of code here, but I will say that Polish notation is very useful when you have a long list.

 

OK, I will also note that length of code may have a lot to do with the prowess of the programmer. If you look around, you may see that the best programmers often have the shortest code, but you may have a much harder time deciphering it than the much longer code of a beginner.

[Lee Mac]

Might not mapcar be used here?

 

(mapcar 'princ '(“the value of dx is: ” dx))

Or as a utility

(defun MPrint (list_to_print)
 (mapcar 'princ list_to_print)
 (princ)
)

 

It could, but it would be redundant since you would be constructing a list for the sole purpose of being able to use mapcar, and the resulting list returned by mapcar would also not be used.

(mapcar 'princ (list "the value of dx is: " dx))

As opposed to:

(princ "the value of dx is: ")
(princ dx)

[neophoible]

It could, but it would be redundant since you would be constructing a list for the sole purpose of being able to use mapcar, and the resulting list returned by mapcar would also not be used.

(mapcar 'princ (list "the value of dx is: " dx))

As opposed to:

(princ "the value of dx is: ")
(princ dx)

 

OK. And I can't help but agree when the list is short. But now I'm curious whether all of this still holds true when increasing the list. One may very well wish to include several items of output in one go. Another way to ask the question is, is there a better way to apply a print function to a worthier list? Or do you prefer lots of prints, princs & prin1s?

[Lee Mac]

Another way to ask the question is, is there a better way to apply a print function to a worthier list? Or do you prefer lots of prints, princs & prin1s?

 

It would depend upon the data to be printed; if the data is already in a list format, then I would opt for a foreach loop to print each item in the list (since the return of the prin* evaluation is not likely to be required); however, if the data is not in a list format, I see no reason to construct a list simply to use a list iterator (such as mapcar / foreach etc.) in order to print the data.

[neophoible]

Thanks for sharing, Lee. It's always interesting to learn what the experts know.

 

...I see no reason to construct a list simply to use a list iterator...in order to print the data.

Except perhaps if one wishes to be lazy in writing his code? From what you already said, I guessed that foreach would be your preference over mapcar in the case I mentioned.

 

I suppose your reluctance has to do with extra time for the prog to run? Or memory constraints? I'd never really thought much about that in a case like this. For most of the stuff I've done, it didn't seem to matter much, especially compared to messing with the drawing itself, but I can't claim to have done any timing studies on it.

[neophoible]

@Stefan, be careful with (princ_val 'x)

 

The warning went right over my head. Lee or Stefan, what's the deal here?

[Lee Mac]

From what you already said, I guessed that foreach would be your preference over mapcar in the case I mentioned.

 

Again, it would depend on the application, if I were to require the return of the prin* evaluations, I would opt for mapcar, since the result of each evaluation is present in the list returned (whereas foreach would require an additional variable and list construction); its all about choosing the right tool for the job.

 

I suppose your reluctance has to do with extra time for the prog to run? Or memory constraints? I'd never really thought much about that in a case like this. For most of the stuff I've done, it didn't seem to matter much, especially compared to messing with the drawing itself, but I can't claim to have done any timing studies on it.

 

Regardless of the application or diminutive nature of the task, I always strive to write my code as efficiently as possible, whilst also retaining a balance of readability to keep the code maintainable (for example, maximum efficiency is not always a practical route if the code becomes needlessly obfuscated).

 

However, I would say that if you find yourself repeating expressions over and over in the source code, then usually its time to rethink how your data is structured & stored.

 

The warning went right over my head. Lee or Stefan, what's the deal here?

 

Consider a function requiring a quoted symbol argument:

(defun foo ( x )
   (print x)
   (prin1 (eval x))
   (princ)
)

In normal operation:

_$ (setq a 123.0)
123.0
_$ (foo 'a)

A 123.0

However, if the function is passed a quoted symbol which matches the parameter symbol, since the parameter symbol is local to the function, when evaluated you are evaluating the parameter symbol to display the argument data, and not the symbol that was passed to the function:

_$ (setq x "abc")
"abc"
_$ (foo 'x)

X X

The concept is similar to indirect addressing in other languages, e.g. consider this console example:

_$ (setq a 'b)
B
_$ (set a 123)
123
_$ b
123

By passing the same symbol as an argument to the function, you are effectively doing this:

_$ (setq a 'a)
A
_$ (eval a)
A

[neophoible]

Lee, many thanks for the explanation. You are very thorough. I sort of have an understanding of the idea, at least indirectly.

 

So, it was that he would be passing the name of the argument. If so, it would also hold for yours if it was passed '*sym*.

 

I was just ruminating on this some more and it looks like one should be very careful if passing a symbol that's used locally period. Which might lead to the caveat: Don't pass symbols unless you know for sure the calling routine doesn't use them (or you have a really good reason to do so and really know what you are doing, e.g., have a naming system worked out, etc).

 

Again, thanks , Lee. I appreciate your sharing your expertise.

[Lee Mac]

Lee, many thanks for the explanation. You are very thorough. I sort of have an understanding of the idea, at least indirectly.

Eye see what did there

You're welcome.

 

So, it was that he would be passing the name of the argument. If so, it would also hold for yours if it was passed '*sym*.

Indeed, when passing quoted symbols there is no way around this issue (to my knowledge); hence, without control of where the code will be used (as in this thread), I would advise following the same logic as when dealing with global variables by using relatively obscure symbols - hence why I initially raised the point, since 'x' is a very common variable name.

 

I was just ruminating on this some more and it looks like one should be very careful if passing a symbol that's used locally period. Which might lead to the caveat: Don't pass symbols unless you know for sure the calling routine doesn't use them (or you have a really good reason to do so and really know what you are doing, e.g., have a naming system worked out, etc).

Precisely.

 

Again, thanks , Lee. I appreciate your sharing your expertise.

You're very welcome; my posted explanations are simply my understanding of these concepts and consequently may not be 100% correct all of the time, but I openly welcome corrections from others more knowledgeable than myself.