Gambit-list Septembre 2008

gambit-list@iro.umontreal.ca

24 participants
33 discussions

Expose C constants to Scheme
by Arnaud Bergeron 26 Sep '08

26 Sep '08

For the LLVM interface to Scheme I am working on I need to export some constants in C to Scheme. I was advised to proceed with the following construct: (define <scheme-name> ((c-lambda () int "__result = <c-name>;"))) Since it is boring to retype the same thing a lot of times I considered making a macro, but I am facing the problem that c-lambda wants a literal string as its third argument. I can make the string I need with string-append, but I have no idea how to build a literal string in a macro. Here is what I have right now: (define-macro (c-define-const name c-name) `(define ,name ((c-lambda () int (string-append "___result = " ,c-name ";"))))) If anybody has a better idea on how to do this or a way to fix my macro, I would appreciate. Arnaud

2 1

Small patch requested
by William Cook 24 Sep '08

24 Sep '08

I'm about ready to release an alpha version of my Eclipse-based Gambit IDE. TO get this working I had to make a small change to Gambit to enable another hook. If there is a better way to do this, using the existing binaries, I'd love to know it. Here's the patch to lib/_repl.scm: ============ 2145c2145 < (define-prim (##repl-within cont write-reason) --- > (define-prim (##repl-within-default cont write-reason) 2512a2513,2514 > (set! ##repl-within ##repl-within-default) > ================== I'm asking about this because I started building a version of GSI with this feature on mulitple platforms, and its proving to be a challenge. If I could get a standard build with this feature it would be great. It allows me to hook into ##repl-within any time an error or break happens So far the IDE has: *debugging - stack trace and source location - inspection of lists, tables, and *closure* - stepping (sort of) *syntax coloring *indenting and formatting *Other things like autocompletion, source outline are not done *I don't think I can do true breakpoints without more support, but I might be able to do some function-breaks. -- William Cook http://www.cs.utexas.edu/users/wcook

2 3

Re: [gambit-list] Gambit-list Digest, Vol 48, Issue 22
by Ken Dickey 23 Sep '08

23 Sep '08

On Monday 22 September 2008 18:06:25 Arthur Smyles wrote: ... > My original example > > (if (values #f #f) #t #f) > > doesn't work in scheme because values creates a special object that is > not false so to make it work properly, No. The example does not work as you expect because you are expecting a different language semantics than the Scheme standard specifies. > I have to do: > > (if (call-with-values > (lambda () (values #f #f)) > (lambda (primary . secondary) primary)) > #t > #f) > > But if I always have to do that in order to use my function, then I > might as well not use values/call-with-values and split the function into > 2. The root problems with what you suggest are [1] not all functions talk an arbitrary number of values and [2] making this change would really torque the semantics. You are asking for ((lambda (x) (* x x)) 2 3) -> 4 (if (vaues #f 2 3 4) 1 2) -> 1 The decision that the language designers made was for safety and for compiler optimization. The safety assumption is that an error message is more appropriate than ignoring "extra" values and filling in "missing" values. Perhaps it is best to think of calling a function. Do you want all functions to pay the cost of a "rest" list? I.e. you wish to require the following two functions to be equivalent? (define (double n) (* 2 n)) == (define (double n . rest) (* 2 n)) [Some languages are defined this way. I would claim that they pay a performance penalty, but that is another discussion.] > >> Unfortunately, the only way to use the current implementation of > >> 'values' properly is to de-structure it using call-with-values. In many/most common used cases a compiler can optimize this so that values are transmitted directly without the need of a procedure call or construction of a function. I.e. (call-with-values (values 2 3) cons) can be transformed to (cons 2 3) by the compiler and even constant folded to '(2 . 3) if the compiler can "prove" from context that the cons cell is never side effected and that CONS refers to the classical binding of the cons function. Whether or not this is done is a compiler optimization problem. [I have not looked, so don't know if Gambit currently performs this optimization. You should probably do so]. You are asking that this type of optimization never be done. I think it is a lot to ask. $0.02, -KenD

1 0

Re: [gambit-list] gambit + llvm
by Arnaud Bergeron 23 Sep '08

23 Sep '08

2008/9/22 David Rush <kumoyuki(a)gmail.com>: > On Mon, Sep 22, 2008 at 8:19 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: >> I haven't looked at LLVM since its first release, and following your >> post I took a new look > > As have I. I am glad of the reminder. > >> For fun I tried compiling Gambit with llvm-gcc on my Mac OS X machine > ... >> The good news is that this works > ... >> The bad news is that the compile time is really high (10 minutes for >> some of the larger C files like lib/_num.c and lib/_io.c) and the >> execution speed if often lower than when using the standard gcc. > > Well a custom back-end would be using Gambit's high-level > optimizations and LLVM's low-level ones. I wouldn't be at all > surprised if the use of C as an intermediate language (however > stylized) introduces inefficiencies. > >> If anyone is interested in contributing to implement an LLVM back-end >> for Gambit, please send me an email. I can guide you through the >> steps required. > > I am indirectly interested, and may become actively so depending on > what happens in the next couple of months (waiting on funding :) > Please keep the list posted if anyone steps up. Too late :) I will be doing this for the semester with somebody else as a project for our compilation course with Marc. Our original project was just to compile scheme to LLVM, but since this enquiry popped up we got a proposition to do this and we accepted. Arnaud > david rush > -- > GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >

2 1

Symbol warning output made by (load) when making multiple (load):s in another thread than the primordial block the thread
by Mikael More 23 Sep '08

23 Sep '08

Hi! We have been having a strange annoyance - probably very simple to solve - for quite some while, and I wanted to address it here so that we and anyone running into it might get around it. What we do is to run a procedure that runs (load) multiple times in a sequence, where the (load):s are such that they output multiple warnings about unresolved symbols during the process. I'm well aware that unresolved symbols are not acceptable in final code, but, during development, there may be good reasons to prioritize other things than fixing symbol usage in code that's not used in the present moment anyhow. As you know, the general pattern for unresolved symbol warnings output by (load) is *** WARNING -- Variable "some-module-name#some-function-name" used in module "some-object-file.o1" is undefined The problem is that when we execute the procedure from another thread than the primordial, quite each of its warning output operations block (i.e. is blocked / freezes / waits), and gets output to the console first after that one makes an evaluation in the REPL. Making a thread-sleep! or evaluating zero is sufficient. After the evaluation, the procedure resumes until it outputs another line, and then another evaluation needs to be made to make it resume again, etc. How do we make (load) never block, undepending of in what thread it is executed? Example code below. Thanks Mikael - Set up test environment echo "(define (test) (unknown-symbol-a) (unknown-symbol-b) (unknown-symbol-c))" > a.scm echo "(define (test) (unknown-symbol-d) (unknown-symbol-e) (unknown-symbol-f))" > b.scm echo "(define (test) (unknown-symbol-g) (unknown-symbol-h) (unknown-symbol-i))" > c.scm gsc (compile-file "a.scm") (compile-file "b.scm") (compile-file "c.scm") ,q Expected behaviour, load:s don't block: gsc (load "a") (load "b") (load "c") ,q Output is: > (load "a") (load "b") (load "c") "/home/mikael/a" > *** WARNING -- Variable "unknown-symbol-d" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-e" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-f" used in module "b.o1" is undefined "/home/mikael/b.o1" > *** WARNING -- Variable "unknown-symbol-g" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-h" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-i" used in module "c.o1" is undefined "/home/mikael/c.o1" Unexpected behaviour, load:s block: gsc (thread-start! (make-thread (lambda () (load "a") (load "b") (load "c")))) Output is: #<thread #2> > (thread-sleep! 5) ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-d" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-e" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-f" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-g" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-h" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-i" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > Alternatively: #<thread #2> > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-a" used in module "a.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-b" used in module "a.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-c" used in module "a.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-d" used in module "b.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-e" used in module "b.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-f" used in module "b.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-g" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-h" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-i" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 > 0 0

2 1

Question/feature request regarding #!key parameters
by Per Eckerdal 23 Sep '08

23 Sep '08

Hi. I am working on a hygiene system on top of Gambit. It is a syntactic closures implementation and syntax-rules on top of that. There are definitely some quirks left to fix, but it is slowly getting mature. I have run into one problem though. The code (let ((a #t)) (let ((a #t)) a)) expands to something like (let ((h1#a #t)) (let ((h2#a #t)) h2#a)) This is working fine. (It is so because the outer a must be reachable from the inner let.) However, this approach cannot be used for #!key parameters. (define (fun #!key a) #f) cannot expand into (define (fun #!key h1#a) #f) Because it would force the user of the function to call it like (fun h1#a: name). It cannot expand into (define (fun #!key a) #f) either, because it breaks hygiene. This is what the system does right now, but it would be nice to actually make correct. It works rather well already, because #!key parameters are relatively rare, and usually have rather unique names (that is, not builtin functions and not nested with the same names). Is there any way of working around this? One way of fixing this would be to change Gambit to add support for syntax like (lambda (#!key ((outside-name . inside-name) default-value)) #f). In that case the example above would expand into (define (fun #!key ((a . h1#a) #f)) #f) which would be hygienic. It would be better with something that didn't needed a change in Gambit though. Any ideas? /Per

2 1

Re: [gambit-list] strange results using values
by Arthur Smyles 22 Sep '08

22 Sep '08

I've looked into your bug comment. The additional use case that I see is your example code: (let ((v (values 1 2))) (call-with-values (lambda () v) cons)) It could be re-written as: (let ((v '(1 2))) (call-with-values (lambda () (apply values v)) cons)) I don't see what a user-visible values structure provides when the user already has cons, vectors, and records. I see the call-with-values as a way to create multi-value continuations and values as the standard way to call them. If the continuation does not accept multiple values (any continuation not created by call-with-values) then I'd like to see it behave as if you just returned one value. Unfortunately, the only way to use the current implementation of 'values' properly is to de-structure it using call-with-values. I think that is redundant since I can perform the same with a list, vector, or record. What I would like is to forget about secondary values when I use it normally, and only care about them when I explicitly request it. The only way to achieve this is a values semantics that I'm advocating. Some use cases (to name a few). 1. When the primary value is expensive to create and the secondary value is cheap and dependent on the primary value. 2. for table-ref, you can have a secondary value on whether the item was actually set or not. Arthur ----- Original Message ---- I've once written a response to someone posting this as bug in bugzilla: http://www.iro.umontreal.ca/~gambit/bugzilla/show_bug.cgi?id=63 I.e. I personally still think the "take first value if continuation only expects one value" approach is a bad idea. If you're really wanting to see that behaviour, maybe you could describe the reasons in more detail and think about the issues I've lined out above; maybe there is a way to achieve both. Christian.

2 3

gambit + llvm
by Andrew I. Schein 22 Sep '08

22 Sep '08

Hi all - I am wondering if there are any efforts underway to port gambit to a llvm back end? Would this provide opportunity to eliminate a trampoline, at least in certain cases? -A -- web: www.andrewschein.com

7 18

Re: [gambit-list] strange results using values
by Arthur Smyles 22 Sep '08

22 Sep '08

Not exactly, The definition of values given by the spec is: The R5RS's definition of values: (define (values . things) (call-with-current-continuation (lambda (cont) (apply cont things)))) Let's say you can have 2 types of continuations: 1. Single value continuations 2. multi-value continuations. If the current continuation is a single value continuation, then only return one value, otherwise for a multi-value continuation (created with call-with-values) send all the arguments. The behavior could then be like: (define (values . things) (call-with-current-continuation (lambda (cont) (if (mv-continuation? cont) (apply cont things) (apply cont (car things) '()))))) In the case of (values), I'd leave that unspecified. Arthur ----- Original Message ---- From: Bradley Lucier <lucier(a)math.purdue.edu> To: Arthur Smyles <atsmyles(a)earthlink.net> Cc: Bradley Lucier <lucier(a)math.purdue.edu>; Marc Feeley <feeley(a)iro.umontreal.ca>; gambit-list(a)iro.umontreal.ca Sent: Monday, September 22, 2008 11:35:51 AM Subject: Re: [gambit-list] strange results using values It sound like you want every place in the program that takes a value to check whether there are more than one value returned, and pick the "primary" one. So if you have (define (f a b) (+ a b)) (define (g a b) (values a b)) (f (g 0 1) 2) you'd want the code to f to check that g returned only a single value, strip out extra ones if it returned more than 1, perhaps signal an error if g didn't return any values, do something else? Common Lisp deals with this somehow, but I'm not sure that we want the semantics of values in Scheme to be complicated so much in able to implement such a proposal. Brad

1 0

Re: [gambit-list] strange results using values
by Arthur Smyles 22 Sep '08

22 Sep '08

My use case for using 'values' is to pass a primary value and secondary values to a caller. If the caller can only use one value then I want it to use the primary value and discard the secondary values. So what I would like to see is: (if (values #f #f) #t #f) => #f since the primary value is false and the 'if' function can only use the primary value. As it stands now, as a caller of an api that uses 'values', I'd have to deal with it as a specialized data structure, in which case, the utility of it is very limited since I could just as well pass a vector or some other structure. I think the above semantics could be implemented and still be R5 compliant. Arthur ----- Original Message ---- From: Marc Feeley <feeley(a)iro.umontreal.ca> To: Arthur Smyles <atsmyles(a)earthlink.net> Cc: gambit-list(a)iro.umontreal.ca Sent: Sunday, September 21, 2008 7:35:59 PM Subject: Re: [gambit-list] strange results using values On 21-Sep-08, at 3:25 PM, Arthur Smyles wrote: > (if (values #f) #t #f) > > => #f > > (if (values #f #f) #t #f) > > => #t > > I was surprised to discover this. Although technically not a bug > since the scheme spec considers this situation unspecified, it makes > using multiple-values unreliable. In what way is it "unreliable"? The situation is defined as an error by the Scheme standard, which means a user cannot expect any specific behavior. Gambit handles multiple values by treating the "values" procedure as a data structure constructor (just like "vector" except with a different type tag). The exception is that when it is given a single argument it behaves like the identity function, so (values 123) = 123 . This explains why (if (values #f #f) 11 22) gives 11, just like (if (vector #f #f) 11 22) gives 11, but (if (values #f) 11 22) = (if #f 11 22) = 22 . > This affects pp as well > > (pp (values #f #f)) > > => #<unknown> What would you expect this to give? I'm not sure this is related to what you want to do, but these operations are available: > (##values? (values 11 22)) #t > (##vector->list (values 11 22)) (11 22) > (for-each pp (##vector->list (values 11 22))) 11 22 Marc

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Septembre 2008