Re: parser hacking: conditional fields

[Hadriel Kaplan <HKaplan@...>]

On Mar 3, 2013, at 2:10 PM, Andrew Starks <andrew.starks@trms.com>
 wrote:

> So, the parser hacking is to there to accomplish:
> 
> table.outer?.inner
> 
> such that outer's absence does nto cause an error.
> 
> If `inner` is absent, then is the answer "nil"?

Are you asking in the sense of what Sven's current (as of this morning) solution is?  Or do you mean "what should any solution do?"

I think any solution should be such that if you used 'table.outer?.inner' and there was a table.outer but no table.outer.inner, then it should cause an error - because you were only checking for outer's existence, not inner's - and once you do the ".inner" portion, outer had better be a table with a 'inner' field or else error.  Sven's current proposal does that, I think.


> If `outer` doesn't exist, is the answer `nil`?

I think the solution should return nil if table.outer doesn't exist and you did 'table.outer?.inner'.  Currently Sven's proposal would return a _SAFE userdata I think.


> It
> seams like if the answer were `false`, I couldn't possibly know if
> `inner` if false or if it wasn't there…

I Agree.


> Does any of this change change if instead you had:
> 
> table.outer?.inner?
> 
> ...or is that not being contemplated?

Yes, that's in Sven's proposal.  In this case 'table.outer?.inner?' would not error if there were no table.outer, but would instead return a _SAFE userdata.  Likewise if there were a table.outer with no inner field, it would return a _SAFE userdata.

The problem is the '?' is not really an existential checker, as he's pointed out, but rather a "safe table navigator".
So if 'inner' is a boolean false or nil, it returns a _SAFE userdata instead of false or nil.

-hadriel