Since 4.ss in srfi is nothing other than: (require (matching-identifiers-in #px"\\b_?[suf](8|16|32|64)vector\\b" scheme/foreign)) (provide (all-from-out scheme/foreign)) I assume just requiring SRFI 4 is negligible overhead and I might as well just use it. Doug <div class="gmail_quote">On Fri, Dec 18, 2009 at 11:45 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The two different -> s are really different things, so when you have both of them in a single file you need to do something to distinguish between them. I think that in this case, probably the best thing is to prefix the foreign imports with, say, f:. Robby On Fri, Dec 18, 2009 at 12:42 PM, Doug Williams <div><div></div><div class="h5"><<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> wrote: > I just tried removing my dependency on SRFI 4 by using the scheme/foreign > module (which also defines them). However, when I require the scheme/foreign > module, I have a problem. It has the following snippet of code: > > (provide ->) ; to signal better errors when trying to use this with > contracts > (define-syntax -> > (syntax-id-rules () > [_ (raise-syntax-error '-> "should be used only in a _fun context")])) > > So, my function contracts in the requiring module now give an error. > > I've never used the FFI interface, but I can see that it uses -> as part of > the syntax for defining foreign functions. But, the comment "to signal > better errors when trying to use this with contracts" would imply it is > supposed to help me somehow, not disallow the use of function contracts with > something that requires scheme/foreign. Am I missing something? > > > On Fri, Dec 18, 2009 at 10:02 AM, Doug Williams > <<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> wrote: >> >> Matthew, >> >> Attached is a zip file with some homogeneous vector and array code I was >> working on in the past. The code in vtype.ss abstracts the definitions of >> the various SFRI 4 vector types (and regular Scheme vectors). The vector >> types it knows about are object (i.e., straight Scheme heterogeneous >> vectors), u(8,16,32,64), s(8,16,32,64), and f(32,64). There are also complex >> vectors of the numeric types cu(8,16,32,64), cs(8,16,32,64), and cf(32,64). >> The code in type-vector.ss abstracts the vector types describes in vtype.ss >> into a single typed-vector type. The code in array.ss provides the array >> abstraction with the underlying data stored as a typed-vector. Finally, the >> array-test.ss test the array abstraction. [Just running array-test.ss will >> give you a pretty good idea about the array abstraction.] >> >> The intent is to provide a homogeneous array implementation similar to the >> underlying arrays in Matlab (or numpy in Python). This is what I would like >> to make more efficient and better integrated into the rest of PLT Scheme. >> >> So, I guess the questions are: >> >> 1) Should I skip SRFI 4 altogether? The SRFI 4 implementation just exports >> things from scheme/foreign, so it would probably make sense to go straight >> to it. But, I am also using the naming convention from SRFI 4. >> >> 2) How would array slicing best look syntactically? I have a simple >> slicing capability there now so you can see what it looks like. But >> basically, for any dimension, you can specify a list (start end step) and >> any element can be wildcarded using * - also, the whole dimension can be >> wildcarded. Efficient slicing (e.g., no copying required) is an important >> element of the design. >> >> 3) How would we best tie it to the rest og PLT Scheme? In particular, it >> would be nice to have efficient implementations of the various for routines >> that just strided through the underlying vector efficiently. But, I think >> that will require knowledge of the underlying vector type. etc and might be >> a lot of work. >> >> So, I think getting a really efficient implementation would require >> significant coordination with the PLT developers. My long-term goal (as >> you've probably heard me say before) is to get a Matlab-like (or >> Matlab-lite) analysis capability. >> >> Any thoughts? >> >> Doug >> >> On Fri, Dec 18, 2009 at 8:41 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote: >>> >>> In case anyone is already using the `flvector' operations, they've >>> moved to a new `scheme/flonum' library. >>> >>> (I'm preparing a post about `scheme/flonum' for the plt-scheme list.) >>> >>> >>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> <a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a> >> > > > _________________________________________________ > For list-related administrative tasks: > <a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a> > > </div></div></blockquote></div>