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


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

Re: [engelang] Re: [jboske] LoCCan3 development ideas.



Mike S., On 27/08/2012 18:31:
Let's see...  pdjd = monday, cnb = kiss

cnbakefu
"U is the event of A kissing E"
Or maybe: "A kissing E is in event U"

In Xorban, "on-monday(kiss(x,y))" is not possible of course. Ignoring
free variables, would this formula work for "kiss(x, y, z) +
on-monday(z)":

su pdjdu cnbakefu
"In some event-on-Monday, A kisses E."

Yes.
I am starting to see a subtlety made available in the use of this
approach, and how it can clear up things. A minor mystery in my mind
has always been how the prohibitive works, and why so many natlangs
had a marked negative form to cover it. "Don't eat the cookies" =/=
"Be in a state of not eating the cookies" because you could comply by
achieving such a state at 3pm and then proceed eat the cookies at
4pm, and "Never eat the cookies" doesn't feel right. Maybe it means
"make it so that event e does not exist such that you eat the cookies
in e."

Yes.
You will have to explain what juxtaposition is and why that is to be
preferred.

Not necessarily preferred in Xorban, but preferred in a fullblown event-arg system. Firstly because the logical connectives themselves will reduce to predicates, and secondly because in, for example, "false(x1,x2) angry(x2,x3)" no binary logical connective would yield the requisite meaning. (Not just because "false" is a logical operator -- "Unlikely" or "discussed" could create problems if the connectives were truth-functional.

    Conjunctions and negation can also be reduced to combinations of quantification and predicates with event arguments.


Starting to understand, partially based on the XorbanDev thread.
Basically ~Pxy => ~Ew Pxyw, where event(w) is true, correct?

Yes.

    But Livagian in one way or another or more probably does stretch ordinary innate human abilities beyond their breaking point. My aim is find an optimal design and then consider whether humans can cope with it.

In what sense could an optimal design be anything but human-copable?
Whom are we designing these languages for if not ourselves?

I don't have a clear sense of what is human-usable in advance. The first goal is to create an explicit unambiguous encoding of predicate--argument structure in a way that's no more verbose than natlangs. If several solutions appear, the most ergonomic might win. I suppose it might happen that the only solution is barely human-usable, so then you'd have to balance its difficulty with the verbosity of its more usable alternatives.

With regard to Xorban, I do think the fact that every variable is named places a heavy burden on memory.

What perplexed me, and sent my mind on wild goose chases, is why it
would be required to say "exists(x1) event(x1): not exists(x2)
event(x2): angry(x2, x3)" when "not exists(x2) event(x2): angry(x2,
x3)" appears to suffice. Then it dawned on me that, in your system,
"false(x1,x2)" would be grammatically crippled if it too did not also
have its own event argument x1. Now what perplexes me is the
motivation behind this design choice.

Most formalizations of natural language (and not that I have seen a
million of them, but I have seen a few floating around, incl.
Montague's stuff) treat logical operators as a closed class that
interacts with the grammar in special ways. Likewise, the
corresponding semantic rules are special: They are unique in that
their semantic value does not vary wrt the model (universe of
discourse) nor wrt to possible worlds and time indices. Could you
explain in a little detail what advantage you find in shoehorning
them into the class of open predicates?

I don't agree that the semantics are special or that they are unique in the ways you say. So I see them just as semanticaly ordinary predicates with special syntax.

Given that they're not special semantically, the question then arises whether there's any justification in creating special syntax for them.

     >Secondly, it would be tricky to reorder the
     > constituents without changing the meaning, except perhaps by again
     > defining alternate predicates.

    Yes, reordering would by tricky. any particular reasons why you want reordering to be possible?


Primarily to allow the speaker to reorder the quantifiers with the arguments when needed (this was a loglang after all), and secondarily to allow the speaker to front a focus.

I see. Me I don't like scope based on linear order rather than hierarchical syntax. And moving things around for focus can be done by having placeholders a bit like English "it" ("I consider it highly unlikely that it will rain").

--And.