3 ms·

Definitely a few interesting ideas here. As someone who dabbles in Haskell, I'm certainly all in favor of separating pure code from side-effecting code. I'm no

Definitely a few interesting ideas here. As someone who dabbles in Haskell, I'm certainly all in favor of separating pure code from side-effecting code. I'm not quite sure how the constraint that procedures can't return values would work with fetching data from external sources; I suppose that ties in with the reactivity bit? That could work for long-running applications, such as the web apps you seem to mostly have in mind, but for one-off scripts or anything operating in more of a batch mode it seems overly complicated. Building off of that point, it might be better to focus more narrowly on web apps as the target domain, rather than trying to make a general-purpose language. Maybe don't focus the language as tightly as Elm does (where SPAs are the only thing it really supports), but make clear that web apps (and more broadly, reactive GUI applications) come first. Deep const is an interesting idea that I think is worth exploring. While I partially like Haskell's approach of making everything immutable (besides stuff like the ST monad), there's definitely some logic that's easier to express in a mutable fashion. Might be worth looking at the immer library for presenting a mutable interface for working with immutable objects; maybe with a language construct that allows mutability only within a certain scope?

brundolf 5y ago
Fetching data will definitely be one of the more interesting use cases for the func/proc separation. However, I've got a pattern I've already had success with in MobX which should translate here: - loading state, response value, and any error are all observable state (wrapped up in a class) - at creation time you pass a lambda that just generates a promise; this function is set to automatically re-run whenever its dependencies change (this will need to be slightly different for Bagel because promises run eagerly; I plan on somehow expressing a "lazy request" or "request spec" as a pure value that can be generated in a pure context and then requested later in a procedural context) I've seen Immer, it's a very cool idea. Right now I'm planning to stick with raw values even for immutable code, though I'm definitely interested in optimizing over that if I can do so transparently > maybe with a language construct that allows mutability only within a certain scope? I've already got a language construct that allows mutability only within a certain scope ;) As for priorities/focus, I would say the order is: 1) Web GUIs 2) Web Servers 3) Games (probably web-based) 4) Everything else (scripts, etc) I have interest in supporting all of these, and I don't think anything I'm doing will be prohibitive of any of them, but when faced with a choice that's good for one at the expense of another, higher priorities win Though I will say: > but for one-off scripts or anything operating in more of a batch mode it seems overly complicated I disagree; I think I can make the reactive model ergonomic enough that it wouldn't be poorly-suited even to casual scripting. It may not benefit you as much there, but I don't think it will hinder you.

brundolf 5y ago

Fetching data will definitely be one of the more interesting use cases for the func/proc separation. However, I've got a pattern I've already had success with in MobX which should translate here: - loading state, response value, and any error are all observable state (wrapped up in a class) - at creation time you pass a lambda that just generates a promise; this function is set to automatically re-run whenever its dependencies change (this will need to be slightly different for Bagel because promises run eagerly; I plan on somehow expressing a "lazy request" or "request spec" as a pure value that can be generated in a pure context and then requested later in a procedural context) I've seen Immer, it's a very cool idea. Right now I'm planning to stick with raw values even for immutable code, though I'm definitely interested in optimizing over that if I can do so transparently > maybe with a language construct that allows mutability only within a certain scope? I've already got a language construct that allows mutability only within a certain scope ;) As for priorities/focus, I would say the order is: 1) Web GUIs 2) Web Servers 3) Games (probably web-based) 4) Everything else (scripts, etc) I have interest in supporting all of these, and I don't think anything I'm doing will be prohibitive of any of them, but when faced with a choice that's good for one at the expense of another, higher priorities win Though I will say: > but for one-off scripts or anything operating in more of a batch mode it seems overly complicated I disagree; I think I can make the reactive model ergonomic enough that it wouldn't be poorly-suited even to casual scripting. It may not benefit you as much there, but I don't think it will hinder you.