[YG Conlang Archives] > [ceqli group] > messages [Date Index] [Thread Index] >
Rex May - Baloo wrote: > > on 4/4/02 8:51 AM, kevinbsmith at yahoogroups@hidden.email wrote: > > > --- In txeqli@y..., "John Schilke" <doc@c...> wrote: > >> Glosa has this business of "fu," "du," "pa" for tenses (only > >> if needed) and often it remains unused. > > > > As a semi-fluent Glosa speaker, I have to chime in here. On a > > side note, there is some substantial disagreement on the Glosa > > list right now about tense, aspect, etc. It seems that the Glosa > > system isn't quite complete. > > > > Anyway, the real point I wanted to make is that in Glosa, these > > tense markers (plus "nu" [now]) double as verb phrase markers. > > When you encounter one, you know you have left the subject and > > are entering the verb. Similarly, "u" and "plu" are the main > > noun phrase markers that let you know the verb is finished. > > There seem to be others, like "mi", but there is no concrete list > > so it is open to interpretation. > > > > Unfortunately, because these markers are optional, it is often > > difficult to parse sentences correctly. Generally it is possible > > by context, but often it requires one or more restarts because > > you hit a dead end. > > > > One example was when I recently said "mi volu auxi". I intended > > the meaning as "I want to-help", but it can equally be > > interpreted as "I want assistance". Even if I had said "mi nu > > volu auxi", it wouldn't have helped. > > > > The only way my meaning would be clear would be if the NP marker > > was required instead of being optional. Then, because I didn't > > say "mi nu volu u auxi", readers would KNOW that auxi was still > > part of the verb phrase. > > > > I hope Ceqli is able to avoid this confusion. I strongly believe > > that you should be able to parse almost any sentence in one try. > > It may take some context to grasp the intended meaning, but not > > the intended structure. > > Hm. That is a problem. Let's see. In Ceqli it would be > > Go vol pomo. which is short for. > Go vol ke go pomo. > > Now, to say I want asstance.... > > Go vol bepomo. I want to-be-helped. short for > Go vol ke go bepomo. > > Of course, pomoka is an act of helping, so could say > Go vol pomoka. > > If you mean some kind of tangible help, like money, could say > Go vol pomoxo. > > However, this whole thing leads me to wonder if maybe the thing to do is go > with the Loglan system, which started this whole thing anyway. If we did, > here's what we'd have: > > 1. Except for some grammatical particles, everything is a verb. > > Go pomo. I help. > > To pomo sa kan The help dog. dog who helps. > > To pomo. The helper, one who helps, which we now signify by 'pomovo'. And would you still have "bepomo"? Go bepomo. I am/was/will be helped. To bepomo sa kan The helped dog To bepomo The helpee Now how do we say: The dog helped the cat. To kan pomo sa felin. The cat was helped by the dog. To felin bepomo to kan. ??? Mandarin-style would be: To felin be to kan pomo. The cat who was helped by the dog ate the rat. To kan pomo sa felin kom to xu. Mandarin <bei4> is not attached to the verb, and can be followed by the subject of the verb. > In this case, the rule would have to change and there could be no more > sentences like > Kan pomo felin. Dog helps cat. > We'd have to make it explicit that a noun is a noun. > > Te kan da pomo te felin. Dog helps cat. Now "da" starts to look like the postpositional subject marker "ga" in Japanese. Or else, "te kan" is the topic, and "da" is the subject, repeated for emphasis. What does "da" add to this sentence? How is it different from "Te kan pomo te felin."? > Te being the default noun marker that can be definite/indefinite, whatever. > > And if we do that, why not go ahead and reserve CV(V) for grammar words that > do _not_ behave that way? I say not because it's just too darn arbitrary. > The number of grammar words should be small enough to memorize. > > Anybody want to Loglanize the predicates of Ceqli this way? Mike, this wd > maybe give it some internal consistency that you feel a lack of. [...] Hmm. The farther I go in this, the more I see a lack of internal consistency in Mandarin. Although I feel very comfortable with it, I'm beginning to see that it's not a lot more consistent than English. At this point, if I were designing a conlang from scratch, I'd take only the following points from Mandarin: 1) strict SVO word order, with topicalization in sentences 2) modifier-head order throughout 3) prepositions rather than postpositions 4) stative verbs not requiring the copula in the predicate 5) no obligatory syntactic gender, number, tense, person, mood, aspect, or definiteness I would examine every new idea about syntax to make sure it didn't violate any of these five principals. Beyond that, I'd aim at simplicity, consistency, and clarity. I would go as far as possible in abstract syntax design without any concern for expressing particular ideas. One purpose would be to avoid relying on familiar forms. Another would be to avoid relying on context. I agree with Kevin's point that grasping the intended structure should not depend on context. I would write out the syntax as a set of formulas, either creating my own notation, or learning about what linguists use: 0) simplest sentence Pred <intransitive|stative> 1) simple sentence with intransitive verb NounMarker Subj <noun|pronoun|verb> Pred <intransitive> 2) simple sentence with stative verb NounMarker Subj <noun|pronoun|verb> Pred <stative> 3) simple sentence with transitive verb NounMarker Subj <noun|pronoun|verb> Pred <transitive> NounMarker DirObj <noun|pronoun|verb> 4) simple sentence with passive and no subject NounMarker DirObj <noun|pronoun> PassiveMarker Pred <transitive> 5) simple sentence with passive and subject NounMarker DirObj <noun|pronoun> PassiveMarker NounMarker Subj Pred <transitive> or, alternatively, NounMarker DirObj <noun|pronoun> PassiveMarker Pred <transitive> NounMarker Subj Throughout this process, I would attempt to enumerate the various instances required for each category of particles (markers), and begin to come up with actual sounds for them. A single PassiveMarker, "be" might suffice, but there would be a need for quite a few NounMarkers. This means that I would have to identify what kinds of ideas should be expressed through syntactical structures and particles, and which should be left to lexical items. I would have to decide, for example, whether tense needs to be expressed through syntax, or whether it can be left to words like "today", "next Wednesday", "last year", "want to", "plan to", and "already". Only after I had gone as far as possible with this would I begin creating a bare minimum of vocabulary items to replace the placeholders and test the abstract syntax. I would then move from simple sentences to more and more complex, convoluted sentences. I would strive to always create patterns that could be expressed as formulas. (And I would not promote flexibility at the cost of simplicity and consistency.) The fact is that any language will have hundreds of basic sentence patterns. There is no way to avoid designing them. The work has to be done. The only question is whether to do it the easy way or the hard way. It seems to me that approaching the design of those patterns from the bottom up is bound to be the most efficient, just because it will be easier to be consistent. And approaching the design at an abstract level will reduce the introduction of inconsistencies based on natural languages. No matter how it's approached, it's a very difficult task. I'm glad I don't have to do it. -- Mike Wright http://www.CoastalFog.net ____________________________________________________________ "The difference between theory and practice is that, in theory, there is no difference between theory and practice; in practice, however, there is." -- Anonymous