hasheddan / tepl

Tweet Eval Print Loop
1 stars 1 forks source link

Define language syntax in EBNF #2

Open hasheddan opened 3 years ago

hasheddan commented 3 years ago

The tepl language should have a formal specification, with syntax defined in Extended Backus-Naur Form (EBNF). Goals of the language include:

  1. Brevity: users only have 280 chars
  2. Simple: users are not going to want to invest a lot of time to learn
  3. Composable: given the constraints of the programming interface (and presumably the desire not to tweet tepl programs constantly) it should be easy to compose and reuse code
nickgerace commented 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
hasheddan commented 3 years ago

@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?

nickgerace commented 3 years ago

@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());
hasheddan commented 3 years ago

@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.