Re: [pure-lang-users] C macros

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
>> Better yet: HYGIENIC macros. :-P
> I'm looking forward to playing with this.

These thingies are really useful! I'll post something to the list as
soon as I've had a chance to play with them some more.

> I would probably do this to if I had a computer at home. It is probably
> best that I don't because I would never get anything around the house
> done ;-)

I'm all thumbs, so my wife wouldn't let me near a hammer anyway, let
alone more precious equipment. ;-)

> In csv.c and csv.pure I just invoked an error rule with a message about
> the error. Maybe I should revisit csv.c and throw a Pure exceptions in
> the alloc cases?

(NB: Sorry, I *still* didn't have the time to review your csv yet. I'll
eventually get to it, but maybe you should just commit it to svn, so
that people can start using it. There's just so many things on my TODO
list. In particular, I have to get Pure working in Pd before October,
because I want to use that combo in a course on algorithmic composition
during the winter semester.)

Getting back to your problem:

In fact, with macros being available now, you can make it work either
way. If you already have a foo_error function, say, you can easily make
it throw an exception instead, by just adding a rule:

foo_error msg = throw (foo_exception msg);

Conversely, if you have a function foo which throws an exception and
that's unconvenient for your application, you can simply patch it up
with a macro which catches the exception and returns a foo_error value
instead.

This even works with builtins. (That'll slow them down, of course, but
in some cases it might still be a useful trick.) Example:

   > 3 div 1; 3 div 0;
   3
   <stdin>:1.9-15: unhandled exception 'signal 8' while evaluating '3 div 0'

Naughty div! Let's patch it up, baby!

   > div_fun = (div);
   > def (div) = \x y -> catch div_error (div_fun x y);
   > 3 div 1; 3 div 0;
   3
   div_error (signal 8)
   > map (\x->3 div x) (0..2);
   [div_error (signal 8),3,1]

Almost like magic. :) (Note: The extra indirection through div_fun is
needed, because we can't use (div) itself on the rhs of the macro
definition for (div) to prevent infinite macro recursion.)

> Yes, it is a GSL struct. I've been playing with the following
> constructor.
> 
> Matrix (x:xs) = (gsl_matrix_alloc rows cols, rows, cols)

No, what I meant is to wrap it up in a real constructor, not a tuple, so
that you can match against it. For the container data types, Jiri and I
developed the convention to use xyz for the construction function, Xyz
for the constructor symbol and xyzp for the type predicate, this works
pretty well. So:

matrix ys@(x:xs) = Matrix (gsl_matrix_alloc rows cols) when rows = #ys,
cols = #x end;

matrixp m = case m of Matrix _ = 1; _ = 0 end;

Of course it would be more convenient to have the Pure compiler do the
type checking on C pointer types. That's not possible with the current
symbol tables, but when I have some spare time I'll see whether I can do
something about that...

> Since I can access fields, I can completely do away with the rows and cols and access the
> rows and cols with getter functions.

Exactly. Say that these are named gsl_matrix_rows and gsl_matrix_cols,
then you could define:

#(Matrix m) = gsl_matrix_rows m, gsl_matrix_cols m;

> So you're suggesting to differentiate matrices and vectors.

No sorry, I assumed that it would be that way in GSL, but what do I
know? If vectors are just 1D "matrices" in GSL then there's no need to
do that.

> I hope you got a good rest.

Yeah, I already completed the documentation of macros in the manual this
morning, and now I'm working on private/public symbols. :)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag