[YG Conlang Archives] > [engelang group] > messages [Date Index] [Thread Index] >


[Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What meta language development environment is everyone using?



--- In engelang@yahoogroups.com, And Rosta <and.rosta@...> wrote:
>
> MatthewDeanMartin, On 15/04/2011 21:27:
> > Besides notepad and pencil&  paper?
> 
> In my case, none. But I can't even think of what I would wish for, other than notepad.

If you're using notepad, then what is your compiler? If you say your brain, then I guess you're trying to say the meta language is English, and at best can be tidied up in LaTex or the like, to then be used primarily by meatware-- 2nd language acquisition, or as a mother tongue.  All this makes the "engine" in "engineered languages" sound like it's misplaced?

> You mention parsers, but parsers written for natlangs don't truly parse, and even if you were to create something that could genuinely be parsed by a parser, you then be designing something constrained by the need to work with the parser.

I'm not smart enough to understand what you mean when you say parsers don't really parse. 

And Lojban isn't constrained by the state of the art when it's formal syntax was written down? The formal syntax that is somewhere on the lojban site is the same one used to write computer programming languages.  I'm going to make a modest prediction that BNF style grammars will look as quaint and restrictive in a long time as COBOL looks today. But conlang grammars need to be written today and we have to use the tools available, unless we have the time & resources to personally write parsers or invent brand new metalanguages-- but those new metalanguages will probably be definable in BNF or the like as well, so were back to tools for coping with BNF & the like.

> So what would you wish for?

At the very least, validity checks are good. I've worked with one of these "natural language parsers" that "don't really parse" to demonstrate that a given toki pona sentence is valid relative to the BNF grammar (which imho, doesn't really cover all the ways people use the language, but the BNF valid statements do appear to be a proper subset of what a human would deem valid toki pona.)  I don't know or care if these natural language parsers parse natural language. I can't create a natural language anyhow.

IDE's for BNF syntax do exist, such as ANTLR is still outside of my ability to grok it. It would be useful to be able to validate the BNF rules itself, for example to detect data structures that aren't atomic, but defined by by anything else either (i.e. say a rule about prepositional phrases without having defined propositions first, as a contrived example of a defect in a possible BNF grammar itself)

It's too much to ask for without custom programming, but it would be nice if there was a tool that would generate random sentences for a given syntax. I've written one for toki pona, and at the end sort of wished there was a more general tool.  There is a word generator that uses a custom domain specific language to generate random words that fit a given phonotactics, I would be nice if there existed something from the computer programming compiler world that could be subverted to do the same thing for sentences.

A means to translate BNF constrained sentences into queryable data structures would be nice, although I'm not sure what use it would be. Again, using toki pona as example, the noun phrase syntax is somewhat like XML in some ways.  I haven't gotten as far as finishing writing a custom toki pona specific parser, but if I did finish it, it would be fairly easy to query a corpus for things like "jan seme li mije li moli?" and get matches on "jan Ko li mije. jan Ko li moli." and other equivallent variations, such as "jan Ko li moli li mije"   Tools for writing custom query languages though seem rather science fictiony, although some of the database technologies I work with look like they are moving in that direction (e.g. custom Linq providers-- an relatively new technology from Microsoft)

Matthew Martin