## Papers' repositories

Was not able to find a section that would mention arXiv, CiteSeer and other repositories. Wouldn't it be nice to have one besides Research Papers, which is great, but covers specific papers and not "libraries".
The reason for using searches in the specific repository instead of Google is that some queries like "path tree graph free generated category product" result in much more enterprise related topics than category related when run under generic searcher (Google).

Luke once pointed to Peter Norvig's embedding of Prolog in Lisp as an example of the power of the language, and asked whether (or if) it could be done in Haskell. I said I would think about it, but never got around to working out the details.

Well, it turns out it's been done, and the essential bits are quite simple and intuitive, though macros would help to hide some of the abstract syntax-looking stuff (not apparent from the paper's append example).

J. M. Spivey and S. Seres. Embedding Prolog in Haskell. In Proceedings of Haskell '99 (E. Meijer, ed.), Technical Report UU-CS-1999-28, Department of Computer Science, University of Utrecht.

## Fantazies on "final"

Yesterday I was playing with unification algorithms and decided to implement one for general Java "terms" (object instances). This naive attempt stopped after 10 minutes when I understood that to make logical variables transparent to user I have to be able to create proxies for objects of any type. Even if I outlaw unboxed types, unfortunately this is not possible also for final classes... Which are expected to form the bulk of typical business objects (they are strings, numbers, ...).

This failure caused me to exercise my English in not very creative ways - I understand the original considerations of the JDK standard libraries, but history aside - is it reasonable to even wish to create a dynamic (or for that matter even static) proxy for an instance of a final class? Does not it contradict the semantic of final (that is - not inheritable)? Should not ability to intercept be separated from implementation reuse?

PS: lack of proxies for any class is not the only problem for this micro-project - mutability by default instead of having explicit cells kills any chances for transparency of such manipulations in Java - one has to proxy all objects, not just cells and transients. Ironically, both problems are related to word "final" - the first for classes and the second for variables.

## New CLR Language: Boo

This project is very interesting: a CLR-based language with Python-esque syntax, optional type declarations, open compilation pipeline, and some interesting ideas about generators and class attributes. There are some unique ideas about running a dynamic language atop the CLR, as well, like syntax to declare "duck" typing for individual objects, which lets you use them as dynamic proxies for COM objects, web services, etc.

It's definitely a bit green, but if even a significant fraction of the features discussed in the "manifesto" are there, it looks like an impressive effort, regardless.

## CÏ‰ Preview Available

CÏ‰ (pronounced C-Omega) is an extention to C# in two areas: asynchronous concurrency (formerly known as Polyphonic C#) and XML data types (Xen). A preview compiler is now downloadable from MSR:

## AOP Without The Buzzwords

I found this attempt at a buzzword free explanation of aspect oriented programming from Adrian Colyer's blog in the June archives of the ll-discuss maillist just posted. I think I finally have some idea what the aspect oriented hoohah is about, at least I was able to read the Introduction to AspectJ and make some sense of it for the first time. Maybe I'm just dense but until now I just didn't get it. This comment from Pascal Constanza in the ensuing thread shed a little more light on it at least for me coming from a functional perspective.

## ll-discuss's new home

For all those (like me) who didn't get the memo, I just found out that the seemingly defunct ll1-discuss mailing list has in fact found a new home at:

http://lists.csail.mit.edu/pipermail/ll-discuss/

## Full abstraction is not very abstract (via comp.lang.scheme)

There's been a raging battle on comp.lang.scheme for two months and 300+ posts about interpreters, denotational semantics and compositionality. I've skipped most of it, but this post from Will Clinger was instructive to me, particularly the part on full abstraction:

In other words, one of the most un-abstract semantics that could be imagined is fully abstract. Examples like this are part of the reason full abstraction is no longer regarded as a terribly useful concept.

It turns out that full abstraction is more easily achieved by making the operational semantics *less* abstract than by making the denotational semantics *more* abstract. Hence a fully abstract pair of semantics is likely to be *less* abstract than a pair of semantics that are *not* fully abstract.