From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60286 invoked by alias); 30 Oct 2016 19:10:58 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 60273 invoked by uid 89); 30 Oct 2016 19:10:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=rectangle, picture X-HELO: aibo.runbox.com Received: from aibo.runbox.com (HELO aibo.runbox.com) (91.220.196.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 30 Oct 2016 19:10:47 +0000 Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1c0vVE-0005RS-3Y; Sun, 30 Oct 2016 20:10:44 +0100 Received: from 70-36-239-8.dsl.dynamic.fusionbroadband.com ([70.36.239.8] helo=toshie.bothner.com) by mailfront12.runbox.com with esmtpsa (uid:757155 ) (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) id 1c0vV0-0000ov-D9; Sun, 30 Oct 2016 20:10:30 +0100 Subject: Re: (kawa pictures) square-limit pictures To: Sudarshan S Chawathe References: <9603.1477853671@vereq.eip10.org> Cc: kawa From: Per Bothner Message-ID: <07c5b6ff-e52b-7869-6761-29138d840456@bothner.com> Date: Sun, 30 Oct 2016 19:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9603.1477853671@vereq.eip10.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q4/txt/msg00045.txt.bz2 On 10/30/2016 11:54 AM, Sudarshan S Chawathe wrote: > An issue related (I think) to the choice of names is how closely the > library follows the original SICP pictures language v. how closely it > tries to match Kawa's composable pictures style. Here I am thinking > about, for instance, the implementation of "below" using SICP's explicit > notion of painting into frames (and frame transformations) v. using > Kawa's re-center and vbox. When I first started writing the > square-limit example, I went with the first option, but then decided > that is probably not in the spirit of the Kawa pictures library. There > is probably value in having both methods. I've considered adding a procedure to help bridge the SICP model and the Kawa model. Something like: (transform-to RECT PICTURE) This would be equivalent to some (with-transform TRANSFORM PICTURE) such that the bounds of the result matches RECT. More generally RECT could be a parallelogram. (Note a rotated rectangle is a parallelogram but is not considered a rectangle.) In that case the bounds of the transform would not match RECT, but would have the same bounds as RECT. The RECT corresponds to the "frame" of SICP. -- --Per Bothner per@bothner.com http://per.bothner.com/