From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Taylan Kammer Newsgroups: gmane.lisp.guile.user Subject: Re: [EXT] Can guile be implementation independent? Date: Sat, 18 Dec 2021 18:10:58 +0100 Message-ID: <91c20674-e4e7-ae31-c33f-072c566312bf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34821"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Cc: Guile User To: "Thompson, David" , Jacob Hrbek Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sat Dec 18 18:12:11 2021 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mydFj-0008uZ-Ic for guile-user@m.gmane-mx.org; Sat, 18 Dec 2021 18:12:11 +0100 Original-Received: from localhost ([::1]:51714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mydFi-0003jv-Bt for guile-user@m.gmane-mx.org; Sat, 18 Dec 2021 12:12:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38782) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mydEc-0003O4-UZ for guile-user@gnu.org; Sat, 18 Dec 2021 12:11:02 -0500 Original-Received: from [2a00:1450:4864:20::433] (port=34683 helo=mail-wr1-x433.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mydEb-0000I3-2D for guile-user@gnu.org; Sat, 18 Dec 2021 12:11:02 -0500 Original-Received: by mail-wr1-x433.google.com with SMTP id s1so10434013wrg.1 for ; Sat, 18 Dec 2021 09:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=b3zguXSzpEQw1s3u2S9ek41f1K3nBj4WrTOhRUyg2p0=; b=jlvd9bqd4/sQwepd2IY9jVcbuA86UUO4fVak2LGOozO9Qe36R2cfrzDoehoPAjgLgO +j3FNzyVA5dRT4ktRBQiHHuSsustD7FCAIQQyiaHtTU79B4DTVtyF1qR3fdxQSGTfHAq NnZJa0kEmyeoQGLZkT0C4F36ec9GBoT+ktgcagpbgKXrr6c/Rhs8La4m4xOk/bXsbkq4 zVQnekoVMHYTSqE/nydK1nmP0V/MPlhctcamkJpPr0etxAoOVBL7FctTG+mlUrw+5fmo XgehzvM/c3cfTjOQeXhPNjQXKXR7k7XFa9Bw7G1OL/PMbo4efc8o1RMNoSkdAVsaZAR0 DoNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=b3zguXSzpEQw1s3u2S9ek41f1K3nBj4WrTOhRUyg2p0=; b=rsihaqMAfJqept32QU56UsHWfc5IxU0ud3a1hKBR9h+ldkTh0UXDep+qDG5/z2c2AK OI/rcjJzoRm6M43mCmTPGvvzp4L5YupSdO/LuQM6Paxfg/nq//GTAKRl8pdtxn93Dke7 1DOwxgfejPUg6SrQbHU0pQF88F1NTLKHZyMbsxVRH9z9dfVuKIrGDAFK8S/IiUKv780a y6yC+YhXbNHby9or0RgWOkxzbUdGm2cVDHB3PzT0spOj6FDQwouIRqG/7uyekrVqQWdT gvACVxEMoy1CNYE/6T41l+D6tFsdKZmGA+zwe0757wp7mE9/X8OehkYBkYuWhvXAMLWm iRag== X-Gm-Message-State: AOAM531W+uOehZmYoX8vBRxCuZ7/PP41yq7TfgjM5fKASuFJk+jIxFqx hwOsW4z4dIqAVJg3Z9au9hA= X-Google-Smtp-Source: ABdhPJyzuNxdYmll91wM6MBofpGwoFioaV4uChXuPyXaquQ3u8qB18kuNNke1W+IUPNd04JoZEhZ+g== X-Received: by 2002:a5d:6d88:: with SMTP id l8mr7037999wrs.270.1639847459544; Sat, 18 Dec 2021 09:10:59 -0800 (PST) Original-Received: from [192.168.178.20] (b2b-109-90-125-150.unitymedia.biz. [109.90.125.150]) by smtp.gmail.com with ESMTPSA id j85sm17588105wmj.3.2021.12.18.09.10.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Dec 2021 09:10:59 -0800 (PST) Content-Language: en-US In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::433 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=taylan.kammer@gmail.com; helo=mail-wr1-x433.google.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.716, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17872 Archived-At: On 17.12.2021 18:05, Thompson, David wrote: > Hi Jacob, > > On Thu, Dec 16, 2021 at 8:43 PM Jacob Hrbek wrote: >> >> I am used to working with common lisp where i can write code that is >> "implementation independent" meaning that following a specific coding >> style makes it compatible across multiple interpretators/compilers >> (sbcl, LispWorks, etc..) >> >> Is there a way to do the same on GNU Guile? Like writing a code that can >> be interpreted by implementations that are following the IEEE 1178-2008 >> or R7RS standard? > > I think the shortest and easiest answer to this question, in practice, is "no." > > While it is possible to write programs that conform to a specific > Scheme standard and thus work on all implementations supporting that > standard, there are few real world programs that can be written within > such limits. And coming from a Common Lisp background, where the > standard is huge, you'll likely find the available Scheme standards > lacking. > > I prefer to think of each Scheme implementation as its own distinct > language, because in many ways they are. I don't write Scheme > programs, I write Guile programs. I want to use Guile's delimited > continuations, foreign function interface, compiler tower, etc. so > limiting myself to standard Scheme would be a real bummer. > > - Dave > > "This here ain't no Common Lisp." > - Thaddeus Scheme, Sr. (1975) > Well said. I have minor disagreements. The RnRS have some severe limitations. In all RnRS: - No TCP/IP - No POSIX or Win32 - No threads In R7RS-small, and R5RS and earlier: - No hash tables - No sub-typing In R5RS and earlier: - No user-defined disjoint types at all - No exceptions or other meaningful error handling There's SRFIs for all of these, but many aren't widely supported. I guess SRFI 9 and SRFI 69 are supported widely enough to get good cross-platform support for user-defined types and hash tables, but no sub-typing. You're not going to get good cross-implementation support for networking, threads, or OS interfaces at all. Still, some interesting libraries or applications can be written in a cross-platform manner. My scheme-bytestructures library supports R6RS, R7RS, and also Guile-specific sub-libraries: https://github.com/TaylanUB/scheme-bytestructures How "real-world" it is without the Guile extensions might be up for debate though. :-) Libraries that only deal with string processing, like parsers for data formats such as JSON, XML, YAML, Markdown, etc. shouldn't be too difficult to implement in pure RnRS I think, and would count towards "real-world" I guess. My opinionated summary would be: If the application or library you're intending to write can be written in a cross-implementation manner, go for it so that the whole Scheme community can benefit from it. But if that seems like an unpleasant challenge, it's perfectly understandable that one wouldn't care about going that way. And for any sufficiently complex task, you will have to commit to a particular implementation anyway. -- Taylan