[PPL-devel] client data for ppl_io_set_variable_output_function?

[Basile STARYNKEVITCH]

Hello All & Enea

Enea Zaffanella wrote:
> Basile STARYNKEVITCH wrote:
>>
>>
>> It would be cute if the routine passed to 
>> ppl_io_set_variable_output_function could take some client data. 
>
>
> I think I should be missing something.
>
> Can't you "embed" the access to this supplementary data pointer into 
> your own variable output function? That is, you provide an output 
> function that, when called, accesses some (possibly many) global data 
> pointer(s), rather than a single data pointer passed as a parameter.
>
> Wouldn't that be enough for your purposes?

Yes, except for one important thing. You suggestion requires adding a 
new global or static data (which I am already doing in MELT branch since 
one week ago, the static variable basilys_pplcoefvectp in line 8212 of 
gcc/basilys.c MELT branch rev144956) and that is sometimes very messy 
and error prone.

As a hint, in GCC everyone was doing that kind of "dirty" tricks, and 
the resulting code is (in that repect, and  in my humble & biased 
opinion) hard to read, hard to maintain, and hence brittle. GCC has 
hundreds of static or global variables, and that is way too much (in 
contrast, QT has basically one global variable, the QApplication one, 
and I believe GTK also have few global data variables. In term of coding 
comfort that make a huge difference.).

As an example of why client data is practically useful, most recent 
window toolkits (think of GTK, FOX, or QT) have some quite systematic 
way of providing client data for every routine pointer.

And I am very fond of functional languages (like Ocaml; and the MELT 
lisp dialect is quite functional in that aspect). They teach us that 
what matters (ie what functional values are) is not only code (like 
function pointers in C are) but closures, which are exactly an elegant 
mixture of code and data (called closed variables or closed values in 
the functional way of thinking).

So of course keeping the current interface is ok (but error prone, since 
it requires static data, and clearing/freeing it afterwards...), but a 
simplistic client data machinery [like the one I suggested] would be 
more comfortable for your users. I could live without, since my code 
already does live without.

Maybe in a C++ programming style one would subclass the class 
Parma_Polyhedra_Library::Variable (I am not sure of that) to contain 
some client data. I definitely (for GCC "political reasons") want to use 
PPL within MELT only thru its C API ((so I won't code any C++ anyway).

Regards.

BTW: for MELT my most urgent wish is of course not the client data in 
ppl_io_set_variable_output_function but simply a 0.11 version (or 
snapshot) containing the print_ppl_*_t_to_buffer functions inside 
libppl_c.so! Roberto knows about that...

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***