Details

Description

The Clownfish compiler was originally written in pure Perl, which has proven
to be a barrier to entry for people who want to work on binding Clownfish to
other languages but who don't know Perl. We should port the compiler to C,
the common language across all of Lucy's subcommunities.

DONE Migrate to an inside-out object model within the Clownfish
compiler internals. This makes it easier to move piecemeal from Perl
implementations to XS to C implementations.

DONE Eliminate sophisticated usage of polymorphism by Clownfish
compiler components, e.g. by rolling up many Type classes into one
module. In our C-based compiler, we can still use crude inheritance
based on struct layout and casting, but we don't want to require method
overriding if we can help it.

UNDERWAY Port primary Clownfish components to thin XS wrappers around C
implementations. This includes everything within trunk/clownfish/lib/
except the items under lib/Clownfish/Binding/ and lib/Clownfish/Parser.pm.

Port everything under trunk/clownfish/lib/Clownfish/Binding/ to XS
wrappers around C code.

Port Clownfish/Parser.pm to an XS wrapper around a C implementation using
Lemon.

Port all the test files in trunk/clownfish/t/ to C, using the test
harness code provided by Charmonizer.

Change the interface by which bindings are spec'd to e.g. parse static
JSON files rather than be invoked from Perl code, and change over all the
binding specs embedded within .pm files in trunk/perl/lib/ to use the new
interface.

Remove all Perl/XS from trunk/clownfish/.

Since that posting, stage 3 has been completed.

Stages 4 and 5 are actually independent tasks which could be tackled in
either order.

Marvin Humphrey
added a comment - 15/May/11 22:24 The dev list thread at http://s.apache.org/ub , continued at
http://s.apache.org/2vC , contains a list of stages in which the porting
might proceed:
DONE Migrate to an inside-out object model within the Clownfish
compiler internals. This makes it easier to move piecemeal from Perl
implementations to XS to C implementations.
DONE Eliminate sophisticated usage of polymorphism by Clownfish
compiler components, e.g. by rolling up many Type classes into one
module. In our C-based compiler, we can still use crude inheritance
based on struct layout and casting, but we don't want to require method
overriding if we can help it.
UNDERWAY Port primary Clownfish components to thin XS wrappers around C
implementations. This includes everything within trunk/clownfish/lib/
except the items under lib/Clownfish/Binding/ and lib/Clownfish/Parser.pm.
Port everything under trunk/clownfish/lib/Clownfish/Binding/ to XS
wrappers around C code.
Port Clownfish/Parser.pm to an XS wrapper around a C implementation using
Lemon.
Port all the test files in trunk/clownfish/t/ to C, using the test
harness code provided by Charmonizer.
Change the interface by which bindings are spec'd to e.g. parse static
JSON files rather than be invoked from Perl code, and change over all the
binding specs embedded within .pm files in trunk/perl/lib/ to use the new
interface.
Remove all Perl/XS from trunk/clownfish/.
Since that posting, stage 3 has been completed.
Stages 4 and 5 are actually independent tasks which could be tackled in
either order.

I have come to believe that porting the modules which generate
host-language-specific binding code to C was a mistake. I think it would be
best if the Perl-binding generation code was in Perl, the
Ruby-binding-generation code was in Ruby, etc.

The downside is that it will not be possible to e.g. generate Ruby bindings
while running CFC under Python. But in exchange, it becomes easier to
write the binding-generation code, and easier to interface with it and provide
programmatically generated input.

Therefore, I intend to more-or-less revert the porting work I have done for
Clownfish::Binding::Perl*.

Marvin Humphrey
added a comment - 20/Dec/11 03:42 I have come to believe that porting the modules which generate
host-language-specific binding code to C was a mistake. I think it would be
best if the Perl-binding generation code was in Perl, the
Ruby-binding-generation code was in Ruby, etc.
The downside is that it will not be possible to e.g. generate Ruby bindings
while running CFC under Python. But in exchange, it becomes easier to
write the binding-generation code, and easier to interface with it and provide
programmatically generated input.
Therefore, I intend to more-or-less revert the porting work I have done for
Clownfish::Binding::Perl*.

Marvin Humphrey
added a comment - 20/Dec/11 03:58 It is not necessary to port the test suite for CFC in order to move forward
with bindings for other host languages, so I have opened a separate issue for
that task: LUCY-201 .