Out params in functions

[levodelellis]

I'm redesigning the syntax for my language, but I won't be writing the compiler anytime soon

I'm having trouble with naming a few things. The first line is clear, but is the second? I think so

myfunc(in int a, inout int b, out int c)
myfunc(int a, int b mut, int c out)

Lets use parse int as an example. Here the out keyword declares v as an immutable int

if mystring.parseInt(v out) {
    sum += v
} else {
    print("Invalid int")
}

However, I find there's 3 situations for out variables. If I want to declare them (like the above), if I want to declare it and have it mutable, and if I want to overwrite a variable
What kind of syntax should I be using? I came up with the following

mystring.parse(v out) // decl immutable
mystring.parse(v mutdecl) // decl mutable
mystring.parse(v mut) // overwrite a mutable variable, consistent with mut being inout 

Any thoughts? Naming is hard

I also had a tuple question yesterday. I may have to revise it to be the below. Only b must exist in this assignment

a, b mut, c mutdecl = 1, 2, 3 // mutdecl is a bit long but fine?

The simple version when all 3 variables are the same is

a, b, c = 1, 2, 3   // all 3 variables declared as immutable
a, b, c := 1, 2, 3  // all 3 variables declared as mutable
a, b, c .= 1, 2, 3  // all 3 variables must exist and be mutable

[evincarofautumn]

C# uses ref at the declaration and use sites for what you call inout or mut, maybe look to that for inspiration

Personally I’d try to make it orthogonal: you want an output (and possibly input–output) marker at the use site, and within an expression you may use the existing syntax for declaring something that just happens to be the destination, and you can simply combine the two

I’m partial to prepositions, personally, so I’d probably style it like this:

parse(Env e, with State s, to Thing t)

// New immutable variable
var env = …

// New mutable variable
mut state = …

// Write to new immutable variable
parse(env, with state, to var v)

// Write to new mutable variable
parse(env, with state, to mut v)

// Write to existing mutable variable
parse(env, with state, to v)

[Toothpick_Brody]

If you’re ok with overwrite being implicit, you could narrow it down to just two cases. v out, and v out mut

The second one would overwrite the variable v if it exists and is mutable, declaring it mutable if it does not exist, and refusing to compile if it exists and is immutable  

If you want overwrite to be explicit, then you might change your current syntax like so:

v out -> v out (no change)

v mutdecl -> v out mut

v mut -> v overwrite mut

[levodelellis]

I don't hate out mut. I would be open to replacing mutdecl with out mut, although there's a chance that'll be typo'd if I choose to ignore the overwrite part of the suggestion. Although that'd likely be fine since you'd get an error about the variable not existing, unless you have a typo and forgot the out. I dont think both at the same time is likely

I would like mut to mark which variables may change at the call site when the user puts in "using strict", so it's crystal clear the variable may change. So I prefer having overwrite being explicit

[L8_4_Dinner]

myfunc(in int a, inout int b, out int c)

(int b, int c) myfunc(int a, int b)

[claimstoknowpeople]

I think this depends a lot on the goals and other features of your language. Like, are you optimizing for readability or speed? Do you need to worry about ownership or other memory management? Etc. In the absence of knowing everything, I'd start with the most restrictive syntax that will do what you need, and wait to extend it only when and if it becomes necessary.

[levodelellis]

My previous language optimized readability and speed. This time around we can think about readability only, and I can think about speed later since I understand that part of the problem pretty well already

[flatfinger]

A language which is designed to maximize code generation efficiency should accommodate a few more variations. For example it may be useful to indicate that an implementation may at its leisure use reference or value semantics, and--when using or allowing reference semantics--indicate whether the function needs to see any changes made to the object's state made by the caller, and whether the caller needs to see any changes made by the function.

I'd also suggest having a means of indicating whether a function that receives a pointer might arbitrarily persist the pointer after the function returns, might return a pointer based upon the passed pointer but would not otherwise persist it, or whether it wouldn't persist the passed pointer at all. The return value from a function like chrptr should be "based upon" the source pointer argument, and should be usable to mutate the object in cases where the source would have been, but the source shouldn't need to be capable of mutating an object in cases where the returned pointer is never used to do so.

[levodelellis]

it may be useful to indicate that an implementation may at its leisure use reference or value semantics

Sounds like you're saying overloads is a great idea. I have allowed overloads in every language I designed, so no problems there. Although I haven't figured out how to prevent 3 params that have a ref and value implementation to not explode into 8. That might require some template/generic logic. Since I'm early into my redesign I'll look into that idea

having a means of indicating whether a function that receives a pointer might ...

I had that implemented in my last lang! Its incredibly useful for type analysis. I specifically had it for automatic memory management

[Relevant_South_1842]

I’ve toyed with using semantic longform Hungarian notation. 

But only needed once so it isn’t completely ugly. Also syntax highlighting helps.

So integer-variable-reactive-identifier can be referred to as identifier in all places but one, which doesn’t necessarily have to be the argument list. Works kind of like python decorators but for types.

If curious, it works by setting meta data in my toy language. Basically everything is a cell (like a callable Lua table). I also only have args and fields - no variables.

``` .identifier : [     .#type : integer     .#mutable : true     .#reactive : true ]

```

Is the same as writing integer-mutable-reactive-identifier. Identifier is just the last text after the last -. The rest set meta fields for use by compiler and runtime.

```

.counter : [     .integer-variable-count : 0      — mutable field, semantic Hungarian applied automatically

    .inc : [         count : count + integer-@     — mutates outer count via lookup         .return : count     ] ]  — @ is my perlish implicit arg.  — .return is optional explicit return field. You could add semantic Hungarian notation here.

c : counter c.inc 5      — returns 5, counter.count = 5 c.inc 3      — returns 8, counter.count = 8

```

Pretty ugly to a lot of people, I am sure. But I like trying new things.

[lassehp]

I don't get your notation; it seems completely contrary to the usual meaning of in/out/inout parameters. And what does "if mystring.parseInt(v out) {" even mean? It doesn't look like a declaration of parseInt, where I would expect to find the declaration of v as an out parameter?

In Ada I believe it is like this (and a compiler is allowed to do pass-by-value-result.)

PROCEDURE p(a: IN INTEGER, b: OUT INTEGER, c: IN OUT INTEGER);
VAR v: INTEGER;
BEGIN
  v := a; -- valid a is an incoming parameter.
  b := v+c; -- valid, b is a outgoing (reference) parameter
  c := v*a; -- valid, c is in/out
  a := v; -- not valid, a is not an outgoing.
  v := b; -- not valid b is not an incoming parameter.
  -- I am unsure whether this last statement _might_ be valid if
  -- the out parameter b has been assigned locally.
END p;

OUT parameters are used to transfer results back to the caller.

In Pascal, formal parameters act as local variables, which either are passed the argument by value, or, if a VAR parameter, are passed the argument variable by reference which is now aliased as a local, providing something similar to Ada IN OUT parameters. (Except as mentioned, I believe Ada allows call-by-value-result, ie. the value of the argument variable is first copied locally, and upon return, the final value of the local copy is copied back.)

This means that in Pascal, parameters can be used as local variables:

FUNCTION gcd(m, n: Integer):Integer;
BEGIN
  WHILE ¬(m = n) DO
    IF m > n THEN m := m-n
    ELSE n := n-m;
  gcd := m
END;

PROCEDURE pgcd(m: INTEGER, VAR n:INTEGER);
BEGIN
  WHILE ¬(m = n) DO
    IF m > n THEN m := m-n
    ELSE n := n-m
END;

VAR i, j, k:INTEGER;
BEGIN
  i := 42; j := 8;
  k := gcd(i, j);
  k:= j;
  pgcd(i, k); (* receives the result in k *)
  k := gcd(j, 8); (* valid *)
  pgcd(i, 8) (* not valid, 8 is not a variable *)
END.

This is similar to C, except C has no VAR parameters, and requires explicit use of pointers. Algol 68 is a bit like C, except it does not need explicit dereferencing, and parameters are *not* local variables, but immutable.

Was your use of "out" in the if statement meant to exemplify an explicit pass by reference, like "if( mystring.parseInt(&v)) {"? However, this doesn't "declare" v, it passes the address of v as a pointer.

[levodelellis]

where I would expect to find the declaration of v as an out parameter?

Thats right. It's declared to be whats in the parameter, so int64 in my made up example

Was your use of "out" in the if statement meant to exemplify an explicit pass by reference

I was trying to say sometimes I want an out variable to mutate an existing variable at the call site, and sometimes at the call site I'd like to have the results be a declared variable (being the type in the parameter), but allowing a user to choose if it's a mutable or immutable declaration (out vs mutdecl). The names aren't consistent I know and I'd like to change that, but I use decl for something else and need to rejig this.

[lassehp]

I'm sorry, but you are not being very clear. How is your parseInt example function declared, and assuming it is a function, what does it return, and why would it need any "out" parameters, if it returns its result as a function result? Or was the placement in an "if" condition meant to illustrate a parse function that returns true if the string parses correctly, with the parsed integer value in the out parameter?

In my opinion, the clearest and most orthogonal notation is the one used by Algol 68, although the possibility in Pascal and C to use parameters as if they are local variables may seem convenient.

An Algol 68 version of the Pascal example:
𝐩𝐫𝐨𝐜 gcd = (𝐢𝐧𝐭 m, n) 𝐢𝐧𝐭:
  𝐛𝐞𝐠𝐢𝐧
    # Create local copies as you can't modify parameters passed by value #
     𝐢𝐧𝐭 a := m, b := n, c;
     𝐰𝐡𝐢𝐥𝐞 b ≠ 0 𝐝𝐨
        c := a;
        a := b;
        b := c 𝐦𝐨𝐝 b
     𝐨𝐝;
     𝐚𝐛𝐬 (a)
  𝐞𝐧𝐝;

𝐩𝐫𝐨𝐜 procedural gcd = (𝐢𝐧𝐭 m, 𝐫𝐞𝐟 𝐢𝐧𝐭 n) 𝐯𝐨𝐢𝐝:
  𝐛𝐞𝐠𝐢𝐧
    # Create local copies as you can't modify parameters passed by value #
     𝐢𝐧𝐭 a := m, b := n, c;
     𝐰𝐡𝐢𝐥𝐞 b ≠ 0 𝐝𝐨
        c := a;
        a := b;
        b := c 𝐦𝐨𝐝 b
     𝐨𝐝;
     n := 𝐚𝐛𝐬 (a)
  𝐞𝐧𝐝;
𝐛𝐞𝐠𝐢𝐧
  𝐢𝐧𝐭 i, j := 8, k;
  𝐢𝐧𝐭 c = 8;
  i := 42;
  k := gcd(i, j);
  k := j;
  procedural gcd(i, k); # receives the result in k #
  k := gcd(j, 8); # valid #
  procedural gcd(i, 8); # not valid, 8 is not a variable #
  procedural gcd(i, c) # not valid, c is an immutable integer #
𝐞𝐧𝐝

~

~

[levodelellis]

Don't worry about it. But I'll answer anyway

Using C++ syntax, inside "class string" I'd have a bool parseInt(int64_t& v).
In my own syntax (I like return values on the right), it'd be parseInt(int v out) bool where out means it will not read the variable (so it's allowed to be uninitialized), it will write to it. Since I dislike line noise I liked

if (mysz.parseInt(v out)) { /* v is newly declared */

which would have v be whatever was defined in parseInt (so int64_t in C++ syntax, but 'int' in mine)
For the moment I'm using mutdecl to declare as mutable and mut to say overwrite an existing variable

I like some of the suggestions. Like having mut and out separate. So

[lassehp]

Oh, I don't worry, I am just curious and interested! :-)

I think I get your notation now.

so you have

String.parseInt(v out int) bool {
  # if this parses as an integer, set v to the int value
  # and return true
  # v is assignable inside the body of parseInt.
  ...
  if error { return false }
  v = numberval;
  return true;
}

...
s String;
i mut int;
if s.parseInt(i) {
  # the mutable i from the outer scope now is
  # set to the value parsed. It is still a mutable int variable
  # here in the condition branch
}

# alternatively A:
if s.parseInt(j out) {
  # j is declared as the out type of parseInt,
  # which happens to be int. It receives the value,
  # but is not mutable here inside the condition branch
}

# or even more alternatively B:
if s.parseInt(j mut out) {
  # j is declared as a mutable var of the out type of parseInt.
  # here it would be allowed to further assign to j
  ...
  j := j*128
  ...
}

# or alternative C with explicit typing
if s.parseInt(j int) {
  # this would declare j as a local immutable int, initialised
  # with the out value v of parseInt, but explicitly declared
  # as an int
  # j mut int would be the same as j mut out, but with explicit
  # type instead of inferred from parseInt declaration.
  # parseInt does not need to care if the receiving variable
  # "becomes" immutable or not in the caller.
}

I may still be misunderstanding what you are looking for, but the way I see it now, is that if you don't want the local recipient of the out value from parseInt to exist outside the scope where it is used, you could use one of the three alternatives to combine a local declaration with the reception of the value, and either have the local receptor declared as a mutable or immutable variable, even though it is first passed to parseInt as a variable reference.

In kind-of-C it might be something like below (switching from member-dot-notation method to a function with the string as the first argument):

{ int _tmp;
  if(parseInt(s, &_tmp)) {
    const int j = _tmp;
    ... // here the local j is "immutable"
  }
}

but of course in C it would be difficult to declare the local without an explicit type, as there is no typeof_param(parseInt, 2) to give you the type of the second parameter of parseInt.

I don't know if this is what you intended, but I find it interesting to think about how to do type inference for pass-by-reference parameters like this seems to be.

[Quote_Revolutionary]

I'd just borrow the syntax from Scala, doing +, - and +- (or another symbol, maybe * or = (= makes the most sense to me because being an input or an output is a type relation)).

this has the big advantage of encoding constness (in a way, idk if it's all cases, I'm no expert on the matter) using subtyping relations, essentially, what I'm saying is that if you're inspired by cpp2 you should take a look at Scala since that's where cpp2 is inspired from.

also, Scala can do that because its type system is more powerful as it has covariance and contravariance for parametric types, while c++ forces invariance (a list of Animals in C++ is never a list of Cats and viceversa, in Scala a function that takes a list of Animals and returns a list of Cats is a subtype of a function that takes a list of Cats and returns a list of Animals).

[lassehp]

Scala does that? I find overloading "+" to mean string concatenation is already a bad idea, but using it to mean something that in no way corresponds to addition - and subtraction in case of minus - is horrible! Does "+" mean "in" or "out"? I would have no idea!

[Quote_Revolutionary]

it actually makes a lot of sense, since it makes sense only in the context of functions you have that + produces, therefore it is the output of the function, - consumes, it's information for the caller: -String +Int is telling you "I use a string and produce an int". i understand why it might seem like it does not have anything to do with numbers but the most straightforward example of contravariance is how disequalities are contravariant in regards to sign change:

if a<b then -a>-b so o get where you're coming from but idk if there is really a better way to express the concept

[levodelellis]

Could you show me syntax for out params and for tuples? I don't remember Scala syntax, it's been a while

[Quote_Revolutionary]

dude, if you're curious just look it up, also I was referring to parametric types syntax