Final commit before submission
This commit is contained in:
31
notes/papers/report/parts/literature/effects.md
Normal file
31
notes/papers/report/parts/literature/effects.md
Normal file
@@ -0,0 +1,31 @@
|
||||
https://www.unison-lang.org/learn/fundamentals/abilities/
|
||||
|
||||
An excellent description of algebraic effects that lead me to understand how they work and why they present an alternative to monads.
|
||||
|
||||
Algebraic effects essentially associate a set of special types representing families of requests to a function that it may return other than its own return type. Effects usually carry a thunk or function to enable resuming normal processing, and handlers usually respond to the requests represented by the effects by implementing them on top of other effects such as IO. The interesting part to me is that all of this is mainly just convention, so algebraic effects provide type system support for expressing arbitrary requests using CPS.
|
||||
|
||||
Although Orchid doesn't have a type system, CPS is a straightforward way to express side effects
|
||||
|
||||
---
|
||||
|
||||
https://github.com/zesterer/tao
|
||||
|
||||
The first place where I encountered algebraic effects, otherwise a very interesting language that I definitely hope to adopt features from in the future
|
||||
|
||||
Tao is made by the same person who created Chumsky, the parser combinator used in Orchid. It demonstrates a lot of intersting concepts, its pattern matching is one of a kind. The language is focused mostly on static verification and efficiency neither of which are particularly strong points of Orchid, but some of its auxiliary features are interesting to an untyped, interpreted language too. One of these is generic effects.
|
||||
|
||||
---
|
||||
|
||||
https://wiki.haskell.org/All_About_Monads#A_Catalog_of_Standard_Monads
|
||||
|
||||
Originally, I intended to have dedicated objects for all action types, and transformations similar to Haskell's monad functions.
|
||||
|
||||
A monad is a container that can store any type and supports three key operations:
|
||||
|
||||
1. Constructing a new instance of the container around a value
|
||||
2. Flattening an instance of the container that contains another instance of it into a single container of the inner nested value
|
||||
3. applying a transformation to the value inside the container that produces a different type
|
||||
|
||||
The defining characteristic of monads is that whether and when the transformations are applied is flexible since information can't easily leave the monad.
|
||||
|
||||
This system is extremely similar to effects, and at least in an untyped context they're essentially equally powerful. I opted for effects because their defaults seem more sensible.
|
||||
34
notes/papers/report/parts/literature/macros.md
Normal file
34
notes/papers/report/parts/literature/macros.md
Normal file
@@ -0,0 +1,34 @@
|
||||
https://doc.rust-lang.org/reference/macros-by-example.html
|
||||
|
||||
Rust's macro system was both an invaluable tool and an example while defining Orchid's macros.
|
||||
|
||||
Rust supports declarative macros in what they call "macros by example". These use a state machine-like simplistic parser model to match tokens within the strictly bounded parameter tree. Most notably, Rust's declarative macros don't support any kind of backtracking. They are computationally equivalent to a finite state machine.
|
||||
|
||||
---
|
||||
|
||||
https://wiki.haskell.org/Template_Haskell
|
||||
|
||||
Template haskell is haskell's macro system that I learned about a little bit too late.
|
||||
|
||||
Throughout this project I was under the impression that Haskell didn't support macros at all, as I didn't discover template haskell until very recently. It is a fairly powerful system, although like Rust's macros their range is bounded, so they can hardly be used to define entirely new syntax. There also seem to be a lot of technical limitations due to this feature not being a priority to GHC.
|
||||
|
||||
---
|
||||
|
||||
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0707r4.pdf
|
||||
https://www.youtube.com/watch?v=4AfRAVcThyA
|
||||
|
||||
This paper and the corresponding CppCon talk motivated me to research more natural, integrated forms of metaprogramming.
|
||||
|
||||
The paper describes a way to define default behaviour for user-defined groups of types extending the analogy of enums, structs and classes using a compile-time evaluated function that processes a parameter describing the contents of a declaration. It is the first metaprogramming system I encountered that intended to write meta-programs entirely inline, using the same tools the value-level program uses.
|
||||
|
||||
This eventually lead to the concept of macros over fully namespaced tokens.
|
||||
|
||||
---
|
||||
|
||||
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2392r0.pdf
|
||||
https://www.youtube.com/watch?v=raB_289NxBk
|
||||
|
||||
This paper and the corresponding CppCon talk demonstrate a very intersting syntax extension to C++.
|
||||
|
||||
C++ is historically an object-oriented or procedural language, however in recent standards a significant movement towards declarative, functional patterns manifested. This paper in particular proposes a very deep change to the syntax of the language, an entirely new class of statements that simultaneously bind an arbitrary number of names and return a boolean, that may result in objects being constructed, partially moved and destroyed. The syntax extensions appear very fundamental and yet quite convenient, but what little C++ has in terms of local reasoning suffers. This was interesting and inspirational to me because it demonstrated that considerate syntax extensions can entirely redefine a language, while also reminding about C++'s heritage.
|
||||
|
||||
Reference in New Issue
Block a user