From #690, in relation to field storage access (and I hit this in my matrix code, too, by the way):

someLineHere
*s = str   // compiler sees this as 'mult'

Actually, I might like to ask for a general rule change on newlines. How about: Every newline is considered the end of a statement if it can be ended without error and if the next line doesn't start with {?

Does that cover common use cases? Maybe still need some syntax for extending lines in odd cases. Some languages use \, but I prefer .... For example:

this = something ...
  + anotherSomething

The above line could have dodged the ... by putting the + on the end (since it would have left the statement in error otherwise):

this = something +
  anotherSomething

But there might be cases I'm not thinking of, and ... could come in handy stylistically for some formatting, too.

The current syntax error for lines starting with an asterisk is bothersome and should be resolved one way or another.

I think the ... is kind of cute. I always thought the \<Newline> was ugly and bug-prone (since in some languages, \<Space><Newline> does not continue the line).

I'm +1 on this.

in some languages, \<Space><Newline> does not continue the line

I'm totally against significant trailing whitespace in any language.

I just thought about the risk of mental overlap with .., though we did switch ... to ..< by now, at least. Just that \ always seems to try so hard to grab attention and interfere with visual clearness.

The only problem is really that * is both a prefix and binary operator. Other than that I think we've covered all the cases (other than maybe a statement that started with a negative literal).

I think we have a couple options:

1. enforce a very rigid grammar and require all operators to be on previous line of a multi-line statement; I want to make sure IDE parsers can handle well
2. just enforce this for * with regard to newlines
3. potentially select another unambiguous operator/syntax for storage access

I kind of lean towards option 3 if we can come up with something.

I want to make sure IDE parsers can handle well

For my own language experiments, I had a version of my proposed rule working (more or less) in ANTLR. I can't promise it was perfect, though, and I didn't allow a { exception. Basically, I just didn't allow newlines in statement productions except proceeded by ....

Strongly dislike option 1; lot of times in complex expressions I like to rearrange the source so things align neatly, and enforcing placement rules seems like a big change in the spirit of C-derived languages, where any whitespace sequence is equivalent and insignificant.

Option 3 seems right, to me. Storage access is rare enough (usually you probably should go through the getter) that it seems wrong to break the whole rest of the language to make one little thing work.

Having been using Fan fow a good while now, I'm strongly in favor of its style and flavor not changing; I like the way it works. Things like being able to leave off optional (), and not needing semicolon to close statements, all that goes to making it easy to use -- you don't have to give too many hints to the compiler.

Keeping the grammar clean, for ease in tool dev., is pretty important too.

Leans towards option 3 as well.

Actually, I remembered that I oversimplified my grammar gymnastics. I manually chose spots where newlines could be added as part of the whitespace in expressions (such as after +). Sort of a bother, but workable, I think.

Not trying to argue the point much. Just trying to correct my misstatement above.

well my proposal to move back to @ for both symbols and fields would solve the problem (ala option 3)

I still like @ for symbol reference. Maybe use : for field storage access? Just funny since @ is field storage in Ruby, and : is for symbols ..., but I do like @ for facets and I really like being consistent there (between facets and symbol reference), personally.

Still, it's not too hard to learn say :name = someValue or whatever. Would just need a note for Rubyists that it's opposite for them.

I don't like using the same symbol for field access and symbols. :var isn't bad for field access.

When i wrote the grammar, the @ symbol was one of the big issues. Basically it was context sensitive (field vs facet), and ideally you don't want anything to be context sensitive, that makes it way header to write lexer/parser. So i'm not sure i like using @ either.

: might work but it's already quite heavily use with the :: and the maps(which are already syntactically difficult to deal with), but i think a :prefix at least is less ambiguous(new) than the @ (prefix both cases)

Still : might make reading code a bit confusing but i guess the use of filed access is limited anyway.

almost wonder if it wouldn't be better to use a keyword of some sort, kinda like instancof in jav ..... or maybe not since it's be rarely used.

almost wonder if it wouldn't be better to use a keyword of some sort, kinda like instancof in jav ..... or maybe not since it's be rarely used.

As in, storageof name = someValue or something like that?

Yeah .... but on the other and I have a hardtime myself justify a keyword for something that's rarely use.

On the other hand, it reads nicely.

There are a lot more words available, than symbols. So maybe a keyword might be a good idea here.

I don't mind a keyword although I would think we would want something like keyword(field) more like C# uses typeof, since this construct is always part of a larger expression.

It sounds like we have consensus to leave newlines alone and fix this problem by just fixing the syntax of storage itself. Yes?

Other suggestions for keywords of symbols? Double char symbols are probably the easiest to utilize to solve the problem (haven't given any thought though).

Could do something like x.underlying, or x.$underlying. Something to indicate that you're getting access to the actual field underlying the property facade.

Maybe @x.val???

Maybe @x.val???

Don't like it.

OK, here are some suggestions that I don't think we cause problems with existing operators:

Str x { set { $x = val } }
Str x { set { _x = val } } // disallow underbar in slot names
Str x { set { :x = val } }
Str x { set { s:x = val } }
Str x { set { %%x = val } }
Str x { set { >>x = val } }
Str x { set { *(x) = val } }
Str x { set { \x = val } }
Str x { set { ,x = val } }
Str x { set { :>x = val } }

Or to expand on John's idea:

Str x { set { x.$ = val } }
Str x { set { x._ = val } }
Str x { set { x.@ = val } }

$x would seem rather natural to me :-)

Personally I like @ best, notwithstanding the overlap with symbols.

What about super.x, and we pretend that we're overriding the field setter? Then the usage is the same everywhere.

I prefer _foo, where field names cannot start with underscore:

class Thing {
Int foo_bar := 0 {
  get { echo("get foo_bar"); return _foo_bar }
  set { echo("set foo_bar"); _foo_bar = val }
}

}

I'd also note that the val keyword does remove the possibility to name a field as val, which might be a restriction on a common word?

What about super.x, and we pretend that we're overriding the field setter? Then the usage is the same everywhere.

That seems sort of confusing to me, and actually already has a meaning in fields for calling your super class getter/setter.

I'd also note that the val keyword does remove the possibility to name a field as val, which might be a restriction on a common word?

No its actually ok - val is just the implied argument name, not a keyword (I think also the way C# works). We have fields called val with overridden getter/setters.

I don't really like any of those options. Another thought tho, what if we used a different assignment operator?

Str x { set { x @= val }}
Str x { set { x <= val }}

EDIT: I just realized that doesn't work for getters, but food for thought none-the-less.