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!)
- 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>
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>
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
