Support void or signal java.lang.Void as a pre/postfixBind return type

[cyberpwnn]

Is your feature request related to a problem? Please describe.

There are a few situations where I would like to use pre/postfix bindings without a return type, such as... close <Closable>. There are more complex examples but there's no need here.

// Write all text (left) to the file (overwriting if it exists, creating parent directories if needed)
"literal text" write "example.txt";
"or this" write fileObj
write "or even" to fileObj

// Close a closeable
close inputStream;

// Delete all sub-files / folders
deleteTree file;

// With statements things like this could be possible (assuming 5 seconds postfixes to 5000)
sleep 5 seconds;

Describe the solution you'd like

Solution 1

As the documentation states, we cant use void because we need multiple return types, so why not use Void & return null in the method? Then in the compiler just simply call it (ignoring the Void) return result.

Returning type Void (null) would really only be a signal to the compiler that we intend for this to never return a result, and is called just like a void method.

Solution 2

An alternative would also just be to allow ignoring the return result regardless of what the return type is, such that 5 max 8 (same as Math.max(5, 8))

int v1 = Math.max(5, 8); // Valid
int v2 = 5 max 8; // Also valid
Math.max(5,8); // Valid, we're just ignoring the method return

5 max 8; // Not valid

So I'm proposing to allow ignoring the return just like a normal method.

Describe alternatives you've considered Just calling the method (Math.max(5,8)) but that's not the mindset I was in when I chose to use Manifold 😄

[rsmckinney]

Hi @cyberpwnn. As you have discovered, unit expressions can't also be statements. However, your 'close' example makes a decent case for supporting statements. I'll see what I can do. Thanks for the suggestion!

[cyberpwnn]

I've updated the issue with additional ideas, and thanks for taking a look into it!

[cyberpwnn]

👍

[rsmckinney]

Whelp. Not looking good. There's an ambiguity between the declaration statement and the binding expression:

close inputStream;

Java parses this as a declaration statement. The Java parser is context-free, so it builds a conventional untyped/unresolved AST during the parse phase, therefore there is no way to distinguish close and inputStream as anything other than a declaration statement.

My recent change 9d6ba339092c2a405fd0aba45d043ba0f8b57a56 adds support for binding statements that start with a literal such as:

5 sec sleep;

But alone, that's pretty lame.

I can probably maybe get this working as specified, but it's a bigger change than I can muster at this time. Anyhow, here are the changes I'd need to make:

• if a declaration statement fails to parse at parse time e.g.,foo 8; or foo bar baz;, backtrack and attempt to parse as binding expression
• if a declaration statement has errors during attribution, try to parse as a binding expression, if that works rewrite the AST

Bigger changes than I'd like, but probably doable.

[schittli]

Hello

I'm pretty sure that some professional Java developers would rate this feature as 'nice', but not as 'I have always been waiting for this!'. In comparison, not having the existing Manifold functions was really big pain, especially if one works with modern programming languages, too.

I don't think that this function would change the way professional Java developers would / could write Software. One does not have to type less, the errors probably do not become less, only code reading is a bit different.

Maybe, this syntax would be cool for new developers who develop small scripts, e.g. for automation - but there are already great scripting languages.

I think it's worth weighing up the cost and benefit here.

Kind regards, Thomas

[cyberpwnn]

Wasn't looking for a big change, Was simply seeing if there was a quick change to allow it as a capability. I don't think there's anything wrong with having "nice to haves" that aren't essential. I think having a literal is good enough given the effort spent. It would be nice to have a binder followed by a literal as a true statement, however if the work required is beyond the benefits of it, this is good enough.

[rsmckinney]

Hey @cyberpwnn. No, it's fine, no need to close this. It's an interesting feature that is worth pursuing, but at the moment I have other stuff that is more pressing.