iu-parfunc / accelerack

C Bindings for Accelerate, Racket Frontend to Accelerate
2 stars 2 forks source link

Cleanup: rename array -> internal-make-array #23

Closed rrnewton closed 8 years ago

rrnewton commented 8 years ago

This is one of the renames that need to happen.

We expose (acc-array <data>) as our user-facing literal syntax. The internal one that is anntotaed with type and shape info should be called (internal-make-array _ _ _), with the name open to discussion in the comments here.

pavenvivek commented 8 years ago

The current name is acc-array. Should we rename it to internal-make-array? If so then for creating the array we need to do make-internal-make-array which seems to be little bit confusing. Or we can just rename it to internal-array? [acc-array -> internal-array]

rrnewton commented 8 years ago

I was referring to the one that starts:

(define-syntax (array stx) 
  (syntax-case stx ()
    [(array (shape ...) type (data ...))
                           #'(letrec ((data* (process-data (syntax->datum (syntax (data ...)))))
                                      (ret (verify-accelerack (vector type (syntax->datum (syntax (shape ...))) data*))))
                                     (if (car ret)
                                         (acc-alloc type (syntax->datum (syntax (shape ...))) data*)
                                         (error 'verify-accelerack (cadr ret))))]

That was the one I was calling "internal".

But, you know what, I'm not sure there's a good reason to have two syntaxes. We should have the (acc-array ..) syntax which infers the type/shape of its argument. And then we could possibly have internal helper functions (not syntax) that do some of the above logic, if necessary.

And, perhaps even that is not necessary. The newer acc-array one can be updated to call acc-alloc directly.

pavenvivek commented 8 years ago

So how we should proceed here? Should we rename our user facing acc-array to acc-alloc or low level array to internal-make-array?

rrnewton commented 8 years ago

Now that I understand what's going on better, I now think that this macro won't be needed. See #36 for discussion.