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


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

Re: [txeqli] Re: Glosa fu/du/pa (was: Aspect)



on 4/4/02 3:51 PM, Mike Wright at darwin@hidden.email wrote:

> Rex May - Baloo wrote:
>> 
>> 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"?

Yes,  In fact, the 'be' concept was borrowed from Loglan in the first place.
> 
> 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.

Yes, and that has uses, but not nearly as many as the Ceqli be system, thus:

Go fo pani.  I need water.
Pani befo go.  Water is needed by me.
Pani befo.  Water is necessary, is a necessity.

Pani dan spun.  Water is in the spoon.
Spun bedan pani.  Spoon contains water.

A lot of words are the be-ification of others.
> 
> 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."?

Yes.  It's meant here, in Loglanized Ceqli (which is a dead letter, we're
just discussing it) simply to keep the two nouns from forming a compound.
It's kind of an appositive of the Te kan.

> 
>> 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 think all these are principles of Ceqli, except for a little more
looseness in number one, the emphasis of the verb, that is.
> 
> 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 don't entirely agree.  In all languages, context enables a lot of
simplification.  As I said before, ciq stu is short for Go ciq ke zi stu,
but it could mean a lot of other things.  Da pa ciq ke go stu, etc.  But I
want to be able to say Ciq stu.  However, I want to be able to go
context-free when necessary and expand the whole thing till it's no longer
ambiguous.  
> 
> I would write out the syntax as a set of formulas, either creating my
> own notation, or learning about what linguists use:

Gad.  I don't think I'm up to that.
> 
> 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.

Whew!  Other reactions?

-- 
>PLEASE NOTE MY NEW E-MAIL ADDRESS: rmay@hidden.email
> Rex F. May (Baloo)
> Daily cartoon at: http://www.cnsnews.com/cartoon/baloo.asp
> Buy my book at: http://www.kiva.net/~jonabook/gdummy.htm
> Language site at: http://www.geocities.com/ceqli/Uploadexp.htm
>Discuss my auxiliary language at http://groups.yahoo.com/group/txeqli/