Conlang/Advanced/Grammar/Government/Applying knowledge

Applying this Knowledge to the Conlanging Process

So far we’ve explored the beginnings of a syntax as a set of formal theories, but this tutorial is meant to be an aid in constructing a language. To see how we can use this knowledge, I’m going to approach the process of constructing a language from two perspectives. The first is construction from scratch, without any preconceptions or ideas about what the grammar of the language should look like. Then I’ll look at how to take some vague ideas and how to expand them into a full language that you can expect such systems to appear in, and in the process I’ll look at how the same tools can be used to formalize an existing language.

Designing a Syntax from Scratch

Design a syntax from scratch is theoretically a simple process. Without any preconceptions about what certain features should look like, we can follow an orderly approach to the process. Indeed, the process is so formulaic that it might even be useful to just write out a list of things to define for the language.

1: Head-initial or head-final

2: Heads and Phrases (i.e. does the language have Ns? NPs? Vs? VPs? etc.)

3: Phrases that are exceptions to (1) or have exceptional alternative forms

4: PS rules

Some things to keep in mind, especially in (2) and (4) is that the structures don’t have to be identical to English. Modern theories tend to attempt to describe every language with the same basic formulation, the more in common the better, but that doesn’t mean your language has to. If you want to put the subject into the VP and move the object out of the VP, sure go ahead and do so. But keep in mind that making exceedingly different rules means that your constituency tests should have equivalent forms. If you do indeed move subjects into VP and objects out, you’ll need to have a situation where you can replace the VP with a stand in, something similar to “do so”, and have it mean the same thing. It’s important to keep in mind why we say languages have the rules we’ve found for them, or developed, as the case may be.

Formalizing Ideas and Making Generalizations

Finding a syntax for preexisting ideas is a bit more complicated than designing one from scratch. Because we already have some “canonical” forms, we have to perform tests on them to discover how they behave. We can perhaps make a list of things to do here to identify the features of the language.

1: Constituency tests to decide what composes the structure and how

2: PS rules to describe the structure

3: Is the structure’s head positioning typical or exceptional?

4a: Generalization of 1-3 as guides for the steps to design a syntax from scratch

4b: Create more ideas and analyze them

Having multiple ideas would make (3) easier to decide. For example, if we have three ideas that end up having the same head positioning, we might want to say that our language should have that positioning as the typical position. Alternatively, if the ideas have different head positioning we can choose whichever we prefer more and make that typical, while making the other one exceptional.

The rules listed above can apply just as well to a description process as well, treating the entire language as one giant idea to be analyzed. Input from less formal grammars can speed up the process of creating a formal grammar.