Print

Print


On Thu, 15 Nov 2012 09:50:10 -0700, Logan Kearsley <[log in to unmask]> wrote:

>On 14 November 2012 22:01, Alex Fink <[log in to unmask]> wrote:
>> On Wed, 14 Nov 2012 13:51:37 -0700, Logan Kearsley <[log in to unmask]> wrote:
[...]
>> If you had allowed a handful of third-person pronouns with no restrictions on them, you would've just reinvented (the core of) Xorban.  
>
>That's a big "if". I *really* don't like that kind of "pronoun"
>system; it puts the fact that these things are standing in for
>variables at the abstract semantics level way too close to the
>surface. Human languages *don't do* arbitrary variable bindings
>(except maybe for that spatial pronoun thing in sign languages, which
>I'm probably doing a horrible job of referencing accurately). 

There we wholly agree.

>I had an epiphany this morning: clauses define scopes, so quantifiers
>could be encoded as relative particles introducing subordinate
>clauses. I.e.:
>
>   break(y) , ALL(y)-such-that teacup(y) & nurse(x) & throw(x,y) ->
>"All teacups thrown by nurses break"
>
>And that fits quite nicely into common language structures.

Yes.  

I'll take that opportunity to raise a different point that crossed my mind about subclauses, though.  Given that one of the impetuses for my case-lang scheme (which could also be applied to your pronoun-lang scheme) was avoiding ordered lists in its parsing, and given that parsing hierarchical structures wants some kind of stack, one might be moved to try to avoid hierarchical structures.  I wonder if we lose an unacceptable amount of flexibility by flattening your structure here and saying, for instance, that the inner-subclause scope of an ALL is always precisely the material to its left (or you cd choose right) in the current clause, and if there are variables other than the quantified one appearing on both sides of the ALL they get donkeyed in the logical form.  With only one scoping operator there are surely no problems:

    teacup(y), nurse(x), throw(x,y), ALL(y) [such that the foregoing], break(y).
    farmer(x), donkey(y), own(x,y), ALL(x) [such that the foregoing], beat(x,y).

With more?  (I have also silently posited that & is silent.)

>>>> Then there's the problem of subclauses reusing variables [...]
>>>
>>>If you use pronoun-binding instead of case, that problem goes away.
>>
>> How?  In a substantially different way to my variant with a' above?
>
>Oh, it's not substantially different. It's just that instead of having
>a collision of two things needing the same case (hence a'), you'd just
>use a different pronoun (until you ran out of appropriate pronouns in
>the language), which means you neither need a voice changing operation
>of 'eat', nor do you need a relative construction to change what the
>'rat' referent is bound to.

Mm.  This is good, but it seems to me you'd run out of appropriate pronouns in about as many circumstances as you'd run out of appropriate cases.  I dunno, if there are, say, a rat and a vole in the clause (which'll be in the same noun class in any non-wack semantic class system), and the proximate is already taken, wouldn't you then need a pronoun shuffling operation?

>>>But I would point out that "n=a_last" is pretty much *exactly* how
>>>lots of languages actually handle relative pronouns, so hardly
>>>inelegant. E.g., Russian "kotorij" = "the last thing that was
>>>masculine singular? Forget its old case, now it's nominative". 
>>
>> Yeah, that's kinda what I was getting at with my "Latinate notions of elegance": there might be no good reason to favour the "everything possible should be one sentence" style.  Actually, to swing to the other extreme, I wonder how usable it would be to make as many clauses as possible _one_ predicate, and rely on a set of pronouns whose values default to staying the same from clause to clause unless a pronoun moves them around.
>
>I do not understand what you are proposing here at all.

More or less, at the extremest extreme, throwing out clauses altogether and instead just having words, interpreted one at a time as they come.  Pronoun values would be persistent, unless one of the words is a relative to move them around.  Or probably, for usability, there would need to be morphology that says "cancel the old value of this variable, I'm starting afresh with it this word".

>On 15 November 2012 02:55, Leonardo Castro <[log in to unmask]> wrote:
>> In a Xorban-like structure, we could have
>>
>> 1. boy(x); girl(y);
>> 2. kisses(x,y)(z);
>> 3. I-see-it(z)
>> or this-may-happen(z)
>> or this-already-happened(z);
>>
>> maybe better expressed as
>>
>> 1. x=boy; y=girl;
>> 2. z=kisses(x,y);
>> 3. i-see-it(z).
>
>Ah! The Event argument! Re:
>>>Not sure how you'd handle embedded subject/object clauses.
>that's how you do it! I can't believe I forgot that... many thanks for
>writing in that (z). :)

Oh, right!  

I suppose event arguments are a place where my idea of binding all the arguments by default doesn't work so well; they need a different policy.  In my case system, there would be an eventive case, I guess; in the noun class system, similarly, events would surely be one noun class.  In either case, the default binding for _every_ eventive would be z.  That means that even an innocuous sentence like what I had been writing
    nightingale(n) & sing(n) ,
hoping for "a nightingale sings", would really be
    nightingale(n; z) & sing(n; z)
which is the nonsense "a nightingale sings and the event of its being a nightingale equals the event of its singing".  

Though, hm.  Since not all events (just like not all consequents of ALL) will be expressible in just one predicate, perhaps the eventive should be scoping?  (Like Xorban _fe_ I guess.)  With my left-scoping syntax, then,
    boy(x), girl(y), kiss(x, y), EVENT(z) [of the foregoing], see(myself, z)
is more like "an event of (something being) a boy kissing (something being) a girl" than "an event of kissing, involving a boy and a girl", but I don't see a reason to care about the difference between those two.

Alex