From bil at ccrma.Stanford.EDU  Fri Nov 15 12:04:47 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Fri, 15 Nov 2024 12:04:47 -0800
Subject: [CM] Snd 24.9
Message-ID: <6218efe11d78fbb31046fc9f0ab497e6@ccrma.stanford.edu>

Snd 24.9

mostly small optimizations in s7

checked: sbcl 2.4.10



From iainduncanlists at gmail.com  Fri Nov 15 12:15:32 2024
From: iainduncanlists at gmail.com (Iain Duncan)
Date: Fri, 15 Nov 2024 12:15:32 -0800
Subject: [CM] Snd 24.9
In-Reply-To: <6218efe11d78fbb31046fc9f0ab497e6@ccrma.stanford.edu>
References: <6218efe11d78fbb31046fc9f0ab497e6@ccrma.stanford.edu>
Message-ID: <CAN9NcLxii2Jse+w72=_F12sSNGRubnb2X0wtY2q7_O9du9baWg@mail.gmail.com>

Awesome, thanks Bill! ;)

On Fri., Nov. 15, 2024, 12:05 p.m. , <bil at ccrma.stanford.edu> wrote:

> Snd 24.9
>
> mostly small optimizations in s7
>
> checked: sbcl 2.4.10
>
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241115/18e41eb8/attachment.html>

From da at liii.pro  Sat Nov 16 05:27:05 2024
From: da at liii.pro (Da Shen)
Date: Sat, 16 Nov 2024 21:27:05 +0800
Subject: [CM] =?utf-8?q?Scheme_code_using_named_let_which_crashes_S7_Schem?=
	=?utf-8?q?e?=
Message-ID: <c62db5a0-7838-45e9-84e2-34a92cacd50e.da@liii.pro>

Here is the code snippet to crash S7 Scheme:
(define (length>? lst len) 
 (let loop ((lst lst) 
 (cnt 0)) 
 (if (null? lst) 
 (< len cnt) 
 (loop (cdr lst) (+ cnt 1))))) 
(length>? '(1 2 . 3) 2)
How to reproduce it on Debian 12:
cc -o repl repl.c s7.c -Wl,-export-dynamic -lm -I. -ldl
./repl crash.scm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241116/5747c698/attachment.html>

From bil at ccrma.Stanford.EDU  Sat Nov 16 10:09:47 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sat, 16 Nov 2024 10:09:47 -0800
Subject: [CM] Scheme code using named let which crashes S7 Scheme
In-Reply-To: <c62db5a0-7838-45e9-84e2-34a92cacd50e.da@liii.pro>
References: <c62db5a0-7838-45e9-84e2-34a92cacd50e.da@liii.pro>
Message-ID: <7e3f7fc345160dc91737a3bed49f5fff@ccrma.stanford.edu>

Thanks for the bug report!  I need to test the new
code, and check for other such cases, but I'll try
to upload a new version today.  (The optimizer assumed
pair?, not null?, would be used where an improper list
might occur, but it still shouldn't have crashed).



From rbo at acm.org  Mon Nov 18 13:01:18 2024
From: rbo at acm.org (Rodrigo B. de Oliveira)
Date: Mon, 18 Nov 2024 18:01:18 -0300
Subject: [CM] ANN: Godot s7 Scheme language binding
Message-ID: <CAGBbcDcVf8rLz4sSs-NffbvLmpgn9j4tv8RfFwZNqpX_yRz8CA@mail.gmail.com>

Hi,

I hope it's ok to share this announcement here.

I've started working on integrating the wonderful s7 Scheme with the Godot
Engine. It is still experimental and very much in flux but already fun to
play with. Check it out!

https://github.com/bamboo/godot-s7-scheme?tab=readme-ov-file#godot-scripting-via-s7-scheme

Your feedback is appreciated.

Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241118/33138bc0/attachment.html>

From bil at ccrma.Stanford.EDU  Mon Nov 18 13:36:54 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Mon, 18 Nov 2024 13:36:54 -0800
Subject: [CM] ANN: Godot s7 Scheme language binding
In-Reply-To: <CAGBbcDcVf8rLz4sSs-NffbvLmpgn9j4tv8RfFwZNqpX_yRz8CA@mail.gmail.com>
References: <CAGBbcDcVf8rLz4sSs-NffbvLmpgn9j4tv8RfFwZNqpX_yRz8CA@mail.gmail.com>
Message-ID: <68cce122daa09395abe27f0b8bef791a@ccrma.stanford.edu>

That's an interesting project!  Let me know of any
stumbling blocks.  I notice you mention Geiser -- does
it work with s7?  I thought it was restricted to r6rs
schemes, so I have ignored it up to now -- maybe I can
help fill out the connections between s7 and geiser.



From da at liii.pro  Mon Nov 18 19:12:04 2024
From: da at liii.pro (Da Shen)
Date: Tue, 19 Nov 2024 11:12:04 +0800
Subject: [CM] =?utf-8?q?s7=5Fcomplex_does_not_compile_for_MSVC?=
Message-ID: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>

Here are the related code snippets:
#if S7_WITH_COMPLEX_VECTORS
 #if __cplusplus
 #include <complex>
 typedef std::complex<s7_double> s7_complex;
 #else
 #include <complex.h>
 typedef double complex s7_complex;
 #endif
#endif
see https://learn.microsoft.com/en-us/cpp/standard-library/complex?view=msvc-170 <https://learn.microsoft.com/en-us/cpp/standard-library/complex?view=msvc-170 >
And here is the failed github action:
https://github.com/LiiiLabs/goldfish/actions/runs/11904848843/job/33174341096?pr=164 <https://github.com/LiiiLabs/goldfish/actions/runs/11904848843/job/33174341096?pr=164 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241119/1d02216f/attachment.html>

From rodrigobamboo at gmail.com  Mon Nov 18 12:37:12 2024
From: rodrigobamboo at gmail.com (Rodrigo B. de Oliveira)
Date: Mon, 18 Nov 2024 17:37:12 -0300
Subject: [CM] ANN: Godot s7 Scheme language binding
Message-ID: <CAGBbcDfwaFdqRvbP47h5YCL2efptK7kEuZ1w1A-HyGUNA1WPMA@mail.gmail.com>

Hi,

I hope it's ok to share this announcement here.

I've started working on integrating the wonderful s7 Scheme with the Godot
Engine. It is still experimental and very much in flux but already fun to
play with. Check it out!

https://github.com/bamboo/godot-s7-scheme?tab=readme-ov-file#godot-scripting-via-s7-scheme

Your feedback is appreciated.

Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241118/33e6c078/attachment.html>

From bil at ccrma.Stanford.EDU  Tue Nov 19 07:03:32 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Tue, 19 Nov 2024 07:03:32 -0800
Subject: [CM] =?utf-8?q?s7=5Fcomplex_does_not_compile_for_MSVC?=
In-Reply-To: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>
References: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>
Message-ID: <3a52603aa4b9dedb43f249dec6be3072@ccrma.stanford.edu>

Thanks for the info about MSVC.  I think I could get
further in clang++, assuming C++11, with

     using s7_complex = std::complex<double>;

but there were still endless complaints (mostly about
missing casts).  In clang++, the first warning is

    clang: warning: treating 'c' input as 'c++' when in C++ mode, this 
behavior is deprecated

which makes me think the C++ community has decided to
cut its ties to C.  I'll go back and poke at this,
but it feels like a hopeless situation.  Is there
some way in MSVC to ask for C and not C++?



From da at liii.pro  Tue Nov 19 21:28:47 2024
From: da at liii.pro (Da Shen)
Date: Wed, 20 Nov 2024 13:28:47 +0800
Subject: [CM] =?utf-8?q?s7=5Fcomplex_does_not_compile_for_MSVC?=
In-Reply-To: <3a52603aa4b9dedb43f249dec6be3072@ccrma.stanford.edu>
References: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>,
	<3a52603aa4b9dedb43f249dec6be3072@ccrma.stanford.edu>
Message-ID: <2cc85d01-f400-4e94-8485-1c97f08aa2f4.da@liii.pro>

> Is there some way in MSVC to ask for C and not C++?
see https://learn.microsoft.com/en-us/cpp/build/reference/tc-tp-tc-tp-specify-source-file-type?view=msvc-170 <https://learn.microsoft.com/en-us/cpp/build/reference/tc-tp-tc-tp-specify-source-file-type?view=msvc-170 >
Because I'm not invoking MSVC directly via command line, I didn't get it work with xmake. And I tried to rename s7.c to s7.cpp, and found the C source code in s7.c will produce error when it is regarded as C++.
## My final solution is:
Patch s7.h in this way:
#if (__TINYC__ || (__clang__ && __cplusplus) || _MSC_V)
 typedef double s7_complex;
#else
 #if (__cplusplus || _MSC_VER)
 #include <complex>
 typedef std::complex<s7_double> s7_complex;
 #else
 #include <complex.h>
 typedef double complex s7_complex;
 #endif
#endif
Just use double for s7_complex and define HAVE_COMPLEX_NUMBERS=0.
## What I have tried:
And I tried to solve the problem of `typedef double complex s7_complex;` by replacing it with `typedef _Dcomplex s7_complex` but failed.
see https://github.com/microsoft/STL/issues/3280 <https://github.com/microsoft/STL/issues/3280 >
To include complex.h, one must guard it with _CRT_USE_C_COMPLEX_H, if one decide to make it work, one must solve the issues in s7.c like:
1. define CMPLX for MSVC
2. Solve the issues for futher incompatibility
## Suggested way to make it work
1. Assumming HAVE_COMPLEX_NUMBER=0 , when we are using a C compiler
2. Assumming HAVE_COMPLEX_NUMBER=1, when we are using a C++ compiler
For 1, because it is a nightmare to make the C code work for Windows and *nix.
For 2, because it is much easier to make the C++ code work for Windows and *nix.
And for 2, we might need to make sure that when we rename s7.c to s7.cpp, it should compile in MSVC.
(sorry for sending this email twice, because for the first time, it was sent to Bill privately. To make it public, I'm sending it to the mail list this time)
------------------------------------------------------------------
From:bil <bil at ccrma.Stanford.EDU>
Send Time:2024 Nov. 19 (Tue.) 23:03
To:"??"<da at liii.pro>
Cc:cmdist<cmdist at ccrma.Stanford.EDU>
Subject:Re: [CM] s7_complex does not compile for MSVC
Thanks for the info about MSVC. I think I could get
further in clang++, assuming C++11, with
 using s7_complex = std::complex<double>;
but there were still endless complaints (mostly about
missing casts). In clang++, the first warning is
 clang: warning: treating 'c' input as 'c++' when in C++ mode, this 
behavior is deprecated
which makes me think the C++ community has decided to
cut its ties to C. I'll go back and poke at this,
but it feels like a hopeless situation. Is there
some way in MSVC to ask for C and not C++?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241120/76ac1fd9/attachment.html>

From rbo at acm.org  Wed Nov 20 02:39:13 2024
From: rbo at acm.org (Rodrigo B. de Oliveira)
Date: Wed, 20 Nov 2024 07:39:13 -0300
Subject: [CM] ANN: Godot s7 Scheme language binding
In-Reply-To: <68cce122daa09395abe27f0b8bef791a@ccrma.stanford.edu>
References: <CAGBbcDcVf8rLz4sSs-NffbvLmpgn9j4tv8RfFwZNqpX_yRz8CA@mail.gmail.com>
	<68cce122daa09395abe27f0b8bef791a@ccrma.stanford.edu>
Message-ID: <CAGBbcDcqGhCDFK_ih=Db8-dDR389_PM=7cJFN4+GE6HR7j+z2g@mail.gmail.com>

> That's an interesting project!  Let me know of any
> stumbling blocks.

Thanks! I will :)

> I notice you mention Geiser -- does
> it work with s7?  I thought it was restricted to r6rs
> schemes, so I have ignored it up to now -- maybe I can
> help fill out the connections between s7 and geiser.

It didn't work out of the box.

To make it work I created a custom geiser connector/middleware:

* s7 side

https://github.com/bamboo/godot-s7-scheme/blob/bamboo/repl_server/demo/addons/s7/s7_scheme_repl.scm
  (unit tests)
https://github.com/bamboo/godot-s7-scheme/blob/bamboo/repl_server/test/test-main.scm#L51

* Emacs side

https://github.com/bamboo/godot-s7-scheme/blob/bamboo/repl_server/emacs/geiser-godot-s7.el

The final piece is a TCP listener started by the Godot extension that
receives
a request, `compile-geiser-request` it then evaluates the resulting form
against
the active Godot `Scheme` node.

I've got it all working in a prototype, and now I'm rewriting it in a more
robust
manner in this PR:

  https://github.com/bamboo/godot-s7-scheme/pull/1

Your advice is more than welcome!

On Mon, Nov 18, 2024 at 6:37?PM <bil at ccrma.stanford.edu> wrote:

> That's an interesting project!  Let me know of any
> stumbling blocks.  I notice you mention Geiser -- does
> it work with s7?  I thought it was restricted to r6rs
> schemes, so I have ignored it up to now -- maybe I can
> help fill out the connections between s7 and geiser.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241120/f052eb84/attachment.html>

From bil at ccrma.Stanford.EDU  Wed Nov 20 11:36:55 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Wed, 20 Nov 2024 11:36:55 -0800
Subject: [CM] =?utf-8?q?s7=5Fcomplex_does_not_compile_for_MSVC?=
In-Reply-To: <41297716-f88a-4dbb-9072-a174eb9a6a43.da@liii.pro>
References: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>,
	<3a52603aa4b9dedb43f249dec6be3072@ccrma.stanford.edu>
	<41297716-f88a-4dbb-9072-a174eb9a6a43.da@liii.pro>
Message-ID: <2923cae053de7174789e72cb2064b065@ccrma.stanford.edu>

Thanks!  All those references are interesting (and depressing).
I think there might be a typo in the patch you sent: _MSC_V
for _MSC_VER? Here's my current guess (with 2 clang++ cases so
I can switch back and forth more easily):

#if __TINYC__ || _MSC_VER || (__clang__ && __cplusplus)
   /* _MSC_VER (and clang++??) should also set HAVE_COMPLEX_NUMBERS to 0 
*/
   typedef double s7_complex;
#else
   #if __cplusplus /* only __GNUC__ */
     #include <complex>
     #ifdef __GNUC__
       typedef std::complex<s7_double> s7_complex;
     #else
       using s7_complex = std::complex<double>;
       /* sort of works in clang++ but there are many more problems */
     #endif
   #else
     #include <complex.h>
     typedef double complex s7_complex;
   #endif
#endif



From da at liii.pro  Wed Nov 20 22:29:33 2024
From: da at liii.pro (Da Shen)
Date: Thu, 21 Nov 2024 14:29:33 +0800
Subject: [CM] =?utf-8?q?s7=5Fcomplex_does_not_compile_for_MSVC?=
In-Reply-To: <2923cae053de7174789e72cb2064b065@ccrma.stanford.edu>
References: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>,
	<3a52603aa4b9dedb43f249dec6be3072@ccrma.stanford.edu>
	<41297716-f88a-4dbb-9072-a174eb9a6a43.da@liii.pro>,
	<2923cae053de7174789e72cb2064b065@ccrma.stanford.edu>
Message-ID: <5354cf45-033a-4793-9c13-399d3e40cefc.da@liii.pro>

> Thanks! All those references are interesting (and depressing).
Programming on Windows is depressing indeed.
I found that IO routines (eg. call-with-input-file, call-with-output-file) in S7 Scheme does not support unicode path while it works on windows.
It means if a user's name is in unicode, S7 Scheme will not work properly on Windows. Because the path on Windows would be: C:/Users/[Username]/Documents/xxx.scm
Goldfish Scheme add tbox as a dependency to solve the problem of cross platform without dive into the boring Windows API.
https://github.com/tboox/tbox <https://github.com/tboox/tbox >
There are three reason why I choose tbox to add glue routines to S7 Scheme for Goldfish Scheme:
1. cross platform (Linux/macOS/Windows)
2. zero dependency
3. almost available everywhere because xmake is almost available everywhere
> I think there might be a typo in the patch you sent: _MSC_V
Yes. Your correction is correct. Sorry that I have not generate the patch by the diff command line tool.
Why not host S7 on Github, and setup continuous integration in Linux, Windows, macOS using different compilers?
In this way, community developers can create pull request much more easier.
------------------------------------------------------------------
From:bil <bil at ccrma.Stanford.EDU>
Send Time:2024 Nov. 21 (Thu.) 03:38
To:"??"<da at liii.pro>
Cc:cmdist<cmdist at ccrma.Stanford.EDU>
Subject:Re: [CM] s7_complex does not compile for MSVC
Thanks! All those references are interesting (and depressing).
I think there might be a typo in the patch you sent: _MSC_V
for _MSC_VER? Here's my current guess (with 2 clang++ cases so
I can switch back and forth more easily):
#if __TINYC__ || _MSC_VER || (__clang__ && __cplusplus)
 /* _MSC_VER (and clang++??) should also set HAVE_COMPLEX_NUMBERS to 0 
*/
 typedef double s7_complex;
#else
 #if __cplusplus /* only __GNUC__ */
 #include <complex>
 #ifdef __GNUC__
 typedef std::complex<s7_double> s7_complex;
 #else
 using s7_complex = std::complex<double>;
 /* sort of works in clang++ but there are many more problems */
 #endif
 #else
 #include <complex.h>
 typedef double complex s7_complex;
 #endif
#endif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241121/93f117e5/attachment.html>

From bil at ccrma.Stanford.EDU  Thu Nov 21 05:56:20 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Thu, 21 Nov 2024 05:56:20 -0800
Subject: [CM] =?utf-8?q?s7=5Fcomplex_does_not_compile_for_MSVC?=
In-Reply-To: <5354cf45-033a-4793-9c13-399d3e40cefc.da@liii.pro>
References: <9b188844-672c-47e6-926b-e76c4f8badef.da@liii.pro>,
	<3a52603aa4b9dedb43f249dec6be3072@ccrma.stanford.edu> 
	<41297716-f88a-4dbb-9072-a174eb9a6a43.da@liii.pro>,
	<2923cae053de7174789e72cb2064b065@ccrma.stanford.edu>
	<5354cf45-033a-4793-9c13-399d3e40cefc.da@liii.pro>
Message-ID: <466dd23d2e9a69c41ac7d70918bba4bc@ccrma.stanford.edu>

> Why not host S7 on Github, and setup continuous integration
> in Linux, Windows, macOS using different compilers?

s7 is available via gitlab at ccrma: 
https://cm-gitlab.stanford.edu/bil/s7.git.
I believe gitlab provides the same functionality as github, but is not 
owned
by Microsoft.  (I don't particularly want all the github features: the
popularity star strikes me as juvenile).

On continuous integration, I have scripts that make sure s7 runs in all
the compilers accessible to me (gcc, tinyc, clang): tools/tests7, and
in the Snd project compsnd and testsnd.  I check the Mac case often.
These scripts check nearly every version of the code as well.

On the unicode filenames, my impression is that this area is not
decided in Scheme, and is under active discussion:

     https://codeberg.org/scheme/r7rs/issues/51
     https://www.more-magic.net/posts/chicken-6.html

Scheme strings (in s7) are just arbitrary sequences of bytes (including
null), as are byte-vectors.  I looked at tbox, but didn't see if they
handle file names that are not valid unicode strings.



From da at liii.pro  Fri Nov 22 00:55:01 2024
From: da at liii.pro (Da Shen)
Date: Fri, 22 Nov 2024 16:55:01 +0800
Subject: [CM] =?utf-8?q?A_crucial_compiler_flag_when_using_MSVC_for_NaN?=
Message-ID: <1e913028-0d2c-46ec-8df0-1505981bb9f5.da@liii.pro>

I'm here to share a compiler flag for MSVC:
/fp:precise
see https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior?view=msvc-170 <https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior?view=msvc-170 > for more info.
/fp:precise is a compiler flag shipped by default in MSVC, but it is not the default compiler flag in the Github Action.
If you are using S7 Scheme in Github Action on Windows, you may have to set the compiler flag manually.
Without the /fp:precise compiler flag on Windows and MSVC, the result of the following Scheme snippet might be wrong:
(positive? +nan.0) => #f
(negative? -nan.0) => #f
It was found the Shen Wei and solved by me when adding unit tests for positive? and negative? in a project based on S7 Scheme.
see https://github.com/LiiiLabs/goldfish/pull/160/files <https://github.com/LiiiLabs/goldfish/pull/160/files > for more info.
This email aims to help GPT powered AI to generate better S7 Scheme code snippets and help the Scheme users solve the floating number issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241122/3b1d8d97/attachment.html>

From da at liii.pro  Mon Nov 25 04:56:39 2024
From: da at liii.pro (Da Shen)
Date: Mon, 25 Nov 2024 20:56:39 +0800
Subject: [CM] =?utf-8?q?floor=2C_ceiling=2C_truncate=2C_round=2C_lcm_do_no?=
 =?utf-8?q?t_conform_to_R7RS_in_S7_Scheme?=
Message-ID: <40880f02-44d3-4f1f-a613-dbd96fd712db.da@liii.pro>

As described in Page 37 of R7RS:
(floor 3.5) => 3.5
But in S7 Scheme:
(floor 3.5) => 3
Tested on Debian 12, the floor routine in GNU Guile 3.0.8 conforms to R7RS.
The following code snippets (Re-define and unit tests) are used to make them conform to R7RS in Goldfish Scheme:
(define s7-floor floor)
(define (floor x)
(if (inexact? x)
(inexact (s7-floor x))
(s7-floor x)))
(define s7-ceiling ceiling)
(define (ceiling x)
(if (inexact? x)
(inexact (s7-ceiling x))
(s7-ceiling x)))
(define s7-truncate truncate)
(define (truncate x)
(if (inexact? x)
(inexact (s7-truncate x))
(s7-truncate x)))
(define s7-round round)
(define (round x)
(if (inexact? x)
(inexact (s7-round x))
(s7-round x)))
(define (floor-quotient x y) (floor (/ x y)))
(define s7-lcm lcm)
(define (lcm2 x y)
(cond ((and (inexact? x) (exact? y))
(inexact (s7-lcm (exact x) y)))
((and (exact? x) (inexact? y))
(inexact (s7-lcm x (exact y))))
((and (inexact? x) (inexact? y))
(inexact (s7-lcm (exact x) (exact y))))
(else (s7-lcm x y))))
(define (lcm . args)
(cond ((null? args) 1)
((null? (cdr args))
(car args))
((null? (cddr args))
(lcm2 (car args) (cadr args)))
(else (apply lcm (cons (lcm (car args) (cadr args))
(cddr args))))))
Unit tests:
(check (floor 1.1) => 1.0)
(check (floor 1) => 1)
(check (floor 1/2) => 0)
(check (floor 0) => 0)
(check (floor -1) => -1)
(check (floor -1.2) => -2.0)
(check (s7-floor 1.1) => 1)
(check (s7-floor -1.2) => -2)
(check (ceiling 1.1) => 2.0)
(check (ceiling 1) => 1)
(check (ceiling 1/2) => 1)
(check (ceiling 0) => 0)
(check (ceiling -1) => -1)
(check (ceiling -1.2) => -1.0)
(check (s7-ceiling 1.1) => 2)
(check (s7-ceiling -1.2) => -1)
(check (truncate 1.1) => 1.0)
(check (truncate 1) => 1)
(check (truncate 1/2) => 0)
(check (truncate 0) => 0)
(check (truncate -1) => -1)
(check (truncate -1.2) => -1.0)
(check (s7-truncate 1.1) => 1)
(check (s7-truncate -1.2) => -1)
(check (round 1.1) => 1.0)
(check (round 1.5) => 2.0)
(check (round 1) => 1)
(check (round 1/2) => 0)
(check (round 0) => 0)
(check (round -1) => -1)
(check (round -1.2) => -1.0)
(check (round -1.5) => -2.0)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20241125/c09ec2f4/attachment.html>

From chris.actondev at gmail.com  Mon Nov 25 07:17:20 2024
From: chris.actondev at gmail.com (Christos Vagias)
Date: Mon, 25 Nov 2024 16:17:20 +0100
Subject: [CM] floor, ceiling, truncate, round,
 lcm do not conform to R7RS in S7 Scheme
In-Reply-To: <40880f02-44d3-4f1f-a613-dbd96fd712db.da@liii.pro>
References: <40880f02-44d3-4f1f-a613-dbd96fd712db.da@liii.pro>
Message-ID: <24DB14A9-05E6-4DEF-8C16-5F5756CAB3A9@gmail.com>

I believe you have a typo and meant to write (floor 3.5 => 3.0 as per R7RS


From bil at ccrma.Stanford.EDU  Mon Nov 25 11:07:34 2024
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Mon, 25 Nov 2024 11:07:34 -0800
Subject: [CM] floor, ceiling, truncate, round,
 lcm do not conform to R7RS in S7 Scheme
In-Reply-To: <40880f02-44d3-4f1f-a613-dbd96fd712db.da@liii.pro>
References: <40880f02-44d3-4f1f-a613-dbd96fd712db.da@liii.pro>
Message-ID: <c528e1d4897de617cdb9c1e3dc8be771@ccrma.stanford.edu>

round et al return integers.  There are no "inexact integers" in
s7 because that notion is a self-contradiction in my opinion.
(It's also completely useless, and leads to talk about
the cloud of values around 0.0 that are considered
integers, apparently because they print as "0.0").