Re: [DotGNU]C@

[Peter Minten]

/me wrote:
 
> FEATURE LIST:

Major addition: C@ will support Aspect Oriented Programming. This will allow
developers to create complex webservices more easily than in C#, giving us a
good advantage over MS in this field.

I would consider it possible that when C@ is implemented parts of DotGNU-Base
are rewritten in C@ (since C@ contains all of C# that's not a problem) because
AOP makes extending classes in a hierachy easy (which solves a problem I have
with streams and inheritance which is caused by the fact that I can't implement
certain features at the root class of the stream tree because the features
aren't ECMA/.NET).

For those of you who want to know what AOP is, here are a few good links:
http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html
http://www.aspectj.org

I'm working on a design doc (which will grow into a language spec I hope), it's
attached to this message.

Greetings,

Peter

PS: Rhys, would it be allright if I put the design doc in pnet's doc directory
(since it's the most important source of info for the C@ compiler)?

C@ Design Document

Copyright (C)  2002  Peter Minten

Permission is granted to anyone to make or distribute verbatim copies
of this document, in any medium, provided that the copyright notice
and permission notice are preserved, and that the distributor grants
the recipient permission for further redistribution as permitted by
this notice.

Version 0.1
Alpha stage

Revision history:

---------------------------------------------------------------------

Index:
======

PART 1
* Preface 
* About this document
* Introduction to Aspect Oriented Programming

PART 2
* Requirments for a C@ compiler

PART 3
* Designators
* Pointcuts
* Advice
* Introduction

PART 4
* Examples

TODO

---------------------------------------------------------------------

BEGIN INFORMATIVE TEXT

Preface:
========

The idea of C@ arose during a IRC meeting of C# developers in the
DotGNU project. We were discussing a way to use the expression
'!object' as a shortcut for the much used expression 'object ==
null'. The discussion ended when it became clear that this could be
done with a change in the base library of C#, but it would have a high
cost in performance. I then made a joke that we should start thinking
about the successor of C@, a discussion followed resulting in a naming
the proposed successor language address@hidden

So a the idea for new language was born. In the following days I
collected ideas for the new language, most of the ideas were about
extending C# to make programming with it easier (for example the
friend keyword known from C++ was proposed and accepted).

On the meeting aspect oriented stuff was also mentioned. I ignored the
idea of giving C@ aspect oriented stuff at first but the concept kept
crawling around the inside of my skull so I began reading some stuff
on the net. At first I didn't understand it, but some good tutorials
and a lot of spare time helped me understand the basics of Aspect
Oriented Programming (AOP). 

END INFORMATIVE TEXT

---------------------------------------------------------------------

BEGIN INFORMATIVE TEXT

About this document:
====================

This document is a work in progress, all information in it can
change. The chance that this document is updated can be estimated from
the stage this document is in (which is written at the top of the
document under the version number). Alpha versions are only good for
people who want to closely track the development of the standard, they
are highly subject to change. Beta versions can be used to give a
larger audience an idea of the language, beta versions don't change
very often. Release versions can be considered stable enough to build
a compiler on, they can change however (though we will try to avoid
that). It is possible that at some point in the future a version is
labelled final, this version won't change, but it can be doubted if it
will ever appear.

END INFORMATIVE TEXT

This document describes the C@ language, it gives a set of requirments
and advices that builders of C@ compilers can use. It doesn't say how
to build a C@ compiler in detail however.

The texts in this document can be divided into 3 categories:
* Informative text: Simply information.
* Normative text: Rules that a conforming compiler must obey.
* Conditional normative text: Stuff that a conforming compiler may 
implement, but if it implements it the rules expressed in this text 
must be followed.

All text that isn't explicitely marked as part of one of these
categories is normative text.

---------------------------------------------------------------------

Introduction to Aspect Oriented Programming:
============================================

---------------------------------------------------------------------

Requirments for a C@ compiler:
==============================

A conforming C@ compiler must be able to do the following:
* Reading a C@ source file.
* Validating a C@ source file.
* Printing an human readable error message in English if the C@ source 
file contains errors.
* Compiling a valid C@ source file to an IL executable or IL library.

Also a conforming C@ compiler must be a conforming C# compiler with
some exceptions. The exceptions are marked in this document as
such. The C# specification is available at the website of ECMA
(www.ecma.ch) and is named ECMA-334.

---------------------------------------------------------------------

Designators:
============

---------------------------------------------------------------------

Pointcuts:
==========

---------------------------------------------------------------------

Advice:
=======

---------------------------------------------------------------------

Introduction:
=============

---------------------------------------------------------------------

Examples:
=========

For these examples I use this class:

public class Foo
{
        public int Bar(int something)
        {
                //Code
        }
}

A good example of a pointcut in C@ is:

pointcut a (int b, int c) = call{b = int Foo.Bar(int c)}

This means that pointcut a is activated when method Bar from class Foo
is called. Pointcut a then receives the value of the argument supplied
to the  method (c), it also  receives the returnvalue of  Bar (b). The
following advice uses this information:

advice d : before a(int b, int c)
{
        Console.WriteLine("Bar was called with argument {0} 
                and returned {1}",c, b);               
}

This means that before method Foo.Bar is executed the text is printed
on the console.

An example of a classlist are these (Baz is a struct):

classlist e = Foo;
classlist f = Foo, Baz;

Classlist a is used for an introduction:

introduction = g
{
        private void something; //Useless, but good as an example
} >> e;

This puts 'private void something' in class Foo.