I've been converting text true/false into proper Booleans a good deal recently so to stop re-inventing the wheel in each project I've come up with this
Top one return False, bottom ones True
I've been converting text true/false into proper Booleans a good deal recently so to stop re-inventing the wheel in each project I've come up with this
Top one return False, bottom ones True
I just used report<not<not(val)>>
for my block
Snap! considers all lists true, when I try it.
Imho, if anything other than is going to be considered False, then empty lists should be False, but
should be True.
But basically, Snap! just does what JS does, and no Snap! lists look empty to JS. I think.
I wasn't trying to just get what Snap! or JS thinks is truthy or falsy but what I, myself thought things should be
At a human level, I think the two list instances are both "empty" and if empty means false then both should return false
But, at least my reporter can be customised for anyone's belief system
Oh gosh that's like (analogous to) people who think zero isn't an actual number. isn't empty; it has one item.
well.......
In seriousness, it's not at that level
So, I've got even worse
If, in my mind, a list with 1 element that is empty is "empty" then it doesn't matter how many empty slots a list has
so now list[,,,,,,] is now considered falsey as well!
....runs away fast
Wouldn't this be a lot simpler?
(I've listed all the things I'd consider to be true/false values, you can change them if you want.)
It just sorts the input through lists of true and values until it can either report a boolean value, or deem the input invalid.
insead of
(keep items [predicate] from (val)) = (list @addInput)
, you can just say is @list empty?
, but I would personally use
I was gonna mention that but didn't... What about
For that matter, what about
I agree that a truly empty list should be considered false, if all those other JS-false things are, but not a list of falsey things.
Once you entertain the idea of truthiness (as opposed to IF requiring exactly or
), you really want all non-falsey values to be considered True, e.g., all nonzero numbers, not just 1. Why make things errors that don't have to be?
My current reporter deals with List[false] as true
which in my current belief system is fine as the list isn't "empty"
But is does "fail" on
I'll have to work on it to report False
just use [flatten V] of @list
It was just an example of what the OP could do. Rather than making the reporter over-complicated, they could just add values they'd need or want to consider true or false, and do so with about anything possible.
Oh yeah, I liked that part. Sorry, I should have said.
It's alright. I did think a bit about what you said about having non-zero numbers report as true, and I believe that issue could be fixed with either the (numbers () to ()) reporter, or a check for non-zero numbers with the IF reporter.
What would you use as the upper bound? (And, not all numbers are integers.)
But that would be a retreat from your original goal of avoiding a lot of IF/ELSE clauses. Another reason to prefer the rule that anything not explicitly listed as False is True! :~)
Like I said, it's only an example for the OP, they can change it as they need.
I know, but the OP took a bit of a complicated approach, some code they had seems a bit unnecessary to me. I did think about having a default true condition, but my idea was meant to be for helping the OP in the right direction.