arcfide / chez-srfi Goto Github PK

Picked this up while testing on IronScheme.

Diff : IronScheme@b492745

@jessymilare The new append-map has a bug:

> (import (srfi :1 lists))
> (append-map list '(a b c) '(1 2 3))
()

Expected result:

> (import (srfi :1 lists))
> (append-map list '(a b c) '(1 2 3))
(a 1 b 2 c 3)
> 

In windows, the file name or folder name cannot have a colon.
This will restrict windows users.

There are some bugs in (srfi :126 r6rs-hashtables). According to spec:

- make-hashtable must always accept #f as hash procedure when equiv is eq? or eqv?;
- make-hashtable must always accept a pair of hash procedures or a single procedure;
- weakness can be a lot of values, and Chess Scheme accepts any one of them, but always produces weak-key hashtables. Chez Scheme should signal an error if weakness is one of the unsupported values (weak-value etc);

I've corrected those mistakes and did some optimizations in my own repo (last commit)

With Chez Scheme, make-coroutine-generator is slow compared to the same code that does not rely on call/cc and call/1cc.

Those can be implemented without make-coroutine-generator

• gtake
• make-for-each-generator

Maybe make-unfold-generator can be implemented without make-coroutine-generator

These are just some thoughts on improving the install script. It's been useful for some, but has proven to be a bit brittle.

Its current behaviour is to assume only top level library files have the .sls extension. Those are run through a preprocessor, installed to the destination directory and listed in the generated compile-all script, which is then executed (in order to fully compile the libs).

The preprocessor acts like a C-preprocessor #include for the local macro include/resolve so the contents of the referenced file are inlined in the installed version of the file.

The problem this solved (as include/resolve would only ever evaluate the code at runtime) was that inlining enabled full pre-compiles, pre-compiled srfi libs started up noticably faster on slow machines and some extra errors were caught.

I think one part of this task is to try and replace all that with an include/resolve that resolves the provided path specifier at compile time and passes that to include as include can compile the sourced file.

eg, (include/resolve (("srfi" "%3a115") "regexp-impl.scm")) would resolve to:

• (include "srfi/:115/regexp-impl.scm") or
• (include "srfi/%3a115/regexp-impl.scm") depending on what's locally installed.

If that works, then there's no need to preprocess files and using these libs in-place would also have the benefits of pre-compiles.

So then the question is would an install process be needed? Or does the install process become link-dirs and maybe a compile step as well? Is it useful to install compiled binaries only?

I think the compile component of the install script would still be useful. Adding whole program optimisation files would be great for those using srfi's in compiled programs.

But the issue there is determining what are the top level library files, as those files are the inputs to compile-library.

Is it okay to restrict the .sls extension to the top level libfiles only? Is there a better way to auto-discover top level files?

Or should the compile process be driven from a file? Maybe registry-names.sls?

It would need to handle srfi's that define multiple top level libs. eg, (srfi :146) and (srfi :146 hash) are distinct top level interfaces provided by the one srfi.

Chez doesn't like something about the SRFI-23-error->R6RS procedure used in %3a67/compare-procedures.sls. The error invocation in e.g. if3 gives an out-of-context error:

Chez Scheme Version 9.5
Copyright 1984-2017 Cisco Systems, Inc.

> (import (srfi :67 compare-procedures))
> (if3 1 'less 'equal 'greater)
Exception: attempt to reference out-of-context identifier error
Type (debug) to enter the debugger.
> (debug)
debug> i
#<system continuation in chi-expr>                                : sl
  continuation:          #<system continuation in dobody>
  frame variables:
  0: (("m" top) #[#{extensible-ribcage cqxefau3fa3vz4m0-1} ()] ...)
  1: #f
  2: #<eq hashtable>
  3: #(((...) displaced-lexical . "out-of-phase identifier") (61) ...)
  4: (error "comparison value not in {-1,0,1}")
#<system continuation in chi-expr>                                : 

Chez Scheme's parameters are not quite compatible with SRFI-39, as explained by @akeep here: cisco/ChezScheme#409 (comment)

However, chez-srfi uses them directly:

(library (srfi :39 parameters)
  (export make-parameter 
          parameterize)
  (import (only (chezscheme) make-parameter parameterize)))

The SRFI-42 implementation uses SRFI-23-error->R6RS and then uses error from inside a macro. This makes Chez Scheme (and apparently no other implementation) complain: "attempt to reference out-of-context identifier error":

https://github.com/arcfide/chez-srfi/blob/5ff9fae299a4933188ce7cd1a225a3c26036ef0d/%253a42/eager-comprehensions.sls#L28

Chez Scheme Version 9.5.2
Copyright 1984-2019 Cisco Systems, Inc.

> (import (srfi :42 eager-comprehensions))
> (list-ec (: i 5) (* i i))
Exception: attempt to reference out-of-context identifier error
Type (debug) to enter the debugger.
> 

This same class of bug was fixed in SRFI 67 by @akeep in bae03a5

(Thanks to Francesco Montanari for reporting this at https://gitlab.com/akkuscm/akku/issues/42)

It explicitly imports (chezscheme) .

Here is a simple portable implementation: https://github.com/IronScheme/chez-srfi/blob/master/%253a111/boxes.sls

The last line of:

https://github.com/arcfide/chez-srfi/blob/5cfad653d2f0a5fba59085ee3686db91702b6963/%253a1/srfi-1-reference.scm#L899-L901

lis1 should be lis

I put together almost all red and tangerine libraries of R7RS as R6RS libraries.

I am wondering whether you would accept pull requests to merge this work into chez-srfi. I will also rework the tests to make them work with SRFI-64.

What do you think?

What are the requirements for getting SRFI 146 aka. mapping into the repository?

The path parsing carried out by the include/resolve macro fails with chez-scheme-9.4. To get it to work, I had to apply the attached patch.
include.sls.txt

The tm:leap-second-table list in srfi-19.scm is missing the leap seconds from 2012, 2015 and 2017 and should be updated.

This will be a perennial problem and I'm thinking about different solutions. Here are three ways to solve it:

1. Keep updating srfi-19.scm with new leap seconds. Anyone using an old srfi-19.scm will be using old values and their TAI times will be out of sync with everyone else. Someone should be subscribed to IERS Bulletin C to learn about new leap seconds.
2. Use the leap second database from the operating system. Debian ships /usr/share/zoneinfo/leap-seconds.list and I'm sure other systems have a copy of the same data somewhere.
3. Use an operating system interface that already returns TAI time, like clock_gettime(2) with CLOCK_TAI.

So with this issue I'd like to note that there is a problem and see if anyone has an opinion on what's the best solution.

AFAICT Chez Scheme's fluid-let is compatible with SRFI 15. In that case, this would be a compliant implementation of the latter:

(library (srfi :15)
  (export fluid-let)
  (import (only (chezscheme) fluid-let)))

The SRFI also supplied a portable implementation using dynamic-wind.

What about setting up a continous integration service for the repository?

Hi. I am mostly using your project on linux machines but I need to use it also on windows machine. Unfortunately there is problem with the naming files and folders. Any name in the windows file system does not allow to use character ':'. I have some idea how to use it on windows machine. Loading this file on start of chez scheme allows to map any not supported characters. It maps ':' symbol's character into "%3a" string in this example.

;;;
;;; define windows specific "library-search-handler"
;;;

(define restore-library-search-handler #f)
(define windows-library-search-handler #f)

(let ((*old-library-search-handler* #f))
  (define chars-map '((#\: #\% #\3 #\a)))

  (define (symbol-subst sym)
    (if (not (symbol? sym)) sym
        (let loop ((lst (string->list (symbol->string sym))) (new-lst '()) (changed #f))
          (if (null? lst)
              (if (not changed) sym
                  (string->symbol (list->string (reverse new-lst))))
              (let ((ap (assoc (car lst) chars-map)))
                (cond ((not ap)
                       (loop (cdr lst) (cons (car lst) new-lst) changed))
                      ((pair? (cdr ap))
                       (loop (cdr lst) (append (reverse (cdr ap)) new-lst) #t))
                      (else
                       (loop (cdr lst) (cons (cdr ap) new-lst) #t))))))))

  (define (wlsh who lib dir* ext*)
    (*old-library-search-handler* who (map symbol-subst lib) dir* ext*))

  (set! restore-library-search-handler
        (lambda ()
          (when *old-library-search-handler*
            (library-search-handler *old-library-search-handler*)
            (set! *old-library-search-handler* #f))))

  (set! windows-library-search-handler
        (lambda ()
          (when (not *old-library-search-handler*)
            (set! *old-library-search-handler* (library-search-handler))
            (library-search-handler wlsh))))

  (windows-library-search-handler))

Of course it requires to write the library installator for windows too. Maybe I have something overlooked and there is simpler way to use it on windows. This is only idea, not implementation. Any comment is welcome.

I'm new to this space and found the README language around the Scheme Libraries project to be misleading ('You can let us know by "asking a question" at the Scheme Libraries project page: https://launchpad.net/scheme-libraries'). I gather arcfide/chez-srfi is the clearing house for this effort, but it takes some staring at commit histories to figure that out. Please consider amending the README to indicate the linkage is stale.

Importing partial libraries from outside repo fails.
Setup:

• Checkout this repository into a directory srfi (Absolute path ~/chezlib/srfi)
• Have ~/chezlib in the CHEZSCHEMELIBDIRS
• Be anywhere outside of ~/chezlib/srfi, like ~/
• Try to import (srfi :1 lists)
  This error results:

(import (srfi :1 lists))
Exception in include/resolve: cannot find file in search paths with irritants ("%3a1/srfi-1-reference.scm" ("~/chezlib/srfi/:1" "~/chezlib/srfi/:1" "."))

If you run scheme from within ~/chezlib/srfi then the import works as desired.

The SRFI-14 implementation only handles latin-1 and tends to crash in string-ref when given characters above #\xff.

I plan to fix this rather soon, but first I wanted to open this issue and see if anyone already knows about a working implementation.