Proposed alternative encoding for stray UTF-8 bytes in strings

[John Cowan]

(If this is too late in the process, I understand.  I think the required
code changes will be small and localized.)

>From the unicode-transition page:

The strategy that I favor in the moment is to handle all string data
> injected into the system transparently, the actual bytes are unchanged and
> unexpected UTF-8 bytes are decoded and marked as a U+DC80 - U+DCFF (low,
> trailing) UTF-16 surrogate pair half.


The trouble with this is that it means the internal representation is no
longer valid UTF-8, which may cause problems down the line, since it is
exposed to anyone dealing with bytevectors.

There is an alternative based on the little-known "noncharacter" range.
Despite the name, these really are perfectly valid characters, but Unicode
guarantees that they will never be assigned to anything in the Real World
and are reserved for internal use.[1]  I propose using them instead of the
surrogate space.  Unfortunately there aren't enough of them to assign one
to each possible stray byte, but we can assign one to each high and low
nybble of each stray byte, analogously to the way Planes 1 to 1F are
handled in UTF-16.

Specifically, given a stray byte whose hex representation is xy, we decode
it as the UTF-8 equivalent of U+FDDx U+FDEy, which is EF B7 9x EF B7 Ay in
the internal encoding, which is now valid UTF-8.  If any of these
noncharacters (coming from a UTF-8 or UTF-16 source) is to be decoded, we
escape it with the UTF-8 representation of U+FFFE, which is EF BF BE, so
that (say) external U+FDDA is decoded as EF BF BE EF B7 AA.  U+FFFE is also
used to escape itself, so it becomes EF BF BE EF BF BE internally.

I hope this is understandable.

[1] See https://www.unicode.org/versions/corrigendum9.html for details.

Re: CHICKEN 6 + R7RS

[John Cowan]

Sorry, yes, I meant `module`. I've been thinking about R6RS so much that
for a moment I lost track of what Chicken's conventions are.

I would point to rename-on-export.  Chicken doesn't support this, and
neither does the R7RS-egg.  Most of the time, Scheme programmers do fine
without it, but when it's needed, it's important for it to be there,
notably when you are trying to write your own base library.

On Sat, Sep 30, 2023 at 5:20 AM  wrote:

> > Yes, that's what I mean.  It would be fine if foo/bar.sld and foo.bar.scm
> > would accept either `library` or `define-library`.
> >
>
> You mean "module" or "define-library", I guess? One could make the
> latter available by default. Depending on how we decide on default
> semantics for syntax-rules, there might be nothing else to do.
>
>
> felix
>
>

Re: CHICKEN 6 + R7RS

[John Cowan]

Yes, that's what I mean.  It would be fine if foo/bar.sld and foo.bar.scm
would accept either `library` or `define-library`.

On Mon, Sep 25, 2023 at 4:15 PM  wrote:

> > I think making r7 syntax by default makes sense as does define- library.
> > Using sld would be good if (foo bar) imported from foo/bar.sld and not
> > foo.bar.scm.
> >
>
> How is supposed to be coded? Would that mean foo/bar.sld holds
> a library definition of this sort:
>
> (define-library (foo bar) ...)
>
> Note that source files are not imported, they are loaded or compiled.
> Importing would take place via some import library named (say)
> "foo.bar.import.so", the source file origin of which could be arbitrary.
>
>
> felix
>
>

Re: CHICKEN 6 + R7RS

[John Cowan]

I think making r7 syntax by default makes sense as does define- library.
Using sld would be good if (foo bar) imported from foo/bar.sld and not
foo.bar.scm.



On Mon, Sep 25, 2023, 2:36 PM  wrote:

> Hello!
>
>
> John Cowan suggested to add R7RS support to the CHICKEN core
> in the forthcoming version 6. It certainly is about time to
> commit a bit more to R7RS (small), since it is, as a standard,
> reasonably established now. The current mode of support as an
> egg works quite well, but still feels a somewhat clunky
> (passing "-X r7rs -R r7rs" to the compiler, for example).
>
> The UTF support to appear in C6 already introduces R7RS bytevectors
> to the core system and it seems to me that core support promises
> a smoother and more efficient integration of these features when
> maintained in combination with the base system.
>
> So, I think it might not be a bad idea to make the jump, and I
> would be very interested in getting feedback and to hear what
> others think of this.
>
> The base system should be as compatible to existing CHICKEN code
> as possible, the UTF transtion will already introduce some pain
> (but hopefully in an obvious way, so that code can be adapted
> quickly). So I suggest to add the R7RS modules that the egg
> currently provides, and compiler options ("-r7rs") and perhaps
> parameters to switch behaviour to full R7RS compliance, for
> example enabling R7RS specific syntax-rules behaviour or to
> make "define-library" available by default.
>
> We may then examine whether completely switching semantics to
> full R7RS for certain parts makes sense, depending on how much
> code still relies on R5RS semantics.
>
> I would also be interested in the ergonomics. An option to
> csc and csi ("-r7rs") sounds simple, but perhaps a different
> file extension (".sld") could also be used to assume R7RS code?
> I'm not quite sure, I haven't thought this through, yet. Ideas
> and suggestions would be _very_ welcome.
>
>
> cheers,
> felix
>
>
>

Re: Extending the #u8(...) notation

[John Cowan]

On Tue, Jun 6, 2023 at 10:39 AM  wrote:

Basically, it just means to allow strings and character literals as
> elements of byte vectors written as "#u8(...)".
>

Any strings and characters, or just ASCII ones?

\This is incompatible to SRFI-4 but similar to SRFI-207.
>

Any particular reason not to support SRFI 207 itself?

Re: absolute pathname a.k.a. realpath

[John Cowan]

Thanks!

On Mon, Oct 24, 2022 at 5:37 PM Evan Hanson  wrote:

(Although technically I don't think realpath(3) is available directly,
> you can use `read-symbolic-link' with the "canonicalize" argument set.)
>

I was actually thinking of SRFI 170, which is a Posix library and does have
real-path.

Re: absolute pathname a.k.a. realpath

[John Cowan]

As designed, the pathname module does not access the filesystem (except
that it knows whether the default is Posix or Windows), and I'd like to
keep it that way.  Realpath is available in the Posix module.

On Mon, Oct 24, 2022 at 1:12 PM Lassi Kortela  wrote:

> Note: The Unix realpath() function returns an abspath with all symlinks
> resolved. Hence all realpaths are abspaths, but not all abspaths are
> realpaths. It would be nice to reflect this terminology in Scheme.
>
>

Re: Status of CHICKEN unicode transition

[John Cowan]

Awesomesauce!  IMAO all your decisions are correct: no kludges.

On Thu, Sep 8, 2022 at 6:13 AM  wrote:

> Hi!
>
> I have pushed branches containing an initial attempt at a UNICDOE
> aware CHICKEN core system. See
>
> http://wiki.call-cc.org/unicode-transition
>
> for details. Comments are welcome.
>
> If you want to test it yourself, follow the instructions in the wiki
> page. Feedback is welcome!
>
>
> felix
>
>
>

Re: Plan for support of UTF-8 in core system

[John Cowan]

this is very good news.  points:

1. bytevectors and srfi 4 u8vectors should be the same type.

2. use r7rs file i/o, binary vs textual











;

On Fri, Jan 21, 2022 at 1:25 PM  wrote:

> Hi!
>
> Bevuta IT GmbH has kindly agreed to sponsor some work on CHICKEN and I
> suggest
> to start on full unicode support in the core system, getting rid of
> the current solution with a bolted-on utf8 egg.
>
> This is certainly non-trivial, but necessary, as there have been numerous
> requests by users in the past and the current solution is just too clunky
> to be useful or efficient. Also, for better R7RS support a fully integrated
> solution is preferable.
>
> I have talked with sjamaan about this and collected some details of our
> current proposal here:
>
> http://wiki.call-cc.org/unicode-transition
>
> If you have comments or suggestions, please don't hesitate to share them
> here
> or extend the wiki page.
>
>
> felix
>
>
>

Re: Release process?

[John Cowan]

Just a note on #1675: the max amount of virtual memory in a 64-bit system's
user space is 2^47 bytes, or 1024 TB.  This is out of range for current
machines, but I note that HP has recently demoed a monolithic server with
160 TB of physical memory.


On Fri, Aug 6, 2021 at 4:59 AM Peter Bex  wrote:

> Hi all,
>
> Evan just closed the last ticket in our roadmap for 5.3
> (https://bugs.call-cc.org/roadmap).  So I think now is a good
> time to start the (pre)release process.
>
> However, there are a few questions remaining regarding uninstallation
> of files and the file tree in the README.  Should we wait until those
> are resolved?  Is anyone working on them at all?
>
> Cheers,
> Peter
>

Re: `make uninstall` does not uninstall the chicken-do manpage

[John Cowan]

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/rmdir
and my own Windows experience say that Windows rmdir behaves the same as
Posix rmdir.  A long time ago I used a system in which if you deleted an
empty directory foo, all its files became children of foo's parent, but
that idea never became popular.


On Wed, Aug 4, 2021 at 3:02 PM Lassi Kortela  wrote:

> > Indeed, that does the trick on *nix, even though we won't be able to
> > catch rmdir errors in case it fails on empty directories, but I think
> > that's not too bad in this case.
>
> Agreed. It will just write an error message on stderr in that case.
>
> > Any idea how to do something equivalent on Windows?
>
> A web search shows that Windows also has an "rmdir" command and it
> should work the same way as the Unix command for this purpose, but I
> haven't tested it:
>
> https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/rmdir
>
>

Re: `make uninstall` does not uninstall the chicken-do manpage

[John Cowan]

On Wed, Aug 4, 2021 at 2:38 PM Mario Domenech Goulart 
wrote:

I think the slightly tricky thing is finding out whether the directories
> are actually empty after the CHICKEN core files are deleted (e.g., some
> other program wrote files in there for whatever reason).  In case the
> directories are not empty after the deletion of CHICKEN core files, I
> think they should NOT be deleted.
>

In no universe are you allowed to delete empty directories anyway.  So just
rmdir each expected directory bottom-up and ignore errors.

Re: uname -o does not exist on mac

[John Cowan]

Thanks!  You should see if Chibi has the same problem, since it uses a
very similar Makefile.detect.

On Sun, Jul 18, 2021 at 5:02 AM Lassi Kortela  wrote:

> Here's a small patch to silence a warning in `make` output on systems
> where the `uname` command does not have the `-o` flag.
>
> diff --git a/Makefile.detect b/Makefile.detect
> index 10d36545..9694b125 100644
> --- a/Makefile.detect
> +++ b/Makefile.detect
> @@ -19,7 +19,7 @@ else
>
>   # Now we can use uname tests
>   uname_s:=$(shell uname)
> -uname_o:=$(shell uname -o)
> +uname_o:=$(shell uname -o 2>/dev/null)
>
>   # Check for specific platforms
>   ifeq ($(uname_o),Msys)
>
>

Re: #chicken has moved to Libera.Chat

[John Cowan]

The server name is "libera.chat".

On Wed, May 26, 2021 at 8:38 AM elf  wrote:

> How  does one access the libera.chat network? What is the servername etc?
>
> -elf
>
> On 26 May 2021 14:26:07 GMT+03:00, Mario Domenech Goulart <
> ma...@parenteses.org> wrote:
> >Hi,
> >
> >The CHICKEN Team has decided to move the #chicken IRC channel to the
> >Libera.Chat network.
> >
> >Our main IRC representative (vandusen) is already there and our
> >documentation has been updated.
> >
> >In case you use IRC, see you there!
> >
> >All the best.
> >Mario
>
>

Re: [PATCH] force finalizers only if finalizers exist

[John Cowan]

The Right Thing is probably to eventually run the GC on a private thread,
at least when multiple threads are running at all.  That way the finalizers
run on the same thread that doesn't hold any locks or otherwise risk
trouble.  That's what the JVM and the CLR do.

On Wed, May 6, 2020 at 5:42 AM  wrote:

> > There might be a situation where a thread is already executing
> > ##sys#run-pending-finalizers, but has run out of its time slice, or gc
> > interrupted or something. In this situation running
> > ##sys#run-pending-finalizers only once might not be enough.
>
> This is basically true, but with threads we make no effort to terminate
> them properly once the main thread exists - all unjoined threads will die
> anyway,
> regardless of what they are currently doing.
>
> Also, the interplay between threads and finalizers is more or less
> undefined - interrupts are executed in whatever thread happens to be
> active and manually forcing finalizers in a different thread than the
> main thread is already asking for trouble. This is a known problem of
> the threading/interrupt system and needs to be solved differently.
>
>
> felix
>
>
>
>

Re: Fwd: Comments on draft #3

[John Cowan]

The behavior of a macro keyword in operand position is not affected by the
patch.

On Sun, May 3, 2020 at 1:04 PM Peter Bex  wrote:

> On Sun, May 03, 2020 at 12:55:40PM -0400, John Cowan wrote:
> > This is the first of two patches that allow macros to be expanded when
> they
> > appear in operand position, so that if pi is a macro for 3.14159, then
> (+ 5
> > pi) will be expanded to (+ 5 3.14159).  This allows macros that work like
> > procedures in the sense that they can be passed as operands.
> >
> > This patch works for er-macros and ir-macros.  Basically if a low-level
> > macro is found in operand position, rather than an a syntax error,
> whatever
> > the macro expands into is substituted.
>
> To me it seems this introduces an ambiguity between (foo) and foo.
> What if foo is a macro that expands to a procedure?  Then
> (apply foo '()) would then be identical to (apply (foo) '()),
> unless I'm misunderstanding something.  I would find that highly
> undesirable.
>
> Cheers,
> Peter
>

Fwd: Comments on draft #3

[John Cowan]

This is the second of two patches that allow macros to be expanded when
they appear in operand position.  It allows a syntax-rules pattern to be a
single variable rather than a list; this rule will be used when the macro
keyword is in operand position.

-- Forwarded message -
From: Marc Nieper-Wißkirchen 
Date: Sun, May 3, 2020 at 12:10 PM
Subject: Re: Comments on draft #3
To: John Cowan 
Cc: , Lassi Kortela 


With the attached patch, SYNTAX-RULES macros now allow a single identifier
as a top-level pattern, which matches the whole form:

(define-syntax foo
  (syntax-rules ()
(x (begin (display 'x) (newline)

foo ;Expands into code that displays "foo".

Am So., 3. Mai 2020 um 17:51 Uhr schrieb Marc Nieper-Wißkirchen <
m...@nieper-wisskirchen.de>:

> Am So., 3. Mai 2020 um 11:06 Uhr schrieb Marc Nieper-Wißkirchen <
> m...@nieper-wisskirchen.de>:
>
> [...]
>
>
>> I bet that implementing identifier macros in any Scheme system is a
>> work of less than one day each. Already now every Scheme system
>> handles macro keywords, which are not in head position, (usually by
>> throwing an error). To make it usable in systems without
>> ER-MACRO-TRANSFORMER and SYNTAX-CASE, a top-level pattern in
>> SYNTAX-RULES, which just consists of an identifier has to be allowed
>> (as all other patterns won't match).
>>
>
> To prove that my bet is not insubstantial, I have attached a patch for the
> Chicken implementation of Scheme. With the patch (it may need to be
> polished by the maintainers of Chicken), transformers associated with
> keywords are now also invoked when the keyword is not in head position.
>
> The following example will expand `foo' into #f and display "foo" on the
> console.
>
> (define-syntax foo
>   (er-macro-transformer
> (lambda (x r c)
>   (display x)
>   (newline)
>   #f))
>
> foo
>
> Although I have just installed the Chicken source code, which is still
> alien to me, it took me less than two hours to get the thing done.  I
> shouldn't be a hurdle for other implementations as well.
>
> Marc
>
From 73a2cce9168b451e83e92fe5e85380d43e9da657 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Nieper-Wi=C3=9Fkirchen?= 
Date: Sun, 3 May 2020 18:07:32 +0200
Subject: [PATCH 2/2] Add a single identifier top-level pattern to
 syntax-rules.

---
 synrules.scm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/synrules.scm b/synrules.scm
index d0919862..4a8c46f5 100644
--- a/synrules.scm
+++ b/synrules.scm
@@ -138,7 +138,7 @@
   (define (make-transformer rules)
 `(##sys#er-transformer
   (,%lambda (,%input ,%rename ,%compare)
-	(,%let ((,%tail (,%cdr ,%input)))
+	(,%let ((,%tail (,%cond ((,%pair? ,%input) (,%cdr ,%input)) (,%else ,%input
 	  (,%cond ,@(map process-rule rules)
 		  (,%else (,%syntax-rules-mismatch ,%input)))
 
@@ -146,7 +146,9 @@
 (if (and (pair? rule)
 	 (pair? (cdr rule))
 	 (null? (cddr rule)))
-	(let ((pattern (cdar rule))
+	(let ((pattern (if (pair? (car rule))
+			   (cdar rule)
+			   (car rule)))
 	  (template (cadr rule)))
 	  `((,%and ,@(process-match %tail pattern #f))
 	(,%let* ,(process-pattern pattern
-- 
2.20.1

Fwd: Comments on draft #3

[John Cowan]

This is the first of two patches that allow macros to be expanded when they
appear in operand position, so that if pi is a macro for 3.14159, then (+ 5
pi) will be expanded to (+ 5 3.14159).  This allows macros that work like
procedures in the sense that they can be passed as operands.

This patch works for er-macros and ir-macros.  Basically if a low-level
macro is found in operand position, rather than an a syntax error, whatever
the macro expands into is substituted.

-- Forwarded message -
From: Marc Nieper-Wißkirchen 
Date: Sun, May 3, 2020 at 11:51 AM
Subject: Re: Comments on draft #3
To: John Cowan 
Cc: , Lassi Kortela 


Am So., 3. Mai 2020 um 11:06 Uhr schrieb Marc Nieper-Wißkirchen <
m...@nieper-wisskirchen.de>:

[...]


> I bet that implementing identifier macros in any Scheme system is a
> work of less than one day each. Already now every Scheme system
> handles macro keywords, which are not in head position, (usually by
> throwing an error). To make it usable in systems without
> ER-MACRO-TRANSFORMER and SYNTAX-CASE, a top-level pattern in
> SYNTAX-RULES, which just consists of an identifier has to be allowed
> (as all other patterns won't match).
>

To prove that my bet is not insubstantial, I have attached a patch for the
Chicken implementation of Scheme. With the patch (it may need to be
polished by the maintainers of Chicken), transformers associated with
keywords are now also invoked when the keyword is not in head position.

The following example will expand `foo' into #f and display "foo" on the
console.

(define-syntax foo
  (er-macro-transformer
(lambda (x r c)
  (display x)
  (newline)
  #f))

foo

Although I have just installed the Chicken source code, which is still
alien to me, it took me less than two hours to get the thing done.  I
shouldn't be a hurdle for other implementations as well.

Marc
From 32416f1e97f6ccdecf858ff8cbc41a55a4099afb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Nieper-Wi=C3=9Fkirchen?= 
Date: Sun, 3 May 2020 17:43:21 +0200
Subject: [PATCH] Implement identifier macros for er/ir-macro-transformer.

---
 core.scm   |  20 +++---
 eval.scm   | 204 +++--
 expand.scm |  99 ++
 3 files changed, 169 insertions(+), 154 deletions(-)

diff --git a/core.scm b/core.scm
index 584c3453..f84fd619 100644
--- a/core.scm
+++ b/core.scm
@@ -637,7 +637,11 @@
 
   (define (walk x e dest ldest h outer-ln tl?)
 (cond ((keyword? x) `(quote ,x))
-	  ((symbol? x) (resolve-variable x e dest ldest h))
+	  ((symbol? x)
+	   (emit-syntax-trace-info x #f)
+	   (let ((xexpanded (expand x (##sys#current-environment) #f)))
+	 (if (not (eq? x xexpanded)) (walk xexpanded e dest ldest h outer-ln tl?)
+		 (resolve-variable x e dest ldest h
 	  ((not (pair? x))
 	   (if (constant? x)
 	   `(quote ,x)
@@ -793,15 +797,15 @@
   vars tmps)
 			   (##core#let () ,@body) ) )
 			e dest ldest h ln #f)))
-  
+
 ((##core#with-forbidden-refs)
  (let* ((loc (caddr x))
 (vars (map (lambda (v)
  (cons (resolve-variable v e dest
- ldest h) 
+ ldest h)
loc))
 (cadr x
-   (fluid-let ((forbidden-refs 
+   (fluid-let ((forbidden-refs
  (append vars forbidden-refs)))
  (walk (cadddr x) e dest ldest h ln #f
 
@@ -2129,10 +2133,10 @@
 (not (db-get db name 'global))
 (not (db-get db name 'unknown))
 (eq? '##core#lambda (node-class val))
-(not (llist-match? (third (node-parameters val)) 
+(not (llist-match? (third (node-parameters val))
(cdr subs
 (quit-compiling
-		  "known procedure called with wrong number of arguments: `~A'" 
+		  "known procedure called with wrong number of arguments: `~A'"
 	  (real-name name)))
 		 (collect! db name 'call-sites (cons here n
 	 (walk (first subs) env localenv fullenv here)
@@ -2773,8 +2777,8 @@
 		  boxedaliases) ))
    (if (null? aliases)
    body
-   (make-node 'let (list (car aliases)) 
-		  (list (car values) 
+   (make-node 'let (list (car aliases))
+		  (list (car values)
 			(loop (cdr aliases) (cdr values))
  body) ) ) )
 		(let ((cvars (map (lambda (v) (ref-var (varnode v) here closure))
diff --git a/eval.s

Re: Exposing subsecond precision in current-seconds

[John Cowan]

Such a procedure is in SRFI 170: (posix-time).

As I pointed out in #chicken, gettimeofday() has been obsolete since 2008,
per Posix, which recommends clock_gettime(), which is precise (of course
not accurate) to nanoseconds and has been part of Posix since 1997.  Not
that getttimeofday() is likely to go away, but more precision is better
than less.'

On Windows 8 and later, you can use GetSystemTimePreciseAsFileTime, which
returns the number of 100-nanosecond clunks since the beginning of the year
1601 proleptic UTC.

On Mon, Apr 27, 2020 at 2:31 PM Lassi Kortela  wrote:

> SRFI 174 (POSIX Timespecs) provides a datatype for a seconds-nanoseconds
> pair. 
>
> It doesn't define any procedures to get the current time.
>
>

Re: [PATCH] use -rpath option

[John Cowan]

Again, amazing.  Does this mean that Chicken *output* can also be built
with tcc?  Now that the compiler is modularized, that would give Chicken a
dynamic compiler.

On Tue, Mar 24, 2020 at 9:03 AM  wrote:

> felix.winkelm...@bevuta.com wrote:
> > This patch replaces the use of the "-R" linker option by "-rpath", which
> appears to be
> > more portable (accepted by tcc, for example). According to the GNU ld
> manual, -R is
> > actually a compatibility alias for -rpath, so the latter seems to be
> more canonical.
> > The manual page for Solaris' ld lists only -R, so on that platform we
> still use it.
>
> Pushed, thank you!
>
> I also took the liberty to push the remaining change needed to make
> CHICKEN build with TCC.
>

Re: [PATCH] Implement platform autodetection when possible

[John Cowan]

Thanks for wrapping this effort up.  I think it will make Chicken easier to
build for both new users and Chicken developers.

On Mon, Mar 9, 2020 at 6:06 PM Evan Hanson  wrote:

> Hi there,
>
> Here's a signed-off version of the latest patch, including removing the
> handling of iOS as John suggested. I've also fixed the capitalisation of
> the Haiku platform name, added a bit more info to the NEWS entry, and
> moved it into the correct section.
>
> This has been tested and works correctly on the following platforms:
>
>  - Cygwin
>  - DragonflyBSD
>  - FreeBSD
>  - Haiku
>  - Linux
>  - MSYS2
>  - MinGW
>  - NetBSD
>  - OpenBSD
>
> Given that the PLATFORM can still be provided manually, I'm happy for
> this to go in. Thank you to John for the changes, and to Alex for the
> detection code in the first instance.
>
> Evan
>

Re: Patch for autodetection of platforms

[John Cowan]

I don't feel like filing another patch at this point, but since iOS is a
cross-compilation target, the 3 lines for iOS should just be removed from
Makefile.detect before it is merged.

On Mon, Dec 30, 2019 at 2:25 PM John Cowan  wrote:

> This patch supersedes all other patches and correctly distinguishes
> between mingw, mingw-msys, and cygwin.  It is also more efficient (only
> runs uname twice) and doesn't have a zillion trailing endifs.
>
>
> On Sat, Dec 28, 2019 at 11:24 AM Peter Bex  wrote:
>
>> On Thu, Dec 19, 2019 at 11:19:16AM -0500, John Cowan wrote:
>> > Here's the second patch I mentioned on #chicken.
>>
>> Hi John,
>>
>> I've tried these two patches, but found several problems with them:
>>
>> - The endif in the second patch is misplaced, so on UNIX, platform
>>   detection was skipped completely.  Easily fixed by moving one endif
>>   to the very end.
>> - The quotes in mingw-msys and mingw would be taken literally and this
>>   would result in an error about not being able to find a file named
>>   Makefile."mingw-msys".  Also easily fixed.
>> - The ComSpec environment variable is not defined in Mingw32-msys.
>>   There, it is called COMSPEC (in all caps).  Therefore, it didn't
>>   work properly.  I was able to fix this by changing the check from
>>   ifdef ComSpec to ifneq ($(COMSPEC)$(ComSpec),) so that both variables
>>   concatenated aren't empty.
>> - Finally, I ran into a problem that I couldn't fix: SHELL is defined
>>   as sh.exe on Mingw32 (without msys).  I don't know how to make the
>>   distinction between mingw and mingw-msys.
>>
>> I'm not super happy with the unreadable mess of endifs (like you see in
>> my first bullet point, this results in real problems), but I think the
>> change itself brings a convenience that I think is worthwhile enough to
>> pursue it anyway.
>>
>> So, could you try to fix the final issue with mingw/mingw-msys detection?
>>
>> I've attached a new version of the patch where I fixed the issues I was
>> able to fix.  Obviously, this should *not* be pushed yet until the mingw
>> issue is fixed.
>>
>> Cheers,
>> Peter
>>
>

Re: Patch for autodetection of platforms

[John Cowan]

This patch supersedes all other patches and correctly distinguishes between
mingw, mingw-msys, and cygwin.  It is also more efficient (only runs uname
twice) and doesn't have a zillion trailing endifs.


On Sat, Dec 28, 2019 at 11:24 AM Peter Bex  wrote:

> On Thu, Dec 19, 2019 at 11:19:16AM -0500, John Cowan wrote:
> > Here's the second patch I mentioned on #chicken.
>
> Hi John,
>
> I've tried these two patches, but found several problems with them:
>
> - The endif in the second patch is misplaced, so on UNIX, platform
>   detection was skipped completely.  Easily fixed by moving one endif
>   to the very end.
> - The quotes in mingw-msys and mingw would be taken literally and this
>   would result in an error about not being able to find a file named
>   Makefile."mingw-msys".  Also easily fixed.
> - The ComSpec environment variable is not defined in Mingw32-msys.
>   There, it is called COMSPEC (in all caps).  Therefore, it didn't
>   work properly.  I was able to fix this by changing the check from
>   ifdef ComSpec to ifneq ($(COMSPEC)$(ComSpec),) so that both variables
>   concatenated aren't empty.
> - Finally, I ran into a problem that I couldn't fix: SHELL is defined
>   as sh.exe on Mingw32 (without msys).  I don't know how to make the
>   distinction between mingw and mingw-msys.
>
> I'm not super happy with the unreadable mess of endifs (like you see in
> my first bullet point, this results in real problems), but I think the
> change itself brings a convenience that I think is worthwhile enough to
> pursue it anyway.
>
> So, could you try to fix the final issue with mingw/mingw-msys detection?
>
> I've attached a new version of the patch where I fixed the issues I was
> able to fix.  Obviously, this should *not* be pushed yet until the mingw
> issue is fixed.
>
> Cheers,
> Peter
>


0001-Implement-platform-autodetection.patch
Description: Binary data

Re: Time to make a 5.2.0 release candidate?

[John Cowan]

I should mention that credit goes mostly to Alex Shinn and only some of it
to me.  And yes, giving an explicit PLATFORM always works; this code is
triggered only if PLATFORM is not defined.  As opposed to empty, in which
case you get, as an artifact of how it's implemented, the good old "Set
PLATFORM to one of these" text.

I would say the biggest risk is that you want a cross-build and forget to
specify PLATFORM, in which case you get a native build.  Which isn't much
of a risk.


On Sat, Dec 28, 2019 at 7:56 PM  wrote:

> > Hi Peter,
> >
> > On 12/28/19 4:42 PM, Peter Bex wrote:
> > > I think we're about ready to start the process for a 5.2.0
> > > release.  What do you think?  Should we wait for the eggs
> > > from #1655 to be fixed?
> > >
> > > What about the plaform auto-detection  patch?
> >
> > IMO we should try to fix the eggs but wait until after a new release to
> > add the autodetection patch.
> >
>
> It would of course be better to fix the eggs first, but this might take
> time,
> especially since some maintainers may not react instantly. We should
> perhaps in general think about whether eggs broken by fixing bugs should
> hold off the release process, particularly with a growing number of eggs.
> #1655 fixed a genuine bug and the eggs that broke with this change took
> advantage of this inconsistency, admittedly being tricked into believing
> that adding arbitrary .c files to the command-line of csc would work. This
> was simply overlooked in the design of the custom-build feature and
> therefore caused the c-object egg components to be added.
>
> For the autodetection patch: As I understand it, giving an explicit
> PLATFORM
> should work in all cases, so not too much is lost, if particular systems
> give
> trouble. Unless it takes serious effort to test all supported
> Windows platform variants (which are the most difficult cases, IIRC) then
> I
> think it would be a nice simplification.
>
>
> felix
>
>
>
>

Re: Patch for autodetection of platforms

[John Cowan]

Here's the second patch I mentioned on #chicken.

On Wed, Dec 18, 2019 at 6:48 PM John Cowan  wrote:

> With this patch, you don't need to specify PLATFORM unless
> cross-compiling, but if you do it will still be respected.
>


0002-fixed-mingw-msys-detection-added-to-NEWS-and-manifes.patch
Description: Binary data

Patch for autodetection of platforms

[John Cowan]

With this patch, you don't need to specify PLATFORM unless cross-compiling,
but if you do it will still be respected.


0001-Implements-platform-auto-detection-when-possible.patch
Description: Binary data

Re: [Chicken-hackers] [PATCH] Distinguish between positive and negative zero in flonums

[John Cowan]

On Mon, Jul 29, 2019 at 5:39 AM  wrote:


> (signum -0.0) => 0.0 seems totally right to me.
> >
>
> I wholeheartily disagree.
>

Here's my argument:  The signum function's definition guarantees that if
its argument is equal to zero, its result is equal to zero.  Since (= 0.0
-0.0) => #t, that guarantee is preserved.  However, in the case that you
want the sign of an underflowed value (which is the whole point of negative
zero), you can detect it if you want to.  For example, you can use (/ 1.0
result), which produces +inf.0 or -inf.0 respectively.


John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Distinguish between positive and negative zero in flonums

[John Cowan]

That seems totally right to me.

On Sun, Jul 28, 2019 at 1:06 AM Evan Hanson  wrote:

> Thanks Peter, applied.
>
> On Sat, Jun 29, 2019 at 03:26:54PM +0200, Peter Bex wrote:
> > I'm not happy with the hacky way the reader deals with these, but I could
> > not really come up with a clean solution for it.  Suggestions for
> > improvement are welcome.
>
> I experimented a bit with splitting the "go negative" logic from the "go
> inexact" logic to perhaps make things more clear and avoid passing a
> boolean around, but it didn't really help.
>
> One thing I noticed is that now (signum -0.0) => -0.0. Does that seem
> right? If so, it may be worth documenting that it's both exactness and
> sign-preserving.
>
> Evan
>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that define-record-printer is not a definition

[John Cowan]

Scheme doesn't yet have any way to print record types specially; all you
get is whatever the implementation chooses to supply.  Consequently, there
is nothing like define-report-printer in any records SRFI.


On Fri, Jul 12, 2019 at 7:04 PM Evan Hanson  wrote:

> On 2019-07-12 10:45, Peter Bex wrote:
> > > In any case, I think we should try to address the issue one way or the
> > > other rather than keep a potential pitfall around. If we don't make it
> a
> > > "real" (i.e. fake) definition, could we at least introduce a new name
> > > and encourage its use? Perhaps `set-record-printer!', maybe even with a
> > > SRFI 17 setter on the type descriptor? Unfortunately, we probably can't
> > > remove the old name, since it comes from SRFI 99. But again, making it
> > > an actual definition seems OK to me.
> >
> > It's not from SRFI-99 (or SRFI-9) AFAICT.  We can rename it, but that's
> > a breaking change.  Of course we could keep around the old one during a
> > deprecation phase.
>
> Oh, indeed. The srfi-99 egg includes it so I assumed it came from the
> SRFI, but that must just be for compatibility with CHICKEN.
>
> Evan
>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

[John Cowan]

On Sun, Jun 30, 2019 at 9:57 AM Peter Bex  wrote:

Captured simply means that it needs to be wrapped up in the closure,
> AFAIK.  But if it's replaced, then the original variable will need
> to end up in the closure.  The only case where you can't replace is
> if either variable is assigned to, because then they don't point to
> the same thing anymore.
>

Obviously this is not something you can do in a patch,
but at some point Chicken may want to go
over to the assignment conversion strategy, in which all mutable
local variables are transformed into immutable references to boxes.

When the original code uses such a variable, it becomes a
call on box-ref, and a set! of such a variable becomes a call
on box-set!  Eventually the box will be reclaimed by the
garbage collector.  Local mutable variables are rare enough
that this does not create significant memory pressure.

Chez and perhaps other compilers use this transformation because
of how much it simplifies bookkeeping.  In ML, it's actually exposed
to the programmer, and the *only* mutable thing are boxes ("refs")
and mutable arrays.  But of course ML is not Scheme.


John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
The experiences of the past show that there has always been a discrepancy
between plans and performance.--Emperor Hirohito, August 1945
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Emit C99 constants for +nan.0 and [+-]inf.0 `##core#float' nodes

[John Cowan]

Done; < https://bugs.call-cc.org/ticket/1627#ticket >.

On Thu, Jun 27, 2019 at 10:26 PM Evan Hanson  wrote:

> On 2019-06-27 21:27, John Cowan wrote:
> > No, you do.  If a Schemer writes (/ 1.0 -0.0) the result must be
> > -inf.0, not +inf.0.
>
> OK, but I think that's a separate issue, because currently if a CHICKEN
> user writes (/ 1.0 -0.0) they get +inf.0. And -0.0 gets them 0.0.
>
> It sounds like this might be worth a bug report (would you be so kind?).
> But, for the purposes of this patch, there is no negative zero.
>
> Cheers,
>
> Evan
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Emit C99 constants for +nan.0 and [+-]inf.0 `##core#float' nodes

[John Cowan]

No, you do.  If a Schemer writes (/ 1.0 -0.0) the result must be -inf.0,
not +inf.0.  But that fact leads to a better way to compile a negative zero
into C:
(1.0 / (-INFINITY)).  No unions needed.

On Thu, Jun 27, 2019 at 6:50 PM Evan Hanson  wrote:

> Hi John,
>
> On 2019-06-27 18:28, John Cowan wrote:
> > Don't forget to cast them to double, however.
>
> Good point. Updated version attached.
>
> > To get a negative zero you need an initialized global variable:
>
> I'm not sure we need a negative zero here, do we?
>
> Evan
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Emit C99 constants for +nan.0 and [+-]inf.0 `##core#float' nodes

[John Cowan]

Don't forget to cast them to double, however.

To get a negative zero you need an initialized global variable:

double negative_zero = 1.0 / -INFINITY;

and then negative_zero is the Right Thing.


On Thu, Jun 27, 2019 at 5:20 PM Evan Hanson  wrote:

> Putting this here so it doesn't get lost.
>
> Evan
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Pessimizing undefined behavior

[John Cowan]

On Thu, Apr 4, 2019 at 11:41 AM megane  wrote:

The R5RS says (1.3.2) that the value of an expression with undefined
> (actually "unspecified") value has to be a valid scheme value
> ("object"), and it's up to the implementation what that value is.


That's true.  But a violation of syntax, which (begin) is, is what the
RnRS calls "an error", which is the same as "undefined behavior"
in other standards.  The program can misbehave in arbitrary ways,
and in particular the compiler is free to reject such programs
(which amounts to a failure before the program starts to run).

This is the same case as (car 1) or (substring "abc" n (- n 1))
or (let ((x 10) (x 20) ) x) or in particular (if #t).
It is completely different from (set! x 32) which returns an
unspecified value, the case you describe above.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Half the lies they tell about me are true.
--Tallulah Bankhead, American actress
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Pessimizing undefined behavior

[John Cowan]

On Tue, Apr 2, 2019 at 12:10 PM  wrote:

> > And it has to be error, not just a warning. Otherwise the warning just
> > flashes by while you're getting some coffee.
>
> That's the point - it is an error under your interpretation only. It's
> still perfectly legal code, even if it may not make sense.
>

It's also an error under R5RS, which defines this kind of begin (the
expression type as opposed to the top-level type with mixed
definitions and expressions) as (begin   ...).
See section 4.2.3 of R5RS (same story in R7RS).

That doesn't mean an implementation *can't* assign a meaning to
(begin), but I wouldn't call it "perfectly legal", except in the sense
that (if) or (if #t) are perfectly legal (which are syntax errors in
Chicken).

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Pessimizing undefined behavior

[John Cowan]

On Mon, Apr 1, 2019 at 11:26 PM megane  wrote:

When the scrutinizer walks (begin) it knows the returned value is
> undefined.
>
> The value or behaviour of (if (begin) 1 #t) is not defined by R5RS.
>
> AFAIK if it's not defined then whatever the implementation chooses to do
> is OK.
>

> In this case the whole expression can be therefore optimized to 1.


In my opinion, this is not a good direction for implementations of any
language
to go.  The Chicken community has been repeatedly bitten by the increasing
tendency of C compilers to do whatever they want rather than whatever makes
sense in the context of undefined behavior (the C equivalent of "is an
error").

There are some great horror stories, like a null-pointer check being removed
from the compiled code because prior to the check the pointer was
dereferenced (which is of course wrong) and the compiler "knew"
as a result that the pointer could never be null.  When it was, boom.
Similarly, printf-style debugging can be made unusable
if a printf is written just before a dubious
routine is called; if the routine is UB under all circumstances (as by using
a variable before initializing it), the failure can be hoisted above the
printf!

In Scheme, whoever writes (begin) in a value context, even as a result
of macro expansion, is almost certainly making a mistake,
and the Right Thing IMO is to report an error, not to pessimize the code.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Promises become binding when there is a meeting of the minds and
consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
   --Specht v. Netscape
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Patch for ticket #1587

[John Cowan]

I agree also given the existence of complex demotion in Chicken, whereby
(make-rectangular 1.0 0.0) => (the flonum 1.0).  On the other hand, I think
complex demotion is actually a Bad Thing because it means that inexactness
in the computation of the imaginary part can make an inexact complex number
into a real number, even though the imaginary part isn't truly zero.

On Thu, Feb 28, 2019 at 3:44 PM  wrote:

> > On Thu, Feb 28, 2019 at 02:25:33PM -0500, John Cowan wrote:
> > > See the ticket for explanations.
> >
> > After discussing on IRC, I'm not sure I believe this is correct.
> > Given that we don't support complex numbers of mixed exactness, it
> > makes more sense to return 0.0 for the imaginary part of a flonum.
> >
> > Inexactness is contagious in complex numbers; if any of the two
> > parts are inexact, the entire number is inexact.  I think it's
> > quite counter-intuitive to return exact zero for the imaginary part
> > of a flonum, even though we know it to be "not there", so exactly
> > zero.  So given that, I would lean towards keeping the current
> > behaviour, especially since this would strictly speaking require
> > us to go through the change request process.
> >
> > What do others think about this?
> >
>
> Exactness-preservation is exactly the right thing, I think.
>
>
> felix
>
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Patch for ticket #1587

[John Cowan]

See the ticket for explanations.

diff --git a/library.scm b/library.scm
index 6a089955..02b5af36 100644
--- a/library.scm
+++ b/library.scm
@@ -1737,7 +1737,6 @@ EOF
 (set! scheme#imag-part
   (lambda (x)
 (cond ((cplxnum? x) (%cplxnum-imag x))
- ((##core#inline "C_i_flonump" x) 0.0)
  ((number? x) 0)
  (else (##sys#error-bad-number x 'imag-part)) )))
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Request for a small Chicken library in C

[John Cowan]

I haven't written any C code for Chicken since version 3 days, and to save
me some time re-learning., I'd like to see if anyone's willing to write
some for me.  What I need is an implementation of the four native IEEE
procedures (single and double ref and set) in the R6RS bytevectors library,
documented at <
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-3.html#node_sec_2.8>.
I can't find any Scheme implementations that are both portable and portably
accurate (I've experimented with SRFI 56 and the sample R6RS implementation
at r6rs.org).

The contract for the four routines is that they accept a byte vector and an
offset, and read or write an inexact number into the bytevector as 4 or 8
bytes with the native endianism, depending on whether it is an ieee-single
procedure or an ieee-double procedure.  The easiest way to do this in C is
with a couple of unions that map a float or double onto an array of 4 or 8
chars, like these:

union float_map {
  float f;
  char c[4];
}

union double_map {
  double d;
  char c[4];
}

This is in aid of SRFI 160, the proposed heterogeneous vector library for
R7RS-large.  Can anyone help?  Thanks.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules

[John Cowan]

On Wed, Aug 29, 2018 at 4:21 PM  wrote:


> I don't see the motivation for installing files outside of the chicken
> installation
> tree, so it is not clear to me what you want to achieve with this.
>

>From what I understand (which may be wrong) it's so that chicken-install
can put a
file in a place expected by some external library.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
If I read "upcoming" in [the newspaper] once more, I will be downcoming
and somebody will be outgoing.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] strange csc-warning (Version 4.13.0)

[John Cowan]

I've reformatted your code to Lisp standard style (2 spaces instead of
tabs, no parens on their own lines) for better readability.

(define strange-warning (lambda (sym options)
  (let ((el (assq sym options)))
(if (pair? el)
  (if (list? el)
"list"
(cdr el)) ; <== strange warning here
  "found nothing"

While this code is hard to understand, the warning is incorrect.  In
particular, if el => (a . b), then it is a pair but not a list, and the
(cdr el) branch will be taken correctly, returning b.  This is a minor
compiler bug on at least two levels: no warning should be produced, and the
reference to "false" is incorrect.  You should file a bug at bugs.callcc.org
.

I would say that discriminating between pairs and lists this way is a bad
idea: you should always use lists with a car that distinguishes the two
types of values you want to treat differently.  In particular, pair? is
O(1) whereas list? is O(n) in the length of the list.  There's such a thing
as carrying dynamic typing too far.

(define no-warning (lambda (sym options)
  (let ((el (assq sym options)))
(if (list? el)
  "list"
  (if (pair? el)
(cdr el) ; <== no warning here
"found nothing")

No warning is to be expected.  Again, if el => (a . b), it will fail the
list? test but pass the pair? test, and taking its cdr will produce b.
However, this code is *not* semantically identical with strange-warning.
If el is (), then it is a list but not a pair, and this procedure will
return "list", whereas strange-warning will return "found nothing".

(define also-no-warning (lambda (sym options)
  (define el (assq sym options))
  (if (pair? el)
(if (list? el)
  "list"
  (cdr el)) ; <== also no warning here
"found nothing")))

Again, no warning is to be expected.  The fact that strange-warning
triggers a warning but also-no-warning does not is very mysterious.



On Sat, Jun 30, 2018 at 5:18 AM, Martin Schneeweis 
wrote:

> Hi,
>
> the attached file contains 3 procedures
>
>   a) strange-warning
>   b) no-warning
>   c) also-no-warning
>
> (a) and (b) should be semantically identical - just the if's are
> rearranged.
>
> "csc strange-warning.scm" produces a type-warning for (a) but not for
> (b):
>
>   ...call to `cdr', expected argument #1 of type `pair' but was given
>   an argument of type `false'...
>
> (c) has the same if-arrangement as (a) - but the let-form is replaced
> with a define-form.
>
> If you are wondering: i reduced my original procedure to the minimum -
> the original version is a procedure that returns the value for a key in
> an association list using either "cdr" or "cadr" depending on the type
> of the assq-return-value.
>
> lg
> Martin
>
> 
> chicken -version
> (c) 2008-2017, The CHICKEN Team
> (c) 2000-2007, Felix L. Winkelmann
> Version 4.13.0 (rev 68eeaaef)
> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
> compiled 2017-12-11 on yves.more-magic.net (Linux)
>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Eggs for Chicken 5

[John Cowan]

On Thu, Mar 22, 2018 at 12:24 PM, <felix.winkelm...@bevuta.com> wrote:

But if you use an expander as a separate preprocessing step for standard
> Scheme
> code, it should be possible to use the portable syntax-case package at
>
> https://www.cs.indiana.edu/chezscheme/r6rs-libraries/
>
> Some hacking will be necessary, I'm afraid.
>

In addition, Rapid Scheme is a preprocessor that translates full R7RS
including libraries and syntax-rules macros into a reduced R5RS-like form
of R7RS, so at most it might be necessary to add some replacements for
specific R5RS procedures.  It has already been used to R7RS-ify Gambit.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Only do what only you can do.
--Edsger W. Dijkstra's advice to a student in search of a thesis
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Eggs for Chicken 5

[John Cowan]

On Thu, Mar 22, 2018 at 12:11 PM, Sven Hartrumpf <hartru...@gmx.net> wrote:

I use a Chicken-compiled alexpander to get rid of syntax-rules when
> compiling
> some Scheme projects (with non-Chicken compilers).
>

I'm interested in this.  Which compilers do you use that don't have
syntax-rules?
I know that Stalin does not.

--
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Humpty Dump Dublin squeaks through his norse
Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
Humpty Dump Dublin's grandada of all rogues.  --Cousin James
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Eggs for Chicken 5

[John Cowan]

There is no point in converting eggs until the Chicken 5 API has
stabilized, which only happened in the last few weeks.

That sad, I doubt there will ever be a syntax-case egg again, unless
someone figures out how to implement syntax-case on top of explicit
renaming.  Chicken has been committed to explicit (and implicit) renaming
as its low-level macro system for ten years, since the beginning of Chicken
4.

On Thu, Mar 22, 2018 at 5:06 AM, Sven Hartrumpf  wrote:

> Hi.
>
> Is there any rough estimate when eggs (like syntax-case)
> will appear for Chicken 5?
> The page http://wiki.call-cc.org/chicken-projects/egg-index-5.html
> lists no eggs at all.
>
> Ciao
> Sven
>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] require, require-extension-for-syntax, and the initial macro environment

[John Cowan]

On Mon, Mar 12, 2018 at 2:55 PM, Peter Bex <pe...@more-magic.net> wrote:


> I'm not sure why we still need these (probably because require-extension
> is a SRFI (55)?).


As a SRFI fan, I still say flush it.  SRFI 55 isn't very portable: besides
Chicken, where it began, it spread only to Gauche, Guile, SISC, STklos,
SigScheme.


> But honestly, I think it's better to just drop require-extension-for-syntax
> and perhaps even require-extension.
>

Let's drop both.


> One more question: Where should we document "the initial (nameless) macro
> environment"?  For example, cond-expand and module and such need a place
> to be documented too, and they're strictly speaking not part of a module
> (but it's weird to have to look them up somewhere completely different).
>

What all do we need besides import and module?


> ;; TODO: Eventually, cond-expand should move to the
> ;; (chicken base) module to match r7rs.  Keeping it in the initial env
> ;; makes it a whole lot easier to write portable CHICKEN 4 & 5 code.
>

Fair enough.  Note that there are two cond-expands in R7RS: one in R7RS
library language, and one that is a Scheme expression.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] What to do with default modules?

[John Cowan]

perhaps we should have a csi cmd line option to specify the base module

similar to chibi -x switch



On Fri, Dec 15, 2017 at 6:11 AM, Peter Bex  wrote:

> Hi all,
>
> Now that we have a 5.0.0pre4 development snapshot, I wanted to clean up
> some stuff.  The most important cleanup is the mess of toplevel symbol
> definitions at the end of library.scm.
>
> I noticed that if I remove that, the environment for "eval" is empty.
> It turns out that the default eval environment used to contain the
> identifiers from scheme and chicken, but that was sort-of by accident,
> because they were available on the toplevel.
>
> In "csi" we now explicitly perform these two imports:
> (eval `(import-for-syntax ,@default-syntax-imports))
> (eval `(import ,@default-imports))
>
> I tried putting these two at the end of eval.scm, which worked (we could
> then get rid of these in csi.scm).  Unfortunately this breaks the tests,
> because the (import)s cause the import libraries for "chicken.base" and
> "chicken.syntax" to be loaded dynamically, but that's not available when
> the binary is compiled statically.  Scheme is built-in to modules.scm,
> so that doesn't require loading an external library.
>
> Now I see two basic approaches:
> - We remove the chicken.base.import.scm and chicken.syntax.import.scm
>files and move the definitions into modules.scm, like we do for
>"scheme" and a plethora of srfi modules.
> - We figure out if we can link these import files into libchicken.
>
> Both of these raise the question if we should also do that for other
> modules, and if so, how to decide which ones?  Note that chicken.syntax
> is not from library.scm, so we could also decide to remove this from the
> default eval imports instead, because otherwise you can't link a
> custom-built binary without the "expand" unit.
>
> A third approach would be to keep the toplevel definitions, but I think
> that's not really an option.  That would be too much of a mess and
> asking for trouble.  Sometimes it might even be desirable to have a
> completely empty toplevel (like with -explicit-use).  Just having the
> imports clearly indicated is much better.
>
> One small concern: How big will the import library tables be?
> In CHICKEN 4, symbols are at toplevel and if we don't load any import
> libraries, the symbols are directly bound to their values.  In the
> approaches I describe above, we add to that more alists for the modules,
> plus extra (longer, because prefixed with "chicken.base#"!) symbols.
> I'm not sure this is even worth thinking about (especially now we can
> GC any other symbols much better), but I just wanted to point it out.
>
> Cheers,
> Peter
>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
>
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Proposal to rationalize software-type, software-version, and build-platform on Cygwin

[John Cowan]

I have changed the definitions of software-type and software-version in the
manual to be "OS family" and "OS" respectively, since that is what they
actually are.

I am proposing the following changes:

1) Alter the symbol 'unix in software-type to 'posix, and return it for all
Chicken builds on Posix APIs, including Cygwin (which currently reports
'windows) and Windows System for Linux (which currently reports 'unix).

2) With the above change, software-version reports subtypes of 'posix, one
of which should be 'cygwin.  WSL should continue to report 'linux, as it is
intended to be a faithful emulation of Linux (and mostly is, and getting
closer all the time).

3) Cygwin can build C program s with either GNU tools or Clang, though
currently only GNU tools are in the makefile.  Therefore, 'cygwin should be
removed from build-platform, which should return 'gnu or 'clang as
appropriate.

4) Optional: change the API names to something more meaningful, like
chicken-os-api and chicken-posix-api.  These names are not ideal, but they
are better.  "Version" suggests an OS version number, as the example in the
CLHS shows.

5) It's been suggested that 'windows be changed to 'win32.  While it's true
that the Windows API on 64-bit machines is still called "Win32" by
Microsoft, I think people will expect "win32" to imply a 32-bit API.  For
this reason I suggest keeping it as 'windows.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [C5] About `random` and its future

[John Cowan]

On Sun, Sep 17, 2017 at 1:43 PM, lemonboy <thatle...@gmail.com> wrote:

AFAICT the `extras` module contains a bunch of useful procedures to get one
> started writing so it'd be nice if we could choose and implement a single
> PRNG,
> taking advantage of the (light) breakage introduced by C5.
>

Is there anything wrong with SRFI 27 and its MRG32k3a generator?  It's fast,
clean, splittable (you need splitting whenever you are dealing with
independent
random sources and don't want to spend a lot of entropy on them, not just
for
parallel processing), and works well on both 32-bit CPUs (with 64-bit
floats)
and 64-bit CPUs.   I have not seen any indication that MRG32k3a has been
broken.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
If I have not seen as far as others, it is because giants were standing
on my shoulders.  --Hal Abelson
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Move around {rename, delete}-file and a question about module for inexact

[John Cowan]

On Sun, Sep 10, 2017 at 11:40 AM, Peter Bex <pe...@more-magic.net> wrote:

This same inconsistency crops up in (scheme lazy), which has
> delay, delay-force, force, promise? and make-promise, whereas
> the scheme module has delay and force.
>

As the main inventor of the R7RS-small modules, I would advise not getting
hung up on them.  They exist primarily to make things optional for truly
small R7RS-small implementations.  For example, the R5RS numeric tower
makes inexact numbers optional, even though only subminimal and blatantly
non-confirming Schemes (SigScheme, Mini-Scheme, Oaklisp, Owl Lisp in my
test suite) actually omit them.

So in practice (scheme inexact) could have been folded into (scheme base).
It isn't, because R7RS-small is not entirely about practice, but also about
extending downward the range of what counts as a conformant Scheme, say one
that compiles code to run on a microcontroller with no hardware floating
point.  (Similarly with the (scheme case-lambda) module, which is there
because Alex Shinn, who hates the case-lambda macro, insisted on it.)

Again, we could put delay-force, promise? and make-promise into
> (chicken base) _and_ make an aliasing module (chicken lazy)
> that has both the extended and r5rs procedures, but that seems
> awkward and annoying when you import both; you'd get constant
> warnings about re-importing identifiers.


I would not expect a warning about importing the same binding of an
identifier through more than one path: if you define a module foo that
re-exports identifiers from the base module, and then write bar importing
both the base module and foo, you should not (and do not, in Chicken or
Chibi) get a warning.


> OTOH, putting it just
> under (chicken base) might result in the aforementioned confusion
> for people familiar with r7rs.
>

I at least would expect (chicken base) to be a base module incorporating at
least the intersection of (scheme base) and (scheme r5rs), given that
Chicken is R5RS-based.  Most people add an import when they get (or know
they will get) an undefined-variable error, and Chibi's advanced REPL
("chibi-scheme -R") will helpfully search the library for a module that
defines such a variable.

Tl;dr:  merge these small modules into (chicken base).

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Principles.  You can't say A is made of B or vice versa.
All mass is interaction.  --Richard Feynman
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Proposal / patch for fixing #1385 (swapped bit-set? argument order)

[John Cowan]

On Tue, Aug 8, 2017 at 2:11 PM, Peter Bex <pe...@more-magic.net> wrote:

Renaming it to a completely nonstandard name should make it easy to port,
>

I think this is the Right Thing.


> and later on (CHICKEN 5.1 or even 5.2) we can re-introduce the bit-set?
> procedure with the correct argument order, and deprecate the new procedure.
>

I would say: don't even bother bringing bit-set? back in a Chicken package.
  If you want or need it, import it from srfi-33, srfi-60, or (latest and
greatest) srfi-151, all of which use (bit-set? index i).


> The name of the nonstandard procedure is not very relevant since it is
> going to disappear anyway, but I think bit->boolean is a relatively clean
> name.


I agree.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant
le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux,
de rapport nyait pas.   --Jacques Lacan, "L'Etourdit"
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix record type tags to be nonglobal by module-prefixing them

[John Cowan]

On Tue, Jul 18, 2017 at 7:28 PM, Evan Hanson <ev...@foldling.org> wrote:

I really think we should hide the hash prefixing as much as possible.
> It's an implementation detail and not something users should interact
> with directly. The right way to distinguish these things is through the
> module language.
>

Per contra, I find it a great help with debugging module problems.   When I
am not sure if something is correctly imported, it is useful to be able to
type bar into the REPL and see if that means  #
or #.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
How comes city and country to be filled with drones and rogues, our highways
with hackers, and all places with sloth and wickedness?
--W. Blith, Eng. Improver Improved, 1652
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[John Cowan]

On Tue, Jul 4, 2017 at 10:11 AM, megane <megan...@gmail.com> wrote:

Working with the export list is painful without some syntax support. You
> end up repeating every identifier name otherwise.
>

I consider the repetition to be a virtue rather than a vice.

The whole purpose of modules is to control what identifiers are exposed to
the outside world and what identifiers are private.  If you want to expose
everything, why bother with a module at all?  Just have a plain file that
is included rather than imported.

Having an explicit export whitelist separates implementation from
interface: the interface is whatever is exported, whereas the
implementation can change freely, adding or removing non-exported
procedures with no risk of affecting clients of the module in any way.

How about a pair of syntax called export-all and export-none (or
> similar). Every definition lexically after export-all up to a export-none
> is exported and vice-versa.
>

That's the C++ style, and it works in that language because typically
classes contain only declarations, not definitions.  It would be very
error-prone in the Scheme context; for example, if you wanted to refactor
an exported procedure with a helper, you'd have to remember to bracket the
helper with (export-none) and (export-all).  Also, it is not Scheme style
to have such hidden scope: if you wanted to do it so, you'd want
(export-all  ...) and (export-none  ).

But if you want syntactic sugar, consider having exported-define,
exported-define-syntax, etc. in Java style.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Said Agatha Christie / To E. Philips Oppenheim
"Who is this Hemingway? / Who is this Proust?
Who is this Vladimir / Whatchamacallum,
This neopostrealist / Rabble?" she groused.
--George Starbuck, Pith and Vinegar
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] The other part of the FFI improvements

[John Cowan]

On Mon, Jul 3, 2017 at 11:22 AM, lemonboy <thatle...@gmail.com> wrote:

The code/mail ratio is approaching the zero so I'm gonna shut up for a
> while :)


Don't worry about that.  A consultant was called in one day by a chemical
factory because their entire system was blocked and no product was coming
out.  Big money was being lost for every minute of shutdown.  The man
inspected the huge and complex mess of pipes, valves, mixers, boilers, etc.
etc.  Then he took a hammer out of his toolkit and struck one pipe in a
particular place.  Product started to gush out and all was well.

He sent in a bill for $50,005.  When the plant management sent it back
saying "Too much for one blow with a hammer", he sent back an itemized
replacement bill.

One blow with hammer, $5.
Knowing where to hit, $50,000.

Only prose can explain *why* code is the way it is.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Using RELAX NG compact syntax to develop schemas is one of the simple
pleasures in life  --Jeni Tennison
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module

[John Cowan]

On Sat, Jun 17, 2017 at 10:25 AM, Peter Bex <pe...@more-magic.net> wrote:

I can imagine those macros going into (chicken base) and/or some
> other modules, but a (chicken syntax) module with them in it makes
> sense too.  Then we could just rename (chicken syntax) on the
> c-l-r page to (chicken expand) and keep expand.scm as-is.
>

That sounds right to me.  The R7RS Yellow Edition (next after the current
Orange Edition) will focus on syntax, and I plan to propose that all the
macros added to the large language be put in a single (scheme syntax)
library, possibly including SRFIs 2, 8, 17, 26, 31   Keeping the macro
expansion machinery in (chicken expand) makes sense to me as well.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise 
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[John Cowan]

On Thu, Jun 8, 2017 at 3:47 AM, Peter Bex <pe...@more-magic.net> wrote:

The typical way to do that is to put the module definition in another file
> than where you put the definitions.  Then you can simply
> (include "defs.scm") in the tests and in the module.  But yeah, this is
> a bit unwieldy, I admit.
>

My personal practice is to put just the module definition in the main file
foo.scm, and then have it include the plain code in foo-impl.scm.  When
debugging, I just load foo-impl.scm so that I have full access to the
internals.  This also makes foo-impl.scm portable to other Schemes with
different module languages.

As for the tests, I make them say "(use foo)" so that they are truly
black-box.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[John Cowan]

On Wed, Jun 7, 2017 at 4:07 PM, Peter Bex <pe...@more-magic.net> wrote:

Unexport seems to me to be solving a non-problem.
>

As we discussed on IRC, I see unexport as mitigating the problems with
(export *), and it's better to drop exporting * instead.  "Whitelisting is
better
than blacklisting."


> - begin-for-syntax
> - import-syntax (WTF)
> - import-syntax-for-syntax (WTF)
>

I agree that these can be in a module.  Indeed, the only thing that
absolutely
*must* be provided in the initial empty environment of a REPL is "import"
itself, as you have to import the "scheme" module (or some other base
module)
in order to get going.


> - export (which I always found rather useless, given that you have a
>list of exports right at the top already)
>

I never use the list of exports, but always "export".  That's partly
because I'm
working in a style that accommodates Chicken and R7RS at the same time.

Unfortunately, because it's not Scheme, this language isn't (easily?)
> programmable by the user.
>

Not programmable at all.  That was a deliberate choice to keep things
simpler for diverse Scheme implementations.


>  So there's no ambiguity whatsoever: you can have a library
> called (rename file pattern) and it can always be distinguished from
> a rename of an identifier from a library, because "file" and "pattern"
> are not valid library names.
>

That's true, but frankly anyone who names a library (rename ...) or
(drop-prefix ...) deserves to lose. I haven't tested this, but I suspect at
least some R7RS handle such names by treating them as malformed
import qualifiers (i.e. errors) rather than library names.

 It's not like this set of names is going to be growing forever, either.
There is already support for drop-prefix in Chibi and Chez at least,
and I have not heard of any system allowing any other qualifier.
I can imagine some new things, like "(import (silently b))" where
any conflicts with existing modules are silently overridden, but they
wouldn't be fit for standardization for a long time, if ever.


> Regarding the list syntax versus symbols, it would be easier on
> our users, porting-wise, to only allow symbols as library names.
> It also maps more clearly to the file system.  Aesthetically and
> for compatibility with other Schemes, I'd prefer the list syntax
> only.  But accepting both is (in hindsight) quite the mistake.
> We can still change things before it's too late...
>

I think it's quite convenient to accept both, and often wish that
R7RS systems would do this for ad hoc libraries.  I also find
Chicken's file-mapping convention (with dots) superior to
most systems, which map (foo bar) to foo/bar.  Chibi adopts
this strategy for the command line only:  in code you must
say "(import (foo bar baz))" but on the command line you
say "-m foo.bar.baz".  This works well for me.

What happens if you have an export list that includes both a prefixed
> identifier and the same unprefixed identifier?  [...]


Chibi warns if you do this, the same as if you import an identifier
from two different modules.  I'm not sure about Chez.


>   Perhaps a saner approach is to only ever import
> identifiers that actually have the prefix.


I wouldn't be opposed to that except that we have two precedents
for importing all the identifiers.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
All Gaul is divided into three parts: the part that cooks with lard and
goose
fat, the part that cooks with olive oil, and the part that cooks with
butter.
  --David Chessler
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[John Cowan]

On Wed, Jun 7, 2017 at 2:06 PM, <felix.winkelm...@bevuta.com> wrote:

Isn't it easy to forget particular identifiers that happen to start with
> "fp"
> as well? I think explicit "rename" imports are clearer and less error
> prone.
>

My example is bad: you'd want to use it with a module where all the names
begin with the same prefix, or almost all.  Another application is to drop
the author's prefix and then add your own:  (import (prefix (drop-prefix
srfi-13 string-) s:)) would change all the SRFI 13 identifiers beginning
"string-" to begin "s:" instead (you'd want to change the Scheme
identifiers too).

An open question is what to do when an identifier is the same as the
prefix:  Chibi imports it unchanged, Chez changes it to || (the empty
identifier).  A third possibility is to not import it.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Your worships will perhaps be thinking that it is an easy thing
to blow up a dog? [Or] to write a book?
--Don Quixote, Introduction
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[John Cowan]

On Wed, Jun 7, 2017 at 9:28 AM, megane  wrote:

If the module export list is not *, module-unexport-list is not used. In
> this case, it's enough to just remove the identifier to be unexported
> from the module-export-list.
>

Very nice!

While you are messing around with the module system, I'd like to see
"strip-prefix", which is just like "prefix" except it removes a prefix from
identifiers (if present) rather than adding one.  So:

(import (except scheme + - * / bla bla bla))
(import (strip-prefix chicken "fp"))

causes fp+ to be imported as +, fp- to be imported as -, etc. etc., for
programs that don't use exact numbers.  This isn't something you need to do
that often, and it adds no power to rename (but then neither does prefix),
but it can be useful.

--
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix a regression in body canonicalization

[John Cowan]

On Thu, Apr 27, 2017 at 12:14 PM, Peter Bex  wrote:

Now, the spec disallows this (I think..),


Yes, it does:  begin-with-defines is allowed only at top level.  It should
be replaced by (let () (define ...) . body) instead.  In Algol or C terms,
begin is a compound statement, let is a block.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [Chicken-janitors] #1218: chicken-install may fail if TMPDIR is mounted noexec (depending on setup-file details)

[John Cowan]

On Sun, Apr 23, 2017 at 8:04 AM, Peter Bex <pe...@more-magic.net> wrote:

On Sun, Apr 23, 2017 at 01:52:53PM +0200, felix.winkelm...@bevuta.com wrote:
> > Sorry, I lost the context for this discussion - what exactly is the
> problem here?

Basically, if /tmp is mounted noexec, installing an egg like
> coops that builds two modules, one of which loads the other,
> this will fail because you can't dlopen() a .so file on noexec
> mounts.
>

The wider context is that many attacks on Linux systems install executables
into /tmp (which is guaranteed writable), and setting the /tmp filesystem
noexec blocks such attacks in a simple way.  It's now considered a bug in
Debian packages to put executables in /tmp, and I expect the idea will
spread to other Linux distros.

In general, nothing should be both writable and executable.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
If you have ever wondered if you are in hell, it has been said, then
you are on a well-traveled road of spiritual inquiry.  If you are
absolutely sure you are in hell, however, then you must be on the Cross
Bronx Expressway.  --Alan Feuer, New York Times, 2002-09-20
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add chicken.platform module (partially)

[John Cowan]

On Sat, Apr 22, 2017 at 4:29 PM, Peter Bex <pe...@more-magic.net> wrote:

For example, we also define "machine-type" in chicken.platform, which  to
> me is a bit confusing: how does machine-type differ from the "processor"
> entry in system-information's list?  And why do we need the hostname
> to be in both get-host-name and system-information?  On Windows it's
> identical, but perhaps on Unix, gethostname() can return a different
> name than uname()'s nodename?
>

The Linux manpage for uname(2) says:

   Note that there is no standard that says that the
   hostname set by sethostname(2) is the same string as the nodename
   field of the struct returned by uname() (indeed, some systems allow a
   256-byte hostname and an 8-byte nodename), but this is true on Linux.

And for gethostname(2) it says:

   The GNU C library does not employ the gethostname() system call;
   instead, it implements gethostname() as a library function that calls
   uname(2) and copies up to len bytes from the returned nodename field
   into name.  Having performed the copy, the function then checks if
   the length of the nodename was greater than or equal to len, and if
   it is, then the function returns -1 with errno set to ENAMETOOLONG;
   in this case, a terminating null byte is not included in the returned
   name.

So on Linux at least we don't have to worry about it.  In BSD, they are
both library routines, but no relationship between them is documented.  I
would be astonished, however, if a different value were returned on any of
the systems Chicken supports.

--
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
"Your honour puts yourself to much trouble correcting my English and
doubtless the final letter will be much better literature; but it will
go from me Mukherji to him Bannerji, and he Bannerji will understand it a
great deal better as I Mukherji write it than as your honour corrects it."
--19th-century Indian civil servant to his British superior
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Fix

[John Cowan]

On Fri, Apr 14, 2017 at 10:40 AM, Moritz Heidkamp <
moritz.heidk...@bevuta.com> wrote:

char-ready? on string input ports would return #f when they've reached
> the end of their underlying string. However, char-ready? is supposed to
> return #t in this case.
>

Yes.  The semantics of char-ready? is that it returns #f if there are no
characters available now, but there might be some available in future.  In
particular, at EOF there is always an EOF object available.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Schlingt dreifach einen Kreis vom dies!
Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau,
Und trank die Milch vom Paradies.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] new CHICKEN 5 egg installation

[John Cowan]

On Wed, Feb 22, 2017 at 4:58 PM, Mario Domenech Goulart <
ma...@parenteses.org> wrote:

> * "-test" implies that all tests are executed, including dependencies;
> >or should only those tests run that belong to the eggs explicitly
> given
> >on the command line?
>
> I personally like the current behavior in C4 (run tests only for eggs
> explicitly given on the command line).
>

I like the recursive behavior better.  If you want to test your eggs before
using them, why would you care whether they are installed by hand or as a
dependency?

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture.  And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein.  --Gospel of
Tux
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/1] Fix spurious array bounds warnings on OpenBSD

[John Cowan]

On Sat, Jan 21, 2017 at 9:09 AM, Peter Bex <pe...@more-magic.net> wrote:

I still think it's much better to declare that CHICKEN requires a C99
> compatible compiler, and remove the conditional, using [] always.
>

I strongly agree.  Chicken's build system already makes fairly strong
assumptions about the compiler: it works with modern versions of gcc or
with clang, not with Joe's Own C Compiler.  There is no reason not to do
C99 things, especially when they express meaning better and are illegal in
C89 for no good reason.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
It was impossible to inveigle
Georg Wilhelm Friedrich Hegel
Into offering the slightest apology
For his Phenomenology.  --W. H. Auden, from "People"
(1953)
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[John Cowan]

On Tue, Oct 4, 2016 at 4:00 AM,  wrote:

> > We could still get rid of the tagged pointer type.  After some more
>


> > thought on the matter, I believe they're mostly worthless.
>
> "They" means tagged pointers? I agree.
>

I continue to disagree.  Tagged pointers make it possible to have
dynamically type-safe or type-dispatched treatment of C objects referred to
by the pointer side.  Logically it is equivalent to encapsulate the raw
pointer in a record, but record dereference is much slower than pointer
dereference for whatever reason, so it adds substantial overhead.

--
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] substring

[John Cowan]

On Fri, Aug 26, 2016 at 12:36 PM, Mario Domenech Goulart <
mario.goul...@gmail.com> wrote:

> I'm not proposing doing anything with substring=?.  The discussion
> came up when I wrongly used substring=? in my code and thought it was
> a bug.  After reading and reflecting on what the documentation says, I
> understand that substring=? is not buggy (although I still think it is
> a bit convoluted).
>

IMO, the SRFI-13 string= is far easier to understand, because it specifies
two strings and two start/end pairs.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
They do not preach that their God will rouse them
A little before the nuts work loose.
They do not teach that His Pity allows them
to drop their job when they damn-well choose.
--Rudyard Kipling, "The Sons of Martha"
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

[John Cowan]

Peter Bex scripsit:

> That's not their main usefulness.  The main usefulness is that you can
> treat them like any other _pointer_ type, yet they can be kept apart
> if you want to by checking the tag.

Quite so.  They are pointers, but the tag allows you to factor them
into Scheme-detectable types without losing their pointer nature.
In essence, they let you subtype pointers.

> My main concern, after giving it some more thought, is that you can't
> easily make the FFI check the pointer type, unless you enforce that
> pointer tags are somehow either compile-time constants, or also stored
> in some global that's directly accessible to the FFI.  

As someone who has used them in the past, I would be quite content to
require that tags be symbols.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] A few small performance and scrutiny warning improvements to assignments

[John Cowan]

Peter Bex scripsit:

> It seems silly to ask the length of a vector that's statically known.

Not at all.  If your program needs a vector of constants, thus:

(define pi-digits #(3 1 4 1 5 9)

then you might want to future-proof the rest of your program against
extending this constant by writing (vector-length pi-digits) rather than
the magic number 6.  This more usually comes up with strings rather than
vectors, but the principle is the same.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
If I have not seen as far as others, it is because giants were standing
on my shoulders.  --Hal Abelson

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] user-information update for OpenBSD

[John Cowan]

Peter Bex scripsit:

> Yeah, but what if you're writing, say, a login manager or ssh replacement
> in Scheme?  Then you need to be able to crypt & compare the password and
> preferably use a portable API to get the crypted password.

Then make such a portable API and don't try to use getpasswd() at all.
Most modern systems have a service of some kind to handle login anyway.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Micropayment advocates mistakenly believe that efficient allocation of
resources is the purpose of markets.  Efficiency is a byproduct of market
systems, not their goal.  The reasons markets work are not because users
have embraced efficiency but because markets are the best place to allow
users to maximize their preferences, and very often their preferences are
not for conservation of cheap resources.  --Clay Shirky

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] user-information update for OpenBSD

[John Cowan]

Christian Kellermann scripsit:

> Maybe it makes sense to split out the sensitive information from the
> user-information for all Operating systems and thinking of another set
> of procedures that will produce the credentials. These can then use OS
> specific functions to get at the information.

I'd say, set the passwd field to '*' (which is not the encryption of anything
on any known password scheme) on all systems.  *Nobody* should be depending
directly on the value of the encrypted password in 2016.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
--the Earendillinwe

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Hash all the record slots

[John Cowan]

Peter Bex scripsit:

> On the other hand, limiting the hash calculation at an arbitrarily low
> value like we do seems broken, too.  However, if we fix this, we should
> also fix it for vectors.  I don't really see why vectors should be
> treated fundamentally different.

Indeed.  There was a discussion of this on the SRFI 128 mailing list,
and Will Clinger made the point that if you try to examine the whole
object (other than strings), you end up not only using a lot of time,
but potentially a lot of extra overhead to make sure that you are not
recursing into a circular data structure.  So only some slots should
be examined.

> In any case, we can all agree that the srfi-69 module is pretty
> (almost hopelessly) broken.  That's one reason we made it into an egg
> for CHICKEN 5.  Might you be interested in taking over maintainership
> of this egg?  It sounds like you have some interesting ideas, and it
> makes more sense to iterate quickly on an egg than keep tweaking this
> code in core, just before what (hopefully) will be the final release
> of a CHICKEN in the 4 series.

It might be even better to flush the egg in favor of the Larceny version,
which supports both SRFI 69 and its upward compatible extension SRFI 125.
See 
<https://github.com/scheme-requests-for-implementation/srfi-125/tree/master/srfi>.


-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
The whole of Gaul is quartered into three halves.
--Julius Caesar

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Include files relative to the current source file

[John Cowan]

Peter Bex scripsit:

> IMHO, include should do one or the other: relatively to file or the
> current dir, but not both.

C's #include "foo", at least as implemented by gcc, uses the "directory
containing the current file" rule, and I think it makes the most sense.
However, for backward compatibility it would make sense to me to look in
$PWD next before looking in the standard include path.

> An include-relative is defined by the s48-modules egg.  I think it
> makes more sense to have that, especially considering we also have
> load-relative.

Good point.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Tautology is something that is tautological.  --Francois-Rene Rideau

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/5][5] Generalize port directionality and add basic refinement types

[John Cowan]

Peter Bex scripsit:

> Regarding our earlier discussion, I think it's a good idea to now
> change all procedures which return both an input and an output port to
> return a bidirectional port instead.  This makes it less of a hassle
> to get these values; you wouldn't need receive, call-with-values or
> let-values anymore.

+1

You should make sure that close-input-port and close-output-port close
only the appropriate side of a bidrectional port, and add R7RS close-port
to cleanly close both sides when they exist.  In addition, it would be
good to provide R7RS input-port-open?  and output-port-open?, which are
explicitly designed to detect the case of a half-open bidirectional port.

> For situations when it's desirable to expose only one end of a
> pair, we could create a procedure like "extract-input-port" and
> "extract-output-port" from a bidirectional port.  I'm not sure what
> good names would be for these.

I'm not sure that these are in the spirit of Scheme's duck typing.
In general we rely on programmer restraint to prevent, e.g., mutation
of lists or strings when the rest of the program doesn't expect it.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Almost all theorems are true, but almost all proofs have bugs.
--Paul Pedersen

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] R7RS-large Red Edition election has begun

[John Cowan]

The election to determine the contents of the Red
Edition of R7RS-large has begun.  To vote, please visit:
.
Ballots may be returned through the form, or on the WG2 mailing list,
or by email to me, .

The balloting period is from whenever you receive the ballot until the
last moment of Monday, July 19, in any time zone, which is equivalent to
noon July 20 in UTC.  Eligible voters are those who have registered for
this election, or those who were registered in the most recent Steering
Committee election, the R6RS plebiscite, and/or the R7RS-small plebiscite.
All registrations received before noon July 20 UTC will be counted.

-- 
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix hygiene in ##sys#expand-extended-lambda-list

[John Cowan]

Peter Bex scripsit:

> This is rarely a problem, because everyone always imports the chicken
> and scheme modules anyway, but it shouldn't be *required* to do that.

Indeed.  I try to write maximally-portable code, so I generally don't
import chicken as a whole: I use (import (only chicken use ...)) with
whatever I actually need.

> It's unhygienic.

Or as we say, "Ewwwww."

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Include files relative to the current source file

[John Cowan]

Evan Hanson scripsit:

> Adds the directory of the current source file to the list of pathnames
> searched by "(include ...)". This is given the lowest search priority,
> below CHICKEN_HOME and any directories specified by "-include-path".

It seems to me that it should have the highest priority, so that if a
specific version of some library code is packaged with the code, it will be
used in preference to any installed version.  This is what is done in C,
at least by gcc and clang.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
--Calvin, giving Newton's First Law "in his own words"

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] PATCH Re: slow polling

[John Cowan]

Peter Bex scripsit:

> I'll have to think about this, maybe we can come up with a way to
> avoid paying the price on UNIX for the shit Windows implementation.
> Better would be to have a *proper* implementation on Windows, but
> nobody has stepped up to actually overhaul the entire code to make
> that possible, so far.

A huuge amount of the code in the Cygwin DLL is concerned with
faking Posix semantics for select(); I've heard that it's the single
most complex thing in the library.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Unless it was by accident that I had offended someone, I never apologized.
--Quentin Crisp

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix string->number (bug #1272) by checking early for invalid bases

[John Cowan]

Peter Bex scripsit:

> See #1272 for more info.  I think the best solution is to check the
> argument and barf when a base outside the range 2..36 is passed,
> because what are even supposed to be the digits in higher bases?

Indeed, R5RS and R7RS only require bases 2, 8, 10, and 16 to work.
Everything else is surplusage.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING.  Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Send C_DEBUGGER_REPLY_GET_BYTES responses as unsigned char values

[John Cowan]

Peter Bex scripsit:

> Does this mean an unsigned char argument to a varags function is always
> widened to "int"?  How else can it know how much to take off the stack?

Yes, it does.  This pattern is called "the integer promotions" in the C
standards: _Bool, short, char, bitfield, and enum types are automatically
promoted to int, or if int is too small, to unsigned int, whenever (a)
they are used in an expression, or (b) passed as a function argument
and there is no function prototype in scope (which there cannot be for
varargs arguments).  Basically, C does not deal with types narrower than
int unless a function prototype forces it to.

> And if it really is the case that characters are always widened to
> integers, why bother to have a %c format specifier in the first place?

The %c format specifier converts its input to a character and outputs that
character.  There is no other format specifier that does this.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Where the wombat has walked, it will inevitably walk again.
   (even through brick walls!)

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Re: wrong type for alist-delete!

[John Cowan]

Peter Bex scripsit:

> I haven't yet published this as a new release because it's a minor
> change.  I noticed there are no tests for the srfi-1 egg, maybe we should
> consider copying them from another Scheme?  From a quick check, only
> Chibi has some minor tests for it.

I've modified my tests for SRFI 116 to run against SRFI 1 instead.  You
can snarf them from <http://www.ccil.org/~cowan/temp/lists-test.scm>.
They don't offer complete coverage, but better than nothing.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
If I have not seen as far as others, it is because giants were standing
on my shoulders.  --Hal Abelson

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] PATCH: wrong type for alist-delete!

[John Cowan]

Evan Hanson scripsit:

> Looks good to me. Debatably it ought to have an undefined return value,
> as with typical destructive update procedures, but hey.

Not how linear-update works:  the !-less version is pure, the ! version is
not pure (or at least may not be pure).  In any case, the data structure
being changed is what is returned.  A number of SRFIs work like this.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
What is the sound of Perl?  Is it not the sound of a [Ww]all that people
have stopped banging their head against?  --Larry

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] PATCH: wrong type for alist-delete!

[John Cowan]

Peter Bex scripsit:

> (alist-delete! (forall (a b) (#(procedure #:enforce) alist-delete! (a 
> (list-of pair) #!optional (procedure (a b) *)) (list-of pair

That seems right, but isn't b here equivalent to star?

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Verbogeny is one of the pleasurettes of a creatific thinkerizer.
--Peter da Silva

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [s...@speechcode.com: More SRFI reviewers needed.]

[John Cowan]

- Forwarded message from "Arthur A. Gleckler" <s...@speechcode.com> -

Date: Wed, 06 Jan 2016 11:09:21 -0800
From: "Arthur A. Gleckler" <s...@speechcode.com>
To: srfi-annou...@srfi.schemers.org
Subject: More SRFI reviewers needed.

Happy new year, Scheme users and implementers!

We need your help.

Partly as a result of the R7RS-large standardization effort
(see <http://trac.sacrideo.us/wg/#WorkingGroup2Charter>),
there are now twelve draft SRFI (Scheme Requests for
Implementation <http://srfi.schemers.org/>) in progress:

  <http://srfi.schemers.org/draft-srfis.html>

  SRFI 121: Generators
  SRFI 122: Nonempty Intervals and Generalized Arrays
  SRFI 125: Intermediate hash tables
  SRFI 126: R6RS-based hashtables
  SRFI 127: Lazy Sequences
  SRFI 128: Comparators (reduced)
  SRFI 129: Titlecase procedures
  SRFI 130: String cursors
  SRFI 131: ERR5RS Record Syntax (reduced)
  SRFI 132: Sort Libraries
  SRFI 133: Vector Library (R7RS-compatible)
  SRFI 134: Immutable Deques

While there has been excellent discussion on each, I would
like to encourage more Scheme users and implementers to give
their feedback on the SRFI documents and their reference
implementations, tests, etc.  Participating in the
discussion is an excellent way to help shape the standard.
The goal is to make sharing code between Scheme
implementations more practical and pleasant.

If you're interested, just read a SRFI document in which
you're interested,
e.g. <http://srfi.schemers.org/srfi-121/>; review the
discussion archive; sign up for the associated mailing list
(or <http://srfi.schemers.org/srfi-list-subscribe.html> for
all SRFI discussions); and post away.  We're grateful for
all constructive feedback.

Thank you, and happy scheming!

— SRFI editor

- End forwarded message -

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Normally I can handle panic attacks on my own; but panic is, at the moment,
a way of life. --Joseph Zitt

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix (restore?) specializations from types.db when compiling core itself

[John Cowan]

Peter Bex scripsit:

> We *could* declare this situation hopelessly lost in CHICKEN 4 because
> it uses unqualified names everywhere in types.db.  Then we can apply
> the fix to CHICKEN 5, where the core definitions will all be properly
> namespaced into modules.

+1 to that.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
The man that wanders far from the walking tree
--first line of a non-existent poem by me

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Improve irregex matching performance a lot by adding two type declarations

[John Cowan]

Peter Bex scripsit:

> Maybe this is a good feature to add: a way to indicate that a type
> declaration for the argument types to a procedure declared elsewhere
> should be considered an assumption in the procedure body.  This way
> it would not only affect callers, but also the procedure itself, which
> makes it easy to improve performance of portable libraries without
> hacking them to pieces.

As an author of SRFIs, I strongly support this.  I don't think users of
other Schemes want to read code littered with Chicken-specific (or
Racket-specific) type information, even if judicious use of macros
makes the type information disappear before their compilers or interpreters
try to process it.  It's just as important for programs to communicate
algorithms to other people as to their computers.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Tautology is something that is tautological.  --Francois-Rene Rideau

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Improve irregex matching performance a lot by adding two type declarations

[John Cowan]

Peter Bex scripsit:

> I can't say I find the documentation very clear, but it looks like it
> doesn't really use these declarations to optimize code (which is the
> goal of this patch).

It does, actually, specifically for JVM primitive types.  However, there
are no external type declarations, only declarations of procedure arguments
and `as`, the equivalent of `the`.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
BALIN FUNDINUL  UZBAD KHAZADDUMU
BALIN SON OF FUNDIN LORD OF KHAZAD-DUM

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

[John Cowan]

Jörg F. Wittenberger scripsit:

> One more question.  I would have expected chicken to store signals
> received while C_interrupts_enabled==0 and deliver them at some point
> after C_interrupts_enabled becomes true.  Why are those signals ignored?

That's what signal blocking is supposed to be for.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
In computer science, we stand on each other's feet.  --Brian K. Reid

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] mutex-lock! sometimes not srfi-18 compliant

[John Cowan]

Jörg F. Wittenberger scripsit:

> Looks like I shot myself into the foot (using git) again the very same
> way.  (Looks like "git add" caches the changes, thus must be given not
> once per file but once I'm done changing things.)

As long as all your changes are going into a single patch, avoiding
"git add" and going with "git commit -a" is usually safer.
See <https://xkcd.com/1597>.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Charles li reis, nostre emperesdre magnes,
Set anz totz pleinz ad ested in Espagnes.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

[John Cowan]

Peter Bex scripsit:

> As far as I know, R5RS doesn't say anything about a maximum number of
> procedure arguments in direct calls or when using apply.  In my book,
> it's "better" in some absolute way to remove any limitations beyond
> those which R5RS allows for.

The general permission to report implementation restrictions covers this;
the cases given in 1.3.2 are only examples.  No programming language I
know of sets an upper limit on code size, but all implementations do.

> Calling a function directly with 5000 arguments will "just work" in the
> common case.  However, if this call happens to occur while the stack is
> full, the assertion will be triggered.  Let's say this happens in
> production but not in your development setup, then it would be pretty
> hard to find this bug.

And if your production code is embedded in a device, it's really bad.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
--Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

[John Cowan]

felix.winkelm...@bevuta.com scripsit:

> If I have to pass 10 million arguments to a procedure, I'm probably
> doing something wrong.

In general this is true, but `apply` is an exception: when you say
`(apply fn giant-list)` you end up invoking fn with an argument count
that's equal to the length of giant-list.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix unsafe specializations in types.db

[John Cowan]

Moritz Heidkamp scripsit:

> The only one I'm a bit unhappy about is `move-memory!' as I couldn't
> find a safe inline version of it. Does anyone have a clue whether there
> is such a thing already?

Presumably that would check lengths only while leaving types to be validated
by the scrutinizer?

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
"Any legal document draws most of its meaning from context.  A telegram
that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
5-bit Baudot code plus appropriate headers) is as good a legal document
as any, even sans digital signature." --me

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Fix , q in csi by not overriding ##sys#quit-hook

[John Cowan]

Peter Bex scripsit:

 The attached patch gets rid of the override and lets ,q simply be
 an alias for (quit), which I think it should always have been.  This
 also makes the code just a little bit simpler to reason about.

I think this dates back to the days when quit always terminated the whole
process rather than the current REPL.  However, there seems to be a bug:

$ csi -q
#;1 ,q


$ csi -q
#;1 (repl)
#;1 ,q

Error: unbound variable: unquote

Call history:

syntax  (unquote q)
eval(unquote q)   --

In other words, the , syntax is not handled properly in subordinate REPLs.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
There is no real going back.  Though I may come to the Shire, it will
not seem the same; for I shall not be the same.  I am wounded with
knife, sting, and tooth, and a long burden.  Where shall I find rest?
--Frodo

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] argvector chicken (was: ABI woes)

[John Cowan]

Scripsit felix.winkelm...@bevuta.com:

 CPS calls are surprisingly expensive in general in CHICKEN,

Ah, I'm confused now.  Are CPS calls a specific type of call?  I had
assumed that all calls (except to C primitives) are CPS calls.

 I assume that the continuous growth of the stack
 and/or the memory usage pattern in CHICKEN-generated CPS code totally drowns
 any performance advantage than register-passed arguments would give.

Sounds reasonable.

-- 



___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] New dimensions in ABI design braindamage

[John Cowan]

felix.winkelm...@bevuta.com scripsit:

 a function ptr of type
 
   typedef void (*C_proc4)(C_word, C_word, C_word, C_word, C_word)
 
 that points to a function of (say) this type
 
   void myproc(C_word c, C_word k, C_word a1, ...)
 
 will break, 

Yes.  That's undefined behavior according to the C standard, and if it happens
to work when compiled with gcc on i386 and x86_64, that's just good luck.

 I'm out of my wits. This is extremely stupid and breaks every attempt at 
 implementing generic function-pointers in C without paying a massive 
 performance penalty. 

C really doesn't have any generic function pointers.  If the numbers
and types of the arguments, and the presence or absence of '...', don't
match as between the function pointer and the pointee, then the pointee
can't count on where to find its arguments.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Ambassador Trentino: I've said enough. I'm a man of few words.
Rufus T. Firefly: I'm a man of one word: scram!--Duck Soup

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix undefined behaviour of shifting left signed values

[John Cowan]

Christian Kellermann scripsit:

 Let's keep that as it is, it looks like it is too much effort for the
 gain atm.

As I say, even the most insanely aggressive C compiler won't try to trmp
IEEE 754, or the numerical programming community would abandon it.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Historians aren't constantly confronted with people who carry on
self-confidently about the rule against adultery in the sixth amendment to
the Declamation of Independence, as written by Benjamin Hamilton. Computer
scientists aren't always having to correct people who make bold assertions
about the value of Objectivist Programming, as examplified in the HCNL
entities stored in Relaxational Databases.  --Mark Liberman

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix undefined behaviour of shifting left signed values

[John Cowan]

Peter Bex scripsit:

 - We are using left shifts on signed types.  According to the C spec
this behaviour is undefined (which is completely retarded, IMHO).
The even more retarded fix is to simply cast to unsigned and back to
signed whereever this is done.  

Yeah, it reflects old processors.

 - We are dividing floating-point numbers by zero, which is apparently
undefined.  

Don't worry about that.  Any C compiler that ignored IEEE 754 constraints,
even though C doesn't assume them, would be ostracized by numerical
programmers.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
And it was said that ever after, if any man looked in that Stone,
unless he had a great strength of will to turn it to other purpose,
he saw only two aged hands withering in flame.   --The Pyre of Denethor

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] An alternative internal time type.

[John Cowan]

Peter Bex scripsit:

 Thanks for the patch.  However, I'm not sure how useful it will be,
 considerng that CHICKEN 5 is now (or should be) using exact integers
 everywhere (so it'll use bignums to store timestamps), and I don't
 think we should be adding such big-impact changes to CHICKEN 4 at
 this point.  Of course other core members may disagree.

FWIW, R7RS-small (time) returns an inexact integer to minimize
unpredictable allocation.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Even a refrigerator can conform to the XML Infoset, as long as it has
a door sticker saying No information items inside.  --Eve Maler

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Ambiguity in csc's command line options (#1193)

[John Cowan]

Mario Domenech Goulart scripsit:

 2. support GNU-style command line options, that is, --long and -l.
Then we'd have --lfa2 to ask chicken to perform an additional
lightweight flow-analysis pass and -lfa2 to link against libfa2.

I consider X-style -foo options to be obsolete, and much prefer the
GNU-style --foo options.  I'm always annoyed when I type --foo to
Chicken and it gets mishandled.  As a first step to switching, I'd
recommend allowing --foo=bar options everywhere, and eventually
deprecating and removing the -foo options.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Normally I can handle panic attacks on my own; but panic is, at the moment,
a way of life. --Joseph Zitt

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] More efficient numbers integration through scratchspace

[John Cowan]

Peter Bex scripsit:

 Except for the fact that this causes the needed stack space is bigger,
 resulting in more minor GCs even for code that doesn't need these numeric
 types.

How can that be?  If the code doesn't use them, they aren't on the stack,
so they can't cause more minor GCs.

 I don't understand how this would work and why it will be needed.  If you
 need flonum behaviour, you can simply convert to inexact before making
 your calculations.

Yes, indeed.  But if your existing code expects (/ 884279719003555
281474976710656) to return 3.141592653589793 and then to continue to
do flonum arithmetic after that, it will not be happy allocating two
bignums and a ratnum instead.  (Silly example, but there are non-silly
ones out there.)  Existing Chicken code has been able to count on this.

 The compiler cannot make the decision to use inexact numbers for you:
 that depends on the application and the domain-specific nature of the
 calculations you're performing, I would say.

Which is exactly why a switch is needed to restore the old behavior
for backward compatibility.  This does not mean shutting off bignums
and ratnums, just not creating them as a result of fixnum operations.
Arguably the most important of the two is not creating ratnums
unexpectedly.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
He played King Lear as though someone had played the ace.
--Eugene Field

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] More efficient numbers integration through scratchspace

[John Cowan]

Peter Bex scripsit:

 I managed to drastically reduce the overhead of the full numeric
 tower in core by introducing a new memory allocation area: 

This design sounds ingenious.  A few questions:

 The scratch area is seen as an extension of the nursery: the
 C_demand() and C_stack_probe() checks will add the size of the scratch
 space to the stack's size, and trigger a minor GC when the sum of the
 two exceeds the maximum nursery size.

So when a bignum needs to be allocated for the first teim, a scratch
space is alloca()ed?  How big is it?  It sounds like it needs to be
big enough to hold a sufficient number of biggest-bignums to perform a
single operation.

 a cplxnums containing two ratnums, which both contain two bignums will
 be correctly updated, regardless of where any of the 7 objects lives.

Compnums, rectnums, and ratnums are already fixed-size, so there is
no obvious reason to allocate them in the scratch space rather than
on the regular C stack.

It seems to me that there needs to be some way in the new design to force
part of the old behavior: for overflow and for / of integers to return
a flonum.  Notoriously, Scheme programs on full towers can get horribly
slow because they generate bigger and bigger ratnums, and any time where
efficiency beats accuracy, you want to switch to flonums.  This is often
done by inserting judicious decimal points into the constants in the
program, but it would be better to make it a switch of some sort.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
BALIN FUNDINUL  UZBAD KHAZADDUMU
BALIN SON OF FUNDIN LORD OF KHAZAD-DUM

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers