3 ms·

https://www.blech-lang.org/docs/user-manual/declarations/#subprograms https://www.blech-lang.org/docs/user-manual/declarations/#su... > There are two parameter

https://www.blech-lang.org/docs/user-manual/declarations/#subprograms https://www.blech-lang.org/docs/user-manual/declarations/#su... > There are two parameter lists. The first lists declares formal parameters that may only be read (like `let` variables), the second list declares formal parameters that may be both read and written (like `var` variables). In particular the two lists are useful for activities which, in every reaction, receive a list of read-only inputs, perform some calculation and set the list of read-write outputs. We will therefore often refer to these two parameter lists as “input list” and “output list”. I would have personally used explicit `in` or `out` keywords a la C#, but otherwise it seems a reasonable rationale.

myrmidon 4y ago
Thx for the link! I actually like how that probably strongly pushes towards const-correct design just to be able to omit the second list...
samatman 4y ago
`in` and `out` would have been the familiar choice, but I think Blech made the better one. They sort of wink at this in the documentation, by naming parameters in and out, but more than just freeing a couple nice names from being keywords, this spare notation is a good fit, read vs. read+write is a crucial distinction in embedded. In particular, a function with one parameter list can only read the variables, and that is as clear at the call site as it is on declaration. This is a nice property to have!
- myrmidon 4y ago
  I also kinda like it , but I believe this implies that function types either can't be first class values or that parsing needs full type information because otherwise you couldn't distinguish between single and chained calls-- or am I missing something?
  - samatman 4y ago
    I wouldn't call C functions first class either, it's a fuzzy term though. Function pointers, yes, and that's another place where it's pretty cool that there are two distinct parameter lists. I just found Blech this morning so I don't know how it deals with function pointers. Competently, I'm guessing.
  - samatman 4y ago
    Completely missed your point in a sibling reply, let me try again. Returning a function pointer should be ok, chain syntax is a sugaring which is probably not high-payoff in an embedded language. So would explicitly capture the pointer as a stack variable and then use it, three parentheses would be illegal instead of ambiguous. Seems reasonable to me.
- lifthrasiir 4y ago
  Syntax only distinguished by a relative order doesn't sound robust to me. In contemporary languages keyword arguments are a thing exactly because of that. Marginally related example: many wiki syntaxes had a link syntax similar to `[[foo|bar]]`, where `foo` and `bar` can be either a label or a target and the order wildly varied across softwares---later lightweight markup languages had their lessons and used a different syntax for a label and a target (e.g. Markdown `[label](target)`).
  - samatman 4y ago
    I don't think that's a problem here. There are three options, function(val), function(valA)(valB), and function()(val). I read the manual once this morning before coffee and I know which vals are read only and which are writeable. I've never written a line of Blech. That's pretty good design if you ask me.

myrmidon 4y ago

Thx for the link! I actually like how that probably strongly pushes towards const-correct design just to be able to omit the second list...

samatman 4y ago

`in` and `out` would have been the familiar choice, but I think Blech made the better one. They sort of wink at this in the documentation, by naming parameters in and out, but more than just freeing a couple nice names from being keywords, this spare notation is a good fit, read vs. read+write is a crucial distinction in embedded. In particular, a function with one parameter list can only read the variables, and that is as clear at the call site as it is on declaration. This is a nice property to have!

myrmidon 4y ago
I also kinda like it , but I believe this implies that function types either can't be first class values or that parsing needs full type information because otherwise you couldn't distinguish between single and chained calls-- or am I missing something?
- samatman 4y ago
  I wouldn't call C functions first class either, it's a fuzzy term though. Function pointers, yes, and that's another place where it's pretty cool that there are two distinct parameter lists. I just found Blech this morning so I don't know how it deals with function pointers. Competently, I'm guessing.
- samatman 4y ago
  Completely missed your point in a sibling reply, let me try again. Returning a function pointer should be ok, chain syntax is a sugaring which is probably not high-payoff in an embedded language. So would explicitly capture the pointer as a stack variable and then use it, three parentheses would be illegal instead of ambiguous. Seems reasonable to me.
lifthrasiir 4y ago
Syntax only distinguished by a relative order doesn't sound robust to me. In contemporary languages keyword arguments are a thing exactly because of that. Marginally related example: many wiki syntaxes had a link syntax similar to `[[foo|bar]]`, where `foo` and `bar` can be either a label or a target and the order wildly varied across softwares---later lightweight markup languages had their lessons and used a different syntax for a label and a target (e.g. Markdown `[label](target)`).
- samatman 4y ago
  I don't think that's a problem here. There are three options, function(val), function(valA)(valB), and function()(val). I read the manual once this morning before coffee and I know which vals are read only and which are writeable. I've never written a line of Blech. That's pretty good design if you ask me.