anselme/notes.txt

# Symbol selection

Anselme favor symbols over keywords, as it make translation easier.

We prefer to use symbols available on a standard US keyboard as it often is the lowest common denominator.

As we want to be able to write identifiers with little restriction, we try to only use symbols which are unlikely to appear naturally in a name.

Considering Anselme is aimed to people with a light programming introduction, are safe to use for syntax purposes:

* Diacritics (should be safe when used on their own): ~`^
* Usual mathematical symbols (should be safe to use): +-=<>/
* Unusual punctuation / main use is already programming (should be safe to use): []*{}|\_
* Usual punctuation used to separate parts of a sentence (should be safe to use): !?.,;:()
* Signs (could be used in a name, but also common programming symbols): @&$#%
* Usual punctuation (could be used in a name): '"

In the end, we decided to reserve all of those except '.

Using other unicode symbols may be also alright, but there also should be a way to only use these symbols.

Reserved symbols that are still not used in expressions: `\_?@$

Reserved symbols that are still not used as a line type: `^+-=</[]*{}|\_!?.,;)"&%$

# Code Q&A

* What does "fqm" means?
	It means "fully qualified matriname", which is the same as a fully qualified name, but considers the hierarchy to be mostly mother-daugher based.
	It has nothing to do with the fact I'm inept at writing acronyms and realized I wrote it wrong after using it for a whole year.
* Why are built-in anselme scripts stored in Lua files?
	I believe it was to avoid reimplementing the require() file search algorithm myself.
* What's a "variant"?
	One of the different forms of a same function with a given fqm. No idea why I chose "variant".
* Why emojis?
	They're kinda language independent I guess. I have no idea.
* Why?
	I still have no idea.

# Other

Broad goals and ideas that may never be implemented. Mostly used as personal post-it notes.

TODO: support parametric types in contraints: list(number)
     should then also allow polymorphic constraint like
     $ fn(l::list('a), x::'a)
          (push a constraint context when checking compatibility)
     or more generic constraints? allow custom functions to check constraints, etc (performance?)

TODO: type system is not super nice to use.
     UPDATE: tried to implement a static type system, ain't worth it. Would require major refactoring to go full static with good type inference. The language is supposed to allow to not have to worry about low level stuff, so no deal if the type inference isn't good. Thank you multiple dispatch for making everything complicated (i still love you though)... Well, if I ever reimplement Anselme, let's thank the Julia devs for doing the hard work: https://docs.julialang.org/en/v1/devdocs/inference/

TODO: some sensible way to capture text event in string litterals (string interpolation/subtexts)? -> meh, this means we can capture choice events, and choice events contain their code block, and we don't want to store code blocks in the save file (as code can be updated/translated/whatever)
     ignoring choice events, we might be able to use subtexts in string litterals; using the same code for text lines and text litterals? we would lose tags...
     -> no. would break ability to switch between two translations of the script as the save would contain the text events from the previous language.

TODO: simplify language, it is much too complicated. Less line types? (var def, func, checkpoint, tag). Rewrite some ad hoc syntax using the expression system?

TODO: fn/checkpoint/tag: maybe consider them a regular func call that takes children as arg; can keep compatibility using $/§ as shortcut for the actual call.
     would allow more flexibility esp. for tags...
     a func def would be:

     :a = $
     	stuff

     but then args?

     :a = $(args)
     	stuff

     how are children passed on? overloading? -> means a code block would be passed as a value, how to avoid it ending up in the save file?

     if not possible, at least make checkpoint or fn defined using the other or some superset... -> checkpoints defined using fn

     OK for tag though: pushtag/poptag fn:

     # color:red
     	a

     translate to something like

     ~ tag.push(color:red)
     a
     ~ tag.pop()

TODO: make language simple enough to be able to reimplement it in, say, nim. Especially the AST interpreter (we could precompile a lot of stuff...)

TODO: test reacheability of script paths + visualization of different branches the script can take. For one of those overarching story visualization thingy.

TODO: redisign the checkpoint system to work better when used with parallel scripts (if both change the same variable, will be overwritten); not sure how to do that, would need some complicated conflict resolution code or something like CRDT...

TODO: redisign a static type checking system
If we want to go full gradual typing, it would help to:
* add type anotation+type check to functions return ($ f()::number) -> there's a lot of function calls, so probably checked at compiling only
* enforce some restrictions on type (assume they're constant/sublanguage, not full expressions)
* make some tuple/list distinction (homogenous/heterogenous types) as right now index operations are a type roulette. Or type annotate lists using some parametric type.
Advantages:
* can be used for better static variant selection; if everything is type annotated, selection could be restricted to a single function
Disadvantages:
* idk if it's worth the trouble
* could do something like `$ ()(l::list(?), i::number)::?`, but then can't return nil on not found...

TODO: write a translation guide/simplify translation process

TODO: make injection nicer. Some decorator-like syntax? to select specific functions to inject to

TODO: allow multiple aliases for a single identifier?

TODO: closures. Especially for when returning a subfunction from a scoped variable.