Return-Path: Delivery-Date: Received: from leopard.cs.byu.edu (no rfc931) by swan.cl.cam.ac.uk with SMTP (PP-6.5) outside ac.uk; Thu, 14 Oct 1993 14:28:45 +0100 Received: by leopard.cs.byu.edu (1.37.109.4/16.2) id AA08325; Thu, 14 Oct 93 07:19:03 -0600 Sender: info-hol-request@leopard.cs.byu.edu Errors-To: info-hol-request@leopard.cs.byu.edu Precedence: bulk Received: from dworshak.cs.uidaho.edu by leopard.cs.byu.edu with SMTP (1.37.109.4/16.2) id AA08321; Thu, 14 Oct 93 07:18:56 -0600 Received: from swan.cl.cam.ac.uk by dworshak.cs.uidaho.edu with SMTP (1.37.109.4/16.2) id AA15945; Thu, 14 Oct 93 06:18:41 -0700 Received: from guillemot.cl.cam.ac.uk (user jrh (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Thu, 14 Oct 1993 14:08:42 +0100 To: info-hol@cs.uidaho.edu Subject: Re: Inefficiency when processing big pairs In-Reply-To: Your message of "Wed, 13 Oct 93 21:07:35 PDT." <9310140407.AA13727@maui.cs.ucla.edu> Date: Thu, 14 Oct 93 14:08:29 +0100 From: John Harrison Message-Id: <"swan.cl.cam.:276960:931014131057"@cl.cam.ac.uk> On the subject of a more efficient implementation of pairs, the following may be worth thinking about. Observe that: (\x. s[x]) = @f. !x. f x = s[x] This has a natural extension to pairs: (\(x,y,z). s[x,y,z]) = @f. !x y z. f (x,y,z) = s[x,y,z] So how about *defining* paired abstraction this way rather than the current prettyprinting? It also extends to more general varstructs, which may not be exhaustive, e.g. (\(CONS h t). s[h,t]) = @f. !h t. f (CONS h t) = s[h,t] I haven't thought it through carefully, but the varstruct which you are (intuitively) abstracting over is actually *there* in the basic term, so it might well be more efficient for operations. Anyone have any thoughts on this? John.