cfml

```var isArray = (required any v) =&gt; {
	return isArray(v);
           ^^^^^^^^^^ name lookup finds bif
}

x = [[],0,[]]

writedump(x.map(isArray)) // [true,false,true]
                ^^^^^^^ name lookup finds NON-bif```
a call expression finds BIFs; non-call-expressions don't look into BIF table?

I'm not quite sure what you're trying to test there.

I do know BIFs can't be passed as a UDF into higher order functions.

Well, you're trying to SHOW something, lol

Whatever you want to call it :slightly_smiling_face:

I guess I want to know if this lookup rule is consistent everywhere

```x.map(isArray)```
:point_up: I'm fairly sure that would never find a BIF and would only reference a UDF of that name

if you say `builtinfunction` vs `builtinfunction()` , that is the trigger to find BIF vs not find BIF
(ok that's what I'm trying to test)

BIFs are not defined as variables on the page.  Does that help.

```var now = now(); // no problem```
i guess it's the parens

```var myFunc = ()=&gt;{}
local.keyExists( 'myFunc' ) // true
local.keyExists( 'dateFormat' ) // false```

Well, parens are how you _invoke_ a method.

```var now = () =&gt; { return 42; }
var foo = now(); // calls bif```


But since BIFs don't live in the variables scope, there's no concern of `now` somehow being a reference to a BIF.

I'm wanting to say with no scope in place (meaning `local.now()` ), BIFs are given precedence over a UDF of the same name in a searchable scope.

Which is why legacy code I've run across that has a CFC method with the same name as a BIF had to change to `this.render()` to still work inside the CFC.

yeah ok, unqualified name lookup on a function call finds BIFs first; `local.now` would find "my" now

Yep, and if that wasn't the case, we basically wouldn't be able to have any variables with the same name as a BIF.