![]() ![]() This step also we can do in Rust via "cargo build" and "cargo web start. Generating an x86 binary (compiling the shared code + Se4rver Monad) and app.js (compiling the shared code + Client Monad). I think we can do something similar here in Rust - one crate, some with different #cfg directives on different functions. Other functions have type signature on Client Monad. Some functions have type signature in Server Monad. Haste, however, is a separate compiler from GHC. ![]() Haskell's "metaprogramming", "template haskell" tends to not be used as much. Afaik, that is not what is going on with Haste. To me, "metaprogramming" means macros - lisp or rust style macros. I do not know what you mean by "metaprogramming" here. Additional design issues arise because of Rust's explicitness about error handling.Ĭorrect me if I’m wrong, but Haste apps look a lot like metaprogramming The compilation artifacts are derived from the recipe, which happens to be a Haskell script file. This is where conditional compilation (feature gates) and clever abstractions come in again. So the haste compilation step introduces a communication interface that is also injected into the clientserver calls.ĭeriving that interface is an easy step, but injecting it into the program logic to replace procedure calls sounds like an obstacle. Features could gate items to only compile in either situation. At a minimum, you'd need | macro's or script parser (build file) | and clever abstractions to get similar results. Haste is a compiler on itself, but I'm unsure what and how it exactly creates the artifacts. Instead of two separate codebases that talk over some API, se think of it as a “single app” (with main function in Client monad). So your idea brings nothing new, it just ignores actual characteristics of implementation details.Ģ.3 Everything is type checked by Haskell type system. Without testing type constraints this will simply lead to crashes and/or memory exposure. You cannot 'not dynamically test' because wire-encoding is a transformation with loss of information. One could assume decoding is a statically type-checked process, but that's practically transforming a byte buffer into a struct type without validity checks at runtime. (Encoding into wire format is not relevant here) Except for the wire format decoding, everything (all application logic) is already type-checked statically. It's already transport-agnostic because the returned (boxed) future could be an instance of an RPC resolver or a 'from memory' resolver. This trait is the common interface between client and server. A service trait defines functionality and provides a future that resolves with the service result. (Almost) every Service/RPC library already works like that. All ajax/get/communication is handled by macros.įor this example, the server does NOT need to notify all clients whenever inc/dec happens (for simplicity, we can worry about updates later). Then, the client can interact with the counter as if it's calling a local function (that returns a future). The "Hello World" of this is to have a single shared counter with.Question: How close can we get to this model in Rust? I would like to have a single app, compile it twice (wasm32, x86), have it generated client + server code, and have all communication (GET/Post over AJAX) to be type safe and automatically generated on the fly. ![]() Instead of two separate codebases that talk over some API, se think of it as a "single app" (with main function in Client monad). The client can call server side functions (and AJAX Get requests automatically taken care of).Ģ.3 Everything is type checked by Haskell type system. Some functions are in Client monad.Ģ.2 The codebase is compiled twice. My understanding of Haskell/Haste ( ) is something like this:Ģ.1 We write a single Haskell codebase. However, for this post, let's focus optimistically on what subset can work rather than which cases can't work. I agree there are many cases where borrow, Rc, type system, versioning. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |