guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EXT] Can guile be implementation independent?


From: Taylan Kammer
Subject: Re: [EXT] Can guile be implementation independent?
Date: Sat, 18 Dec 2021 18:10:58 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]