[plt-dev] flvector

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 <
m.douglas.williams at gmail.com> 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 <mflatt at cs.utah.edu> 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:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091218/5ffe062a/attachment.html>