merging getters and properties syntax

[jnorthrup]

I looked in the readme for a voidfunc call

the first and one of the only i see is
{5}()

one language I use has properties, and also void functions (0 params) with parens and commas

several languages i use have 0 or more params with infix parameter passing for one or all params, no commas, though perhaps quotes and escapes matter for holding position.

I also have and use a scenario where

class A{val size:Int}
and
class B(fun size():Int)

really don't look much different under the hood without some annotations to specify that A.size is a java attribute

but these belong to the same language and have different syntax.

obviously A.size() must be an error and B.size must be a lambda/function reference right?

is reasonable to promote void funcs to infix syntax per kotlin's infix, such that a voidfunc declared in an expression then simply call rather than yield a reference? I like kotlin;s infix but there's too many shackles in other parts of the expression limitations to get traction with that. I really don't have an opinion on how much value applies to special 1-parameter calling syntax, but I run into the 0-parameter divivde between size and size() more often than i'd like.

acknowledging void, or empty parens, seems like a rip in the fabric of consistent programming space.

[cliffclick]

In AA, functions are specified as an arg list, then ->, then the body, all wrapped in {}.
A one-arg function: { arg -> body }
A zero-arg function: { -> body }.
The arrow can be skipped if there are no arguments: {body}.

Everything in AA is an expression, and there is no "void". A function will return its last expression, and you can use a 0 to make it explicitly clear to ignore the return.

As for auto-calling a zero-arg function, I'm currently of the opinion that this leads to "hidden" function calls and cost-model confusion far too often.
Is A.size cheap (i.e., 1-clk load)?
How about mySharedCache.size?
I know for sure that calling size on a concurrently modified structure (such as a busy multi-threaded cache / hashtable ) can be really REALLY expensive (or the size call lies and returns a bad approximation). So I am currently in the zone of "no auto-calling" or "no hidden function calls". I want a visual clue that a function is being called.

fun = ...some...function...expr; // Some function

Using it with a single trailing arg is a call:
fun (arg_tuple) // valid for zero or more arguments
fun arg // Valid for a single non-tuple argument
fun() // Only valid syntax to call a zero-arg function, and your visual clue that something non-trivial is going on
Using it in other contexts is NOT a call:
...fun; OR
...fun, OR
..fun} OR
...fun) OR
...fun + ... OR
etc... any syntax after fun which is not, itself, a complete expression.

[jnorthrup]

You are promoting attribute calls to getter calls for the sake of a false positive complexity condition, in order to have these co-exist. BUT now I can go write some kind of non-getter size calls for incompatible loops. does this distinction buy me a tangible payoff for the limitation?

this to me is not far from saying no function call shall be less than 3 characters while attributes can be 1, or 3, at user's discretion

[cliffclick]

Not sure what "false positive complexity condition" is.
Not sure what "attribute calls" is, and this term is used in several different languages to mean different things in each of them.
I've certainly seen the term "attribute" used to denote an automatically generated getter, with optional user overriding. i.e., a function call.

On character counts:

Field loads (often conflated with attribute calls and/or getters) are a minimal of 2 chars ".x", one for syntax, one for the label.
Function calls are normally minimal of 3 chars: "f a" or "f()"; one or 2 chars for syntax, one or 2 for the expression(s).
Function calls can be done via operators in 2 chars: "!x" or "x#"; one char for op, one for the expression.

But this:
"x"
is never a function call, by language design, because of the correctness and cost model confusion. Its not just me, most of my C-coding (game writers and non-game writers) brethren fall into this camp. Function calls should be obvious, since being functions carries a lot of red-flags around behavior.

[jnorthrup]

here's where I think AA produces a kolmogorov complexity win, and could capitalize even moreso, but then in the name of weirdness budget and older conventions ropes in comfort food concepts.

If I'm a game writer i might write 25 different functions because there is no cheaper way to generalize them and occupy 4k of ram.

If I write games long enough I'm going to become an expert in cutting and pasting perfectly adapted copies of loops and functions rather than waste time socializing generative grammars for library consumption -- In one world I'll be able to make a perfect estimate of clock cycles based on the lines of code on the screen for a loop, in the other I'm going to take a peer-review beating for every syntactical anachronism unless there's a showstopper with no workaround, like if the underlying language requires a flip-flop to do type specialization, unification, or polymorphism.

I think the latter, generative grammars is the emergent paradigm tbh. AAA game programmers coming from c/c++ aren't likely to be on the lookout for a new c/c++ with a sea of nodes jit compiler. They have enums and empty tuples and macros whenever they want with the associated muscle memory.

wrt to provability by a "(\s*)" token I don't see a huge distinction from what you're saying and an investor-funding decree that "thou shalt" suffix all void function names with "()" to gain the cultural benefits without imposing the syntax flipflop of having

n=run(n1,n2,...)
1=run n1
0="run()"

[cliffclick]

Well, the "comfort food" is the usual C/Java/Fortran/Kotlin/etc style:
for 0 to N args, called as
run(...args...)
which I claim is a lot of "comfort".
I ALSO allow one alternative form: run n1 to appease the functional programming crowd.

Still not a fan of the no-arg no-syntax function call. Grammar ambiguities abound.

I might be talked into an optional syntax where you could ask for a zero-arg function to auto-call, although this becomes a tough problem for the parser (and needs more types-for-perf support, i.e. a "no zero-args fcns in my code please" keyword). In any case, not changing this feature right now. Too many irons in the fire already.

[jnorthrup]

a "no zero-args fcns in my code please" keyword

it seems like a serialization scope operator, seemingly in prior discussion elsewhere, could be a helpful and low cost alt syntax which aids code-gen, boilerplate, wire format overheads, and cheats on comforts. kolmogorov-syntax where kolmogorov is not unwelcome.

…

Message ID: ***@***.*** com>