Commit 4b4bd197 authored by Nicolas Lenz's avatar Nicolas Lenz

Clean up ideas

parent 6315a332
......@@ -2,14 +2,45 @@
Please be aware that at this point this document is just a collection of quite random notes and ideas.
TODO: Clean this up
## The Zen of Katrin
## Features
Inspired by the Zen of Python principles, these are the general paradigms the language should be designed to.
### Functional
- Nudges (By default, allow only the good stuff, but make anything possible)
- Modularity (very small language core for a lean compiler and good forward compatibility, learn from Python 2/3)
- Dry (Don't repeat yourself)
- Fancy, but not too fancy (Don't do stuff just because it looks cool, e.g. Unicode syntax)
- Question everything
- Explicit is better than implicit
- In general: Practical usability first, theoretical precision second
## Syntax
### Identifiers
- No pretty Unicode identifiers, [for similar reasons as in Idris.](http://docs.idris-lang.org/en/latest/faq/faq.html#will-there-be-support-for-unicode-characters-for-operators) It might look pretty but that's a small gain for the large price of possibly unwritable and unreadable functions flying around.
- Normal identifiers: `[a-z][A-Za-z0-9_]*` (string literals are of course Unicode)
- Constructor identifiers: `[A-Z][A-Za-z0-9_]*`
- Operator identifiers: `[!#$%&*+-/<>?@^|~]`
### Misc
- Infix syntax?
- Allow flexible function syntax like in Agda?
- Idris has a syntax statement for that, maybe that's better. Deviating syntax should be disicentivized to keep stuff consistent
- Something like `x <elementOf> list` is clearly more expressive than `x elementOf list` where you can't know wether x or elementOf is the actual function. And I can't think of many situations where non-explicit non-standard function application syntax would be a good idea
- That also poses a lot of problems for the parser
- if-then-else might be an exception
- How to handle that? Syntax statement sounds good. Still difficult for the parser
- Or simply disallow it and do something like `if (a == 0) (print "0") (print "Not 0") but that might be less readable
- Disincentivize special characters only operators. Better `<map>` than `<$>` or `<parseKey>` than `.:!`
- Far easier to comprehend.
- Basic stuff like `<$>` might still be okay, but then again, `<map>` really isn't that much longer (and maybe even easier to type).
- Prefer meaningful names in general (looking at you, Haskell!)
- do-notation?
## Type System
- ~~Mainly lazy or~~ mainly strict? (→ Haskell/Idris)
- Probably mainly strict with explicit laziness possible (like in Idris) because of performance and algebraic typing
- Algebraic types
- [Dependently typed](https://en.wikipedia.org/wiki/Dependent_type)
- How far can we go? Pattern matching types → powerful but drawbacks with *free theorems*
......@@ -18,8 +49,29 @@ TODO: Clean this up
- Types are (context free? decision problem in polynomial time? should only be a compile-time problem) languages over the Universe where the Universe is the Kleene closure of the set of literals
- ~~μ-Calculus as theoretical foundation?~~ Well, that was a bad idea. Probably.
- Constructors unique or not?
- Typeclasses are called »traits« (→ Rust)
- Named trait instances (→ Idris)
- Are traits/type classes even a good idea? (TODO find article)
- In general, probably yes.
- Records in Haskell are deeply flawed. Fix that, they're really importent in practice! Bring in the dot operator (as some people also did for Haskell).
- Don't concentrate on actual types and data, but rather on "capabilities"? <http://degoes.net/articles/kill-data>
## Evaluation
- ~~Mainly lazy or~~ mainly strict? (→ Haskell/Idris)
- Probably mainly strict with explicit laziness possible (like in Idris) because of performance and algebraic typing
- Totality enforced by default (no `fromJust`, `error` etc.)?
- Do the pros outweigh the cons here?
- Not decidable in general, so it's a burden on the user if the totality checking fails
- Should be optional of course
### Interaction-oriented
## Proofs
- Possible, but no priority – it isn't meant to be a proving tool
- [Curry-Howard-Isomorphism](https://de.wikipedia.org/wiki/Curry-Howard-Isomorphismus)
- How to handle trait/typeclass laws
## Interaction
Interaction (with users, windows, servers, ...) is a very important thing in programming. Unfortunately, it is quite awkward (especially for beginners) in many functional languages. Find better solutions working without loads of monad transformers.
......@@ -33,9 +85,8 @@ Good GUI solutions are important. Haskell still has no reasonable GUI solutions,
- Monad typeclasses instead of transformers (`MonadIO`, `PandocMonad`…)
- `katrin shell` usable as full command shell (replacing bash etc.) (→ innaytool)
- Things like piping etc. possible with type-safety
- How to most elegantly integrate non-Katrin programs?
### Data handling
## Data Handling
In the real-world, working with external data in file systems and databases is one of the most important tasks for programs. It should be easy.
......@@ -44,42 +95,6 @@ In the real-world, working with external data in file systems and databases is o
- ~~*Languages* (regular, context-free) at the language heart~~
- *Probably* nonsense
### Interfacing
What to do with typeclasses? Are they good, are they bad?
Don't concentrate on actual types and data, but rather on "capabilities"? <http://degoes.net/articles/kill-data>
### Proofing
- Possible, but no priority
- [Curry-Howard-Isomorphism](https://de.wikipedia.org/wiki/Curry-Howard-Isomorphismus)
### Miscellaneous
- Typeclasses are called »traits« (→ Rust)
- Named trait instances (→ Idris)
- Infix/Prefix/Custom argument placement (→ Agda)
- Probably a bad idea
- Totality enforced by default (no `fromJust`, `error` etc.)
- Do the pros outweigh the cons here?
-
## Influenced by
- Haskell
- Idris
- Agda
- [Cayenne](http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.155) (first dependent language)
- Python: Indentation syntax
- Go
- Rust: Trait naming
- Erlang
Languages to look into: Lisp (homoiconicity?), (S)ML, Clojure, F#, Scala, Nix, Nim, Elm
## Meta-Usability
### Tooling
......@@ -104,41 +119,40 @@ YAML files are used for configuration as they're especially human-friendly.
Debugging needs to be easy and comprehensive.
## The Zen of Katrin
- Tracing option that outputs what functions were called with what values in what order, without changing the code
- Debugger with breakpoints?
Inspired by the Zen of Python principles.
## Misc Features
- Nudges (By default, allow only the good stuff, but make anything possible)
- Modularity (Very small language core for a lean compiler and good forward compatibility)
- Dry (Don't repeat yourself)
- Fancy, but not too fancy (Don't do stuff just because it looks cool, e.g. Unicode syntax)
- Question everything
## Stuff
- Unicode syntax or not? (→ [here](http://docs.idris-lang.org/en/latest/faq/faq.html#will-there-be-support-for-unicode-characters-for-operators))
- Probably not :sad:
- Only allow a certain set of characters in the code, but Strings are of course Unicode-compatible (it's the 21st century after all)
- Might look pretty, but that's a small gain for the large price of possibly unwritable and unreadable functions flying around
- Can be overridden
- do-notation?
- Are traits/type classes even a good idea? (TODO find article)
- In general, probably yes.
- Infix syntax?
- Allow flexible function syntax like in Agda?
- Idris has a syntax statement for that, maybe that's better. Deviating syntax should be disicentivized to keep stuff consistent
- Something like `x <elementOf> list` is clearly more expressive than `x elementOf list` where you can't know wether x or elementOf is the actual function. And I can't think of many situations where non-explicit non-standard function application syntax would be a good idea
- That also poses a lot of problems for the parser
- if-then-else might be an exception
- How to handle that? Syntax statement sounds good. Still difficult for the parser
- Or simply disallow it and do something like `if (a == 0) (print "0") (print "Not 0") but that might be less readable
- Disincentivize special characters only operators. Better `<map>` than `<$>` or `<parseKey>` than `.:!`
- Far easier to comprehend.
- Basic stuff like `<$>` might still be okay, but then again, `<map>` really isn't that much longer (and maybe even easier to type).
- Prefer meaningful names in general (looking at you, Haskell!).
- Records in Haskell are deeply flawed. Fix that, they're really importent in practice! Bring in the dot operator (as some people also did for Haskell).
- One of the pros of OO-programming is that you can set a paramater for a whole class and then all functions of the class can use that. Without that functions calls sometimes get awkward when you have to pass the same parameters (config, server URL) over and over again. There are ways to alleviate that, maybe find something elegant to integrate into the language?
- Something like singletons? Constants that can be set on module load? Something like that
- Stay functional and type-safe of course
- Maybe dependent types can be useful for this?
- Closures?
## Other Interesting Languages
- Haskell
- Idris
- Agda
- [Cayenne](http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.155) (first dependent language)
- [Luna](https://www.luna-lang.org/)
- Very interesting graphical representation and design stuff
- Erlang
- Actors
- Python
- Indentation syntax
- Some parts of the Zen
- Go
- Rust
- Trait naming
- (Common) Lisp
- Homoiconicity?
- (Standard) ML
- Clojure
- F#
- Scala
- Nix (not a programming languae per se)
- Nim
- Elm
- PureScript
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment