From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by sourceware.org (Postfix) with ESMTPS id 0D121385E00A for ; Tue, 28 Jun 2022 06:17:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D121385E00A Received: by mail-yb1-xb31.google.com with SMTP id p136so14315991ybg.4 for ; Mon, 27 Jun 2022 23:17:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=stmVK/2wegdRo7pZRafhGjZ/3kRhjr9fAD6NGIa66Rs=; b=eoXnj+e+R9BlvxK/pLFlCqJ9q/1gRHuRtHaieJaO2ggazGwJc0nEoRt6RJ2ff9CpYg qPrT42+/4FTGt5M9i73OVqSwcdJAPH4jfRye6TKWlQjWAgIbligJhxg6y3UvcN65Q7xb dEm6kJu6rQZklkJb4Wcua/ksIhYjLVCGkqQr4uhKcI1QVAVA6tJ0cqj/yWFCNNj/epQ6 9uLmdxP/ifnhMKKQZE69XNMl9wXO/O/KeUk83pX8cJuzXtkTmem2l7tRb1Tqn3ylHaBR cQlrPW/EDafOV1DTO2k3y6jSSTsl2wjx3WLEIHB3KE/ShH0kHqjvnZ8NsPtANSzanIsO 9DVA== X-Gm-Message-State: AJIora8mS2I8Jyycha52Gmy71nwdmAClH1XSjNQ0bApBgv/lpey1Qkeg bnF5GdLkgOJMZcnXGoV5r27fTLTqbOmaDVO5YQnRh1FVEIU= X-Google-Smtp-Source: AGRyM1vzqrUOI6sC9LHyiaJf33f4Na2cYqmOYgFjihs94fi3ZYaCBa132CV96EaBfPwKjNbF5n+Cofv3y2Zd079B3xQ= X-Received: by 2002:a25:e812:0:b0:66c:90a4:b812 with SMTP id k18-20020a25e812000000b0066c90a4b812mr15127295ybd.23.1656397042440; Mon, 27 Jun 2022 23:17:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Panicz Maciej Godek Date: Tue, 28 Jun 2022 08:17:09 +0200 Message-ID: Subject: Re: Kawa evaluation process To: Per Bothner Cc: kawa@sourceware.org X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2022 06:17:25 -0000 Thanks for the quick response! wt., 28 cze 2022 o 07:20 Per Bothner napisa=C5=82(a): > > > On 6/27/22 21:54, Panicz Maciej Godek via Kawa wrote: > > So I've been wondering if there's an option to create a "box" that woul= d > be > > transparent to the process of evaluation (possibly with some tweaks to > > Kawa): that I would have an object that holds a string and a value, and > > when the evaluator asks it for the value, it would provide whatever val= ue > > would result from parsing the string? > > Wel, we mostly have that. Every atom (almost - see below) appears as the > car of a cons cell in a list. So we can associate extra information with > the Pair. Since Pair is a class you can inherit from, you can create > subclass of Pair with extra information. This sounds great! Actually, I already have a subclass of Pair (because Kawa pairs failed to work with Java's weak hash tables, because of their identity function): https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/sr= c/primitive.scm#L33 so what I think I can do is override the getCar and getCdr methods, so that - if the item held by them is an atom - they would return that atom's value. (I think it makes sense) > This is how line number information > is handled in Kawa - see the PairWithPosition class. > > Note a PairWithPosition can specify a range in a sourcefile, which gives > you > the actual source string for the atom. The comments in the file hint at > generalizing the filename/position pair to use a general > gnu.text.SourceMapper. > Or you can you can create new subclasses of PairWithPosition. > > That's good to know. I actually haven't been using PairWithPosition (or subclassing, for that matter). Instead, I've been using weak-key hash tables representing spaces before head, after head, before (dotted) tail and after tail, and some other properties: https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/sr= c/space.scm#L370 I guess that subclassing would result in more efficient code (but I don't know if I'd be able to change it quickly at this point) I also wrote my own parser that uses this representation https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/sr= c/parse.scm but I wonder if I could somehow piggyback on your parser to parse atoms? (I mean something like (call-with-input-string read), but perhaps a bit more low-level, because at that point we already know that the thing we're reading isn't a list) There are some limitations to the atom/car-of-Pair identity. One is > in the case of an impure list (dotted pair) - which isn't valid in source > code > anyway except inside quotes. Another limitation is for atoms that are > top-level forms. > Kawa handles that by wrapping such an atom in a fake begin list - see > gnu/kawa/lispexpr/LispReader.java line 503. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ >