Function Return Value Data Checks Syntax (Prefix or Postfix?)

[rwp0]

Why not do:

sub TYPE NAME (TYPE PARAM) { ... }

similar to the existing my TYPE VARLIST syntax

ie. a syntax similar to C unlike PHP, Python, TypeScript.

method ! VOID get (STR $key) {
  ...
}

sub OBJ [Cache::LRU] | VOID set (OBJ [Cache::LRU] $self, STR $key, DEF $value) {
  ...
}

Or for enhanced readability:

sub OBJ [Cache::LRU] | VOID
  set ( OBJ [Cache::LRU] $self, STR $key, DEF $value ) {
    ...
}

Source:

https://youtu.be/uT0S-jfO1mE

[rwp0]

Prefix C vs Postfix TypeScript/Python/PHP function RV type declarations

C

Using prefix type name without special characters.
The function type is read (and known) first.

return_type function_name( parameter list ) {
   body of the function
}

int max(int num1, int num2) {

}

// https://www.tutorialspoint.com/cprogramming/c_functions.htm

---

TypeScript

Using postfix :

function add(x: number, y: number): number {
  return x + y;
}
 
let myAdd = function (x: number, y: number): number {
  return x + y;
};
// https://www.typescriptlang.org/docs/handbook/functions.html

Python

Using postfix ->

def add_number(value: int | list, num: int) -> int | list:
  ...
# https://blog.logrocket.com/understanding-type-annotation-python/

PHP

Using postifx : as with TypeScript

function returnIntValue(int $value): int {
  return $value;
}
// https://www.tutorialspoint.com/php7/php7_returntype_declarations.htm

[happy-barney]

once again - checks are NOT types

[happy-barney]

it's not ... type is typically not available during runtime whereas constraints are. IMHO it also leads into misconceptions.

[rwp0]

I can agree with you, that's just the existing syntax in the Perl variable documentation that I re-used for functions, which I believe won't easily change in the near future.

my VARLIST
my TYPE VARLIST
my VARLIST : ATTRS
my TYPE VARLIST : ATTRS

https://perldoc.perl.org/functions/my

https://github.com/Ovid/oshun/blob/main/README.md#syntax

Anyway, let's skip this trivial argument over, we may later denote it with something else in the documentation, that's not the point in this discussion.

[happy-barney]

if decision will be to use prefix syntax for variables, it will change soon :-) (well ... depending in implementation progress soon)

[Ovid]

@rwp0 The main reason we say "checks" instead of "types" is to avoid the endless arguments and bikeshedding around "types." There's a video on Youtube (which I'm not going to link to) which attacks ideas like this by calling the "fake types", based on two conditions:

1. They're often arbitrary and sloppily put together (this is very true)
2. They don't map to C types

The second point is largely about CPU performance, but we're focusing on developer performance.

There's nothing inherently wrong with the word "type". but we deliberately try to avoid it because of all of the emotional baggage that developers have.

[happy-barney]

I'd add another reason ... types are available only in compile time, checks are (should be) available at runtime

[rabbiveesh]

The prefix doesn't parse well by me, neither as a human nor a computer

Also, for parity you would put the check BEFORE the keyword sub, and that would be more similar to C (yet also suffer from the same parsing issues).

All in all, I think the syntax where return type follows the signature is more natural (maybe just cuz I think rust is cool)

[happy-barney]

hm, that raises another questions about usage patterns :-)

• who (and how) uses folding in their editors
• how do they search for given sub by name and want by return value check - grep, IDE magic, long-term memory access (for those capable to remember code base they are working on)
  • related - how they search for variables

[rwp0]

Ok, but why putting the checks before sub, I meant to make it in par with my where the check follows the keyword.

[rabbiveesh]

it's not really on par. you can do my sub, which would mean that a more similar declaration would by my TYPE sub. sub is just implicitly global.
Also, the way you'd have it, declaring an anonymous sub with a return check would be deceptive my $cb = sub Int { ... }

[rabbiveesh]

oh, i see that my points have been made already

[tobyink]

The following is already supported in Perl:

my sub blah { ... }

The following syntax is proposed as part of this project for adding data checks to variables:

my Int $blah = ...;

The most consistent way to add a data check to a lexical sub would thus be:

my Int sub blah { ... }

But what about non-lexical subs?

our Int sub blah { ... }

[tobyink]

my $foo = do {
  my Int sub temp { ... };
  \&temp;
};

[tobyink]

use Sub::Util qw( set_return_check );
my $foo = set_return_check( Int, sub { ... } );

[happy-barney]

ouch :-( seriously ? How user friendliness ?

Next question to solve:

sub foo (&) ...;
foo Int (Int, Int | Undef) { }

[Ovid]

@tobyink I agree that our Int sub blah { ... } isn't going to fly (at least I think I agree because I think you're pointing this out as an objection).

Because these checks are optional, it's not easy to know if a leading bareword before the sub keyword is a check or a sub call.

So if we look at @happy-barney's example:

declare check Foo ...;
sub Foo ($) { ... };

my $foo = Foo sub {};

I don't know how that should be parsed. But if we change the last line:

my $foo = sub () Foo {};

Now I think that's unambiguous (even if Foo had a & prototype).

That being said, if we look at Raku, ideologically the closest language to Perl, we have four alternatives on how to specify the return type (or types).

1. sub foo(--> Int) {}
2. sub foo() returns Int {}
3. sub foo() of Int {}
4. my Int sub foo() {}

Perhaps one of those would be even better.

I just listed a bare check in my slides because I had to list something.

[happy-barney]

plus consider also :lvalue attribute ... I'd say postfix attribute syntax here is more natural
(and there can be more such attributes, I can imagine eg :readonly)

[Plato]

I actually wouldn't mind "our Foo sub {}"; it has a certain consistency to it.
But of the four choices above, I prefer "sub foo() returns Int". Using 'returns' (or 'return'?) as a keyword is simple and explicit and serves as a bit of a break between all the punctuation.

And that eliminates the need for the empty parens, right? Brackets that don't bracket anything are a pet peeve of mine. (I'm very fond of the way Perl almost never requires a "()" the way other languages do.)
":returns" would also be OK if that works better.

[Ovid]

Would want return because that overloads the meaning of return. Otherwise, your comments seem solid.

(Who could have imagined Ovid having a chat with Plato? What a mad world)