unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Taylan Kammer <taylan.kammer@gmail.com>
To: "Thompson, David" <dthompson2@worcester.edu>,
	Jacob Hrbek <kreyren@rixotstudio.cz>
Cc: Guile User <guile-user@gnu.org>
Subject: Re: [EXT] Can guile be implementation independent?
Date: Sat, 18 Dec 2021 18:10:58 +0100	[thread overview]
Message-ID: <91c20674-e4e7-ae31-c33f-072c566312bf@gmail.com> (raw)
In-Reply-To: <CAJ=RwfYGrDeGQc1gfR_4VQ7TPnOcK8pYDdSqqPkEGdFktmRzxw@mail.gmail.com>

On 17.12.2021 18:05, Thompson, David wrote:
> Hi Jacob,
> 
> On Thu, Dec 16, 2021 at 8:43 PM Jacob Hrbek <kreyren@rixotstudio.cz> 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



  reply	other threads:[~2021-12-18 17:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  1:42 Can guile be implementation independent? Jacob Hrbek
2021-12-17  2:53 ` Nala Ginrut
2021-12-17  3:01   ` Jacob Hrbek
2021-12-17  3:27     ` Nala Ginrut
2021-12-17 13:32     ` silas poulson
2021-12-17 16:26       ` Dr. Arne Babenhauserheide
2021-12-18 15:30         ` Tim Van den Langenbergh
2021-12-18 18:47           ` Dr. Arne Babenhauserheide
2021-12-17 16:19 ` Maxime Devos
2021-12-17 17:05 ` [EXT] " Thompson, David
2021-12-18 17:10   ` Taylan Kammer [this message]
2021-12-19 20:03     ` Keith Wright
2021-12-19 20:57       ` Taylan Kammer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91c20674-e4e7-ae31-c33f-072c566312bf@gmail.com \
    --to=taylan.kammer@gmail.com \
    --cc=dthompson2@worcester.edu \
    --cc=guile-user@gnu.org \
    --cc=kreyren@rixotstudio.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).