Open hasheddan opened 3 years ago
We should probably ensure that we split our libraries into intended "real" language frontends too. Even if tepl
only works with a (mostly) english frontend, splitting be "real" language would mostly likely be a minor library pathing change.
For example: rather than creating the translation library with hardcoded english, we should have an en
library.
# without the suggested change
./src/lib/tepl_lang/translation
# with the suggested change
./src/lib/tepl_lang/translation/en
@nickgerace do you think "real" language is going to make much of a difference here? Our productions are just going to be made up of ASCII characters I believe. Can you expound on the need for translation?
@hasheddan It depends on user input. If this will look like other EBNF grammar where single ASCII characters (or a short string of them), then we would not need the split by "real" frontend languages. However, if the tepl language looks more like real words or phrases (at conflict with brevity), then we may want to leave the option for another "real" language frontend for the future. Here's an example...
Print my name! --> print($TWITTER_USERNAME) --> println!(twitter_api_client.get_username());
@nickgerace gotcha :+1: I am definitely thinking we would look like a more traditional language with a small set of english keywords (e.g. var
, const
, etc.) and naming of variables can be any sequence of ASCII characters. However, it could be interesting to have a set of keywords that are relevant to other languages.
The tepl language should have a formal specification, with syntax defined in Extended Backus-Naur Form (EBNF). Goals of the language include: