Re: Can guile be implementation independent?

2021-12-18 Thread Tim Van den Langenbergh
On 17/12/2021 17:26, Dr. Arne Babenhauserheide wrote:
> The short of this: Call guile with --r7rs and the main incompatibility
> is missing reading of circular data structures with datum labels.
> 
> Best wishes,
> Arne

Well, Guile is also missing digit-value, which is easily mocked-up by using 
char->integer and subtracting 48 from it.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [EXT] Can guile be implementation independent?

2021-12-18 Thread Taylan Kammer
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



Re: Can guile be implementation independent?

2021-12-18 Thread Dr. Arne Babenhauserheide

Tim Van den Langenbergh  writes:
> On 17/12/2021 17:26, Dr. Arne Babenhauserheide wrote:
>> The short of this: Call guile with --r7rs and the main incompatibility
>> is missing reading of circular data structures with datum labels.
>
> Well, Guile is also missing digit-value, which is easily mocked-up by using 
> char->integer and subtracting 48 from it.

Are there any more missing parts?

I think for those that are easy to mock, we just should fix the 
incompatibilities.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature


Guile-GDBM 1.1.1 available

2021-12-18 Thread Thien-Thi Nguyen

release notes:

  Although the README mentions GNU dbm 1.19, this is really only a
  maintenance release, w/o any new features post 1.10.  We'll get to
  that good stuff sooner or later.

  OTOH, things work fine w/ Guile 2.2.7, as advertized.

README excerpt:

  Guile-GDBM is a Guile module that provides Scheme bindings to the
  GNU dbm library.  It was originally written by Martin Grabmüller
  and is now released under the GNU General Public License (GPL)
  version 3.

NEWS for 1.1.1 (2021-12-19):

  - portability tweak

Previous versions of Guile-GDBM were developed on a 32-bit host,
where ‘sizeof (size_t)’ and ‘sizeof (int)’ were interchangeable
(identical value of 4).  Although the code as written compiled
fine on 64-bit hosts, where those two expressions can have
different values, it caused runtime errors, notably in the
‘gdbm-getopt’ procedure.  This is now fixed.

  - bootstrap/maintenance tools

upgraded:

 Guile-BAUX 20211208.0839.a5245e7
 GNU gnulib 2021-12-10 21:54:54
 GNU Autoconf 2.71
 GNU Automake 1.16.5
 GNU texinfo 6.8

as before:

 (none)

source code in dir:

  https://www.gnuvola.org/software/guile-gdbm/

-- 
Thien-Thi Nguyen ---
 (defun responsep (query)   ; (2021) Software Libero
   (pcase (context query)   ;   = Dissenso Etico
 (`(technical ,ml) (correctp ml))
 ...))  748E A0E8 1CB8 A748 9BFA
--- 6CE4 6703 2224 4C80 7502



signature.asc
Description: PGP signature