Keyword inputs and outputs

multisamplednight commented

2024-01-09 10:56:47 +00:00

Collaborator

This proposal introducing keyed inputs and outputs.

Inputs need to be keyed if there are more than 1 of them
Outputs need to be keyed if there are more than 1 of them

The example from the Source section in the design document transformed to fit this:

open base.png    >|base
open stencil.png >|stencil
mask
  rest|> (invert | show)
masked|> show

Notes

Simple forwarding is only possible if the streamer produces only one output and the consumer takes only one input.
If a command has only one {in,out}put, it may be keyed, though the key doesn't have to be specified when pipelining, as it's unambiguous.
We could maybe expand this to support renaming of arguments:

-- ...
mask >masked|divisor> div 1

This'd take the masked output of mask and use it as the divisor input of div.

Pros

Code can be read without intricate knowledge of argument order
- Be it through docs
- Be it through trial and error

Cons

Might make simple code more complicated

Questions

Other syntax suggestions?
- Is the syntax from above readable?

This proposal introducing keyed inputs and outputs. - Inputs need to be keyed if there are more than 1 of them - Outputs need to be keyed if there are more than 1 of them The example from the `Source` section in the design document transformed to fit this: ```haskell open base.png >|base open stencil.png >|stencil mask rest|> (invert | show) masked|> show ``` ### Notes - Simple forwarding is only possible if the **streamer** produces only one output and the **consumer** takes only one input. - If a command has only one {in,out}put, it _may_ be keyed, though the key doesn't have to be specified when pipelining, as it's unambiguous. - We could maybe expand this to support renaming of arguments: ```haskell -- ... mask >masked|divisor> div 1 ``` This'd take the `masked` output of `mask` and use it as the `divisor` input of `div`. ### Pros - Code can be read without intricate knowledge of argument order - Be it through docs - Be it through trial and error ### Cons - Might make simple code more complicated ### Questions - Other syntax suggestions? - Is the syntax from above readable?

multisamplednight added the

proposal

label 2024-01-09 10:56:51 +00:00

multisamplednight changed title from ~~Keyword inputs and outputs?~~ to Keyword inputs and outputs

2024-01-09 10:57:00 +00:00

schrottkatze commented

2024-01-10 11:59:31 +00:00

Owner

Yeah, makes sense.

However, I'd treat outputs as lists so one could also split an array like this:

[ 1 2 ] 
    |> ...
    |> ...

That's however impractical, if we want full static typing so we probably should differentiate between static and variable length lists... potentially tuples, so we can easily destructure them?

The splitting and combination syntax is kinda a headache in general, and i think we should on a type level only allow single inputs and outputs in an operator/command/modifier (though, of course with syntactic sugar for lists/tuples to simplify?)

Yeah, makes sense. However, I'd treat outputs as lists so one could also split an array like this: ``` [ 1 2 ] |> ... |> ... ``` That's however impractical, if we want full static typing so we probably should differentiate between static and variable length lists... potentially tuples, so we can easily destructure them? The splitting and combination syntax is kinda a headache in general, and i think we should on a type level only allow single inputs and outputs in an operator/command/modifier (though, of course with syntactic sugar for lists/tuples to simplify?)

multisamplednight commented

2024-01-18 18:21:32 +00:00

Author

Collaborator

The splitting and combination syntax is kinda a headache in general, and i think we should on a type level only allow single inputs and outputs in an operator/command/modifier (though, of course with syntactic sugar for lists/tuples to simplify?)

Why exactly? Then we'll just end up using lists, dictionaries or structs for commands that do need multiple inputs (e.g. add/sub/mul/div/mod).

> The splitting and combination syntax is kinda a headache in general, and i think we should on a type level only allow single inputs and outputs in an operator/command/modifier (though, of course with syntactic sugar for lists/tuples to simplify?) Why exactly? Then we'll just end up using lists, dictionaries or structs for commands that **do** need multiple inputs (e.g. add/sub/mul/div/mod).

multisamplednight commented

2024-01-18 18:24:08 +00:00

Author

Collaborator

However, I'd treat outputs as lists so one could also split an array like this:
[ 1 2 ] 
  |> ...
  |> ...

What would be a usecase for splitting a list like this?

Also this again introduces the problem of not knowing which index refers to what semantic output. Take the mask operation for example, which could return the masked part and the rest (the unmasked part).

> However, I'd treat outputs as lists so one could also split an array like this: > > ``` > [ 1 2 ] > |> ... > |> ... > ``` What would be a usecase for splitting a list like this? Also this again introduces the problem of not knowing which index refers to what semantic output. Take the `mask` operation for example, which could return the masked part and the rest (the unmasked part).

schrottkatze referenced this issue

2024-01-18 19:04:55 +00:00

docs: some initial groundwork #2

multisamplednight commented

2024-01-18 21:27:22 +00:00

Author

Collaborator

From @schrottkatze in #2:

This is why I proposed using lists, dictionaries etc. in #4, to make this easier/cleaner

We'd need a type system before we could implement this then.

From @schrottkatze in #2: > This is why I proposed using lists, dictionaries etc. in #4, to make this easier/cleaner We'd need a type system before we could implement this then.

schrottkatze commented

2024-01-18 22:48:15 +00:00

Owner

I will take care of that ASAP, it's just that i'm horrible in thinking in documentation and rather just implement something and get it working and improve that and then document it, so that effectively depended on your work ^^'

multisamplednight commented

2024-01-19 02:01:52 +00:00

Author

Collaborator

"ASAP" is definitely not necessary, lol. Do it anytime you want. And if you figure out that you don't, then we'll think of something else.

schrottkatze referenced this issue

2024-01-19 11:22:30 +00:00

feat: Graph IR #6

multisamplednight referenced this issue

2024-01-22 09:05:02 +00:00

feat: Graph IR #6

Keyword inputs and outputs #4

Notes

Pros

Cons

Questions