Featurescript language - testing non booleans?

traveler_hauptman

This is not really a feature request because it depends a lot on the intent of the FS language designers.

It can be really useful if undefined tests as false and everything other non-boolean value tests true.

var result = maybe_do_something(); //Returns undefined if unable to do something
if(!result){/*Handle missing value*/}

It can be useful if && and || can take non-boolean operands.

myCondition && nonBooleanExpression();
approach1() || approach2();

kevin_o_toole_1

Part of FeatureScript's philosophy is that we prefer explicitly intent over hidden behavior.

if (result != undefined) {} makes it clear that result is not intended to be a boolean, and that undefined is the intended error state (someone looking at your code sees that immediately). In this specific case an equally worthwhile protocol can be to have maybe_do_something() throw an error in the empty case, and use try/catch, rather than an if statement, when calling it. This allows the function return and the result variable to be have checked types.

myCondition : nonBooleanExpression() ? undefined makes it clear what the return value will be when myCondition fails.

try { approach1(); } catch { approach2(); }  is certainly more more verbose than the boolean, but also makes it obvious when each statement gets run and what the result is in each case.

traveler_hauptman

That's awesome and exactly the right thing for the standard library.

For myself though, I'll be trying to bang out a quick bit of automation in featurescript a couple times a year and will have just been using who-knows-what language and idiom. I have done multi-week projects in C++, Ruby, Python, Bash, Javascript, and Java in the last six months and I forget the syntax details of every one when I put it down (except C ) .

I've never been angry at a programming language for being too expressive or flexible.

john_f_carr

function truthy(boolean b) { return b; }

function truthy(x) { return x != undefined; } /* or !(x is undefined), if that's what you mean */

traveler_hauptman

In FS as it is, I think the type test is most readable.

if ( result is undefined) { /*handle it*/}

That doesn't make me want the shortcut any less though.

Thinking about undefined reminds me how uneasy I get with returning undefined when a map key is missing. I always get stuck wondering if I need to differentiate, and test for, a missing key vs an existing key with a value of undefined. This trips me up everytime I touch Lua for instance where maps are such an integral part of the programming idiom. JS has the same behaviour but I don't use JS in a way that makes me confront this.

...now I'm trying to remember which languages treat the undefined/nil value as true. I know I've seen it in other places but can't find it now.

ilya_baran

In FeatureScript, there is no difference between a missing key and a key with an undefined value: when you iterate over a map, the values are never (untagged) undefined.  To be precise, use "== undefined" instead of "is undefined" because "is undefined" will return true on undefined with a type tag.

traveler_hauptman

I'm not following using == undefined vs is undefined. Under what conditions will they give different results?

ilya_baran

It's a dark corner edge case -- if you (for some strange reason) decide to make a custom type tag that has undefined as a possible value (something we normally don't do).  In that case, x is undefined will return true, but x == undefined will return false because x has the type tag and undefined does not.  I don't expect this distinction to come up in real life.

traveler_hauptman

Yes. Interesting. I haven't worked with type tagging a lot. I'll have to take a look.