Gambit-modules-list

gambit-modules-list@iro.umontreal.ca

21 discussions

Duh. Sorry. Re: Cannot define variables by the
by Mikael More 08 Aoû '09

08 Aoû '09

Duh... +1 and -1 are integers. Sorry. Mikael 2009/8/8 Mikael More <mikael.more(a)gmail.com> > In gsc: > > > (define +1 'a) > *** ERROR IN (console)(a)1.9 -- Identifier expected > > (define -1 'a) > *** ERROR IN (console)(a)2.9 -- Identifier expected > > (define 1+ 'a) > > (let ((+1 #t)) #t) > *** ERROR IN (console)(a)4.8 -- Identifier expected > > > In BH: > > (define (+1) #t) > *** ERROR IN ##main -- (Argument 1) SYMBOL expected > (symbol->string 1) > > (define (-1) #t) > *** ERROR IN ##main -- (Argument 1) SYMBOL expected > (symbol->string -1) > > (define (1+) #t) > > (define (*1) #t) > > (define (%1) #t) > > (define +1 #t) > *** ERROR IN ##main -- (Argument 1) SYMBOL expected > (symbol->string 1) > > (define -1 #t) > *** ERROR IN ##main -- (Argument 1) SYMBOL expected > (symbol->string -1) > > (define + #t) > > (define - #t) > > (define -5 #t) > *** ERROR IN ##main -- (Argument 1) SYMBOL expected > (symbol->string -5) > > (define +a #t) > > (define -a #t) > > (let ((+1 #t)) #t) > *** ERROR IN ##main -- (Argument 1) SYMBOL expected > (symbol->string 1) > > (let ((+ #t)) #t) > #t > > > Why? > > Mikael > > > _______________________________________________ > Gambit-modules-list mailing list > Gambit-modules-list(a)mercure.iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-modules-list > >

1 0

Cannot define variables by the name +1 or -1 neither in Gambit nor in
by Mikael More 08 Aoû '09

08 Aoû '09

In gsc: > (define +1 'a) *** ERROR IN (console)(a)1.9 -- Identifier expected > (define -1 'a) *** ERROR IN (console)(a)2.9 -- Identifier expected > (define 1+ 'a) > (let ((+1 #t)) #t) *** ERROR IN (console)(a)4.8 -- Identifier expected In BH: (define (+1) #t) *** ERROR IN ##main -- (Argument 1) SYMBOL expected (symbol->string 1) > (define (-1) #t) *** ERROR IN ##main -- (Argument 1) SYMBOL expected (symbol->string -1) > (define (1+) #t) > (define (*1) #t) > (define (%1) #t) > (define +1 #t) *** ERROR IN ##main -- (Argument 1) SYMBOL expected (symbol->string 1) > (define -1 #t) *** ERROR IN ##main -- (Argument 1) SYMBOL expected (symbol->string -1) > (define + #t) > (define - #t) > (define -5 #t) *** ERROR IN ##main -- (Argument 1) SYMBOL expected (symbol->string -5) > (define +a #t) > (define -a #t) > (let ((+1 #t)) #t) *** ERROR IN ##main -- (Argument 1) SYMBOL expected (symbol->string 1) > (let ((+ #t)) #t) #t Why? Mikael

1 0

Re: [Gambit-modules-list] BH - how do references from depending
by Mikael More 16 Jul '09

16 Jul '09

I thought that when you compile with (declare (block)), the variable references created to exported-var of a.scm from b.scm would be bound to the first loaded version. This was however not the case. This is how it is: any variable references you make in closures and data structures are locked to the first version. All other are not. Very nice! Mikael (work-closure1 below is indeed not a closure.) mc@debian:/tmp$ cat > a.scm.1 (print "Module A import\n") (define exported-var 'something) mc@debian:/tmp$ cat > a.scm.2 (print "Module A import\n") (define exported-var 'something-else) mc@debian:/tmp$ cat > b.scm (import a) (define (work-when-separate) exported-var) (begin (declare (block)) (define (work-when-block) exported-var)) (define work-closure1 (lambda () exported-var)) (define work-closure2 (let ((c exported-var)) (lambda () c))) (define structure (cons exported-var 'something-tihrd)) debian:/tmp# bsc > (import b) Module A import > (work-when-separate) (work-when-block) (work-closure1) (work-closure2) structure *something > something > something > something > (something . something-tihrd) *> [1]+ Stopped bsc debian:/tmp# cp a.scm.2 a.scm debian:/tmp# fg bsc (import b) Module A import > (work-when-separate) (work-when-block) (work-closure1) (work-closure2) structure *something-else > something-else > something-else > something > (something . something-tihrd) *> ,q debian:/tmp# bsc > (module-compile! 'b) > [1]+ Stopped bsc debian:/tmp# cp a.scm.1 a.scm debian:/tmp# fg bsc (module-compile! 'a) > (import b) Module A import > (work-when-separate) (work-when-block) (work-closure1) (work-closure2) structure *something > something > something > something > (something . something-tihrd) *> [1]+ Stopped bsc debian:/tmp# cp a.scm.2 a.scm debian:/tmp# fg bsc (import b) /tmp/a is being compiled... Module A import > (work-when-separate) (work-when-block) (work-closure1) (work-closure2) structure *something-else **> something-else > something-else > something > (something . something-tihrd)* > 2009/7/15 Per Eckerdal <per.eckerdal(a)gmail.com>: > Jag förstår inte frågan? > > 15 jul 2009 kl. 11.01 skrev Mikael More: > >> Per, >> >> Regarding what variable references that module B does to module A, that >> are updated when A has been changed and you import A again (for instance >> through importing B again) - >> >> given a.scm: >> >> (print "Module A import\n") >> (define exported-var 'something) >> >> And b.scm: >> >> (import a) >> >> (define (work-when-separate) exported-var) >> (begin (declare (block)) (define (work-when-block) exported-var)) >> >> (define work-closure1 (lambda () exported-var)) >> (define work-closure2 (let ((c exported-var)) (lambda () c))) >> >> (define structure (cons exported-var 'something-tihrd)) >> >> And doing (import b) in BH >> >> And then altering a.scm into: >> >> (print "Module A import\n") >> (define exported-var 'something-else) >> >> And doing (import b) again, thus reimporting a: >> >> I get something-else from (work-when-separate), (work-when-block) and >> (work-closure1), both when B is executed in interpreted and compiled mode. >> >> Even if it's great from incremental development point of view; should it >> really be like this? >> >> Mikael >> >> _______________________________________________ >> Gambit-modules-list mailing list >> Gambit-modules-list(a)mercure.iro.umontreal.ca >> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-modules-list > >

2 1

Black Hole documentation released in beta version, request for
by Mikael More 15 Jul '09

15 Jul '09

The documentation for Black Hole is released in a beta version on http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Black_Hole . The bundled libraries documentation document is an early draft. Give your input on how you prefer the bundled libraries and their exports to be documented and indexed - including what file format it should be written in, and how document files should be generated - at this early stage of the construction of their documentation. Please submit any feedback, questions or suggestions you have on the current version of the documentation, during the next three weeks from now. Thanks, Mikael

1 0

BH - how do references from depending modules to the modules depended
by Mikael More 15 Jul '09

15 Jul '09

Per, Regarding what variable references that module B does to module A, that are updated when A has been changed and you import A again (for instance through importing B again) - given a.scm: (print "Module A import\n") (define exported-var 'something) And b.scm: (import a) (define (work-when-separate) exported-var) (begin (declare (block)) (define (work-when-block) exported-var)) (define work-closure1 (lambda () exported-var)) (define work-closure2 (let ((c exported-var)) (lambda () c))) (define structure (cons exported-var 'something-tihrd)) And doing (import b) in BH And then altering a.scm into: (print "Module A import\n") (define exported-var 'something-else) And doing (import b) again, thus reimporting a: I get something-else from (work-when-separate), (work-when-block) and (work-closure1), both when B is executed in interpreted and compiled mode. Even if it's great from incremental development point of view; should it really be like this? Mikael

1 0

Syntactic tower again – would this work?
by Per Eckerdal 25 Mai '09

25 Mai '09

Ok, So, when working with trying to understand how to implement and work with hygiene, one of the things that I have discovered is that often the specification and/or documentation of stuff related to hygiene contain seemingly random and stupid things. Later on, I have often had to realize the hard way why it was like that. I wonder if I have come to another situation like that. SRFI-83 (R6RS library syntax) contains a seemingly random and ugly limitation; It doesn't have anything like BH's syntax-begin. What you can do instead is to specify whether you want to import modules for run-time or compile-time. Importing srfi-1 for use by macros could look like this in BH: (syntax-begin (import srfi-1)) Or like this in SRFI-83: (import (for srfi-1 expand)) The two rows above are roughly equivalent, but as I understand it there is no SRFI-83 equivalent of (syntax-begin (syntax-begin (import srfi-1))) That is, importing things for use in the macro expansion expansion phase. So far, I have thought that this is a stupid thing, needlessly limiting what can be done, plus it's not as theoretically elegant. But I have realized that there might be a point in doing it like SRFI-83: It is an elegant way of limiting imports to the first and second level of the syntactic tower. Even though you cannot (or at least should not) limit how high the syntactic tower can be, you can limit all levels above two to not include any other modules, thus limiting them to the standard library. You would also need to remove the possibility to have state in levels higher than the first. (For instance (syntax-begin (define state-var #f))). In practise this would mean to remove syntax-begin and replace it with a less powerful construct like the one in SRFI-83, let's call it import-for-syntax. I hope this limitation would allow BH to only have at most two instances of each module at any given time. (Assuming that the standard library doesn't have any state) Consider this example: a.scm: (import b) (b-mac) b.scm: (import c) (define-syntax b-mac (sc-macro-transformer (lambda (form env) `(c-mac)))) c.scm: (import-for-syntax d) (define-syntax c-mac (sc-macro-transformer (lambda (form env) (my-not #t)))) d.scm: (define (my-not bool) (if bool #f #t)) When macro expandng (compiling) modules, the module system would conclude to do it in the order d, c, b, a. Compiling d, it would compile two functions, say d#my-not and d~#my-not. Compiling c, it would compile the c-mac macro (only one instance of it). c-mac would use the d~#my-not function. Similarly for b, it would compile one instance of b-mac. When compiling a, it would invoke b-mac, which would expand to (c-mac), leading to an invocation of that macro, which would call the compile-time version of my-not. Doing it this way, it would be possible to allow two modes of compilation, one for releases, where only run-time versions of definitions are included, and all macro information is stripped, and one for development, which also contains compile-time definitions, macros, and other module information like dependencies and exported variables and macros. Does this make sense? To me, this seems like a good compromise between correctness, power and speed. I can't think of any practical case where this less powerful way of doing things isn't powerful enough, although sometimes helper modules for containing macro state would be needed. /Per

1 1

Does Black Hole export C type definitions just like it does with
by Mikael More 30 Avr '09

30 Avr '09

Per, I have a vague memory that when I checked the most previous time, when in module A I declared a particular C type, and in module B I had a C FFI definition that made use of that type (for argument or return value), I needed to redefine the C type in module B. How is it nowadays? Are there any risks involved in this, such as that the one and same C type, as created by FFI routines in module A and B, could somehow appear as made of two different types, or that they would somehow be incompatible with each others? Mikael

3 2

Ann.: CHICKEN 4.0.0 - comp.lang.scheme | Google Groups
by Bradley Lucier 06 Avr '09

06 Avr '09

Note particularly: - The macro system has been completely rewritten and is now fully hygienic with highlevel R5RS "syntax-rules" macros and low level "explicit renaming" macros that allow full control over hygiene; "define-macro" is not available anymore - A module system has been implemented that fully supports hygienic macros and integrates with separate and cross compilation; module- and syntax meta-information is not retained in compiled run-time code, unless explicitly enabled by the user - Experimental support for cross-module inlining http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/ 3d248d275f929b97#

1 0

Re: [Gambit-modules-list] Syntactic tower
by Marc Feeley 03 Avr '09

03 Avr '09

On 2-Apr-09, at 4:25 PM, Per Eckerdal wrote: > But I still don't see any error in the main point of my previous > mail, that is that only two different sets of globals are needed. No... that's wrong. In the tower model each instance is an independent cell. If one of the levels is keeping state in one of these cells, you don't want it to interfere with the state in another cell (i.e. for the same variable at a different level). Keeping state is useful at the macro expansion level to keep tables of macros you have seen in the file being expanded. State is not the only thing... you might store in a module's variable "v" some information which will not be the same at all levels (a timestamp, a data structure, a list, etc). So you can't get out of this trouble by ordering the initializations. Marc

2 4

Syntactic tower
by Per Eckerdal 02 Avr '09

02 Avr '09

Hello again. I have been thinking about how to implement the syntactic tower in a simple but correct way. What I have come up with is this: In a module, there are different environments, one for each different phase of evaluation (runtime, macro expansion time, macro macro expansion time and so on). (This is not a new invention in any way. I just hope that I have copied the concepts correctly.) If you write normal code with no macros, only environment with phase 0 is into play. You get into the next phase in macro definitions or by using the syntax-begin form: (import srfi-1) (syntax-begin (import srfi-13)) (define (a-function) ;; This is inside environment phase 0. ;; Things from srfi-1 are available, but not things from srfi-13. fold) (define-macro (a-macro) ;; Because this is macro definition, this is inside environment phase 1. ;; Things from srfi-13 are available, but not things from srfi-1 (define-macro (an-inner-macro) ;; This is inside environment phase 2. ;; Neither srfi-1 nor srfi-13 are imported in this environment. "hello world") (string-titlecase (an-inner-macro))) The module system's runtime functions (for instance expand-macro and syntax-rules) are available at the REPL and at all environments whose phase >= 1. It's possible to use the module system's runtime in modules' functions, but then you have to explicitly import the module system. This is to make it clear that unless explicitly noted, compiled code is not dependent on the module system. This also makes it easier to tell which modules need to be loaded when compiling a module. Does this make sense? Or am I trying to solve a non-problem? Is this overly difficult to understand? /Per

4 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Gambit-modules-list