Received: from mail-yk0-f190.google.com ([209.85.160.190]:33872) by stodi.digitalkingdom.org with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1YfbQ6-0001jE-Dr; Tue, 07 Apr 2015 14:52:31 -0700 Received: by ykp9 with SMTP id 9sf13824930ykp.1; Tue, 07 Apr 2015 14:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:from:date:message-id:subject:to:content-type :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe; bh=j4QHDybBu20tgBpiBTHDQxcIU0wPVgYU9H1DdgB4jrQ=; b=eiIgmpJ1KX5V+2RdRSV8LRQTR64fGyxHQbv0oqq1VNiOMpZf4WvxEN6TRj+ewO3jnF t+xZvLyz9wMXnzGz+LkID58D03WVXndq1G4Yq/1yDYMMmpTxc6rcBKf2UyBP1jT4TMbK khrbYxDhM98oKKEIvDjXpI1sjOBVWkToTmrVkVqKeVGuP7AMJLGMGxsB8n/T9ahWUqOx /xU5lj8bML0hhJv1j0AMtB3DMNRIso2+dsCeCxSrrlOKvIaRTgYEUBS9QGkjLiiF5834 XQChylAgf5oIkgqRyPzK8kepjTVN387kezIuNTwCp+GwRNvxo348ZlSPytXM6Sch+/yk nvlA== X-Received: by 10.50.90.178 with SMTP id bx18mr125743igb.13.1428443543783; Tue, 07 Apr 2015 14:52:23 -0700 (PDT) X-BeenThere: bpfk-list@googlegroups.com Received: by 10.107.131.68 with SMTP id f65ls391715iod.24.gmail; Tue, 07 Apr 2015 14:52:23 -0700 (PDT) X-Received: by 10.43.5.201 with SMTP id oh9mr27635867icb.10.1428443543624; Tue, 07 Apr 2015 14:52:23 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com. [2607:f8b0:400d:c04::232]) by gmr-mx.google.com with ESMTPS id z1si1473595qcn.2.2015.04.07.14.52.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 14:52:23 -0700 (PDT) Received-SPF: pass (google.com: domain of nictytan@gmail.com designates 2607:f8b0:400d:c04::232 as permitted sender) client-ip=2607:f8b0:400d:c04::232; Received: by mail-qg0-x232.google.com with SMTP id i89so27445411qgf.1 for ; Tue, 07 Apr 2015 14:52:23 -0700 (PDT) X-Received: by 10.140.147.5 with SMTP id 5mr27427128qht.31.1428443543507; Tue, 07 Apr 2015 14:52:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.28.73 with HTTP; Tue, 7 Apr 2015 14:52:03 -0700 (PDT) From: Jacob Errington Date: Tue, 7 Apr 2015 17:52:03 -0400 Message-ID: Subject: [bpfk] FA as a TAG (Was: One cannot refer to inner nodes in Lojban PEG) To: bpfk-list@googlegroups.com Content-Type: multipart/alternative; boundary=001a1135377efe18c10513296db1 X-Original-Sender: nictytan@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of nictytan@gmail.com designates 2607:f8b0:400d:c04::232 as permitted sender) smtp.mail=nictytan@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: bpfk-list@googlegroups.com Precedence: list Mailing-list: list bpfk-list@googlegroups.com; contact bpfk-list+owners@googlegroups.com List-ID: X-Google-Group-Id: 972099695765 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.7 (-) X-Spam_score: -1.7 X-Spam_score_int: -16 X-Spam_bar: - Content-Length: 6332 --001a1135377efe18c10513296db1 Content-Type: text/plain; charset=UTF-8 I'm making a separate thread out of this because I'm going on a tangent here. On 7 April 2015 at 15:04, wrote: > Terms can have FA or tags equally well, but we don't want to merge > FA with BAI generally, to avoid things like "se fa" and ".i fa bo", > which are nonsense. I agree that {se fa} has no clear interpretation upon first examination. However, {.i fa bo} can be interpreted like any other {.i TAG bo} construct. .i broda .i TAG bo brode -> .i broda TAG lo su'u brode Hence, .i broda .i fa bo brode -> .i broda fa lo su'u brode This provides us with another way to do essentially what {la'e di'e} does. For instance, .i mi pu pensi la'e di'e .i lo mi bruna cu cmalu mutce -> .i mi pu pensi .ifebo lo mi bruna cu cmalu mutce I was thinking about this: my brother is very short. Taking this idea to the extreme, we can conceive of a somewhat silly higher-order predicate -- call it {brodrfV} for now -- whose x1 is an arbitrary sumti and whose x2 is a nullary predicate supplied with than fV having the value of the x1. We can define {brodrfV} with the following statement. .i ko'a brodrfV lo du'u broda <=> broda fV ko'a We can derive some obvious results from this statement. .i lo brodrfV be lo du'u fV ko'a broda === ko'a .i fV ko'a broda === .i fi'o brodrfV ko'a broda This gives us a way to pick out sumti from du'u-abstractions, an otherwise arduous task for the fancylojban programmer/speaker. Furthermore, this gives us a way to interpret {se fV}. Since {fV === fi'o brodrfV}, we have {se fV === fi'o se brodrfV}. For instance .i lo mi bruna cu cmalu mutce se fe lo du'u mi pu pensi -> mi pu pensi lo du'u lo mi bruna cu cmalu mutce I've basically hijacked FA to recreate bridi relative clauses. I'm sure there're plenty of holes in this idea since I cooked it up in just a few minutes. Feel free to come up with weird cases and we can examine them. Do I want this to be a feature of standard Lojban? Not necessarily. Do I think it's a cool idea? Sure. I hope you do too :) .i mi'e la tsani mu'o -- You received this message because you are subscribed to the Google Groups "BPFK" group. To unsubscribe from this group and stop receiving emails from it, send an email to bpfk-list+unsubscribe@googlegroups.com. To post to this group, send email to bpfk-list@googlegroups.com. Visit this group at http://groups.google.com/group/bpfk-list. For more options, visit https://groups.google.com/d/optout. --001a1135377efe18c10513296db1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm making a separate thread out of this because I'= ;m going on a tangent here.

On 7 April 2015 at 15:04, <cowan@cci= l.org> wrote:
Terms can have FA or tags equally = well, but we don't want to merge
FA with BAI generally, to avoid things like "se fa" and ".i = fa bo",
which are nonsense.

I agree that {se fa} ha= s no clear interpretation upon first examination. However, {.i fa bo} can b= e interpreted like any other {.i TAG bo} construct.

.i br= oda .i TAG bo brode -> .i broda TAG lo su'u brode

= Hence,
.i broda .i fa bo brode -> .i broda fa lo su'u = brode

This provides us with another way to do essentially= what {la'e di'e} does. For instance,

.i mi pu pe= nsi la'e di'e .i lo mi bruna cu cmalu mutce -> .i mi pu pensi .i= febo lo mi bruna cu cmalu mutce
I was thinking about this: my= brother is very short.

Taking this idea to the extreme, = we can conceive of a somewhat silly higher-order predicate -- call it {brod= rfV} for now -- whose x1 is an arbitrary sumti and whose x2 is a nullary pr= edicate supplied with than fV having the value of the x1. We can define {br= odrfV} with the following statement.

.i ko'a brodrfV = lo du'u broda <=3D> broda fV ko'a

We can de= rive some obvious results from this statement.

.i lo brod= rfV be lo du'u fV ko'a broda =3D=3D=3D ko'a
.i fV= ko'a broda =3D=3D=3D .i fi'o brodrfV ko'a broda
=
This gives us a way to pick out sumti from du'u-abstract= ions, an otherwise arduous task for the fancylojban programmer/speaker.
=
Furthermore, this gives us a way to interpret {se fV}. Since= {fV =3D=3D=3D fi'o brodrfV}, we have {se fV =3D=3D=3D fi'o se brod= rfV}.

For instance
.i lo mi bruna cu cmalu = mutce se fe lo du'u mi pu pensi -> mi pu pensi lo du'u lo mi bru= na cu cmalu mutce

I've basically hijacked FA to recre= ate bridi relative clauses.

I'm sure there're ple= nty of holes in this idea since I cooked it up in just a few minutes. Feel = free to come up with weird cases and we can examine them.

Do I want this to be a feature of standard Lojban? Not necessarily. Do I t= hink it's a cool idea? Sure. I hope you do too :)

.i = mi'e la tsani mu'o

--
You received this message because you are subscribed to the Google Groups &= quot;BPFK" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bpfk-list= +unsubscribe@googlegroups.com.
To post to this group, send email to bpfk-list@googlegroups.com.
Visit this group at ht= tp://groups.google.com/group/bpfk-list.
For more options, visit http= s://groups.google.com/d/optout.
--001a1135377efe18c10513296db1--