3 ms·

At first glance, the multiple bracket groups in the function signatures look really weird to me. Does anyone know what the motivation for those is? Example (f

At first glance, the multiple bracket groups in the function signatures look really weird to me. Does anyone know what the motivation for those is? Example (function definition): function writeTicksToDisplay (ticks: int32) (display: Display) [...] end Function use: writeTicksToDisplay(totalTime)(display)

lifthrasiir 4y ago
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.

lifthrasiir 4y ago

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.