Open matthewdeanmartin opened 6 years ago
I'm planning an RTN parser, probably implemented in Scheme. I think I'd strat off with 'plain' toki pona and then add the changes we talked about.
Oh, will I understand all this? ;-) Let us start with some basic considerations.
Should the language be oriented more towards Toki Pona (no flexions) or Esperanto? I'm for Toki Pona.
Which sentence types should be supported? declarative sentences interrogative sentences (questions) imperative sentences (command) exclamatory sentences (interjections, greetings) headlines
Sentence Syntax Fixed constituent order SVO, simple sentences only. sentence(subject_phrase(subject),predicate_phrase(predicate(verb),[objects]))
How do we identify the different types of words? With the position in the sentence? With separators? Using the word ending (like Esperanto)? Should certain words only be used for prepositions?
How many letters should be used for word formation? I am in favour of the same principle as Toki Pona.
Please write your opinion.
I think it should be very close to toki pona. It's exactly the simplicity that I find attractive, pushing the boundaries of what you can do if you discard parts of grammar and vocab.
Happy to ditch morphology completely, and have a strict word order only (so word class through position in the sentence). Separators between constituents would make analysis/parsing easier. Overall we should retain the 'feel' of toki pona.
I'm going to side step jan Lope's question (or answer it with "sure")
I might just be saying that because I find the tooling more interesting than the syntax.
Imho, if we could get the effort cost of generating a toki-pona-like (in goals and size) language, say by creating tools to work with small vocabs, small grammars, then people could create many toki pona like languages. I've lost count how many toki pona variants have been proposed, over 50, I think. They're all good, but just evaluating them, without tooling would take a lifetime.
For example- a tool to generate cvcv words. Since it is a toki pona style language, this tool wouldn't need IPA or a college course in phonetics.
For example - if we had a grammar file for a small toki pona like language, it would be nice to have a random text generator. Random text can show the language designer flaws in the grammar without waiting to get 100 speakers and waiting 10 years well past the point where you can't convince anyone to change
For example - a machine glosser. No one wants to spend 7000 hours learning a natlang-like language, they just want to read a gloss that shows off the internal structure of the sentence without spending an hour flipping through dictionaries and grammar texts.
I would suggest the pattern of "let folk propose a working implementation" and if it works, write a spec for it. Easier than designing a language by committee and then waiting for someone to implement it.
If the parser uses a dictionary, then people who don't like the sound of it can effortlessly relex it.
Also, I'd suggested permitting two parses- a mono-parse (which people do a poor job of doing, but can be used to write code), and a multi-parse (which people excel at, but computers lack a sense of semantics for choosing the intended parse). For the 2nd case, BNF isn't going to work, we'd need some other strategy.