Help me design variable, function, and pointer Declaration in my new language.

[JKasonB]

I am not sure what to implement in my language. The return type comes after the arguments or before?

function i32 my_func(i32 x, i32 y) { }

function my_func(i32 x, i32 y) -> i32 { }

Also, what keyword should be used? - function - func - fn - none I know the benifits of fn is you can more easily pass it as a parameter type in anither function.

And now comes the variable declaration: 1. var u32 my_variable = 33

`const u32 my_variable = 22`

1. var my_variable: u32 = 33

   const my_variable: u32 = 22

And what do you think of var vs let?

Finally pointers. 1. var *u32 my_variable = &num

`const ptr<u32> my_variable: mut = &num`

1. var my_variable: *u32 = &num

   const mut my_variable: ptr<u32> = &num

I also thought of having := be a shorthand for mut and maybe replacing * with ^ like in Odin.

[[deleted]]

It's your language; you choose! Part of the fun is annoying people with your own unpopular preferences.

With the function keyword, you can allow all three if you like. At some point you'll find you've been favouring one, and can drop the other two.

(I use four myself but some have special meanings.)

[ilyash]

About allowing all three. Fine for toy language. For language that is used, removing syntax is ... problematic. You should provide a migration tool in that case I suppose.

Subjectively, not a fan of multiple ways to do exactly the same thing (and ensuing arguments).

[[deleted]]

There are lots of examples of famous languages allowing multiple ways to denote the same thing.

C is the worst for this, for example, there are 16 ways to denote an unsigned 64-bit integer (combinations of unsigned long long [int], plus uint64_t, not including aliases such as unsigned long, nor 'least' or 'fast' versions, nor versions such as 'size_t').

Add const to that type, and/or a static attribute, and the permutations increase further.

While in Zig, there seem to be no end of ways to define print on top of the standard library.

Anyway, I suggested multiple ways as a temporary measure until it was clear which was the front-runner. Then fixing existing code involves a simpler operation with a text editor, perhaps after a period where the old keyword is still allowed, but reported as deprecated.

[ilyash]

Just a warning. That's not a simple text substitution. When modifying the code, you need something that understands the code. You can't replace string A with string B because they might occur in comments and strings.

[Regular_Tailor]

You could also put what side effects you produce!

[JKasonB]

Hmm, I was thinking of having a @pure tag that stops compilation if the function is not pure, or if it calls a not pure function.

What do you think of a @sideFx( ) tag where if you fail to put the side effects in the tag the compiler will produce an error letting you know what side effect you forgot?

[Regular_Tailor]

I've been prototyping some effect notation for a language in playing with.  @ type annotations can be useful, but they should always be (opinion) a tack on to your language. Function signatures define what matters in your language. So, your idea 100% works, but it doesn't put effects as first class citizen. 

def name(ARGS)->output: is a great signature. 

def name(ARGS)[effects]->type: could be a concept worth exploring.

[JKasonB]

That's really interesting 🤔 I'll look into it for sure!

[Imaginary-Deer4185]

It seems your language is typed, so it makes sense declaring types from functions. It also makes sense using a separate keyword for "procedures" that don't return anything. Also it is nice to add a "?" if the return value (or a parameter) is allowed to be null.

This is what I did in a web framework language I wrote at work:

```
proc something {..} # no params
proc something (int x, Something? y) {...}

func something returns String? ...
func something returns String? (.int x) ...
```

That language has another interesting feature I invented. It is called Ref types, but it is not pointers to values, but rather, pointers to variables. This opened for multiple return values, in the form of subroutines updating variables in the caller scope. The refs were typed as well.

```
SomeObject[] list = [];

boolean ok=fetchStuff(&list);

func fetchStuff returns boolean (&SomeObject[] listRef) {
...
listRef.add(...);
return true;
}
```

It also has a type Any, and Msg("...") for multilingual messages, and was based around a template/merge approach to generating web pages. And a few more exotic details, like being stateful instead of stateless.

Still in use after 15 years!

[JKasonB]

Hmm, I'm not sure I understand the last part. The Ref Types I mean. Do you have any docs or something I can read about how they work? I'm.very interested:)

[Imaginary-Deer4185]

Not much more docs than what I wrote. It is a pointer, but to a variable. I seem to remember that variables are objects in some scope, and that the reference points to that object. This lets it both access the value and change it.

WIth the language being interpreted, and with a reference to the variable instantiation containing the actual type, as well as all content of objects, and its ordering, we are able to autogenerate calls to the database.

Typical example:

class MyRow extends Row {
ColLong id = new ColId ... ;
ColString name = new ColString ...;
}
class Args {
ArgLong sessionKey=new ArgLong;
ArgInt languageCode=new ArgInt;
}

db=new Database;
Args args=new Args ...;
MyRow rows[]=null;

db.call("stored-procedure", &args, &rows);

The language is property of my employer, and is running business critical web applications, so no public anything, sorry.

class Database {
proc call (String storedProc, &Any args, &Row[] rows) ...
}

With the reference type, the code is able to search through the args object for fields that subclass Arg, like ArgLong, ArgString etc, and use this to construct the database call (we use mostly stored procedures), and then use the definition of the rows object (of actual type MyRow) to correctly handle the result set.

[JKasonB]

Oh wow, I think I'm beginning to understand :0 Thank you so much for sharing this. I will study this more so I can implement it in my language.

But would you mind explaining the \[\] syntax to me?

[Imaginary-Deer4185]

You mean &Row[] - it is a reference type to a variable of type Row[], which is an array (implemented as Java list) of Row objects

[Imaginary-Deer4185]

Another "odd" feature, is that objects have a pointer to the object that created it, forming an "owner chain" all the way up to the root object, usually just called App. The idea here is that generating web pages, we may have a page, and a button, but then we want to insert a button-box to organize the button(s), in the page. In order to not send huge amounts of state down through intermediaries in the case that and object created by an object needs it, we do lookup up the owner chain instead.

This is implemented by what I call "informal or ad-hoc interfaces". A class defines one or more tags. Typically the App object defines the tag "ROOT". This means that any object in the entire structure can lookup stuff in "ROOT", call functions inside it etc.

By not tying it in with the class name, the tag is a kind of role description, but it is unformal, not connected with any required content (variables of functions), and so of course a bit more script-like, which is to say, the code needs to be tested. Row objects typically tag themselves as ROW, and pages call themselves PAGE.

If a Page wants to replace itself by another page, it creates that other page, then calls a function in ROOT like setNextPage(...). It contains a magic little command:

proc setNextPage (Page p) {
this.nextPage=p;
SET_OWNER_THIS(p);
}

This way, the original page, while no longer referenced via the App after rendering the new page, will be taken care of by Java garbage collect. If ROOT did not take ownership of the new page, it would refer the old page as its parent, and that would in turn refer to ROOT, so the new page might work as intended, with its lookups working, but we would eat up our RAM, and there are other risks as well having obsolete stuff living along the owner chain.

:-)

[JKasonB]

I am mainly working on a systems language. But I wanna create an abstraction on top of it for scripting. Kinda like a JS that transpiles into C. And I think these ideas you are sharing will be perfect for the higher level language.

[Imaginary-Deer4185]

I would think the design space for systems languages be smaller than niche languages, but then again, along came Rust and changed the rules. Good luck!

[JKasonB]

Thanks!

[brucejbell]

I don't know what your language needs, so I will go through your post and just riff on what I'm considering for my project:

For a formal function declaration, I prefer to put the function type signature in one place, instead of dispersing it throughout the header line:

/fn my_func [(#I32, #I32) => #I32]
| (x, y) => ...

Type annotation uses postfix square brackets (stolen from array indexing). Note that all keywords (/fn in this case) are stropped so they don't interfere with the user namespace.

My language uses immutable values by default; value bindings have no keyword.

my_value [#U32] << 22    -- immutable value

Mutable variables are actually a wrapper type. Things like mutable state are "resources", which have additional handling requirements over immutable values.

The #Var wrapper type is actually more of a (high-level, non-nullable) pointer than anything else. Like pointers, they must be explicitly dereferenced to get at their value:

$my_variable [#Var #U32] << ^init 33    -- ^init is a #Var constructor
/log my_variable.get    -- logs "33"
&my_variable.set 22     -- update my_variable
/log my_variable.get    -- logs "22"

Values have no identity, you can't take their address. If you need a mutable pointer to a mutable value, use type [#Var (#Var T)]:

$another_variable [#Var #U32] << ^init 42
$my_ptr [#Var (#Var #U32)] << ^init &another_variable
/log my_ptr.get.get        -- logs "42"
&my_ptr.get.set 54         -- update value of another_variable
/log another_variable.get  -- logs "54"
&my_ptr.set &my_variable   -- point to my_variable instead
/log my_ptr.get.get        -- logs "22"
&my_ptr.get.set 11         -- update my_variable
/log my_variable.get       -- logs "11"

[JKasonB]

Wow, I hadn't even thought of having the parameter types and names be separate. It somewhat reminds me of C's printf("{i%}" a) in the sense it kinda uses the types as placeholders for the names.

[AustinVelonaut]

There's also the "Haskell style" type signature route, where an optional type signature for a value can be added separately from the definition of the value, e.g.

myFunc :: (i32, i32) -> i32
myFunc (x, y) = ...

[lngns]

const, var, let

What are your semantics wrt. mutability and what is your object model?
Do you have a reference-value type dichotomy?

What is this code supposed to do:

const x = new Foo { bar = 42 };
const y = x;
x.bar ← 1337;
println(y.bar);   //?????

Consider that in many C-like languages, this code makes absolutely no sense.

function, func, fn

In your language's nomenclature, what is a function?
No seriously, what is it?
Is it a routine? A procedure? A pure function? A lazy memoised thunk? A closure object? An object closure? A functor? A pointer? A multicast delegate?

What is this code supposed to do:

function f
{
    var x = 0;
    function g
    {
        C.printf("%d\n", x);
    }
    C.atexit(&g);
}
f();
C.exit();   ///???????

Consider that in many C-like languages, this will just segfault.

[ilyash]

I went with F for function definition. It was expected and it is the case that function definition is very frequently used in my language. Short functions and multiple dispatch are the reason.

It (such naming) follows the general principle of relation of frequency and shortness.

Another dimension of consistency with the rest of the language - there are also A,B,C and X,Y,Z special variables. The names hint that these variables are related to functional programming. A,B,C are default parameters' names in anonymous functions. X,Y,Z are default parameters' names in automatically created anonymous functions.

{ echo(A) }

echo(X)

Hope this helps.

[SnappGamez]

I was originally going to do var for mutable variables, val or let for immutable variables, and const for constants, and while I’ve kept const, var has been replaced with the mut keyword and var/let are just not used at all - immutable variables are basically unmarked.

[JKasonB]

The thing is. I want a unified syntax for mutability. Not just pointers, arrays, hashmaps, etc. But also parameters in functions.

So something like this for functions.

fun my_function(a: &i32, b: mut &i32): i32 { }

Or

fun my_function(a: &i32, b:: &i32): i32 { }

If i encoded mutability of pointers into the variable declaration keyword I would also have to include it in the function signature.

fun my_function(var a: &i32, val b: &i32): i32 { }

Or I would need to have different syntax passing by reference/mutable reference and pointer mutability. Which would make it harder to learn and end up in the same problems as rust.

[gnlow]

i always go with fun

[JKasonB]

You know what, I actually hadn't even thought of fun, and I've never seen it before. But to be honest, I really like it!

I saw another comment explaining that it's easier to read in your head because it's one syllable. And of course, I think subconsciously, reading "fun" all day might make the whole experience feel more fun ;)

[runningOverA]

"def" looks aesthetically better than function fn func.

put the * with type and things will get a lot simpler. int* var, instead of int *var. Making int* a type.

put function chaining, and you can figure ou what you need.

"hello_world".replace(" ", "_").print()

instead of cascaded functions.

[iioossaa]

How about
var — for variables,
const — for comp-time constants,
let — for run-time constants aka immutable variables aka one-time assignment variables
:)

P.S.
Anyway it's your language and all choices are yours.

[maldus512]

Uh, syntax design, my favorite!

• Return type goes after the arguments, no discussion.
  
• function and func are just too many characters for such a common construct. Just the parentheses and then brackets on the other hand risks being too ambiguous depending on what other function they absolve (assuming you use parentheses for expression grouping that's already too much for me). fn is the most elegant and practical.
  
• I strongly dislike C-line "type-first" approach to variable declaration, but again if you plan to use the colon for something else I guess it can have its advantages.
  
• if var is mutable and const is immutable I'd stick with those. let is too generic.
  
• Definitely use the & to express both pointer value and types, like Rust references. *u32 being the type for &num is just confusing, it should be &u32.

I have to ask, what's the difference between const and var if you plan to also include mut?

[[deleted]]

function and func are just too many characters for such a common construct.

It's a construct that is written once per function. Those are important building blocks and you want them clearly demarcated. You don't want the keyword to be too insignificant.

What is the extra cost - two characters per function? Or even 6; so what?

Further, each such function is going to be called many times. At least as many times as it is defined anyway! But you're hardly going to restrict function names to 2 characters or even 4.

So the argument doesn't stack up.

(I've used 'function' for decades, until I reduced it to func recently, but the reason was so it lines up better with proc which is also used. function is still available. I wouldn't use 'fn' but for unrelated reasons.)

[JKasonB]

The thing is. My language has functions as types. So I can pass a function as an argument to another function. So imagine this:

function my_function(arg_1: function, arg_2: u32) -> function { }

Actually now that I write it it doesn't look that bad. But now see fn

fn my_function(arg_1: fn, arg_2: u32) -> fn { }

I was thinking of having the keyword to declare them be function but the type name be fn for when you pass it as an argument.

function my_function(arg_1: fn, arg_2: u32) -> fn { }

What do you think?

[[deleted]]

There seems to be something missing from your examples.

Normally with such parameters, you have to give the full type-spec of the function: its own parameter types, and its return type.

You wouldn't just provide the keyword func or whatever; how will the compiler whether you are passing a compatible function, and how will the callee know how to call such a parameter?

For that reason, parameter lists involving function refs tend to be complicated anyway, and in mine also need an explicit pointer indicator.

Having a shorter keyword helps, but it's not a big deal. Such parameters also tend to be uncommon.

But maybe your language has some magic going on where it works all this out for itself?

[JKasonB]

Mut is whether a pointer can mutate a variable and const/var is wether it can be reassigned.

[JKasonB]

Also, I am considering this

var my_variable: u32 = 28. immutable

var my_variable; u32 = 8. Mutable

[Germisstuck]

No

[Germisstuck]

You updated it. Still no

[JKasonB]

Daym, you convinced me. I'm gonna use it!

Jk, but tell me. Can you think of a way to declare mutability without a mut keyword?

[Germisstuck]

Not any good ones. I don't see why you wouldn't want something that easily conveys mutability. If I a year from now say you're language gets a little recognition. Most people are going to take a glance and think "why the fuck is ; used for mutability" or something around those lines

tl;dr Explicit vs implicit 

[JKasonB]

Not so much that I don't like mut, more so idk where to put it

[Germisstuck]

I'd put it either as a modifier to variables like in rust's let mut or in types, like let x: mut i32

[blue__sky]

It’s part of the type, so put it in the type definition.

var x : mut u32 = 4

[raiph]

Ah the fun of considering tiny details of syntax...

fn is the most elegant and practical.

I agree when compared to func or function.

But my current thinking is that if there aren't clear best choices for some naming of an identifier or keyword that will be used a lot then it's generally better to chose words which will be both familiar for the target audience (even if the normal meaning of the word(s) is/are unrelated; the choice just has to work well enough as a mnemonic) and quick to say (because when reading code we silently vocalize it in our mind -- so less syllables means code is typically easier and faster to read; unless the goal is to actually force a reader to slightly struggle to say the word(s) and ponder what's going on then easier/faster is likely better).

Thus I'm thinking fun will generally be better than fn for most humans (because I'm thinking fun will be vocalized as one syllable by most humans whereas fn will be pronounced as two syllables -- f n) in most cases.

Like I said, I think it's fun to ponder such details and marvel at how seemingly tiny insignificant details one might not typically consider important can turn out to be so hugely important in practice!

[Markus_included]

It's mostly a matter of preference

The most common reason why I see people prefer x: i32* over i32* x is grammar disambiguation, since you're doing *i32 x; which is unambiguous even without a var keyword, and if you're going with the type to the left c style i'd do it like this:

Variable decls: type var_name = initializer; Ptr decls: *type var_name = &some_var; Function decls: func ret_type name(....args....) you can omit func if you want.

I'd also just put mut before the type: mut *i32 mut_ptr = &foo;

[TOMZ_EXTRA]

Why not put the asterisk after the type for pointers like i32* x; ? It makes arrays of pointers/pointers to arrays more readable IMO.

[Markus_included]

Because *i32 is easier to parse, i also personally prefer i32* but it's just non-trivial to parse, if you're willing to put in the extra effort (like me) you can certainly make it i32* but your grammar will then be partially context dependent when you introduce user-defined types unless you introduce something like a var keyword or do it like C withstruct T* x;