Okay, I've been working on this guy for a while now in secret.  It's not complete, but I do have some primary features mostly working.  It's a new language I'm developing called Q.  I think the name is already taken, so I'll have to rename everything internally, but that's not a huge concern right now.

The language is what I call a "mutated" superset of C.  In reality, it takes many leaves from D's book, but doesn't go into the murky waters of object-oriented programming.  I borrowed a lot of basic features from D, like the type names, cast() operator, typeof() operator, and most parser features. It also uses the concept of modules and imports.  The lexer in my language is nearly identical to that in D, except I wrote mine from scratch in C, not C++.

The reason I'm posting this here is because I've implemented a few features for my language that have been asked about for D, and so I thought it was somewhat relevant.

The features that I have working right now are:
  - overloadable functions
  - function return type overloading
  - multiple return values for functions
    (int a, char b) foo (float x, double y);
  - operator overloads for user-defined types

As of now, I have only one back-end implemented: a C source code translator. That is, it translates the analyzed Q code into compilable C code.

Test it out for yourselves!  I have provided a binary executable for Win32 and some example Q source code.

test zip archive:  http://jamesdunne.no-ip.org/qcompiler/qctest.zip language website:  http://jamesdunne.no-ip.org/qcompiler/

Regards,
James Dunne

"James Dunne" <james.jdunne@gmail.com> wrote in message news:d9uiee$1mui$1@digitaldaemon.com...
> Test it out for yourselves!  I have provided a binary executable for Win32
> and
> some example Q source code.

Hehe, cool :)  It would be nice to have a "smaller" language, sort of a companion to D, that would be nice to program in (like D) but easily portable to smaller systems i.e. Palm, embedded systems, etc.

One thing I thought of immediately when I saw the code for the functions overloaded by return type - man, is that confusing.  You have to know which type a variable is when calling the function to know which function is called.  Might I suggest that it be made possible, but the function call _must_ be made with a cast() to indicate which overload you want to use?  As in:

int fork()
{
    return 5;
}

short fork()
{
    return 10;
}

...

int i;
short s;
i=cast(int)fork();
s=cast(short)fork();

I also like the "type" keyword - yay BASIC :)

In article <d9ul3d$1puj$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"James Dunne" <james.jdunne@gmail.com> wrote in message news:d9uiee$1mui$1@digitaldaemon.com...
>> Test it out for yourselves!  I have provided a binary executable for Win32
>> and
>> some example Q source code.
>
>Hehe, cool :)  It would be nice to have a "smaller" language, sort of a companion to D, that would be nice to program in (like D) but easily portable to smaller systems i.e. Palm, embedded systems, etc.
>
>One thing I thought of immediately when I saw the code for the functions overloaded by return type - man, is that confusing.  You have to know which type a variable is when calling the function to know which function is called.  Might I suggest that it be made possible, but the function call _must_ be made with a cast() to indicate which overload you want to use?  As in:
>

Did you catch the 'call' operator?  Take a closer look at the example source code overloads.q.  It can be made to explicitly specify the return value type overload to use in any case, not just where it is needed, as in the float case I wrote.  It's use is only required in the case where the the type match is not explicit (no implicit casting).

>int fork()
>{
>    return 5;
>}
>
>short fork()
>{
>    return 10;
>}
>
>...
>
>int i;
>short s;
>i=cast(int)fork();
>s=cast(short)fork();
>

Same exact idea as the call() operator, I didn't want cast() getting too hairy
like it is in D.  I might take your suggestion and make it mandatory...

>I also like the "type" keyword - yay BASIC :)

Heh, didn't even think of that.  I just figure you're defining your own type, unlike BASIC where it was really just a struct.  My types you can add operator overloads to, and define properties as well.  I really love that C# property syntax ;)

BTW, macros are supported in the language but the compiler has yet to implement real support for inlining them into the calling function.  Check out the design doc on the language's website.

And thanks for your interest!

Regards,
James Dunne

Cool!
James, my respect.

> As of now, I have only one back-end implemented: a C source code
> translator.
> That is, it translates the analyzed Q code into compilable C code.

I think it make sense to take a look into EiC http://eic.sourceforge.net/index.html

As it is C interpreter (bytecoded VM + compiler) I guess
that it will be pretty easy to add your syntax constructions to it.
E.g. to remove '->' from C syntax it took me half an hour :).

EiC uses simple bytecodes which can be (my guess) directly
translated into native asm instructions ( possible JIT impl, sic!).

AFAIK EiC is already ported on many platforms including mobiles.

And as it is VM then it is pretty simple to implement deterministic GC there.

Andrew.

> I also like the "type" keyword - yay BASIC :)

I think that 'type' makes really real sense. Instead
of struct, class, or some type wrapper around single int member
but with your own methods.

Just one 'type' which may or may not have subfields.
I like it to be short.

Andrew.

Forgot to mention: as EiC is pretty close to C99 then
it has 'const' already implemented. :)))

Andrew.

In article <d9uuae$22p7$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>Cool!
>James, my respect.
>

Thank you sir.  The project has consumed the last couple weeks of my life...

>> As of now, I have only one back-end implemented: a C source code
>> translator.
>> That is, it translates the analyzed Q code into compilable C code.
>
>I think it make sense to take a look into EiC http://eic.sourceforge.net/index.html
>
>As it is C interpreter (bytecoded VM + compiler) I guess
>that it will be pretty easy to add your syntax constructions to it.
>E.g. to remove '->' from C syntax it took me half an hour :).
>
>EiC uses simple bytecodes which can be (my guess) directly
>translated into native asm instructions ( possible JIT impl, sic!).
>
>AFAIK EiC is already ported on many platforms including mobiles.
>
>And as it is VM then it is pretty simple to implement deterministic GC there.
>
>Andrew.
>

That's a neat idea, but I'm trying to stay clear of the whole VM'd language thing.  I had in mind that I'd use TinyCC (http://tinycc.org/) to compile the generated C code into native machine code.  It works as a library and is damn fast!

I forgot to mention that my compiler is actually implemented as a static library (probably soon to switch to dynamic library DLL).  Everything you wish to compile is contained within a compiler context.  This means you can have two separate compilation jobs being processed by the same library instance, which is really cool.

Also, it sports a nice 'n shiny flexible back-end interface.  The compiler library can implement multiple back-ends and the front-end application can choose which back-end interface to use.

Having the compiler in library form also allows it to be easily tossed into an IDE or plug-in for IDE to support syntax highlighting, error reporting, intellisense, code-completion, you name it.  Very cool.  Why not have D do this in the front end?  DMDFE could very well be a nice gateway to that kind of functionality!

Regards,
James Dunne

Andrew I thought about that too, long ago - I share Your opinion on this matter. Nice language should have "type" for structs, classes, unions...

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

In article <d9v1c6$25it$1@digitaldaemon.com>, James Dunne says...
>
>In article <d9uuae$22p7$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>Cool!
>>James, my respect.
>>
>
>Thank you sir.  The project has consumed the last couple weeks of my life...
>
>>> As of now, I have only one back-end implemented: a C source code
>>> translator.
>>> That is, it translates the analyzed Q code into compilable C code.
>>
>>I think it make sense to take a look into EiC http://eic.sourceforge.net/index.html
>>
>>As it is C interpreter (bytecoded VM + compiler) I guess
>>that it will be pretty easy to add your syntax constructions to it.
>>E.g. to remove '->' from C syntax it took me half an hour :).
>>
>>EiC uses simple bytecodes which can be (my guess) directly
>>translated into native asm instructions ( possible JIT impl, sic!).
>>
>>AFAIK EiC is already ported on many platforms including mobiles.
>>
>>And as it is VM then it is pretty simple to implement deterministic GC there.
>>
>>Andrew.
>>
>
>That's a neat idea, but I'm trying to stay clear of the whole VM'd language thing.  I had in mind that I'd use TinyCC (http://tinycc.org/) to compile the generated C code into native machine code.  It works as a library and is damn fast!
>
>I forgot to mention that my compiler is actually implemented as a static library (probably soon to switch to dynamic library DLL).  Everything you wish to compile is contained within a compiler context.  This means you can have two separate compilation jobs being processed by the same library instance, which is really cool.
>
>Also, it sports a nice 'n shiny flexible back-end interface.  The compiler library can implement multiple back-ends and the front-end application can choose which back-end interface to use.
>
>Having the compiler in library form also allows it to be easily tossed into an IDE or plug-in for IDE to support syntax highlighting, error reporting, intellisense, code-completion, you name it.  Very cool.  Why not have D do this in the front end?  DMDFE could very well be a nice gateway to that kind of functionality!
>
>Regards,
>James Dunne

I just updated the zip archive to include the libqc library and C header file for it.  I've also included the source to the main compiler program which calls the libqc library.

The compiler is actually updated/fixed quite a bit from my initial post.  More stuff works now.  Too many fixes to list.

BTW, please read the license/legal verbage on my site.  It applies to all code and software I may release regarding the Q language.

Regards,
James Dunne

In article <d9v305$26ut$1@digitaldaemon.com>, Dejan Lekic says...
>
>
>Andrew I thought about that too, long ago - I share Your opinion on this matter. Nice language should have "type" for structs, classes, unions...
>
>-- 
>...........
>Dejan Lekic
>  http://dejan.lekic.org
> 

The compiler already does handle the user-defined types with support for operator overloading, properties, and data members.  It's like a struct on steroids.  I plan to implement the opNew and opDelete overloads, but it requires a bit of restructuring within the compiler's code.

Regards,
James Dunne