Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chat #1

Open
qfunq opened this issue Oct 18, 2021 · 0 comments
Open

Chat #1

qfunq opened this issue Oct 18, 2021 · 0 comments

Comments

@qfunq
Copy link
Owner

qfunq commented Oct 18, 2021

Welcome to IO-Monad chat.

Feel free to discuss ideas, techniques, compiler technology, or just to say hi!

Compiler tech is my first issue, yes, the code can be more efficiently implemented in terms of trampolines, but its much more
work, and the compiler should be smart enough to know when code is in the CMC, and it can apply optimsations, since intermediary results are inaccessible. The CCC assumes every state is cloneable, which introduces copying. Obviously both cases involve code transformations to a trampoline, for O(1) stack growth. Without it, the beautiful simplicity of the IO monad is purely aesthetic, in all but non-recursive environments (the easy route for compiler writers).

To obtain ultimate performance requires a jump instruction, so none of C,C++ or wasm make ideal targets for this type of code. A good old fashioned jump is needed. However, trampolines can be used in all of these languages, and my own research shows extremely good performance from C++, treated as a high level assembler for a higher level abstraction of it, capable of performing the required transformations.

If it's possible for a single programmer to do this, how come there are essentially no languages out there that do it? The only reason I can think of is that most programming languages provide apis for various components, strings, IO, objects, interfaces, Promises, exceptions. Haskell is an exception to this, but it doesn't really seem practical to code in. For a functional language, it doesn't look very much like the lambda calculus! But its founding functors are very cleverly constructed. The do notation doesn't read naturally, and it is strangely dependent on a pre processor less powerful than itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant