on generating types files for compound libraries of multiple modules

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

on generating types files for compound libraries of multiple modules

Marco Maggi-2
Ciao,

  I see  there is  no declaration  specifier for  "-emit-types-file", is
there   a   reason?    I   would   appreciate   something   similar   to
"emit-import-library".

  Also: how do  you handle types files for shared  libraries composed by
multiple modules?   Should I generate a  types file for each  module and
install all of them along the shared library?  I doubt this is correct.

  I have shared  libraries with multiple modules compiled  in.  Only one
module is the "public" one (exporting the public API), the others export
some "public" syntactic bindings  and some "private" syntactic bindings.
Is this case currently supported by CHICKEN?

TIA
--
Marco Maggi

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: on generating types files for compound libraries of multiple modules

Peter Bex
On Wed, Aug 14, 2019 at 08:23:51AM +0200, Marco Maggi wrote:
> Ciao,
>
>   I see  there is  no declaration  specifier for  "-emit-types-file", is
> there   a   reason?    I   would   appreciate   something   similar   to
> "emit-import-library".

I don't know, but it might be just a matter of nobody having had a use
case yet.  I've made a ticket for this: https://bugs.call-cc.org/ticket/1644

>   Also: how do  you handle types files for shared  libraries composed by
> multiple modules?   Should I generate a  types file for each  module and
> install all of them along the shared library?  I doubt this is correct.

No, as far as I know you simply load the types database using -types or
-consult-types-file and that accepts any filename.  The core types
database (types.db) also contains type information for several modules.
So when you emit the types file you can just write it to a single file.

Actually, I don't think there's even functionality in place to separate
out the types per module.  So what you're trying to do sounds perfectly
fine.

>   I have shared  libraries with multiple modules compiled  in.  Only one
> module is the "public" one (exporting the public API), the others export
> some "public" syntactic bindings  and some "private" syntactic bindings.
> Is this case currently supported by CHICKEN?

That should be fine.  It's not completely standard, so you might need to
do a few things here and there to make it work, but I don't see any
problem with it.  If you're running into specific problems, let us know
and we'll try to find out what's going wrong.

Cheers,
Peter

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: on generating types files for compound libraries of multiple modules

Marco Maggi-2
Peter Bex wrote:

> On Wed, Aug 14, 2019 at 08:23:51AM +0200, Marco Maggi wrote:
>>   I see  there is  no declaration  specifier for  "-emit-types-file", is
>> there   a   reason?    I   would   appreciate   something   similar   to
>> "emit-import-library".

> I don't know, but it might be just a matter of nobody having had a use
> case yet.  I've made a ticket for this: https://bugs.call-cc.org/ticket/1644

Thanks!

>>   Also: how do  you handle types files for shared  libraries composed by
>> multiple modules?   Should I generate a  types file for each  module and
>> install all of them along the shared library?  I doubt this is correct.

> No, as far as I know you simply load the types database using -types or
> -consult-types-file and that accepts any filename.  The core types
> database (types.db) also contains type information for several modules.
> So when you emit the types file you can just write it to a single file.

> Actually, I don't think there's even functionality in place to separate
> out the types per module.  So what you're trying to do sounds perfectly
> fine.

I  see that  the type  specifications in  the ".types"  files are  fully
qualified with the module name.  So there is a form of module-awareness.

>>   I have shared  libraries with multiple modules compiled  in.  Only one
>> module is the "public" one (exporting the public API), the others export
>> some "public" syntactic bindings  and some "private" syntactic bindings.
>> Is this case currently supported by CHICKEN?

> That should be fine.  It's not completely standard, so you might need to
> do a few things here and there to make it work, but I don't see any
> problem with it.  If you're running into specific problems, let us know
> and we'll try to find out what's going wrong.

Generation and use of these ".so"  shared libraries works fine.  I meant
this  relative  to the  types  declarations.   I  want to  exploit  this
documented behaviour (from "chicken type"):

   If library code is used with `import` and a `.types` file of the same
   name  exists   in  the   extension  repository   path,  then   it  is
   automatically consulted.  This allows  code using these  libraries to
   take advantage of type-information for library definitions.

  So,  for  now I  will:  generate  a  ".types"  file for  each  module;
concatenate  them  into  a  single ".types"  file;  install  the  global
resulting file along with the shared library.  Two questions:

1. Is  there a  way to print  to stderr the  list of  consulted ".types"
files?  I do not see such an option in:

   http://wiki.call-cc.org/man/5/Using%20the%20compiler

2.   Let's assume  the  relevant  ".types" files  are  loaded; with  the
following pseudo code:  is the type specification of  "the-func" used by
the program?

(module (the-sub-module)
    ()
  (import (scheme) (chicken type))
  (: the-func (fixnum -> fixnum))
  (define (the-func N)
    N))

(module (the-module)
    ()
  (import (only (chicken module) reexport))
  (reexport (the-sub-module)))

(module (the-program)
    ()
  (import (the-module))
  (the-func 123))

TIA
--
Marco Maggi

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: on generating types files for compound libraries of multiple modules

megane

Marco Maggi <[hidden email]> writes:

> Peter Bex wrote:
>
>> On Wed, Aug 14, 2019 at 08:23:51AM +0200, Marco Maggi wrote:
>
> 1. Is  there a  way to print  to stderr the  list of  consulted ".types"
> files?  I do not see such an option in:
>
>    http://wiki.call-cc.org/man/5/Using%20the%20compiler

Giving this to csc should print the consulted .types files: -debug p

>
> 2.   Let's assume  the  relevant  ".types" files  are  loaded; with  the
> following pseudo code:  is the type specification of  "the-func" used by
> the program?
>
> (module (the-sub-module)
>     ()
>   (import (scheme) (chicken type))
>   (: the-func (fixnum -> fixnum))
>   (define (the-func N)
>     N))
>
> (module (the-module)
>     ()
>   (import (only (chicken module) reexport))
>   (reexport (the-sub-module)))
>
> (module (the-program)
>     ()
>   (import (the-module))
>   (the-func 123))

This should work if you -consult-types-file all the relevant modules
(the-module and the-sub-module) when compiling the-program.

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users
Reply | Threaded
Open this post in threaded view
|

Re: on generating types files for compound libraries of multiple modules

Marco Maggi-2
megane wrote:

> Marco Maggi <[hidden email]> writes:

>> Peter Bex wrote:

>>> On Wed, Aug 14, 2019 at 08:23:51AM +0200, Marco Maggi wrote:

>> 1. Is  there a  way to print  to stderr the  list of  consulted ".types"
>> files?  I do not see such an option in:

>>    http://wiki.call-cc.org/man/5/Using%20the%20compiler

> Giving this to csc should print the consulted .types files: -debug p

Yes.  I see it, thanks.

>> 2.   Let's assume  the  relevant  ".types" files  are  loaded; with  the
>> following pseudo code:  is the type specification of  "the-func" used by
>> the program?

>> (module (the-sub-module)
>>     ()
>>   (import (scheme) (chicken type))
>>   (: the-func (fixnum -> fixnum))
>>   (define (the-func N)
>>     N))

>> (module (the-module)
>>     ()
>>   (import (only (chicken module) reexport))
>>   (reexport (the-sub-module)))

>> (module (the-program)
>>     ()
>>   (import (the-module))
>>   (the-func 123))

> This should work if you -consult-types-file all the relevant modules
> (the-module and the-sub-module) when compiling the-program.

Good.
--
Marco Maggi

_______________________________________________
Chicken-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/chicken-users