On 15 November 2012 13:43, Alex Fink <[log in to unmask]> wrote: > 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: [...] > 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.) I shall have to think about the case or more than one quantifier. I'm sure that's an issue that has been solved in mathematical notation, but I don't recall what the solution is, or whether it even is a problem. But, positing a silent & brings up a different issue- sentence termination. With explicit &s, you know the sentence ends when you don't pronounce an & between two things. Without them, how do you tell where your quantifier scope ends without using some kind of explicit sentence-ending particle, which is not very humany? Incidentally, Mev Pailom has some ambiguities with clause boundaries which are *usually* solved by the presence of semantically meaningful particles that happen to exclusively occupy clause-initial or clause-final positions. But if you don't need the meanings of any of those particles, you just deal with the ambiguity, and pragmatics usually makes it very obvious what the right interpretation is. >>>>> 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? That's what direct embedding is for, to sidestep the need to bind a variable so you don't run out of variables. (Yay referential transparency!) If you need to reference both the rat and the vole more than once, though, then yes, you'd need a subordinate or conjoined clause to give you a new scope in which to talk about just those two. >>>>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". Ah! Yes, I had thought about that briefly. I would probably analyze such a language as simply having really enormous clauses with lots of serial verbs or somesuch, with clause boundaries indicated by whatever morphology is used for rebinding. But it would be a bit of a stretch. It doesn't seem to work at all with the suggestion for flattened out quantifiers, though. You need some kind of clause termination so that you aren't stuck with the entire remainder of your discourse stuck in quantifier scope! >>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. That is what I would do, seeing as how that's how natural languages that I am familiar with (particularly English, wrt subject and complement clauses) seem to work. In Palno, any referent must be bound to an implicit continuation, and event arguments are handled by having different predicates that return/project either the event argument or something else. It's messy. Lambda calculus turns out not to be able to do everything in human language conveniently, and thus Palno is in constant revision. :) -l.