Collection: Language semantics

[jonasstrehle]

Collection to discuss language semantics.

[jonasstrehle]

Syntax for function declarations

What would be a nice syntax to declare functions? Do we have to restrict parsing logic due to logic issues here?

A DATEX function can consist of keywords (pure / async / whatever), name, params, return type, and body.
Do we want to stick to the bracket only syntax as we did in DATEX v1? Note that we might run into issues to detect what exactly is intended to be the body because of the fact that brackets are allowed anywhere in DATEX and we have support for apply chains.

First of all the naive syntax could look like this:

// default
function myFunction(x: integer) -> integer | string (
    42
)

// untyped and typed params
function myFunction(x, y: integer) -> integer | string (
    42
)

// mutable ref
function myFunction(&mut myRefMut) -> integer | string (
    42
)

// ref, variadic args
function myFunction(x: &MyRef, ...y: integer[]) -> &integer (
    x
)

// ref, variadic args and error
function myFunction(x: &MyRef, ...y: integer[]) -> Result<integer, Error> (
    Ok 4
)

Questions

1. What is a nice compact syntax?
   1.1. Do we want to use function as keyword or something shorter like fn?
   1.2 Shall parameters be handled as tuple that allows optional type declaration? (x, y), (x: integer, y)
   1.3 Which keywords do we want to support and which order? (pure, ...)
   1.4 What is a syntax for the return type? -> type okay?
   1.5 Which types of brackets or separators do we want to use? ({} over ()?)
2. Do we want to add support for implicit return? Like the last value gets automatically returned from the method and the type gets inferred?
3. Do we want to difference between functions and procedures? Like methods that don't return anything
4. How to we differentiate between references (including mutability) and values?
5. Do we want to support generic functions or templates? (function<T>(x: T) -> T ())
6. Should functions support overloading based on type signatures?
7. Do we need generator functions?
8. Do we like to introduce a custom error type as return type like Rust or some annotation for throws as in Java? myFunction() -> string throws Error vs myFunction() -> Result<Good, Error>
9. How to declare coroutines? With keyword only?
10. Shall we support default parameters? (x: integer = 5) (Note that this is not okay syntax for the rest of the grammar without var keyword!)
11. What is up with variadic args like function(x: integer, ...y)?
12. Do we need decorators or function attributes?

@benStre @janiejestemja @asbng @ced1406

impl wip

[jonasstrehle]

Alright, thanks for the input @benStre. Most looks good to me, let's create issues for the stuff that we need to discuss in another round.

1.1. I prefer 'function' for readibility, even if you have to write a few more characters (ask the we don't live in 1945 anymore guy). In the end, it somewhat depends what our main focus for DATEX (script) is. I see i more as a universal, precise, easily human-readable description of structures, interfaces and functions. Therefore, I prefer readability. For more efficient code writing, you could make the argument for 'fn', but in the end Copilot auto-completes this for you anyway.

I'm ok with that, shorter keyword is not hard preference imho, would just be a cleaner syntax maybe. But since DATEX also uses long names for types such as integer over int we could argue that function makes sense. Btw fun is ugly 🗡️

1.2 I would actually enforce type declarations for function signatures. We want to enforce typing from the start and not start like a python-like scripting language that realizes later on how useful types are.

good for me

1.3. 'pure' definitely. I'm not so sure about 'async', because we don't really need this concept for the runtime functionality. DATEX functions could implicitly be inferred as async if this has any use for the compiler, but wouldn't want to introduce an explicit async/await paradigm for normal async execution. DATEX script syntax especially for remote executions is so clean and minimal because we don't need explicit async code (e.g await @example :: 1 + 2). Imo, DATEX works on a higher abstraction level, where we don't need to distinguish here between async and sync execution. If the user wants to explicitily run a task in the background, he can explicitly state this using a keyword like run or do and await the result with await.

unsure, what happens when function use coroutine inside? Can we wait for the inner execution to finish before return? I guess to see if a function might be executed as coroutine or no a decorational keyword might be helpful. Fair, that we dont want to introduce a oll await paradigm as there is in JS but somehow only using run might be not enough here. Do you see this point?

1.4 I'm fine with ->, but I also like the simple : - this would keep the -> syntax free for other use cases.
Note that for function declarations we are absolutely free to parse independent of the other grammar (for example we only allow strict tuples and not empty commas or no brackets or whatever as params), so we don't need to "reserve" the -> syntax, because in another context outside of function declaration (that consist of keyword, params, return, body....) this can be used without issues for something totally else.

I see that function test(x: int): int (5) is way less readable than test(x: int) -> int (5) is. I'd highly prefer to not overuse the : syntax here.

1.5 There is definitly some ambiguity regarding this, but we don't solve this by just using {}. We really need to make sure that the return type can be distinguished from the function body. Here's an example that would also not work with curly brackets:

Yes, also my solution - disallow apply chains here

5. / 6. / 7.

ok

8. Not sure about this. I don't really want to introduce generics like Result and Option, blowing up the core type even more - we already have null for options: e.g. astring | null type to represent Option<string>. Similarly, we could just return a union type containing the errors, like string | ParseError.

highly unsure, from first POV union only would be cool, yes. But I see that we can not handle ergonomic like in Rust with ? as the compiler doesn't know that "union with Error" should imply special handling as error case. Also errors (what I think should involve special handling by design for compiler & runtime) shouldn't find there way into the "normal" data flow, what would be easily possible in any case (just see how you do an addition on x = callwithpossibleerrorunion() + 5 without ? or unwrap syntax). If we would strictly enfore the user to inherit some core:Error type, we could handle for that and also know which values shall be treated as Errors and which not, but this would disallow us from defining an any-return error case for example as we can do in Rust Result<string, integer>. Maybe this is a tradeoff we can make?

9. / 10.

ok

11. Not a huge fan of rest params. We already (probably) have named arguments, and also addding rest params on top could be confusing and is not really that beneficial imo. The only real use case I can currently imagine is something like the print!() macro in rust (note that rust does also not have rest params in normal functions). But we can represent formatted strings with values much better in DATEX with template strings, so no need for rest params in this case.

no strict nok from me, see your point and might be odd in special use cases.
Nevertheless stuff like max(1, 2, 3, 10, 5) or sum or definition of mathematical stuff like matrixes or vectors or shit would be really cool with rest params. Also JSX later div("hello", span("world"), strong("!")) would be cool to allow the method to be function x(x: string, ...args: JSX[]). On the other hand we could argue that function x(x: string, args: Tuple<JSX>) {} would be also ok here. Maybe tuples are our way of representing variadic args already.

12. ok

[benStre]

regarding 11., I think tuple applies are the correct way to go. An apply like max (1, 2, 3, 10, 5) could be interpreted as a function call with a single tuple argument, like function max(values: tuple<integer>). Since we allow function calls with a single argument without parentheses, this would not be interpreted as a function call with multiple args, but with a single tuple as an arg, matching the function signature. Similarly, something like max [1,2,3,4] would also always work.

[benStre]

Let's discuss point 1.3 in the next meeting. I really don't think we benefit from async declarations, since almost any function in DATEX is potentially async, as soon as pointer loading, updates and remote sync is involved.

[janiejestemja]

Left out the points i got no opinion on. Also i have no idea if i am on track with any of the following.

• 1.1 Personally i prefer shorter expressions - however readability wise i'd argue it depends on the rest of the language. Meaning - if type declerations like integer or Error are not shortened to int and Err respectively, why should a function declaration be shortened - wouldn't that be just inconsistent?

• 1.2 If return types can be specified, input types should be specifiable as well.

• 1.4 I'd argue this depends more on Point 8 down below? (-> type is nice but would -> type | other_type throws SomeError also be nice?).

• 1.5 I'd argue () is more beginner friendly to type (especially on std german keyboardlayout), so it might be worth sticking to it.

"2." If input param types are optional, inferrence of output types is inheritely ambigious - and if inferred types are off too often type-casting becomes the norm. Other than that i think flexibility of inferred types would be a great thing to have.

"5." Good templates and generics can avoid overloading, i guess?

"6." Only overloading i tend to do is for operators - but for functions i'd avoid it.

"8." Maybe something like

function myFunc(x: integer, y: string) 
-> integer | string
~> TypeError | NameError
( function body )

would stay readable and scalable even in complex scenarios?

10. Defaults are too nice to pass up on.

11. If it is possible to use containers of arbitrary length as params i don't see a usecase.

[jonasstrehle]

Hi @janiejestemja,
thanks for your comments!

This summarizes the points we settled on and the open ones we have to discuss in another round.

• 1.1 Personally i prefer shorter expressions - however readability wise i'd argue it depends on the rest of the language. Meaning - if type declerations like integer or Error are not shortened to int and Err respectively, why should a function declaration be shortened - wouldn't that be just inconsistent?

Yeah, so decision is made then, we'll stick with function

• 1.2 If return types can be specified, input types should be specifiable as well.

The question is more how they can be specified, not if.
x: integer vs integer x, if we'll allow var x: integer, and if we enforce declarations or no like is (x: integer, y) allowed?

• 1.5 I'd argue () is more beginner friendly to type (especially on std german keyboardlayout), so it might be worth sticking to it.

3/3, so we stick with ()

"5." Good templates and generics can avoid overloading, i guess?

Yes, a polished template / generic system can be a great enhancement for DATEX. But that's gonna be some future stuff and won't be implemented for the first iteration. In any case, you're correct, we can avoid ugly overloading.

"6." Only overloading i tend to do is for operators - but for functions i'd avoid it.

For custom types that would be actually nice allowing operator "overloads", like Vec2d(1,2) + Vec2d(1,4). The user won't be able to define the precedence of the operator, but the implementation on how the operator works can be given. I see no issues here.

"8." Maybe something like

function myFunc(x: integer, y: string) 
-> integer | string
~> TypeError | NameError
( function body )

would stay readable and scalable even in complex scenarios?

Would allow us for a strict separation between error and return types, so quite beneficial for readability. We could also reuse the -> operator for both cases. On the other hand, this forces the user to define functions declarations in multiple lines since one liners become quite fast unreadable. Let's take it as discussion point to the next meeting.

• Defaults are too nice to pass up on.
  3/3

20. If it is possible to use containers of arbitrary length as params i don't see a usecase.

3/3

[jonasstrehle]

Reserved keywords

How shall we treat custom keywords in struct declarations?

If we have custom keywords, such as var, const or type - how can we use them in struct declarations without fucking with our lexer and creating overhead?

{type: "websocket-client", config: {address: "wss://example.unyt.land"}}

Shall we use some special syntax like r#type or d#type such as raw identifiers in Rust or is there a better cleaner way? Note that we must consider the mapping to other languages, like the struct {#type: 4} must be accessible in dx via mystruct.#type or mystruct.type or mstruct["type"] while in JS we allow .type accessor.

@benStre @janiejestemja @TeeB3utel

[benStre]

We must definitily allow all keywords as object/tuple properties to ensure JSON compatibility. This might cause some parser overhead, but JS is also fine with this so I don't see this as that much of a problem. For variable names, we should dissallow reserved keywords to prevent ambiguity.

[ced1406]

1.1 I think "fn" would be a cleaner way, but I already talked to @jonasstrehle about this topic and I fully understand his point. So I agree with using the keyword "function".
1.2 The optional type declaration for parameters be handled as tuple makes sense in my opinion.
1.4 Using "-> type" is a nice and clear way to show the return type of a function.
1.5 I personally prefer these kind of brackets: "{} " for e.g. the "body" of a function. This allows a clear distinction between the different uses.
2. Interesting thought. However, this could easily lead to errors or problems. So I think this shouldn't be supported.
3. I'm not sure about this point, but I think keeping it simple and only use functions is a better way.
4. Using a "&" for references is a common and clear way. I would keep this like in the examples above.
6. A support for overloading is very useful in my opinion.
10. The option to set default values for parameters should be also included. There are tons of use cases for this and it also makes sense to have a cleaner code.