[plt-dev] flvector

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
<m.douglas.williams at gmail.com> 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
> <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
>>
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
>