[e-lang] Next steps for Caja-CapTP

ihab.awad at gmail.com ihab.awad at gmail.com
Sun Oct 11 23:26:01 EDT 2009


On Sun, Oct 11, 2009 at 7:50 PM, Kevin Reid <kpreid at mac.com> wrote:
> On Oct 11, 2009, at 21:40, ihab.awad at gmail.com wrote:
>
>> a. Remove the dependency on E-on-Java and E-on-JS, resulting in a pure
>> Cajita project. ...
>
> It is a design goal of Caja-CapTP to eventually interoperate with
> other CapTP implementations, of course including the 'normal' E-based
> implementations.

Cool.

> I wish that the test suite in Caja-CapTP continue to parallel as
> closely as possible the test suite for CapTP-in-E (which currently
> exists as a component of E-on-CL), from which it was derived, so that
> improvements to tests (which are greatly needed on both sides) may be
> shared.

+1, with some questions below.

> I will not support any changes which will remove opportunities to
> avoid duplicated effort in the future. We are in general desperately
> short of available time from interested programmers.

That's a good point.

> 1. Why do you wish to remove these dependencies?

The main reason behind all these is to make Caja-CapTP easy to
integrate into Cajita projects. This was intended as a contribution to
further developing Caja-CapTP rather than a change of direction.

First of all, I'm really glad that you undertook this GSOC project and
I for one believe it will enable a huge amount of coolness. Thank you.

Speaking for myself, I am not ready to hack the core implementation or
the semantics of the tests. That said, my first step when trying to
learn a library is to look at the tests and use them as a set of
"worked examples" for how to use the library. In this case, the
"worked examples" were not in the language and runtime environment
that I was going to use for my finished product. So I took it upon
myself to rewrite the tests in terms of that environment, and so
hopefully to learn the library some more in the process.

I understand the need to have non-duplication of the tests. Perhaps
what we need may be comprehensive tests in E, and some "spot tests" /
"worked examples" in Cajita. I honestly don't know what the right
answer is at this point.

>    1a. If because E-on-Java is awkward to install, would the existence
>        of a simple installer for Unix-style operating systems, and
>        perhaps other changes to make things more pleasant, resolve
>        this?

Perhaps.

> 2. Would removing E-on-JavaScript's dependency on E-on-Java, such that
>    it was a pure-JS or possibly even pure-Cajita (maybe with some Java)
>    system, suffice? (The necessary work here would be providing a
>    parser for E written in JavaScript, perhaps by way of OMeta.)

Perhaps, though I am loath to impose extra work on you or anyone. :)

> 3. Would revising the test suite such that, while still using the Updoc
>    syntax for tests, the test code itself is Cajita, suffice?

Perhaps. That would require an Updoc-Cajita, which is why I suggested
Mike Samuel's JSDoc as a possible tool.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA


More information about the e-lang mailing list