Topic: Null vs empty?

[CHulse]

Hi folks

In looping through a list of lists, I encounter the first empty row ("" "" "" "" "" "" "" "" "" "" "" "" ""). I'm having trouble testing for the first "" value to escape the program. I've tried

Code - Auto/Visual Lisp: [Select]

1. (if (not (null (car x)))...

So is the "" value something other than "null"?

Thanks

[CHulse]

OK, I'm sorry. I have no idea why this posted 3 times.

[kdub_nz]

See if any of there help

Code - Auto/Visual Lisp: [Select]

1. ;; (KDUB:emptystring-p "1") ->nil
2. ;; (KDUB:emptystring-p "") ->T
3. ;; (KDUB:emptystring-p " ") ->T
4. ;;
5. ;; (KDUB:notemptystring-p "x") -> T
6. ;; (KDUB:notemptystring-p "") -> nil
7. ;; (KDUB:notemptystring-p " ") -> nil
8. ;;
9. ;; (KDUB:validstring-p "x") -> T
10. ;; (KDUB:validstring-p "") -> nil
11. ;; (KDUB:validstring-p " ") -> T
12. (defun kdub:string-p (arg) (= (type arg) 'str))
13. (defun kdub:validstring-p (arg) (and (= (type arg) 'str) (/= 0 (strlen arg))))
14. (defun kdub:emptystring-p (arg)
15.   (and (= (type arg) 'str) (= 0 (strlen (vl-string-trim " " arg))))
16. )
17. (defun kdub:notemptystring-p (arg)
18.   (and (= (type arg) 'str) (/= 0 (strlen (vl-string-trim " " arg))))
19. )
20.  

[Lee Mac]

To test whether the entire row is empty, you could use:

Code - Auto/Visual Lisp: [Select]

1. (= "" (apply 'strcat x))

And yes, the empty string is not considered a null value, only nil is null.

[Grrr1337]

Alternatively to Lee's suggestion:

Code - Auto/Visual Lisp: [Select]

1. (not (apply '= (cons "" x)))

[CHulse]

Thanks folks, I think I've got it working now. Much appreciated.

[JohnK]

Just a word of advice on this topic.
Given a list:

Code: [Select]

(setq x ("" "" "" "" "" "" "" "" "" "" "" "" ""))
Both Lee's and Grrr1337's suggestions will work.

However, if given a list:

Code: [Select]

(setq x ("" "" "" "" "" "" "" "" "" "" "" "" "" 1))
The first method will fail because strcat assumes a string.
-i.e.

Code - Auto/Visual Lisp: [Select]

1. (= "" (apply 'strcat x)
2. ; will fail if non-string entry is found.
3.  
4. (not (apply '= (cons "" x))))
5. ; will still work in case of non-string entry
6.  

In other programming languages you will spend quite a bit of time developing type safe routines and procedures. I would approach this much the same way kdub did and his type checking.

[Lee Mac]

I think it ultimately depends on the use case - in this particular example, I would hazard a guess that the list has been obtained from reading a delimited file, in which case it is guaranteed that the list will only contain strings and any type checking would therefore be superfluous.

[JohnK]

Okay, but my point is that you *should not* do that (assume) because it's more of a matter of time before you get burned and a "stringp" error, being caused in a far-flung section of code will/is not fun to locate; it's far easier and better for everyone if people/you/me/them/Mickey Mouse adds simple "type safety" check into functions like this.

Perhaps I wasn't clear on my second point of my post as well so here is further explanation.
Grrr1337's example code doesn't toss a wobbly when passed the non-string value but I would still--if I were typing--use a (eq (type... function just for extra readability because it works by obscurity (it's not clear that it will pass the type check) to most people.

[CHulse]

Thanks guys. I'm still learning.
But in this case, Lee is correct in assuming since he wrote most of the original routine I use. I've added to it over the years, but it relies on his string break function. So I was looking for a way to get the main routine to see the "end" of that list (i.e. The first empty row of strings). I've been working to make it more stupid proof and less reliant on the user.
So thanks again Lee, the tree block insertion routine has been a huge help and we use it almost daily.

[JohnK]

That sounds like a wonderful way to get out of many of my engineering tasks; I don't need to do any of these calculations because I will just assume it will never happen or always remain the way it is now. Maybe we should design roads that way too; we can post big signs saying no more then ten cars per hour allowed (and no trucks...or livestock). Brilliant!

[dgorsman]

Outside of libraries it's uncommon to have an unbounded "problem space".  One of the key parts to planning software, either top-level or in the weeds, is to create that limited and well defined "problem space" so you don't go cross-eyed trying to handle every possible eventuality.

[ronjonp]

Outside of libraries it's uncommon to have an unbounded "problem space".  One of the key parts to planning software, either top-level or in the weeds, is to create that limited and well defined "problem space" so you don't go cross-eyed trying to handle every possible eventuality.

Agreed .. if you know what data you're passing ( and you should ) why add overhead to check the data.

[JohnK]

*blink-blink* Whaaat?

We are talking overhead measured in milliseconds if you chose to be type-safe (and, honestly, I'd bet that Grr1337's snip is faster to begin with because I think CONS is quicker then STRCAT). Even if it wasn't faster/more overhead, I'd still choose to adopt the method employed by Grrr1337's snip to take on type-safe vs not at all. ...Being redundant in a type-safe check is a little overboard (to add an "eq(type..." to that snip, for example)--I'll give you that--but I've never heard advice about when it is okay to NOT be type-safe.

[owenwengerd]

... I've never heard advice about when it is okay to NOT be type-safe.

To the extent that type safety hides violations of an API contract (i.e. when it's best to crash definitely and immediately), I think it is a very bad idea. And in my opinion, it's a very bad idea in this case, where non-strings mean that something is already wrong.