mirror of
https://github.com/Reuh/anselme.git
synced 2025-10-27 16:49:31 +00:00
102 lines
4.4 KiB
Markdown
102 lines
4.4 KiB
Markdown
Various ideas and things that may or may not be done. It's like GitHub issues, but I don't have to leave my text editor or connect to the scary Internet.
|
|
|
|
Loosely ordered by willingness to implement.
|
|
|
|
# To do or discard before stable release
|
|
|
|
Documentation:
|
|
* language reference
|
|
* tutorial
|
|
|
|
---
|
|
|
|
Translation.
|
|
|
|
Do some more fancy scope work to allow the translation to access variables defined in the translation file?
|
|
|
|
---
|
|
|
|
Standard library.
|
|
|
|
* Text and string manipulation would make sense, but that would require a full UTF-8/Unicode support library like https://github.com/starwing/luautf8.
|
|
- retag/add tags
|
|
* And in general, clean up everything.
|
|
|
|
---
|
|
|
|
Default arguments and initial variables values should pass the value check associated with the variable / parameter.
|
|
Issue: dispatch is decided before evaluating default values.
|
|
|
|
# Can be done later
|
|
|
|
Server API.
|
|
|
|
To be able to use Anselme in another language, it would be nice to be able to access it over some form of IPC.
|
|
|
|
No need to bother with networking I think. Just do some stdin/stdout handling, maybe use something like JSON-RPC: https://www.jsonrpc.org/specification (reminder: will need to add some metadata to specify content length, not aware of any streaming json lib in pure Lua - here's a rxi seal of quality library btw: https://github.com/rxi/json.lua). Or just make our own protocol around JSON.
|
|
Issue: how to represent Anselme values? they will probably contain cycles, needs to access their methods, etc.
|
|
Probably wise to look into how other do it. LSP: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/
|
|
|
|
---
|
|
|
|
Return system.
|
|
|
|
Could be reused for exception handling or other purposes if accessible by the user.
|
|
|
|
---
|
|
|
|
Reduce the number of AST node types ; try to merge similar node and make simpler individuals nodes if possible by composing them.
|
|
Won't help with performance but make me feel better, and easier to extend. Anselme should be more minimal is possible.
|
|
|
|
---
|
|
|
|
Static analysis tools.
|
|
|
|
To draw a graph of branches, keep track of used variables and prune the unused ones from the Environments, pre-filter Overloads, etc.
|
|
|
|
---
|
|
|
|
Multiline expressions.
|
|
|
|
* add the ability to escape newlines
|
|
Issue: need a way to correctly track line numbers, the current parser assumes one expression = one source
|
|
* allow some expressions to run over several lines (the ones that expect a closing token, like paren/list/structs)
|
|
Issue: the line and expression parsing is completely separate
|
|
|
|
---
|
|
|
|
Performance:
|
|
|
|
* the most terribly great choice is the overload with parameter filtering.
|
|
Assuming the filter functions are pure seems reasonable, so caching could be done.
|
|
Could also hardcode some shortcut paths for the simple type equality check case.
|
|
Or track function/expression purity and cache/precompute the results. Not sure how to do that with multiple dispatch though.
|
|
(note for future reference: once a function is first evaluated into a closure, its parameters are fixed, including the value check callable)
|
|
* the recursive AST interpreter is also pretty meh, could do a bytecode VM.
|
|
This one seems like a lot more work.
|
|
Could also compile to Lua and let LuaJIT deal with it. Or WASM, that sounds trendy.
|
|
|
|
Then again, performance has never been a goal of Anselme.
|
|
|
|
---
|
|
|
|
Redesign the Node hierarchy to avoid cycles.
|
|
|
|
---
|
|
|
|
Macros.
|
|
|
|
Could be implemented by creating functions to build AST nodes from Anselme that can also take quotes as arguments.
|
|
That should be easy, but I don't remember why I wanted macros in the first place, so until I want them again, shrug.
|
|
|
|
---
|
|
|
|
High concept ideas / stuff that sounds cool but maybe not worth it.
|
|
|
|
* Instead of using a bunch of sigils as operators, accept fancy unicode caracters.
|
|
Easy to parse, but harder to write.
|
|
Could implement a formatter/linter/whatever this is called these days and have Anselme recompile the AST into a nice, properly Unicodified output.
|
|
Issue: the parser may be performing some transformations on the AST that would make the output an uncanny valley copy of the original. Also we need to preserve comments.
|
|
* Files are so 2000; instead put everything in a big single file and use a custom editor to edit it.
|
|
Imagine selecting an identifier, and then it zooms in and show the AST associated to it. Nested indefinitely. Feels very futuristic, so probably worth it.
|
|
* Frankly the event buffer system still feel pretty janky, but I don't have any better idea for now.
|