This list is for developers contributing to the C2 Language Specification or its Standard Library. The list can be high volume and sometimes quite technical. All decisions related to C2 Language Specification or its Standard Library are discussed here. Formal language or library proposals should also be submitted to this mailing list.

Welcome!

Welcome to the C2 Developers Forum. 

Please see http://c2-lang.org/lists.html for posting guidelines and
other info.

--
Slawomir Lisznianski
C2 Language Group Principal (http://c2-lang.org)

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

headers

Slawomir Lisznianski | 4 Sep 09:09

Sep-4-WD: C2 Programming Style

Attached, for your review, is the September 4 Working Draft of the C2
Programming Style document. 

I figured we might as well go over it and put it behind us. 

The C2 Language Specification uses code examples to clarify some of the
aspects of the language. Those examples will be written to comply with
the programming style laid out in the attached document, after its
approval.

Speak freely about the code conventions this document proposes. If you
have any suggestions or corrections let us know.

Regards,

--
Slawomir Lisznianski
C2 Language Group Principal (http://c2-lang.org)

Attachment (C2ProgrammingStyle.pdf): application/pdf, 36 KiB

headers

edA-qa | 5 Sep 11:28

Proposal for Include files/headers

Rather than use the old C style of just #include I would recommend a 
better manner of handling dependencies.

If you watch the C++ standards discussions you'll also realize there 
technically is now no really portable way of using header files, since 
there is a lack of clarity between #include <file> and #include "file".

What would be nice is a Java style import system, which makes it easier 
for new users, and can remove the problem of ordering of dependencies. 
(The #include system should also remain since it has other uses than 
resolving dependencies).

Example:

	#import Math.Matrix	//get a single definition
	#import Http	//get entire namespace

The implementation then needs a resolution system for importing.  This 
works similar to includes files, but there are "Import" directories. 
Each namespace is translated to a directory and filename.  Beforehand 
the compiler can't know whether it is a namespace or a class or symbol, 
so it has to try all possibilities.

So in the above, the searching for the above might look like:

	1. search for: importDirN/Math/Matrix/all.imp
	2. search for: importDirN/Math/Matrix.imp
	3. search for: importDirN/Math/all.imp
	4. end search

(Continue reading)

headers

Slawomir Lisznianski | 5 Sep 23:16

Re: Proposal for Include files/headers

edA-qa wrote:

> Rather than use the old C style of just #include I would recommend a 
> better manner of handling dependencies.

I agree that a more robust mechanism would be a good change. Let's see 
if we can come up with something useful...

> What would be nice is a Java style import system, which makes it easier 
> for new users, and can remove the problem of ordering of dependencies. 

We have to be very careful in trying to adopt something like the Java 
"import" model. The Java approach is very suitable for systems that use 
intermediate language representation (such as byte-codes). In those 
systems, declaration (header) files and implementation files are blended 
into one. But let's be ignorant for a while...

> (The #include system should also remain since it has other uses than 
> resolving dependencies).

I agree that the preprocessing phase is handy. Some enhancements to the 
preprocessor, such as support for recursion, would be useful-- 
generation of boiler plate templates with N-number of parameters would 
be a snap.

> Example:
> 
>     #import Math.Matrix    //get a single definition
>     #import Http    //get entire namespace

(Continue reading)

headers

edA-qa | 6 Sep 08:45

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> I suggest, rather than introducing another keyword, to enhance the 
> workings of the existing "using" language declaration. Also, I'm not 
> particularly fond of the idea that a program source code relies that 
> there is even a file-system underneath it. After all, classes, 

I don't like the idea of being file system dependent either.  Though in 
interests of portability you need to define at least one mechanism that 
users of the language have that *must* be provided by all implementations.

Also note that C++ doesn't say the <> system includes need to be files, 
an implementation is also free there to magically define everything they 
should include.

> A separate resource would provide necessary mapping information; a naive 
> example in XML:

Uggh, the world of XML comes to make something simple extremely robust. 
  Since, for the most part, people will be using files to define 
namespaces and classes, I suggest a simpler format which must be 
supported by default:

	namespace MySpace = file( "dir/dir/file.h2" ) {
		class MyClass = file( "dir/dir/file.h2" );
	}

This follows a similar syntax to the language itself so it won't be 
foreign to the programmers.  It also is very flexible and allows room 
for expansion.  It additioanlly paves the way to reflection in the 
language itself... :)

(Continue reading)

headers

Slawomir Lisznianski | 6 Sep 17:26

Re: Proposal for Include files/headers

edA-qa wrote:
> Uggh, the world of XML comes to make something simple extremely robust. 
>  Since, for the most part, people will be using files to define 
> namespaces and classes, I suggest a simpler format which must be 
> supported by default:
> 
>     namespace MySpace = file( "dir/dir/file.h2" ) {
>         class MyClass = file( "dir/dir/file.h2" );
>     }
> 

Indeed, the above is far more readable.

> Here is where my intent differed from users.  I do not intend for 
> "import" to move things out of their namespace, that would cause the 
> same sort of name clashes that exist in Java.
> 
> What you are proposing is that "using" does both the "import" and the 
> "using" directive. While this may be convenient it has many pitfalls 
> for name clashes, consider first in my syntax:

Let me clarify. One could use qualified names, in which case "using" 
could be omitted and name clashes prevented. In other words, you don't 
need to write "using" if you plan on explicitly qualifying a type.

Also, I opt for importing namespaces and not individual classes because 
we *want* to pull any free functions, such as operator+, defined for 
those classes.  In order to make it safe and efficient, we would have to 
go away from the existing C++ practice, where, for example, an entire 
std. library is in one namespace. A given bottom-level namespace would

(Continue reading)

headers

edA-qa | 6 Sep 18:03

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> Let me clarify. One could use qualified names, in which case "using" 
> could be omitted and name clashes prevented. In other words, you don't 
> need to write "using" if you plan on explicitly qualifying a type.

Your explanation, not just the above, is omitting one of the common uses 
of the using directive: to import a set of names, not just a single 
object, where further names will be half-qualified, or not qualified.

Consider:

using Architecture.Car;
Door left,right;
...
using Architecture.House;
Door front, back;
...
using Architecture;
Car::Door left, right;
House::Door front, back;

> Also, I opt for importing namespaces and not individual classes because 
> we *want* to pull any free functions, such as operator+, defined for 
> those classes.  In order to make it safe and efficient, we would have to 
> go away from the existing C++ practice, where, for example, an entire 
> std. library is in one namespace. A given bottom-level namespace would 
> have a single type (primary) and any free functions defined for it. Here 
> is a String type written in this fashion:

I've recently read such sections in C++ about free functions on classes.

(Continue reading)

headers

Slawomir Lisznianski | 6 Sep 19:26

Re: Proposal for Include files/headers

edA-qa wrote:
> I've recently read such sections in C++ about free functions on classes. 
>  The search-space for functions occurs within the namespace of those 
> classes as well as the local scope.  The lookup is not simple, but in 
> order to use the String+ operator you do not need to include it in the 
> local namespace.

I think the existing C++ lookup rules are very criptic and not as safe 
as many people assume. Yes, the operator+ is visible without "using", 
but there are plenty of other issues to worry about. Some of them are 
described here: http://boost-consulting.com/writing/qn.html

> Having to import the entire namespace becomes messy, and as you've shown 
> in your example just before, you'd have to separate out every single 
> aspect into sub-namespaces.

I think it would serve the purpose of encapsulation and logical grouping 
(examples later). I would also restrict default rules where 
argument-dependent lookup does not take effect for arbitrary unqualified 
calls.

> Then you need to introduce a "this_namespace" namespace in order to 
> resolve ambiguities.  Example:
> 
> namepsace Math {
> 
> class Complex;
> class Matrix;
> 
> }

(Continue reading)

headers

Slawomir Lisznianski | 6 Sep 23:12

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:

> For clarity, I would recommend that types like Integer, Float and Matrix 
> above be in separate files. The rotate function would then be:
> 
> namespace Math
> {
>   namespace Algorithm
>   {
>     Math.Matrix rotate( Math.Matrix mat, Math.Float deg );
> 
>     // other common algorithms here...
>   }
> }
> 

Actually, since Algorithm, Matrix and Float share common parent 
namespace, it would be even simpler than my example:

namespace Math
{
   namespace Algorithm
   {
     Matrix rotate( Matrix mat, Float deg );

     // other common algorithms here...
   }
}

Now, let's assume that the user decided to add a type within an inner

(Continue reading)

headers

edA-qa | 7 Sep 17:48

Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> I think the existing C++ lookup rules are very criptic and not as safe 
> as many people assume. Yes, the operator+ is visible without "using", 
> but there are plenty of other issues to worry about. Some of them are 
> described here: http://boost-consulting.com/writing/qn.html

Agreed: C++ rules are not clear and lead to very interesting situations. 
  That does not however mean we should abandon some kind of contextual 
name lookup.

>   Math.Complex a, b; // primary deduced from namespace name

This I consider too bulky.  Plus I can give an example below of why it 
doesn't work.

>   class Matrix<Math.Matrix>;

I used this as an example to show resolution in *odd* cases of overlap.

> C++ spec-- admittedly at the cost of being explicit when referring to 
> types.

namespace Precise {
	class Complex;
	class Integer;
}
namespace Rough {
	class Complex;
	class Integer;
}

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30