Neil, Thanks for your offer of the PDK, unfortunately, I only have bought windows ME with my laptop and that got deinstalled a long time ago. ME is a really buggy system! (I was really happy to lose it).
W2K is what I use at work, but I think that it would be a license violation to transfer the files to home from work. I don't have any legal way to install the PerlNet system at home where I am working on free software projects. Luckily we have bought the PDK at work so I can look into it here. Now, I have looked into this issue some more. The plc looks very much like a c# exe, so I wont ask for source code, it seems to be able to emit a il representation, I guess using reflection.emit it would be easy. The headers of the functions look a lot like c++/c#, I wonder what the exact syntax is for them? Is there a formal description of the language syntax? My first plan is to use a pod parser to extract the perlnet blocks, and then to pass them to the parser via some form of inline system. The backend parser for the interface language should be reusable from either the gcc or the pnet c# compiler, personally I think the C# compiler from DotGNU would be the best result. That is why I have cced Rhys, the author of the dotgnu csharp compiler on this mail. If we were to try to implement a PerlNet interface to the DOTGNU, which is not my first priority, then basically, I would try and generate a IL code that resolves in a PInvoke to a perl interpreter that is handled in an object. If that is not possible, then just generate a C# interface that wraps the perl interface, exposing the IL interface and implementing via PInvoke. The implementation is not as important as the high level and typesafe specification of the perl module, that is more important than the implementation. The issue would be to extract the interface definition into some form that can easily be reused. In the introspector project, I dump the ASTs parsed into XML and read them back into perl. In GCC_XML they dump them in a easier to read XML, that might be more appropiate than the introspector XML dump. Inline::C seems to be able to parse the function definition, but I still have not understood its limitations yet. Maybe it's C/C++ header parser could be modified to parse this IDL. I would be for an simple XML data model to begin with, that could be implemented using existing parsers. In any case, the inline load system will be able to return some form of description of the IDL block passed to it, that could then be passed to any code generator needed. What do you think? Mike --- Neil Watkiss <[EMAIL PROTECTED]> wrote: > Hi James, > > I work at ActiveState, so I'll take a shot at this. > > Using the same syntax as PerlNet for creating typed > interfaces would be > great. People only have to learn one syntax for both > PerlNet apps and > other modules. Whether you buy the PDK or not, this > is a great idea. > > As for legality, ActiveState didn't patent or > trademark the interface. > As long as whatever module you write ends up release > under the same > terms as Perl, I think it should be fine. > > Just to allay any fears about this, I've asked Troy > Topnik to get you a > PDK license. > > Later, > Neil > > James Michael DuPont [17/05/02 01:11 -0700]: > > Dear Inliners, > > > > It has been a busy period for me, and you might be > > interested in what I recently found out about > PerNet, > > it uses Pod to declare strong types for language > > binding. > > > > > http://aspn.activestate.com/ASPN/Perl/Reference/Products/PDK/PerlNET/Reference.html > > > > Could this be used to help create WSDL, and also > > better strongly typed interfaces? > > > > Is it legal to use this specification without > buying > > the PDK? > > > > Mike > > > > ===== > > James Michael DuPont ===== James Michael DuPont __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
