Theiling Online    Sitemap    Conlang Mailing List HQ   

isolation vs inflection & other features

From:ebera <ebera@...>
Date:Thursday, April 25, 2002, 8:27
Kisses to petlang owners!

The young me asked : is an isolating language better than an inflected
one?

The present-days me answers :

Not at all. The two are one. Syntax is always marked.
In an inflected language, cases are marked by an affix.
In an isolating language, cases are marked by a preposition.

Example :
'a girl in bikini on the beach'
       - girl, nominative marked by position
       - bikini, genitive case marked by 'in'
       - beach, locative case marked by 'on'
Inflected :
'girl bikiniin beachon'

Chinese is said to be purely structured on word order, but this is
false. Chinese uses postpositions. What makes it look strange for
Occidentals is that the genitive case is always left unmarked, as a
side-effect to the prohibition of compounds ('book man' doesn't mean
'librarian' but 'the book related to the man'). Anyway, compounding is
an implementation of genitive. We could say 'a bikini girl on the
beach' or like Chinese 'girl bikini beach shang' shang being a locative
marker.

In the soft version of compounding, which should be named 'unmarked
genitive', there are two nouns with two definitions linked by syntax;
whereas in the hard version, which is 'compounding', there is one
two-word noun with only one definition. English uses the latter, so
'a bikini girl' must be predefined to be understood. Unmarked genitive
belongs to syntax and compounding belongs to semantics, since it's a
form of agglutination (keep reading).

As I know, case-marking applies to all human languages, at least on
Earth. The only exception is lojban, in which cases are given by the
semantics of each verb in the likes of computer languages. This is why
lojban still have to prove to be humanly speakable.

Probably a lot of people never realised that their own language works
this way. I did not, until recently.

There is no structural difference between the two models. There is also
no difference in the expressive power nor in ease of learning.

For the ease : what would make the learning of 10 affixes harder than
the learning of 10 prepositions?

For the expressivity : natlangs I know use not 10 but rather a hundred
prepositions. This, of course, is hard to learn. And does it increase
precision? I don't think so. Possible meaning is given by the context,
usually the verb. See the examples with 'at' as the only locative mark,

'the kid is at the table' - near the table
'the kid is dancing at the table' - on the table
'the kid is hidden at the table' - under the table
'the kid is walking at the table' - toward the table

As you see, many (most?) prepositions of natlangs are unnecessary. In
a conlang, you don't need to implement more prepositions for an
isolating language than you would implement affixes for an inflected
one. The rule is the following : what is easy to learn and use is a
clean design and what is hard to learn and use is a messy design.

There are two choices : the case-marker stands *before* the noun, or it
stands *after* the noun. My theory is that in the first case, the
marker is naturally written in an isolating fashion to make the noun
itself easier to recognise, whereas when the marker comes after the
noun, recognisability is no more endangered, so it is naturally written
glued to the noun.

Stop and explain me if I'm wrong, but I don't think prefixed cases and
postpositions are very common, although the latter makes sense,
especially with a different writing system (I'm pretty sure Chinese
would be written in an inflected fashion if it used the roman alphabet).
A pseudo-alternative is the german model that transfers the inflection
to the article, but this is a prepositional system, isn't it?

So one might think inflection is harder than isolation, or more
'natural' but this is only a personal preference. Probably it depends
on how much you're addicted to your native language.

A conlang should implement a pure system. Mixing is messy. Case markers
can't be sometimes before the noun and sometimes after. Bad idea.
Anyway, the model to follow will probably be imposed to you by the rest
of the structure you built.

ni'o. I have seen many uses of the word 'agglutinative' as a synonymous
for 'inflected', with the slight difference that agglutination is
regular whereas inflection is messy. Since it's not how I understand
agglutination, I propose we define them.

In syntax :
- inflection (case marker written glued to the noun)
- isolation (case marker written isolated from the noun)
- both can use word order for simplifications.

In semantics :
- agglutination permits semantic declension by adding an affix.
e.g. patro - father, patrino - mother.
- insertion is a form of agglutination, with morphemes inserted inside
the root word. Arab and probably Hebrew are insertive.
- compounding is a form of agglutination, with morphemes being written
as stand-alone words. Can easily become unregular (but powerful).
- the opposed model is one word per concept. This permits the most used
words to be the shortest. Proposed name : empirical.

A pure empirical structure implements unmarked genitive instead of
compounding.

So there are six kind of languages :
*A empirical isolated
*B empirical inflected
*C agglutinative isolated
*D agglutinative inflected
*E exotic
*F messy
Game : which conlang is the most representative of each category?
Do we need conlangs because all natlangs are *F?

End.

Am I right? Is it what you had in mind?
Is there a more recognized name than 'empirical'?

Why should my conlang implement adjectives if it has a genitive case?
It sounds messy. With genitive being 'undefined relation with noun',
I should not need a defined relation like quality (adjective) or
ownership (possessive). Context should provide this information (the
noun for 'blue color' is rarely an owner and 'John' isn't a quality).
If not, paraphrase would be enough. Any argument to make me implement
adjectives?

End.


------ ebera

------ all humans are geniuses
------ they just keep it secret

Reply

Michael Poxon <m.poxon@...>