Require spaces around binary ops

[Charles]

You could be right. In which case the type has to be the nullable of the given type.

Are there any languages with safe navigation that use static typing?

[kirai84]

This one:http://en.wikipedia.org/wiki/Oxygene_%28programming_language%29.
Relevant link:http://wiki.oxygenelanguage.com/en/Colon_Operator.

[Charles]

Looks good. I favor returning nil. The code can also coalesce with 0 or false if they want:

i = foo?.bar?.baz ? 0

[nerdzero]

Here's something else to consider (sorry if it was mentioned earlier but I didn't see it):

Would the ?. operator short circuit or would it evaluate the entire call chain regardless?

name = customer?.name.trim.capitalized ? ""

Would that result in a nil ref exception if customer is nil? I don't think Groovy short-circuits but intuitively it seems like it should. I believe Oxygene does short circuit.

[Charles]

Some more thoughts.

(1)
I meant to post the following before. When I say that this:

foo?.bar

...would be ambiguous if it could be mean both "safe navigation of foo to bar" and "foo coalesced with .bar", I mean that it is ambiguous at the parsing stage. Furthermore, it may be possible to resolve some or all ambiguities at a later phase when symbols are bound, but I think that such a requirement indicates a poor syntax which will make reading other people's code difficult.

(2)
The Oxygene/Chrome approach to "safe navigation" is to use a different operator which stimulates the thought that we could do something similar for both that and "spread", in which case we wouldn't have to require spaces around binary operators:

# just thinking out loud here

# safe navigation
x = foo->bar->baz
x = foo.?bar.?bar

# spread
names = customers-->name
names = customers;name
names = customers.for.name

LOL, I couldn't think of anything reasonable for the spread operator.

I still like these best:

x = foo?.bar?.baz
names = customers*.name

[kirai84]

Here's something else to consider (sorry if it was mentioned earlier but I didn't see it):

Would the ?. operator short circuit or would it evaluate the entire call chain regardless?

name = customer?.name.trim.capitalized ? ""

Would that result in a nil ref exception if customer is nil? I don't think Groovy short-circuits but intuitively it seems like it should. I believe Oxygene does short circuit.

I just checked and it seems like Oxigene doesn't short-circuit. This code works:

Code: Select all

var customer : Customer := nil;
var l = customer:name:trim:length;


And this does not:

Code: Select all

...
var l = customer:name:trim.length; // Throws an exception.


And I guess it should (It could actually be a bug, there are plenty in Oxygene compiler). Implementation is simple and efficient, so why not?
Basically this:

# let ?. be the operator
a?.rest

should turn into this (where 'rest' is processed recursively):

Code: Select all

// for reference type:
(a == null ? null : (a.rest))

// for value type V
(a == null ? (V?)null : (a.rest))

// for void type
if (a != null)
    a.rest;


[hopscc]

aha thats what ct_trace is for...

Default value and not-set value are different things

I agree. They should be kept distinct
We should keep it to returning nil or the deref evaluation result
Its easy (and clear) enough to use nil coalesce to provide defaults if thats desired

amount = customer?.balanceDue ? 0.0

use a different operator

I like using ? somewhere - clearly relating to nilable and nil-coalesce

What about reversing ?. to .?
Its not quite as analogous to ?. = nil-on-prior-id-or-deref but gets the point across and is unambiguous against nil coalesce as operator

amount = customer.?balanceDue ? 0.0 # nilSafe on customer
#OK
amount = customerBal?.balanceDue # nil coalesce on customerBal to .balanceDue
# which is   amount = customerBal ? .balanceDue

#Below is syntax error: 'customer.'  expecting an expression
amount = customer. ? balanceDue

Would the ?. operator short circuit or would it evaluate the entire call chain regardless?

Short cct - if any member/call prior to nilsafe-op ( ?.) is nil, remainder is not evaluated in any way
I dont see the point of doing anything else.

should turn into this..

(a == null ? null : (a.rest))
(a == null ? (V?)null : (a.rest))
if (a != null), a.rest

# These are same as non nil coalesce:
a ! a.rest

My current (faster) implementation does a rewrite using non-nil coalesce.

I think we probably need to see what the effect is of forcing spaces around (some) ops before chasing other op combos

[Charles]

What about reversing ?. to .?
Its not quite as analogous to ?. = nil-on-prior-id-or-deref but gets the point across and is unambiguous against nil coalesce as operator

I see what you're saying but still prefer ?. and *.

But maybe that's just because it's what I first saw.

[hopscc]

New ticket:339 for nilSafe enhancement.

[kirai84]

If there is already

a ! a.rest

then may be

a!!rest

wuold do? Somewhat intuitive and postpones the urgency to introduce spaces around binary ops.