On Fri, Sep 21, 2012 at 3:13 PM, Marvin Humphrey <[email protected]> wrote:
> I believe that we need to separate Clownfish and CFC into different
> directories and build them as distinct CPAN/etc modules.

Agree.

> *   `Clownfish::CFC` is a compiler written in C.  It has no prerequisites
>     aside from the host language.

Glanced at the Git hierarchy, and not sure I'm understanding your
naming scheme.  Clownfish::CFC is a very Perlish name, and does not
sound like something that is done in C.  I think this will scare off
potential users.

"cfish" of "cfc" by contrast help to say that it's a compiled executable.

Also, will CFCPerl.c remain part of the compiler, or can it be moved
to somewhere Perl specific?  It feels like it should be an optional
loadable module rather than built in.  Or will it be selected for at
compile time?

> *   `Clownfish` is the Clownfish core (Hash, CharBuf, VTable, Method, etc.).
.
Even here I'm a bit confused.    "Clownfish" would be a good CPAN
name, but odd for what is essentially a C library.  Why not something
more C-ish like "libclownfish" or "libcfish"?

Or is this library already specific to Perl?  I was thinking there
would be another layer, perhaps a "lib-p5-clownfish.so" wrapper that
incorporates a host-language-free "libclownfish.a".   But I'm not
thinking that clearly.

>     It depends on `Clownfish::CFC`

Do you mean there is a linked-symbol dependency, or just that it's not
likely to of much use without first running the compliler?

I'm not too concerned about the exact names, but think we do want to
combat any sense that Lucy is Lucene-lite for Perl.    Even as a great
fan of Perl, I feel that there are enough Perl haters that it's a
heritage that we don't want to lead off with.  The "loose C"
definition is great.

--nate

Reply via email to