Compiler complains about unbound variables for renames

[kozross]

I'm using Cyclone 0.3.3. I have the following code in a file bitfield.sld:

(define-library 
  (koz bitfield)
  (import (rename (except (scheme base) length set!)
                  (bytevector-length byte-count)
                  (bytevector-u8-ref byte)
                  (bytevector-u8-set! set-byte!))
          (scheme write)
          (koz bitwise)
          (koz rng)
          (koz utilities))
  (export get length new randomly-seeded set!)
  (include "bitfield.scm"))

When I try to compile it using cyclone koz/bitfield.sld, I get the following error:

Error: Unbound variable(s): (byte set-byte!) 
Call history:
scheme/cyclone/transforms.sld:built-in-syms
scheme/cyclone/transforms.sld:difference
scheme/cyclone/transforms.sld:remove
scheme/cyclone/transforms.sld:difference
scheme/cyclone/transforms.sld:remove
scheme/cyclone/transforms.sld:difference
scheme/base.sld:list
scheme/base.sld:error
scheme/base.sld:raise

Obviously, those two are defined by the rename import declaration. Is this a bug, or did I miss something obvious?

[justinethier]

This is a bug. I am able to reproduce the same issue when renaming primitives (such as bytevector-u8-ref) while renaming works fine for regular functions. Sorry about that.

Let me spend some time looking into a fix. In the meantime you can (for example) use wrapper functions for any renamed primitives to maintain your API.

[amirouche]

I stumbled upon this. There is re-export form that allows to re export primitives, it works, but not in cooperation with cond-expand. Here is an example run

;; root@8f6a1c9066f8:/live# cat live/foobar.sld
(define-library (live foobar)
  (import (scheme base))

  (cond-expand
   (cyclone
    (re-export bytevector-u8-ref))
   (else
    (import (scheme bytevector))
    (export bytevector-u8-ref))))

;;
;; The library (live foobar) is accepted by chibi
;;
;; root@8f6a1c9066f8:/live# scheme-live chibi repl
;; (import (live foobar))
;; WARNING: importing already defined binding: bytevector-copy!
;; >

;;
;; XXX: Cyclone does not like (cond-expand (re-export ...))
;;
;; root@8f6a1c9066f8:/live# cyclone live/foobar.sld
;; Error: (Unhandled expansion (re-export bytevector-u8-ref)):
;;
;; root@8f6a1c9066f8:/live#

I do not know how to easily workaround this bug, except:

• A. Create preprocessor that will rewrite live/foobar.live.sld into something that is acceptable by cyclone, and possibly other Scheme implementations

• B. ~Make it so that cyclone first look at live/foobar.cyclone.sld, then look at live/foobar.sld so that I can override the behavior for cyclone~ That does not play nice with mit-scheme

• C. Handle the expansion of re-export inside of cond-expand as part of a library definition

Mind the fact, I will prolly need to have a preprocessor (e.g. inspired from https://unsyntax.org), but solution B seems like a quick win.

I can look at doing the patch if you agree with B.

Maybe C make more sense given cyclone architecture.

[justinethier]

@amirouche what is re-export?

[amirouche]

I do not know what is re-export is, but it is valid according to cyclone when used outside cond-expand.

[amirouche]

Forget about proposal B from above, it does not play nice with mit-scheme.

[amirouche]

Sorry for the noise.