Sunday, October 26, 2008

How to improve Curl

One terrific thing about Curl as a language is that the compiler directives are able to help ensure coding standards as code evolves to production quality.

One vexing thing in Curl code is to find {field } expressions occurring willy-nilly within a {define-class }.

I propose an option for {define-class } such that the expression {attributes } is the one-and-only set of fields declared as follows:
{attributes
my-i-attr1:int
my-f-attr2:float
|| etc
}
In such a class definition the {field } expression may not occur when compiler-directives include
rational? = true ||humor

I would further propose the declaration grouping
{class
}
to replace and preclude the use of
{define-proc }
within a class declaration.

For the instance-side of a class, I would propose the use of the method grouping expressions
{public
and
{private
and
{protected
and that where such expressions occur, that no
{method
be permitted to be free-standing within that class definition when rational? = true and that only one occurrence of each grouping be permitted. A further restriction might require that public precede protected which must precede private.

The {class } expression would also permit some class-side procedures to be declared as final, sealed or open.

The compiler-directive rational? = true would be stronger than stringent?, i.e., classes compiled in a rational? package would be thereby also stringent?

To take a page from another language, within these method groupings, a blank line would separate method declarations and only method declarations.

One further option is to have {i-attributes } and {d-attributes}. No default values are declared for the former as they must be initialized in a factory/constructor method whereas the latter need not.

Clean code is readable code and readable code may be maintainable code.

Saturday, October 25, 2008

The Future of Curl

Over at Curl I have added some comments to an invitation by Richard Monson-Haefel to weigh-in on improving Curl.

Divining the future of Curl means thinking outside the box. Here's a few attempts.

Pair up Curl as a client-side to Gemstone as has been done by Seaside.

Beef-up Curl on the client-side by getting serious about the future of expression-based languages: if there is not room in the marketplace for ICON, UNICON, REBOL and Curl then look to partner with the remnant of the ICON team at U. of Arizona.

If the Curl team cannot partner-up, then look to go beyond one of those languages by having more effective goal-oriented programming than UNICON or more user-friendly parsing than REBOL.

The option of viewing Curl as a platform and not a language seems to close off many avenues unless Curl, the platform, is able to embrace languages such as ICON which appear to be in need of a new home.

Or is there a niche for Curl in the future of Perl with Parrot, or Ruby with an industrial-quality VM, or distributed OZ?

One interesting place to look is GROK and what they are looking to do with Python ZOPE. That project alone might ensure the future of ZOPE.

Then there is RDF. Somehow RDF has become tied to clunky XML implementations or worse. Even now that W3C has embraced "sparkle" for RDF Data Access, we need not ignore the prospects for Curl as a potentially RDF-friendly language. Prima facie, ICON back-tracking and REBOL paths make either look more promising as a language. But Curl, the platform, could be a powerful starting point for a more language-neutral approach to RDF triples. Mozilla XUL has moved away from RDF (blame XML there, where the 'X' is for 'Xtra-heavy' rather than eXtensible.) The real-issue is how to effectively provide metadata. As more people look to HTML and XHTML itself as the answer, Curl appears to be a natural: Curl has always been metadata-friendly.

Curl CSPD could even be used to help ensure that meta-data that would disclose too much would be suppressed where privacy is an issue (think blogging in China and i-journalism most anywhere.)