Sender: lojban@googlegroups.com
Received-SPF: pass (google.com: domain of jake@mail.jerrington.me designates 52.25.106.113 as permitted sender) client-ip=52.25.106.113;
Content-Type: multipart/signed; boundary="Apple-Mail=_377E64E1-F889-4E01-8E72-8A0D61F2787A"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [lojban] A Simpler Connective System (blog article)
From: Jacob Errington <jake@mail.jerrington.me>
In-Reply-To: <7da3b7fb-f99e-ad65-12f6-550176db0fa6@gmx.de>
Date: Mon, 26 Sep 2016 11:58:28 -0400
Message-Id: <44360471-72E2-4CEC-AA45-95FEB1FA3ACF@mail.jerrington.me>
References: <ca63a666-3727-7c2f-8acf-1fbf72d96779@gmx.de> <453FEC09-0446-4E5E-A82D-FCD596B71A5F@mail.jerrington.me> <7da3b7fb-f99e-ad65-12f6-550176db0fa6@gmx.de>
To: lojban@googlegroups.com
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
X-Spam_score: -1.9
X-Spam_score_int: -18
X-Spam_bar: -


--Apple-Mail=_377E64E1-F889-4E01-8E72-8A0D61F2787A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On Sep 26, 2016, at 11:31 AM, selpahi <seladwa@gmx.de> wrote:
>=20
> On 26.09.2016 17:22, Jacob Errington wrote:
>> In the official grammar, it can be observed that {cu} is a terminator
>> by noticing that it is elided only when one or more terms precede the
>> bridi-tail: contrast {ko'a [cu] broda [vau]} with {broda [vau]}. The
>> proposed connective reform does more than reform connectives. It
>> alters the operation of {cu}, so that rather act as a bridi-head
>> elidible terminator, it acts as a bridi-tail elidible *initiator*.
>=20
> {cu} is not really a terminator. The fact that you can't have {cu} withou=
t a bridi-tail is evidence of that. If {cu} were really a bridi-head termin=
ator, {ko'a cu} should be a valid fragment. Note also that people think tha=
t things like {sei broda cu brode} should be legal. This shows that psychol=
ogically {cu} belongs to the tail, rather than the head.

{ko'a cu} is not a bridi-head, since a bridi-head can appear only before a =
bridi-tail. (I gave an informal characterization of bridi-heads and bridi-t=
ails in my last message. Notice that my characterization rules out {ko'a cu=
} as a bridi-head, as it does not precede a bridi-tail.)

As for people wanting to say such things as {sei broda cu brode} as the bas=
is of a psychological argument in favour of {cu} belonging to the tail, I a=
rgue that people think this way because the most common way of explaining {=
cu} to people is a lie: "{cu} is a cmavo that can be placed before the main=
 selbri in order to force the insertion of all elidible terminators necessa=
ry to make the appearance of the main selbri grammatical". Sure, according =
to this explanation, {cu} belongs to the tail, but as I said, this explanat=
ion is a lie. According to this explanation, {cu broda} would be legal, sin=
ce it forces the inclusion of all (zero) terminators necessary to make the =
appearance of the main selbri {broda} grammatical. However, {cu broda} is n=
ot allowed in the official grammar.

Therefore, as I understand it, your psychological argument boils down to th=
is: we should change the operation of {cu} because of a convenient lie we'v=
e told to too many people. (I'm not at all claiming that I'm not guilty of =
perpetuating this lie too; I've explained {cu} this way countless times.)

As for people who want things like {sei broda cu brode} to be legal, accord=
ing to my (rather straightforward) characterization of bridi as a bridi-tai=
l plus an optional head, {sei broda cu brode} is ruled out, as {sei broda} =
is not a term. Hence, there is no bridi-head. ("If a bridi-tail is present,=
 it may be preceded with a bridi-head, which begins after {zo'u}, ends with=
 {cu}, and encloses *one or more* terms." Added emphasis.)

Perhaps we can just teach people this characterization instead of fundament=
ally changing the operation of {cu}. In fact, this is already how I explain=
 {cu} to people now. Rather than change the grammar so that we can have bee=
n right all along, let's just admit that our explanation was wrong and move=
 on.

>=20
> Also, {cu} and {vau} don't really form a pair. {vau} appears even in phra=
ses that contain zero {cu}, and the number of {vau} in sentences containing=
 bridi-tails exceeds the number of {cu}. If they were a real pair, they sho=
uld always appear equally often.
>=20

There's no argument here. I agree with you entirely that {cu} and {vau} do =
not form a pair. This contradicts nothing of what I said though; I never sa=
id that they formed a pair. I merely said that there was a kind of elegant =
symmetry between bridi-heads and bridi-tails, since each has a terminator.

>> Reforming the overly complex connective system is an excellent goal,
>> but I am against the means to that end employed in this proposal,
>> namely the alteration of {cu} to become an elidible initiator (which
>> would also make it the first of its kind, I think).
>=20
> I like to compare {cu} to FA. A FA is an optional marker for a particular=
 sumti, while {cu} is an optional marker for the selbri. Both FA and CU mar=
k particular slots in the bridi.
>=20

And I like to compare {cu} to {vau}! {vau} terminates a bridi-tail whereas =
{cu} terminates a bridi-head. Both terminate important parts of the bridi.

Of course, {cu} cannot appear without {vau}, since a bridi-head cannot be p=
resent without an accompanying tail. But then again, this is no different t=
han how CU differs from FA in your proposal, since {fa mi} is not a bridi w=
hereas {cu broda} is.

.i mi'e la tsani mu'o

--=20
You received this message because you are subscribed to the Google Groups "=
lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to lojban+unsubscribe@googlegroups.com.
To post to this group, send email to lojban@googlegroups.com.
Visit this group at https://groups.google.com/group/lojban.
For more options, visit https://groups.google.com/d/optout.

--Apple-Mail=_377E64E1-F889-4E01-8E72-8A0D61F2787A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJX6UWkAAoJEKmgkgqh5erPOXQIAKg1o7T5zP7FJYXsDHOxJt6t
sliySrsQVbHYrkBLJ3NxpTK3GHppkurQYcug8Gkn6qFjklXjMvp25uRPbBLmxW6O
CYZYIM4pd3eIpUzyZOc0M1lwlAfSFyCN9nMaSTDmOLqLInzJ9FfC5UUV8brMq1QP
gwfju8oNcg5jSs4HLE6R5PcZz6TzYVLhRTHgcnCk4J+2rFBwoQaP1bSjMkdnc+07
twgto9K6SKli4ZfPssEOmXgtRxcPHcwa+Kv6vhqhDFeMu/s94xgqT3TBwgSkWNkO
wawbp5V5EOTmrn4QuIZriKVlko6+jGlf3+wtsQQ7yzN9ro4caDd/zcwYQ5LWsJk=
=NMt3
-----END PGP SIGNATURE-----

--Apple-Mail=_377E64E1-F889-4E01-8E72-8A0D61F2787A--