Re: A R7RS library name part bug?

[Taylan Kammer]

On 13.11.2023 15:21, 無無 wrote:
> I have read that in R7RS a library name is defined as:
> 
>  -> ( + )
>  ->  | 
>  -> 
>  -> 
>  -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
> 
> That means that a valid library name would be something like (a b 1),
> where "1" is a valid library name part, but the following code
> disagrees.  running `guile --r7rs -L . a/good-main.scm` works while
> `guile --r7rs -L . a/bad-main.scm` fails.
> 
> [...]
> 

This is unfortunately a known limitation in Guile's R7RS support.

IIRC, integers in library names only works for (srfi N) which is
internally transformed to (srfi srfi-N).

-- 
Taylan

Re: Question: planning support for SRFI-125, SRFI-133?

[Taylan Kammer]

On 30.10.2023 11:24, Ramin Honary wrote:
> Hello Guile developers:
> 
> I have come to realize that there are several finalized SRFIs
> published by John Cowan and others, for example, SRFI-133 (vector
> library), SRFI-125 (intermediate hash tables), SRFI-126 (R6RS-based
> hash tables) that were intended to replace older SRFIs (for example
> SRFI-43, and SRFI-69) when R7RS-large is supposed to be ratified.
> 
> Looking at the functionality already available in Guile, it seems like
> these newer SRFIs could very easily be supported since the
> functionality is already fully implemented and could be re-exported as
> modules in the (srfi srfi-*) modules. And incidentally, GNU/MIT Scheme
> does provide support for SRFI-125 and SRFI-133 already.
> 
> So I am wondering why this hasn't been done in Guile yet? Is it a lack
> of time and human resources? Or is it somehow against the Guile
> philosophy to try to implement these newer SRFIs? Or maybe you want to
> wait until R7RS-large is ratified?
> 
> If it is a lack of resources, I might like to try implementing these
> SRFIs in Guile and submit a patch.
> 
> Thanks for your time and hard work implementing Guile!
> 
> -- Ramin Honary
> 

Note that SRFI 126 is probably *not* going to be part of R7RS-large.

(As much as it saddens me, since I'm the author.)

That being said, the reference implementation is written specifically
for Guile, and it offers some things 125 doesn't.  If some people like
126 simply as a powerful hash table library, or if they like the R6RS
hashtables API but wish it had a few more bells and whistles, then I
guess it wouldn't hurt to include SRFI 126 in Guile.  (It strictly
extends the R6RS API.)

https://github.com/scheme-requests-for-implementation/srfi-126

-- 
Taylan

Re: Replacing Guile test-suite with SRFI-64?

[Taylan Kammer]

On 26.09.2023 10:17, Taylan Kammer wrote:
> 
> https://github.com/TaylanUB/scheme-srfis
> 
> (I've not yet had time to migrate away from GitHub. Sorry.)
> 

Fixed:

https://codeberg.org/taylan/scheme-srfis

-- 
Taylan

Re: Replacing Guile test-suite with SRFI-64?

[Taylan Kammer]

Re. issues with the standard SRFI 64 implementation, let me point out
that I've written an alternative implementation with cleaner code and
behavior of the default test runner; it's part of this (currently
dormant) project:

https://github.com/TaylanUB/scheme-srfis

(I've not yet had time to migrate away from GitHub. Sorry.)

If I remember correctly, it also runs slightly faster.

To use with Guile, just add the root dir of the repo to the load path
and import (srfi srfi-64) as usual; it should override the default one
if the Guile load path is set up correctly.

To make sure you're not overriding other SRFIs offered by Guile,
remove all but the following files:

srfi/64/*
srfi/64.sld
srfi/srfi-64.sld

Or copy just those into a different directory and add that to your
Guile load path.  You could also rename 'srfi-64.sld' so as not to
override the default SRFI 64, and I think it should still work
under the changed name so long as srfi/64/* aren't renamed.

-- 
Taylan

Re: case source code

[Taylan Kammer]

On 12.09.2022 09:42, Damien Mattei wrote:
> 
> Hello,
> i can not find in the scheme community a definition of 'case in term of macro 
> as for when, unless,while,do... does anyone have it?
> thanks,
> Damien

The RnRS often contain such definitions.  The following is taken from 
R7RS-small:

(define-syntax case
  (syntax-rules (else =>)
((case (key ...) clauses ...)
 (let ((atom-key (key ...)))
   (case atom-key clauses ...)))
((case key (else => result))
 (result key))
((case key
   (else result1 result2 ...))
 (begin result1 result2 ...))
((case key
   ((atoms ...) result1 result2 ...))
 (if (memv key ’(atoms ...))
 (begin result1 result2 ...)))
((case key
   ((atoms ...) => result))
 (if (memv key ’(atoms ...))
 (result key)))
((case key
   ((atoms ...) => result)
   clause clauses ...)
 (if (memv key ’(atoms ...))
 (result key)
 (case key clause clauses ...)))
((case key
   ((atoms ...) result1 result2 ...)
   clause clauses ...)
 (if (memv key ’(atoms ...))
 (begin result1 result2 ...)
 (case key clause clauses ...

-- 
Taylan

Re: string is read-only

[Taylan Kammer]

On 03.08.2022 11:50, Jean Abou Samra wrote:
> 
> 
>> Le 3 août 2022 à 11:49, Taylan Kammer  a écrit :
>>
>> On 03.08.2022 11:12, Damien Mattei wrote:
>>> GNU Guile 3.0.1
>>> Copyright (C) 1995-2020 Free Software Foundation, Inc.
>>>
>>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>>> This program is free software, and you are welcome to redistribute it
>>> under certain conditions; type `,show c' for details.
>>>
>>> Enter `,help' for help.
>>> scheme@(guile-user)> (define str2 "hello")
>>> scheme@(guile-user)> (string-set! str2 4 #\a)
>>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>>> string is read-only: "hello"
>>>
>>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>>> scheme@(guile-user) [1]> ,q
>>> scheme@(guile-user)> (string? str2)
>>> #t
>>>
>>> is it a bug in Guile ? :-O
>>>
>>> i can only find reference to deprecated read-only string in old doc:
>>> https://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Read-Only-Strings.html#Read%20Only%20Strings
>>>  
>>> <https://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Read-Only-Strings.html#Read%20Only%20Strings>
>>>
>>> Regards,
>>>
>>> Damien
>>
>> String literals are constants, and it's intentional.
>>
>> I'm not sure if it's mentioned anywhere in the manual.
>>
>> If you want to get a mutable string from a literal, you can use:
>>
>>  (define str (string-copy "foobar"))
>>
>> -- 
>> Taylan
> 
> This is standard. See the intro of
> 
> https://srfi.schemers.org/srfi-135/ <https://srfi.schemers.org/srfi-135/>
> 
>>

This SRFI defines a new data type, which is not really relevant here.

As far as I know, Guile doesn't support it yet anyway.

-- 
Taylan

Re: string is read-only

[Taylan Kammer]

On 03.08.2022 11:12, Damien Mattei wrote:
> GNU Guile 3.0.1
> Copyright (C) 1995-2020 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guile-user)> (define str2 "hello")
> scheme@(guile-user)> (string-set! str2 4 #\a)
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> string is read-only: "hello"
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> ,q
> scheme@(guile-user)> (string? str2)
> #t
> 
> is it a bug in Guile ? :-O
> 
> i can only find reference to deprecated read-only string in old doc:
> https://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Read-Only-Strings.html#Read%20Only%20Strings
>  
> 
> 
> Regards,
> 
> Damien

String literals are constants, and it's intentional.

I'm not sure if it's mentioned anywhere in the manual.

If you want to get a mutable string from a literal, you can use:

  (define str (string-copy "foobar"))

-- 
Taylan

Re: Maintenance and future of Guile

[Taylan Kammer]

On 17.12.2021 16:48, Olivier Dion wrote:
> On Fri, 17 Dec 2021, Ludovic Courtès  wrote:
>> Hi,
>>
>> Olivier Dion  skribis:
>>
>>> I would also like to contribute in some meaningful way.  In what way
>>> someone with none wizard knowledge of Scheme can contribute the most to the
>>> project?
>>
>> Triage of bugs and patches is always welcome I guess, and communicating
>> what needs to be applied/addressed first to whoever can actually commit
>> it.  That’s one possible way to help.
> 
> Where can this be done?  I know that Guix is using debbugs, but do Guile
> does the same or is it all tracked on Savannah?
> 
> Also, any way to help on the C side?
> 

Guile also uses Debbugs:

https://bugs.gnu.org/guile

-- 
Taylan

Re: Maintenance and future of Guile

[Taylan Kammer]

On 15.12.2021 11:20, Ludovic Courtès wrote:
> 
> While Andy focuses on major improvements to the compiler and VM with a
> long-term vision, I think it would be great to also have people on the
> maintainer team focusing on more day-to-day operations: incremental
> improvements, bug fixes, etc.  I think we’re lucky that there’ve been a
> number of talented contributors chiming in over the last couple of
> years; let’s take advantage of this, at last!
> 

Sounds like a good idea.  Andy obviously does amazing work and I'm sure
I'm not the only one who's grateful for your contributions as well :-)
but having even some small patches for obvious bugfixes sit around for
months is a bit disheartening.

I won't apply because I don't feel like I'd be up to the task on a
technical level (my C skills in particular suck, my knowledge of Guile
internals is also quite limited) and I have way too many unfinished
projects plus a somewhat stressful 40h/week job...

But I would definitely like to contribute some small patches every now
and then if I know I'll get feedback / have them applied.

-- 
Taylan

Re: Implementing Guile with a Windows port

[Taylan Kammer]

On 09.10.2021 14:01, Andrew Goh wrote:
> Hello everybody,
> 
> I was wondering if the GNU Guile development team had thought of implementing 
> a GNU Guile version for Microsoft Windows operating systems (Win 10, 11), to 
> be used as a plug-in on JetBrains Intellij IDEA Ultimate, Community IDE and 
> the VS Code IDE.
> 
> Regards,
> 
> 
> --- Andrew Goh
> 

Hi Andrew,

I can't speak for the developers, but as far as I can tell, there isn't the
right combination of willingness and resources to support a native port of
GNU Guile for MS Windows.

As far as I know, there's a MinGW port, but if I'm not mistaken it's partly
neglected and not as feature-rich as the "normal" GNU/Linux version.

-- 
Taylan

Re: new function

[Taylan Kammer]

Responding to myself:

On 23.09.2021 22:27, Taylan Kammer wrote:

> I can't seem to find syntax-local-binding in Guile 2.2 or 3.0.  Did you
> have to import some special module, or are you using another version?

Worked when I imported (system syntax internal).

> Either way, I suspect that the following will not work with your macro:
> 
>   (let ()
> (let ()
>   (<$ x 1))
> (display x)
> (newline))

Indeed it doesn't work, though for a different reason:

  While compiling expression:
  Syntax error:
  unknown file:43:8: body should end with an expression in form (let () (<$ x 
1))

That's because indeed the inner let expands into:

  (let ()
(define x 1))

And there has to be at least one expression after the define.  So I tried:

  (let ()
(let ()
  (<$ x 1)
  (newline))
(display x)
(newline))

And as I expected, it says 'x' is unbound:

  ;;; :44:45: warning: possibly unbound variable `x'
  <$ : global scope : x
  
  ice-9/boot-9.scm:1685:16: In procedure raise-exception:
  Unbound variable: x

The only way it will work is if you never use nested scopes, but that will
lead to very strange Scheme code, and there will probably be many cases
where you accidentally use a nested scope without immediately noticing it.

Note also that definitions aren't allowed everywhere.  Consider this:

  (let ()
(if 'whatever
(<$ x 1)
(<$ x 2))
(display x)
(newline))

It leads to:

  While compiling expression:
  Syntax error:
  unknown file:49:17: definition in expression context, where definitions are 
not allowed, in form (define x 1)

Because the arms of 'if' aren't allowed to be definitions.

-- 
Taylan

Re: new function

[Taylan Kammer]

On 23.09.2021 19:27, Damien Mattei wrote:
> yes i know parsing the whole code is the only portable solution, but it is 
> slow,even on a few dozen of lines the slowing is visible ,so i can even think 
> of that on one thousand lines...
> 
> I finally succeed in Guile with simple piece of code to make my example run 
> with a single assignment operator <-  , here i define for variable the 
> assignment operator <$ , <- is working with arrays too:
> 
> *Preview:*
> 
> (define-syntax <$
>   
>   (lambda (s)
> 
> (syntax-case s ()
>   
>   ((_ var value)
>
>(case (syntax-local-binding #'var)
>
>  ((lexical) #'(begin
>   (display "<$ : lexical scope : ")
>   (display (quote var))
>   (newline)
>   (set! var value)))
>
>((displaced-lexical) #'(begin
> (display "<$ : displaced-lexical scope : ")
> (display (quote var))
> (newline)
> (set! var value)))
>
>  ((global) #'(begin
>  (display "<$ : global scope : ")
>  (display (quote var))
>  (newline)
>  (define var value)))
>
>  (else #'(begin
>  (display "<$ : unknow variable scope :")
>  (display (quote var))
>  (error "<$ : unknow variable scope : "
> 

I can't seem to find syntax-local-binding in Guile 2.2 or 3.0.  Did you
have to import some special module, or are you using another version?

Either way, I suspect that the following will not work with your macro:

  (let ()
(let ()
  (<$ x 1))
(display x)
(newline))

If I understand correctly, it will expand to:

  (let ()
(let ()
  (define x 1))
(display x)
(newline))

And that won't work because 'x' is only defined in the inner 'let'.

This is where we see the crucial difference between Scheme and Python:
in Python there is nothing similar to an inner 'let'.  There is only
one function-level scope.  In Scheme, there can be as many nested
scopes as you want, and an inner scope can't affect an outer one.

-- 
Taylan

Re: new function

[Taylan Kammer]

On 22.09.2021 23:52, William ML Leslie wrote:
> On Thu, 23 Sep 2021, 4:51 am Taylan Kammer,  <mailto:taylan.kam...@gmail.com>> wrote:
> 
> On 22.09.2021 11:53, Damien Mattei wrote:
> > i already do it this way for internal defines ,using a recursive macro 
> that build a list of variable using an accumulator. It can works but macro 
> expansion seems slow, it was not immediate at compilation on a little example 
> (oh nothing more that 2 seconds) but i'm not sure it is easily maintainable, 
> it is at the limit what macro can do i think ,for speed reasons. In fact i 
> can not really understand in Guile as it is based on C and compiled when 
> macro expansion happens,what is the time cost... so for all those ,perhaps 
> not objective reason ,i prefer to avoid.
> 
> I don't think there's any other way to achieve what you want, especially
> using portable Scheme code.  The lexical scoping semantics of Scheme are
> a very fundamental part of the language, and cannot be worked around in
> portable Scheme code without using a macro that rewrites whole bodies of
> lambda expressions.
> 
> Even using implementation-specific hacks, you won't get very far.  Any
> compiled Scheme implementation, and even most interpreted ones, won't
> allow you to modify an outer scope's set of variable definitions from
> within an inner scope.
> 
> So if you really want to have Python's scoping semantics in Scheme, you
> will probably have to write a complex 'def' macro that walks through the
> body and "hoists" variable definitions to the outermost scope.
> 
> 
> Python is lexically scoped, and the assignment here is supposed to be local.

Well, yes and no.  It implements variable hoisting, meaning all previously
unset variables that are set within a function are implicitly declared at the
beginning of the function.  It doesn't have sub-scopes in function bodies.

-- 
Taylan

Re: new function

[Taylan Kammer]

On 22.09.2021 11:53, Damien Mattei wrote:
> i already do it this way for internal defines ,using a recursive macro that 
> build a list of variable using an accumulator. It can works but macro 
> expansion seems slow, it was not immediate at compilation on a little example 
> (oh nothing more that 2 seconds) but i'm not sure it is easily maintainable, 
> it is at the limit what macro can do i think ,for speed reasons. In fact i 
> can not really understand in Guile as it is based on C and compiled when 
> macro expansion happens,what is the time cost... so for all those ,perhaps 
> not objective reason ,i prefer to avoid.

I don't think there's any other way to achieve what you want, especially
using portable Scheme code.  The lexical scoping semantics of Scheme are
a very fundamental part of the language, and cannot be worked around in
portable Scheme code without using a macro that rewrites whole bodies of
lambda expressions.

Even using implementation-specific hacks, you won't get very far.  Any
compiled Scheme implementation, and even most interpreted ones, won't
allow you to modify an outer scope's set of variable definitions from
within an inner scope.

So if you really want to have Python's scoping semantics in Scheme, you
will probably have to write a complex 'def' macro that walks through the
body and "hoists" variable definitions to the outermost scope.

If you're targeting R6RS implementations, you can use syntax-case to
write such a macro, but it won't be easy.

If you're targeting R5RS or R7RS-small implementations, you will have to
rely on syntax-rules, which will probably be extremely difficult for this
kind of complex macro.

Personally I don't even know how I would approach the problem using the
more capable syntax-case, let alone pure syntax-rules.

-- 
Taylan

Re: new function

[Taylan Kammer]

On 19.09.2021 09:54, Damien Mattei wrote:
> hello,
> i'm developing an extension to Scheme
> and i need a procedure or macro that define a variable only if it is not bind 
> and if it is just set! it.
> 
> I can not do it in Guile or any Scheme,and i'm desperately searching a way to 
> do that. I finally conclude that it can be done only by adding it in the 
> language.
> 
> Can someone include a such function in Guile next release?
> i know guile have a predicate defined? to test binfing of a vairable but 
> writing a macro with it is not possible because define can be used in an 
> expression context.
> 
> Thank in advance for any help
> Damien

What is the utility of such a function?  Since Scheme is lexically scoped,
it's generally obvious whether a variable has already been defined or not,
rendering such an operation useless.

If you're constructing code from outside input so that you don't know
whether a provided variable name represents a variable that's already been
defined or not, then you could use the module reflection API:

https://www.gnu.org/software/guile/manual/html_node/Module-System-Reflection.html

Sounds like 'module-define!' does exactly what you ask for.  I wonder what
exactly your use-case is though.  Chances are that your use-case is best
served with a simple data structure like a hash table...

-- 
Taylan

Re: Request to add *-resize! functions for contiguous mutable data structures.

[Taylan Kammer]

On 07.08.2021 23:19, to...@tuxteam.de wrote:
> On Sat, Aug 07, 2021 at 12:31:09PM +0200, Taylan Kammer wrote:
>> One consideration is how this should behave in the case of
>> bytevectors that were created from an FFI pointer [...]
> 
> Hm. I don't understand. Realloc /may/ return a different pointer
> from the one it receives, for example if there isn't enough
> room "beyond" the currently allocated. It will copy over the
> contents, but if someone is holding a pointer to the old area
> (as I understand you, this will be the case with an FFI pointer),
> this isn't going to end well...
> 
> And then there is the constraint that the (original) pointer
> passed to realloc /must/ be one returned by one of the malloc
> family (how would the allocator know the original size otherwise?)

Bytevectors created from FFI pointers definitely have to be specially
handled so as not to call realloc() on the original pointer.  There are
two ways bytevector-resize! could work in this case:

1. If the requested size is less than or equal to the current size,
   merely change the size information of the bytevector.  Otherwise,
   return an entirely new bytevector that doesn't point to the original
   location anymore.  This is the "safe" variant.

2. Always just change the size information of the bytevector.  This is
   unsafe because providing a larger size might mean that the bytevector
   starts allowing access to unallocated memory.  But it's not any less
   safe than the original pointer->bytevector operation where you already
   provided the size information yourself.

The second behavior would help with this issue:

https://github.com/TaylanUB/scheme-bytestructures/issues/41

-- 
Taylan

Re: Request to add *-resize! functions for contiguous mutable data structures.

[Taylan Kammer]

On 07.08.2021 13:09, Maxime Devos wrote:

> 
> A problem is that this prevents optimisations and can currently
> introduce bugs in concurrent code.  Consider the following code:
> 
> [... snip ... ]
> 
> Greetings,
> Maxime.
> 

Couldn't we just state that resizing a vector/bytevector is a
thread-unsafe operation?

-- 
Taylan

Re: Request to add *-resize! functions for contiguous mutable data structures.

[Taylan Kammer]

On 06.08.2021 16:33, Vijay Marupudi wrote:
> Hello!
> 
> I was curious if Guile would be willing to provide a series of
> new procedures for resizing contiguous memory regions.
> 
> (bytevector-resize!  new-size [fill])
> (vector-resize!  new-size [fill])
> 
> The [fill] parameter could be used if the new-size is bigger than
> the current size.
> 
> This would make writing imperative code easier and more
> performant. I acknowledge that it is not idiomatic Scheme to use
> mutable data structures, however this is useful to me for
> dealing with large amounts of text data, in which I need random
> access and flexible data storage. It would allow me to move off
> my custom C extension vector and allow me to use other
> vector-* functions.
> 
> Ideally, this would use libc's `realloc` to make the resize
> quick, so that it can avoid data copying whenever possible.
> 
> Regards
> 
> Vijay Marupudi
> PhD Student in Human Centered-Computing
> Georgia Tech
> 
Sounds like a good idea to me.  I didn't know realloc() was a
thing in C (I don't write much C) and I suppose it's not possible
to implement equivalent functionality with equivalent performance
purely in Scheme.

I'm on vacation for the next three weeks and will try to write a
patch to implement this if no one beats me to it. :-)

One consideration is how this should behave in the case of
bytevectors that were created from an FFI pointer.  In the FFI,
you provide a pointer and specify how long the bytevector should
be, which means it's a memory-unsafe operation.  I think it would
be ideal to offer a way of forcing an in-place resize, basically
overriding the formerly provided size value.  That means it's
also memory-unsafe, but in some cases that's what you want.

-- 
Taylan

Re: [PATCHES] Use a better SRFI-64 implementation.

[Taylan Kammer]

On 11.05.2021 21:14, Taylan Kammer wrote:
> 
> And here's another minimally changed one.
> 

Aaaand another of course.   on IRC notified me that
there's a way in which both the old and new implementation don't
conform to the standard: they're supposed to uninstall the default
test runner that they install automatically, after tests ended.

I'm not sure if there's any real benefit to actually doing that,
but I've followed 's suggestion and implemented it.

So here's yet another updated patch-set!  You won't be getting
another one for at least 8 hours as I'm going to sleep now. ;-)


- Taylan
From 6746edaf52066c147d85548f439a37beb0c0344c Mon Sep 17 00:00:00 2001
From: Taylan Kammer 
Date: Mon, 10 May 2021 15:23:17 +0200
Subject: [PATCH 1/2] Use a different SRFI-64 implementation.

* module/srfi/srfi-64.scm: Add imports and other boilerplate for new
  implementation.
* module/srfi/srfi-64/execution.body.scm: New file.
* module/srfi/srfi-64/source-info.body.scm: New file.
* module/srfi/srfi-64/test-runner-simple.body.scm: New file.
* module/srfi/srfi-64/test-runner.body.scm: New file.
* module/srfi/srfi-64/testing.scm: Deleted.
* module/Makefile.am (srfi-64.go, NOCOMP_SOURCES): Change accordingly.
---
 module/Makefile.am|   11 +-
 module/srfi/srfi-64.scm   |   17 +-
 module/srfi/srfi-64/execution.body.scm|  431 +++
 module/srfi/srfi-64/source-info.body.scm  |   88 ++
 .../srfi/srfi-64/test-runner-simple.body.scm  |  173 +++
 module/srfi/srfi-64/test-runner.body.scm  |  168 +++
 module/srfi/srfi-64/testing.scm   | 1044 -
 7 files changed, 882 insertions(+), 1050 deletions(-)
 create mode 100644 module/srfi/srfi-64/execution.body.scm
 create mode 100644 module/srfi/srfi-64/source-info.body.scm
 create mode 100644 module/srfi/srfi-64/test-runner-simple.body.scm
 create mode 100644 module/srfi/srfi-64/test-runner.body.scm
 delete mode 100644 module/srfi/srfi-64/testing.scm

diff --git a/module/Makefile.am b/module/Makefile.am
index 41b77095b..e1c5267e7 100644
--- a/module/Makefile.am
+++ b/module/Makefile.am
@@ -29,7 +29,11 @@ $(VM_TARGETS): $(top_builddir)/libguile/vm-operations.h
 
 ice-9/boot-9.go: ice-9/boot-9.scm ice-9/quasisyntax.scm 
ice-9/r6rs-libraries.scm ice-9/r7rs-libraries.scm ice-9/read.scm
 ice-9/match.go: ice-9/match.scm ice-9/match.upstream.scm
-srfi/srfi-64.go: srfi/srfi-64.scm srfi/srfi-64/testing.scm
+srfi/srfi-64.go: srfi/srfi-64.scm  \
+  srfi/srfi-64/execution.body.scm  \
+  srfi/srfi-64/source-info.body.scm\
+  srfi/srfi-64/test-runner-simple.body.scm \
+  srfi/srfi-64/test-runner.body.scm
 $(nobase_ccache_DATA): ../bootstrap/ice-9/eval.go
 
 # Keep this rule in sync with that in `am/guilec'.
@@ -403,7 +407,10 @@ NOCOMP_SOURCES =   \
   ice-9/r7rs-libraries.scm \
   ice-9/quasisyntax.scm\
   srfi/srfi-42/ec.scm  \
-  srfi/srfi-64/testing.scm \
+  srfi/srfi-64/execution.body.scm  \
+  srfi/srfi-64/source-info.body.scm\
+  srfi/srfi-64/test-runner-simple.body.scm \
+  srfi/srfi-64/test-runner.body.scm\
   srfi/srfi-67/compare.scm \
   system/base/lalr.upstream.scm\
   system/repl/describe.scm \
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 925726f5c..e6c6ce80a 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -24,9 +24,9 @@
test-match-nth test-match-all test-match-any test-match-name
test-skip test-expect-fail test-read-eval-string
test-runner-group-path test-group test-group-with-cleanup
+   test-exit
test-result-ref test-result-set! test-result-clear test-result-remove
test-result-kind test-passed?
-   test-log-to-file
test-runner? test-runner-reset test-runner-null
test-runner-simple test-runner-current test-runner-factory test-runner-get
test-runner-create test-runner-test-name
@@ -48,9 +48,18 @@
test-on-group-begin-simple test-on-group-end-simple
test-on-bad-count-simple test-on-bad-end-name-simple
test-on-final-simple test-on-test-end-simple
-   test-on-final-simple)
-  #:declarative? #f) ; #f needed for test-log-to-file
+   test-on-final-simple))
 
 (cond-expand-provide (current-module) '(srfi-64))
 
-(include-from-path "srfi/srfi-64/testing.scm")
+(import
+ (only (rnrs exceptions) guard)
+ (srfi srfi-1)
+ (srfi srfi-9)
+ (srfi srfi-11)
+ (srfi srfi-35))
+
+(include-from-path "srfi/srfi-64/source-info.body.scm")
+(include-from-path "srfi/srfi-64/test-runner.body.scm")
+(include-from-path "srfi/srfi-64/test-runner-simple.body.scm")
+(include-from-path "srfi/srfi-64/execution.body.scm")
diff --git a/module/srfi/srfi-64/execution.body.scm 
b/module/srfi/srfi-64/execution.body.scm
new file

Re: [PATCHES] Use a better SRFI-64 implementation.

[Taylan Kammer]

I was just skimming through the bug tracker and noticed:

https://bugs.gnu.org/21181

This bug doesn't exist in the proposed implementation.


- Taylan

Re: [PATCHES] Use a better SRFI-64 implementation.

[Taylan Kammer]

On 11.05.2021 13:32, Taylan Kammer wrote:
> 
> Here's a fixed patch-set.
> 

And here's another minimally changed one.  Sorry about the noise,
but you know how it goes: you publish something to the public, and
soon after notice another edge or two to polish. :-)

The module definition used to include "#:declarative #f" which I've now
removed as it wasn't necessary anymore.

Apparently it was necessary due to a non-standard global variable exposed
by the old implementation, called test-log-to-file.

It was possible to set this to #f to disable logging.  I'm not sure if
anyone ever used that, but with the new implementation you can achieve
the same by executing:

  (test-runner-current (test-runner-simple))

As an additional extension, you can now also provide a file name argument
to test-runner-simple to change the name of the log file.


- Taylan
From 55f2e4f3bcf9c1b26527f39b6725f44aa4ca635a Mon Sep 17 00:00:00 2001
From: Taylan Kammer 
Date: Mon, 10 May 2021 15:23:17 +0200
Subject: [PATCH 1/2] Use a different SRFI-64 implementation.

* module/srfi/srfi-64.scm: Add imports and other boilerplate for new
  implementation.
* module/srfi/srfi-64/execution.body.scm: New file.
* module/srfi/srfi-64/source-info.body.scm: New file.
* module/srfi/srfi-64/test-runner-simple.body.scm: New file.
* module/srfi/srfi-64/test-runner.body.scm: New file.
* module/srfi/srfi-64/testing.scm: Deleted.
* module/Makefile.am (srfi-64.go, NOCOMP_SOURCES): Change accordingly.
---
 module/Makefile.am|   11 +-
 module/srfi/srfi-64.scm   |   17 +-
 module/srfi/srfi-64/execution.body.scm|  424 +++
 module/srfi/srfi-64/source-info.body.scm  |   88 ++
 .../srfi/srfi-64/test-runner-simple.body.scm  |  173 +++
 module/srfi/srfi-64/test-runner.body.scm  |  165 +++
 module/srfi/srfi-64/testing.scm   | 1044 -
 7 files changed, 872 insertions(+), 1050 deletions(-)
 create mode 100644 module/srfi/srfi-64/execution.body.scm
 create mode 100644 module/srfi/srfi-64/source-info.body.scm
 create mode 100644 module/srfi/srfi-64/test-runner-simple.body.scm
 create mode 100644 module/srfi/srfi-64/test-runner.body.scm
 delete mode 100644 module/srfi/srfi-64/testing.scm

diff --git a/module/Makefile.am b/module/Makefile.am
index 41b77095b..e1c5267e7 100644
--- a/module/Makefile.am
+++ b/module/Makefile.am
@@ -29,7 +29,11 @@ $(VM_TARGETS): $(top_builddir)/libguile/vm-operations.h
 
 ice-9/boot-9.go: ice-9/boot-9.scm ice-9/quasisyntax.scm 
ice-9/r6rs-libraries.scm ice-9/r7rs-libraries.scm ice-9/read.scm
 ice-9/match.go: ice-9/match.scm ice-9/match.upstream.scm
-srfi/srfi-64.go: srfi/srfi-64.scm srfi/srfi-64/testing.scm
+srfi/srfi-64.go: srfi/srfi-64.scm  \
+  srfi/srfi-64/execution.body.scm  \
+  srfi/srfi-64/source-info.body.scm\
+  srfi/srfi-64/test-runner-simple.body.scm \
+  srfi/srfi-64/test-runner.body.scm
 $(nobase_ccache_DATA): ../bootstrap/ice-9/eval.go
 
 # Keep this rule in sync with that in `am/guilec'.
@@ -403,7 +407,10 @@ NOCOMP_SOURCES =   \
   ice-9/r7rs-libraries.scm \
   ice-9/quasisyntax.scm\
   srfi/srfi-42/ec.scm  \
-  srfi/srfi-64/testing.scm \
+  srfi/srfi-64/execution.body.scm  \
+  srfi/srfi-64/source-info.body.scm\
+  srfi/srfi-64/test-runner-simple.body.scm \
+  srfi/srfi-64/test-runner.body.scm\
   srfi/srfi-67/compare.scm \
   system/base/lalr.upstream.scm\
   system/repl/describe.scm \
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 925726f5c..e6c6ce80a 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -24,9 +24,9 @@
test-match-nth test-match-all test-match-any test-match-name
test-skip test-expect-fail test-read-eval-string
test-runner-group-path test-group test-group-with-cleanup
+   test-exit
test-result-ref test-result-set! test-result-clear test-result-remove
test-result-kind test-passed?
-   test-log-to-file
test-runner? test-runner-reset test-runner-null
test-runner-simple test-runner-current test-runner-factory test-runner-get
test-runner-create test-runner-test-name
@@ -48,9 +48,18 @@
test-on-group-begin-simple test-on-group-end-simple
test-on-bad-count-simple test-on-bad-end-name-simple
test-on-final-simple test-on-test-end-simple
-   test-on-final-simple)
-  #:declarative? #f) ; #f needed for test-log-to-file
+   test-on-final-simple))
 
 (cond-expand-provide (current-module) '(srfi-64))
 
-(include-from-path "srfi/srfi-64/testing.scm")
+(import
+ (only (rnrs exceptions) guard)
+ (srfi srfi-1)
+ (srfi srfi-9)
+ (srfi srfi-11)
+ (srfi srfi-35))
+
+(include-from-path "srfi/srfi-64/source-info.body.scm")
+(include-from-path "srfi/srfi-6

Re: [PATCHES] Use a better SRFI-64 implementation.

[Taylan Kammer]

On 10.05.2021 20:25, Taylan Kammer wrote:
> 
> - Improved expand-time performance for large test suites
> 

I thought it would be a good idea to quantify this, so I
benchmarked the compilation performance of a test suite
of 289 tests (that of the scheme-bytsetructures library),
and had the following results.

The first three compilations are with stock Guile 3.0.7,
and the latter three are with the patch that replaces
the SRFI-64 implementation applied to 3.0.7.


=== snip ===

$ touch run-tests.guile.scm && time /opt/guile-3.0.7/bin/guild compile -L . 
run-tests.guile.scm 
wrote `.../run-tests.guile.scm.go'

real0m9.465s
user0m12.787s
sys 0m2.179s

$ touch run-tests.guile.scm && time /opt/guile-3.0.7/bin/guild compile -L . 
run-tests.guile.scm 
wrote `.../run-tests.guile.scm.go'

real0m9.419s
user0m12.988s
sys 0m1.842s

$ touch run-tests.guile.scm && time /opt/guile-3.0.7/bin/guild compile -L . 
run-tests.guile.scm 
wrote `.../run-tests.guile.scm.go'

real0m9.387s
user0m13.132s
sys 0m1.656s

$ touch run-tests.guile.scm && time /opt/guile-master/bin/guild compile -L . 
run-tests.guile.scm 
wrote `.../run-tests.guile.scm.go'

real0m4.371s
user0m5.903s
sys 0m1.239s

$ touch run-tests.guile.scm && time /opt/guile-master/bin/guild compile -L . 
run-tests.guile.scm 
wrote `.../run-tests.guile.scm.go'

real0m4.556s
user0m6.836s
sys 0m1.502s

$ touch run-tests.guile.scm && time /opt/guile-master/bin/guild compile -L . 
run-tests.guile.scm 
wrote `.../run-tests.guile.scm.go'

real0m4.493s
user0m6.273s
sys 0m1.767s

=== /snip ===


As you can see, the time to compile the test suite is cut in half.


Here's the test suite used for the benchmark:

https://github.com/TaylanUB/scheme-bytestructures/blob/master/run-tests.body.scm

(That file is included from run-test.guile.scm.)


- Taylan

Re: [PATCHES] Use a better SRFI-64 implementation.

[Taylan Kammer]

While rebasing an old commit on master, I accidentally reinstated the
old implementation's .scm file in the first commit that's supposed to
delete that file.  (module/srfi/srfi-64/testing.scm)

Here's a fixed patch-set.


- Taylan
From be7f22e65878f5cb5aa7e94873e4b35ef4ae0032 Mon Sep 17 00:00:00 2001
From: Taylan Kammer 
Date: Mon, 10 May 2021 15:23:17 +0200
Subject: [PATCH 1/2] Use a different SRFI-64 implementation.

* module/srfi/srfi-64.scm: Add imports and other boilerplate for new
  implementation.
* module/srfi/srfi-64/execution.body.scm: New file.
* module/srfi/srfi-64/source-info.body.scm: New file.
* module/srfi/srfi-64/test-runner-simple.body.scm: New file.
* module/srfi/srfi-64/test-runner.body.scm: New file.
* module/srfi/srfi-64/testing.scm: Deleted.
* module/Makefile.am (srfi-64.go, NOCOMP_SOURCES): Change accordingly.
---
 module/Makefile.am|   11 +-
 module/srfi/srfi-64.scm   |   14 +-
 module/srfi/srfi-64/execution.body.scm|  426 +++
 module/srfi/srfi-64/source-info.body.scm  |   88 ++
 .../srfi/srfi-64/test-runner-simple.body.scm  |  168 +++
 module/srfi/srfi-64/test-runner.body.scm  |  165 +++
 module/srfi/srfi-64/testing.scm   | 1044 -
 7 files changed, 868 insertions(+), 1048 deletions(-)
 create mode 100644 module/srfi/srfi-64/execution.body.scm
 create mode 100644 module/srfi/srfi-64/source-info.body.scm
 create mode 100644 module/srfi/srfi-64/test-runner-simple.body.scm
 create mode 100644 module/srfi/srfi-64/test-runner.body.scm
 delete mode 100644 module/srfi/srfi-64/testing.scm

diff --git a/module/Makefile.am b/module/Makefile.am
index 41b77095b..e1c5267e7 100644
--- a/module/Makefile.am
+++ b/module/Makefile.am
@@ -29,7 +29,11 @@ $(VM_TARGETS): $(top_builddir)/libguile/vm-operations.h
 
 ice-9/boot-9.go: ice-9/boot-9.scm ice-9/quasisyntax.scm 
ice-9/r6rs-libraries.scm ice-9/r7rs-libraries.scm ice-9/read.scm
 ice-9/match.go: ice-9/match.scm ice-9/match.upstream.scm
-srfi/srfi-64.go: srfi/srfi-64.scm srfi/srfi-64/testing.scm
+srfi/srfi-64.go: srfi/srfi-64.scm  \
+  srfi/srfi-64/execution.body.scm  \
+  srfi/srfi-64/source-info.body.scm\
+  srfi/srfi-64/test-runner-simple.body.scm \
+  srfi/srfi-64/test-runner.body.scm
 $(nobase_ccache_DATA): ../bootstrap/ice-9/eval.go
 
 # Keep this rule in sync with that in `am/guilec'.
@@ -403,7 +407,10 @@ NOCOMP_SOURCES =   \
   ice-9/r7rs-libraries.scm \
   ice-9/quasisyntax.scm\
   srfi/srfi-42/ec.scm  \
-  srfi/srfi-64/testing.scm \
+  srfi/srfi-64/execution.body.scm  \
+  srfi/srfi-64/source-info.body.scm\
+  srfi/srfi-64/test-runner-simple.body.scm \
+  srfi/srfi-64/test-runner.body.scm\
   srfi/srfi-67/compare.scm \
   system/base/lalr.upstream.scm\
   system/repl/describe.scm \
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 925726f5c..a8cb08874 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -24,9 +24,9 @@
test-match-nth test-match-all test-match-any test-match-name
test-skip test-expect-fail test-read-eval-string
test-runner-group-path test-group test-group-with-cleanup
+   test-exit
test-result-ref test-result-set! test-result-clear test-result-remove
test-result-kind test-passed?
-   test-log-to-file
test-runner? test-runner-reset test-runner-null
test-runner-simple test-runner-current test-runner-factory test-runner-get
test-runner-create test-runner-test-name
@@ -53,4 +53,14 @@
 
 (cond-expand-provide (current-module) '(srfi-64))
 
-(include-from-path "srfi/srfi-64/testing.scm")
+(import
+ (only (rnrs exceptions) guard)
+ (srfi srfi-1)
+ (srfi srfi-9)
+ (srfi srfi-11)
+ (srfi srfi-35))
+
+(include-from-path "srfi/srfi-64/source-info.body.scm")
+(include-from-path "srfi/srfi-64/test-runner.body.scm")
+(include-from-path "srfi/srfi-64/test-runner-simple.body.scm")
+(include-from-path "srfi/srfi-64/execution.body.scm")
diff --git a/module/srfi/srfi-64/execution.body.scm 
b/module/srfi/srfi-64/execution.body.scm
new file mode 100644
index 0..717d74bfa
--- /dev/null
+++ b/module/srfi/srfi-64/execution.body.scm
@@ -0,0 +1,426 @@
+;; Copyright (c) 2005, 2006, 2007, 2012, 2013 Per Bothner
+;; Added "full" support for Chicken, Gauche, Guile and SISC.
+;;   Alex Shinn, Copyright (c) 2005.
+;; Modified for Scheme Spheres by Álvaro Castro-Castilla, Copyright (c) 2012.
+;; Support for Guile 2 by Mark H Weaver , Copyright (c) 2014.
+;; Refactored by Taylan Ulrich Bayırlı/Kammer, Copyright (c) 2014, 2015.
+;;
+;; Permission is hereby granted, free of charge, to any person
+;; obtaining a copy of this software and associated documentation

[PATCH] Improve support for R6/R7 SRFI module name formats.

[Taylan Kammer]

Hi Guile devs,

This patch improves Guile's support for SRFI module names in the R6RS
and R7RS formats, i.e. (srfi :n) and (srfi n).


Copying from the commit message:

It was already possible to import an SRFI module by referencing it
as (srfi :n) which is automatically translated to (srfi srfi-n), but
this conversion was only done during import.  After this change, it's
also possible to define a library as (srfi :n) which is automatically
translated to (srfi srfi-n) during definition.

It was not possible at all to define or import SRFI module names in the
R7RS format, (srfi n), where n is a non-negative exact integer.  It is
now possible both to define and import them as such, realized through
the same kind of conversion to a canonical (srfi srfi-n) name.


The patch is attached as a MIME attachment in git format-patch format.


Note, by the way, that there was already a little bit of code in
module/ice-9/r6rs-libraries.scm to support module names like (srfi n),
but it didn't work in practice because syntax-case guards in all the
"entry points" barred the possibility of using that format.


Another note: r6rs-libraries.scm uses both 'identifier?' and the form
'sym?' which is defined as '(symbol? (syntax->datum x))'.  It's unclear
to me what the difference is and I hope my use of 'sym?' is correct.


Relevant bug reports:

- https://bugs.gnu.org/39601 (fixed)

- https://bugs.gnu.org/40371 (partly fixed)


Taylan
From b607613028f8f6764c03c1d7917434242ee32191 Mon Sep 17 00:00:00 2001
From: Taylan Kammer 
Date: Mon, 10 May 2021 18:12:34 +0200
Subject: [PATCH] Improve support for R6/R7 SRFI module name formats.

Fixes <https://bugs.gnu.org/39601>.

Partly fixes <https://bugs.gnu.org/40371>.

It was already possible to import an SRFI module by referencing it
as (srfi :n) which is automatically translated to (srfi srfi-n), but
this conversion was only done during import.  After this change, it's
also possible to define a library as (srfi :n) which is automatically
translated to (srfi srfi-n) during definition.

It was not possible at all to define or import SRFI module names in the
R7RS format, (srfi n), where n is a non-negative exact integer.  It is
now possible both to define and import them as such, realized through
the same kind of conversion to a canonical (srfi srfi-n) name.

* module/ice-9/r6rs-libraries.scm: Numerous changes.
---
 module/ice-9/r6rs-libraries.scm | 84 -
 1 file changed, 62 insertions(+), 22 deletions(-)

diff --git a/module/ice-9/r6rs-libraries.scm b/module/ice-9/r6rs-libraries.scm
index c6ba6a496..33dcbde22 100644
--- a/module/ice-9/r6rs-libraries.scm
+++ b/module/ice-9/r6rs-libraries.scm
@@ -20,6 +20,49 @@
 ;; This file is included from boot-9.scm and assumes the existence of (and 
 ;; expands into) procedures and syntactic forms defined therein.
 
+(define (sym? stx)
+  (symbol? (syntax->datum stx)))
+
+(define (n? stx)
+  (let ((n (syntax->datum stx)))
+(and (exact-integer? n)
+ (not (negative? n)
+
+(define (colon-n? x)
+  (let ((sym (syntax->datum x)))
+(and (symbol? sym)
+ (let ((str (symbol->string sym)))
+   (and (string-prefix? ":" str)
+(let ((num (string->number (substring str 1
+  (and (exact-integer? num)
+   (not (negative? num)
+
+(define (srfi-name? stx)
+  (syntax-case stx (srfi)
+((srfi n rest ...)
+ (and (and-map sym? #'(rest ...))
+  (or (n? #'n)
+  (colon-n? #'n
+(_ #f)))
+
+(define (module-name? stx)
+  (or (srfi-name? stx)
+  (syntax-case stx ()
+((name name* ...)
+ (and-map sym? #'(name name* ...)))
+(_ #f
+
+(define (make-srfi-n context n)
+  (datum->syntax
+   context
+   (string->symbol
+(string-append
+ "srfi-"
+ (let ((n (syntax->datum n)))
+   (if (symbol? n)
+   (substring (symbol->string n) 1)
+   (number->string n)))
+
 (define (resolve-r6rs-interface import-spec)
   (define (make-custom-interface mod)
 (let ((iface (make-module)))
@@ -37,27 +80,13 @@
 (for-each (lambda (mod)
 (module-for-each f mod))
   (module-and-uses mod)))
-  (define (sym? x) (symbol? (syntax->datum x)))
 
   (syntax-case import-spec (library only except prefix rename srfi)
 ;; (srfi :n ...) -> (srfi srfi-n ...)
 ;; (srfi n ...) -> (srfi srfi-n ...)
 ((library (srfi n rest ... (version ...)))
- (and (and-map sym? #'(srfi rest ...))
-  (or (and
-   (symbol? (syntax->datum #'n))
-   (let ((str (symbol->string (syntax->datum #'n
- (and (string-prefix? ":" str)
-  (and=> (string->number (substring str 1))
- exact-integer?
-  (exact-integer? (syntax->d

Re: cond-expand-provide and (scheme base)

[Taylan Kammer]

On 22.10.2020 20:24, Taylan Kammer wrote:

I think the following discrepancy should probably be fixed:

   $ guile -L ~/src/scheme/bytestructures/
   guile> ,use (scheme eval)
   guile> (eval '(cond-expand (lp64 #t) (else #f))
(environment '(guile)  ; <=== DIFFERENCE HERE
 '(bytestructures guile numeric-data-model)))
   $1 = #t
   guile> (eval '(cond-expand (lp64 #t) (else #f))
(environment '(scheme base)  ; <=== DIFFERENCE HERE
 '(bytestructures guile numeric-data-model)))
   $2 = #f


To clarify:

The module (bytestructures guile numeric-data-model) provides the 'lp64' 
condition via 'cond-expand-provide'.


The 'cond-expand' imported from the (guile) module correctly sees this, 
but the one imported from (scheme base) seems to ignore it.


Taylan

cond-expand-provide and (scheme base)

[Taylan Kammer]

I think the following discrepancy should probably be fixed:

  $ guile -L ~/src/scheme/bytestructures/
  guile> ,use (scheme eval)
  guile> (eval '(cond-expand (lp64 #t) (else #f))
   (environment '(guile)  ; <=== DIFFERENCE HERE
'(bytestructures guile numeric-data-model)))
  $1 = #t
  guile> (eval '(cond-expand (lp64 #t) (else #f))
   (environment '(scheme base)  ; <=== DIFFERENCE HERE
'(bytestructures guile numeric-data-model)))
  $2 = #f

WDYT?


Kind regards,

Taylan

Fwd: Re: unhandled constant?

[Taylan Kammer]

(Duplicate of the mail I sent to guile-devel before realizing you're not
on the list.)

> (defmacro define-session (name value)
>   (define (inner n v)
> (set! decl
> (cons
>  (make-var n v)
>  decl))
> )
>   `(,inner ',name ,value))

The problem here is that the macro output

  `(,inner ',name ,value)

would include a # object, because it evaluates 'inner', which
has been defined as a procedure.  The raw output would look something
like this:

  (# 'foo "bar)

And the compiler tries to put that into a file.  But procedure objects
cannot be put into a file.

(They cannot be "serialized" i.e. turned back into text.  Hence the
clumsy "#" thing which tells us a bit about the procedure
like its name and the number of arguments it takes but doesn't actually
include its code.)

That's why the compiler chokes.  It could put a constant like the number
982346 or the string "foo" or the vector #(x 4 "blah") into the output
it generates, because all those objects can be serialized, but a
procedure object cannot be truly serialized.

Note that something like (lambda () ...) is NOT a procedure; it's a
list.  Such a list can be evaluated as Scheme code, within a larger
context (an "environment"), which then yields a procedure object, but
that resulting procedure object cannot be turned back into text, because
it might be relying on the environment in which it was defined.

Like others pointed out, there's a couple of ways to rewrite that code
to avoid putting a procedure object straight into the macro output.  For
instance, you could put the definition of the procedure into the output,
so it will be evaluated (turned into a procedure) at run-time:

  (defmacro define-session (name value)
`(begin
   (define (inner n v)
 (set! decl
 (cons
  (make-var n v)
  decl))
 )
   (inner ',name ,value)))

I'm not sure if this code will work verbatim in 1.8 and 2.2, but you get
the idea: don't put procedures into macro output.

- Taylan


On 29.01.2020 00:08, Han-Wen Nienhuys wrote:
> Some of the lilypond Scheme files do the following:
> 
> 
> (define decl '())
> (define (make-var n v) (list "var" n v))
> (defmacro define-session (name value)
>   (define (inner n v)
> (set! decl
> (cons
>  (make-var n v)
>  decl))
> )
>   `(,inner ',name ,value))
> (define-session foo 1)
> (display decl)
> (newline)
> 
> In GUILE 2.2, this yields
> 
> ;;; WARNING: compilation of /home/hanwen/vc/lilypond/q.scm failed:
> ;;; unhandled constant #
> 
> What does this error message mean, and what should I do to address the 
> problem?
> 

Re: unhandled constant?

[Taylan Kammer]

> (defmacro define-session (name value)
>   (define (inner n v)
> (set! decl
> (cons
>  (make-var n v)
>  decl))
> )
>   `(,inner ',name ,value))

The problem here is that the macro output

  `(,inner ',name ,value)

would include a # object, because it evaluates 'inner', which
has been defined as a procedure.  The raw output would look something
like this:

  (# 'foo "bar)

And the compiler tries to put that into a file.  But procedure objects
cannot be put into a file.

(They cannot be "serialized" i.e. turned back into text.  Hence the
clumsy "#" thing which tells us a bit about the procedure
like its name and the number of arguments it takes but doesn't actually
include its code.)

That's why the compiler chokes.  It could put a constant like the number
982346 or the string "foo" or the vector #(x 4 "blah") into the output
it generates, because all those objects can be serialized, but a
procedure object cannot be truly serialized.

Note that something like (lambda () ...) is NOT a procedure; it's a
list.  Such a list can be evaluated as Scheme code, within a larger
context (an "environment"), which then yields a procedure object, but
that resulting procedure object cannot be turned back into text, because
it might be relying on the environment in which it was defined.

Like others pointed out, there's a couple of ways to rewrite that code
to avoid putting a procedure object straight into the macro output.  For
instance, you could put the definition of the procedure into the output,
so it will be evaluated (turned into a procedure) at run-time:

  (defmacro define-session (name value)
`(begin
   (define (inner n v)
 (set! decl
 (cons
  (make-var n v)
  decl))
 )
   (inner ',name ,value)))

I'm not sure if this code will work verbatim in 1.8 and 2.2, but you get
the idea: don't put procedures into macro output.

- Taylan


On 29.01.2020 00:08, Han-Wen Nienhuys wrote:
> Some of the lilypond Scheme files do the following:
> 
> 
> (define decl '())
> (define (make-var n v) (list "var" n v))
> (defmacro define-session (name value)
>   (define (inner n v)
> (set! decl
> (cons
>  (make-var n v)
>  decl))
> )
>   `(,inner ',name ,value))
> (define-session foo 1)
> (display decl)
> (newline)
> 
> In GUILE 2.2, this yields
> 
> ;;; WARNING: compilation of /home/hanwen/vc/lilypond/q.scm failed:
> ;;; unhandled constant #
> 
> What does this error message mean, and what should I do to address the 
> problem?
> 

Re: GNU Guile 3.0.0 released

[Taylan Kammer]

Many thanks to everyone for this amazing release. :-)

> ** Add support for R7RS

Given the now official R7RS support, let me remind people of this repo:

https://github.com/TaylanUB/scheme-srfis/

Development is inactive, but patches, merge requests, or forks/takeovers
are welcome.

I think there's a few SRFIs there which aren't in Guile yet.


- Taylan

Re: GNU Guile 2.9.9 Released [beta]

[Taylan Kammer]

During the R7RS-small discussion, I remember Will Clinger suggesting to
keep (eqv? proc1 proc2) => #t but unspecifying it for eq?.  Would that
help in Guile's case?  I don't remember the exact optimization he
suggested this for.


- Taylan

On 14.01.2020 17:47, Mikael Djurfeldt wrote:
> It might be reasonable to keep the patch for now in order not to
> introduce novel behavior this short before the 3.0 release.
> 
> But especially in light of Andy's work, I do regret introducing
> procedure-properties. It's a more LISPy feature than Schemey. Did you
> see Andy's argument about procedure equality below?
> 
> I would have preferred to postpone the release and drop procedure
> equality, procedure-properties etc. It can be handy and convenient, yes,
> but there is a reason why R6RS didn't require (eq? p p) -> #t...
> 
> Best regards,
> Mikael
> 
> On Tue, Jan 14, 2020 at 5:37 PM Stefan Israelsson Tampe
> mailto:stefan.ita...@gmail.com>> wrote:
> 
> 
> 
> -- Forwarded message -
> From: *Stefan Israelsson Tampe*  >
> Date: Tue, Jan 14, 2020 at 5:23 PM
> Subject: Re: GNU Guile 2.9.9 Released [beta]
> To: Mikael Djurfeldt  >
> 
> 
> This is how it always have been in guile, without this patch you
> cannot use procedure-property, use a function as a key to hash maps
> etc. If this patch goes you need to forbid usage
> of procedures as keys to hashmap, nuke procedure properties and
> friends or mark it as internal to avoid luring schemers into using a
> faulty method. This patch improves the use of higher order functions
> not risk it. For example I often classify functions into different
> categories and maintain this information as a property on the
> function via a hashmap. This is a quite natural way of programming.
> Without it you need
> to put the procedures in a datastructure and track that
> datastructure that will uglify a lot of code. It is manageable but
> when the opposite is similarly speeded code but much nicer and
> enjoyable code with absolutely no risk in
> higher order functionality countrary as you state (because higher
> order worked flawlessly before in guile and the patch is restoring
> that).
> 
> On Tue, Jan 14, 2020 at 5:07 PM Mikael Djurfeldt
> mailto:mik...@djurfeldt.com>> wrote:
> 
> Hmm... it seems like both Stefan and you have interpreted my
> post exactly the opposite way compared to how it was meant. :)
> 
> I completely agree that procedure equality is not strongly
> connected to the first citizen-ness.
> 
> What I wanted to say is that I probably prefer you to *reverse*
> the recent patch because I prefer to have good optimization also
> when procedures are referenced by value in more than one
> non-operator position. I prefer this over having (eq? p p) => #t
> for the reasons I stated.
> 
> Best regards,
> Mikael
> 
> Den tis 14 jan. 2020 15:33Andy Wingo  > skrev:
> 
> On Tue 14 Jan 2020 13:18, Mikael Djurfeldt
> mailto:mik...@djurfeldt.com>> writes:
> 
> > I probably don't have a clue about what you are talking
> about (or at
> > least hope so), but this---the "eq change"---sounds scary
> to me.
> >
> > One of the *strengths* of Scheme is that procedures are
> first class
> > citizens. As wonderfully show-cased in e.g. SICP this can
> be used to
> > obtain expressive and concise programs, where procedures
> can occur
> > many times as values outside operator position.
> >
> > I would certainly *not* want to trade in an important
> optimization
> > step in those cases to obtain intuitive procedure
> equality. The risk
> > is then that you would tend to avoid passing around
> procedures as
> > values.
> 
> Is this true?
> 
>   (eq? '() '())
> 
> What about this?
> 
>   (eq? '(a) '(a))
> 
> And yet, are datums not first-class values?  What does being
> first-class
> have to do with it?
> 
> Does it matter whether it's eq? or eqv?
> 
> What about:
> 
>   (eq? (lambda () 10) (lambda () 10))
> 
> What's the difference?
> 
> What's the difference in the lambda calculus between "\x.f
> x" and "f"?
> 
> What if in a partial evaluator, you see a `(eq? x y)`, and
> you notice
> that `x' is bound to a lambda expression?  Can you say
> anything about
> the value of the expression?
> 
> Does comparing 

Re: Re-exporting a replaced binding

[Taylan Kammer]

On 03.01.2020 19:30, Ludovic Courtès wrote:
> 
> Should the #:re-export clause propagate the replace bit, or should
> it not?  :-)

The 2.9.8 release notes say one should use #:re-export-and-replace for
this use-case.


Happy new year!

Taylan

Re: conflicts in the gnu project now affect guile

[Taylan Kammer]

On 20.10.2019 05:08, Mark H Weaver wrote:
> Taylan Kammer  writes:
>> I'm mostly fond of the Contributor Covenant that was adopted by Guix
> 
> I suggest that we postpone discussion of this proposal for now.  It
> might create more divisions between us, at a time when we should be
> focused on healing our wounds and coming together as a community.  I'd
> be glad to discuss it later.

Hi Mark,

Sure thing.  It seems like I was missing some context here.  I went
straight into discussing details of the CoC because I had (wrongly I
suppose) assumed that the CoC itself is not so controversial.

It should have occurred to me that there's a reason it's not in Guile
yet despite being in Guix for a while. :-)

Sorry if I threw another controversy into the mix at a bad time.

>   Thanks,
> Mark
> 


Kind regards,

- Taylan

Re: speedup of modifying return values

[Taylan Kammer]

Stefan Israelsson Tampe  writes:

> Hi all, I'm trying to make a python clone in guile. Currently the code is 
> slow and one of  the reasons is the following,
>
> in my pythoon
>
> return 1,2
>
> returns a (values 1 2) in order to get python and scheme to interoperate. but 
> for python if you use
>
> x = 1,2
>
> then x is the tupple '(1 2) and in guile it is 1. So therefore we wrap the 
> result for
>
> x=f(10)
>
> as
> (set! x (call-with-values (lambda () (f x)) (case-lambda ((x) x) (x x
>
> This can be compiled to efficient bytecode but is not done so in guile. In 
> stead a closure is created at each assignment site and creating ineficient 
> code.
>
> Any ideas how to improve this (I don't want "return a,b" to mean (list a b) 
> which is a quick solution
> if we want to just stay in python and not interoperate with scheme at all on 
> this level.

Sounds like a fun project. :-)

Idea:

Make Python tuples a new data type, instead of multi-values.

The fact that they can be stored in a single storage location in Python
means that they are actually a data type, only special-handled for
automatic destructuring in some places...

Therefore, I would represent them as a record type under the hood.
Maybe one with a single field that contains a list or a vector.

I would then compile Python syntax that destructures tuples into
corresponding Guile code that destructures them also.

> Regards
> Stefan

Happy hacking,
Taylan