Open dumblob opened 3 years ago
I'll try. :)
This part still bugs me because in D land I'm forcing developers to create new Range
child classes every time and that feels not only dumb but a lot of work (and the module code starts to feel messy). I'm not happy with the current situation.
At Til land I'm not sure what would be the best syntax. Right now I think about following Nim path and creating a generator
command in the molds of proc
.
generator g (x) {
range $x | foreach i {
yield "this is the item $i"
}
}
g 5 | foreach i {
io.out $i
}
Although I like the idea, that has its own challenges: yield
should not be able to yield multiple values or multiple values would need to be wrapped in a SimpleList. Sad.
But, at the same time, I'm trying to conceive some situation where a "generator"/producer is created by not using another already existent generator/producer, so maybe that'a case to allow DRY principles on the transform
command.
Also: not possible, yet, for any kind of Til procedure to receive from a data stream, like:
proc receiver () {
receive_directly_from_the_pipe_somehow | foreach x { ... }
}
range 10 | receiver
Maybe, in the end, the answer is: "make any receiver/producer a new process and create the proper primitives using Pids". I'm not discarding this possibility.
Let's discuss general concepts in the other thread first and see where it goes: https://github.com/til-lang/til/issues/8
I couldn't find a way to define own (or at least wrap existing) pipe primitives so that I could handle more complex streams (i.e. strems of non-trivial data types), streams of streams, double/triple/quadruple/... streams (select/poll/epoll), etc.
Currently it seems these are pipe "producers":
range
receive
And these pipe "consumers":foreach
And these both "producers" and "consumers":transform
case
Could you enlighten me?