Require spaces around binary ops

[Charles]

Is there any negative collision ( syntactically or visually/conceptually) with Spread and similar syntax for a Stream (, platform-independent Type for an enumerable/iterable collection)

x as String*  = List<of String>(...) 
...
tx = x*.trim

The Spread syntax is shorthand for code walking a Stream (??)

"Yes" to that last thought.

[Charles]

Assuming someone had the parsing of nil-safe working and everything working through to codegen
What do we all think would be the simplest way to implement a nil safe check in c# code for a platform ( like c#) that didnt have that capability/operator available or built in ?
( preferably with least code perturbation i.e without writing/rewriting the parts of the name dot id chain multiple times )

Yeah, we don't want to invoke the expression twice as it could have side effects. Well for identifiers like "foo" and "_foo" (member var) it would be okay, but not for "obj.foo", "obj.foo(args)", etc..

The only way I know to do this in C# code gen is to make use of delegates and call a utility method (presumable located in Native.cs).

[hopscc]

Sorry for the delay in replying - been away

Both ?. and *. need to be put together to disambiguate at a syntactic level

yes but they also both dont need/shouldnt have spaces around them ( as with DOT) whereas the others (will) do.

Python's list comprehensions are most similar to Cobra's for-expression. I don't think Python has anything like the spread operator

right but the point I was aiming at was that they are a shorthand for a more verbose form and it seems that for anything other than the most simple expression uses, the more verbose construct is the one suggested to be used for maximum clarity..

re needing space forcing for ?. and *.
OK I see what you mean now.
You can make weirdly unreadable coalescing/multiplying code without spaces
The point about reading better ( or actually being used) with wrapping spaces is the most germane one
(modified compiler to pickup '?.' as own token didnt throw any spurious errors from collisions indicating either no tests of nil coalesce
(not so)
or canonical uses use wrapping spaces anyway)

re aggregator summing
Sorry - I read summing as slightly more general than just summing or multiplying by the item being referenced
(actually I read it as summing as in summing up by a constant value defaulting to 1 - a count
( probably just from looking at the += 0 expression ( thought it a typo for += 1).
So I obviously find it confusing

The step expression is the expression to assign to the aggregation variable at each step of the iteration so for your accumulator/multiplier
action then needs some placeholder for the item at each step/iteration

# generally
sum = <init-expr>
for item in items, sum  = sum <op> <step-expression>
trace sum

#specifically
sum = 0
for item in items, sum  = sum + item
trace sum

#becomes 
trace 0: sum+itemValue: items*  # spread last
# using 'sum' as placeholder for aggregator variable and
# 'itemValue' as placeholder for each single element of items ( 'item' in longer form above)

Its slightly more verbose for simple aggregation but clearer ( just use the explicit expression given) and more flexible ( can aggregate on any expression)
the impressions re the floating op and confusion with 'normal' form of expressions remain - I still think a punctuation separated form (like slices and counted for) would be preferable/clearer.

"Yes" to that last thought.

And the first question? - Is there sufficient disparity and clarity between a Stream ( Type*) and a Spread ( (enum-)variable*) .

re safeNil code gen
Ok that gives me an idea...

Looks like I need to do some tweaking around forcing need for wrapping spaces around some tokens (ASSIGN and others) for experimentation

[torial]

Just wanted to say I love the idea of a safe navigation operator. Nice to be able to collapse stuff into a single null/nil check

[Charles]

And the first question? - Is there sufficient disparity and clarity between a Stream ( Type*) and a Spread ( (enum-)variable*) .

imo yes. The fact that types are either well recognized (bool, int) or capped (Point, Customer) helps.

But we haven't used it yet.

[hopscc]

OK - I've got a rough and ready version of nilSafe deref working using an internal Library helper method and code gen of delegates same as tryCatch expressions (should have remembered that - it actually uses some of the same code).

Currently it traps the Nullref exception and returns nil so theres a likely large performance overhead if it fires....
(about 800x, if does not fire the overhead is about the same on top (double) of that for doing this vs a direct deref)

However found something else that may work better (perf wise) by rewriting the expression higher up so I'm goanna look at that next..

[Charles]

How do you handle methods that have a return type of int, bool, etc.? e.g., value types?

class Customer

    def balanceDue as decimal
        return 100.0

class P

    def main
        customer as Customer?
        amount = customer?.balanceDue
        # what is the type for amount? what is the value?
        # is it (a) decimal? = nil, or (b) decimal = 0.0

[hopscc]

So far dont do anything specifically - it falls to the current Type inference and assignment
Which appears to make it Object?
(inferred from assigning return value to a local already typed to decimal/Decimal - throws an error)

(how in cobra do I determine the type of a variable whose current value is nil?)

What do you think would be the desirable result for ValueTypes whose derefs return null/fail ?

[Charles]

There's a reasonable default/nil/zero type for the various primitive types:

bool -> false
int -> 0
float -> 0.0f
decimal -> 0.0

Re: your question about type:

1) "foo = nil" results in a type of "dynamic?"

2) You can use "ct_trace foo" to inspect these things at compile-time

If that doesn't answer your question, let me know.

[kirai84]

There's a reasonable default/nil/zero type for the various primitive types:

bool -> false
int -> 0
float -> 0.0f
decimal -> 0.0

IMHO it's not a good idea. Default value and not-set value are different things. Like DBNull, for example.
This is wrong:

def sendMoneyToPoorRealtive(someMoney as Number)
    balance = .customer?.brother?.grandmother?.aunt?.husband?.balance
    if balance == 0
        .customer.brother.grandmother.aunt.husband.balance = someMoney
        # or .customer?.brother?.grandmother?.aunt?.husband?.balance = someMoney, 'no matter

And this is much better:

def sendMoneyToPoorRealtive(someMoney as Number)
    balance = .customer?.brother?.grandmother?.aunt?.husband?.balance
    if balance == nil
        .createDepositeForPoorRelative
        balance = 0
    if balance == 0
        .customer.brother.grandmother.aunt.husband.balance = someMoney