www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Test my preliminary language compiler!

reply James Dunne <james.jdunne gmail.com> writes:
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
Jun 29 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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 :)
Jun 29 2005
next sibling parent James Dunne <james.jdunne gmail.com> writes:
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
Jun 29 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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.
Jun 29 2005
parent reply Dejan Lekic <leka entropy.tmok.com> writes:
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
  
Jun 29 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
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
Jun 29 2005
next sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
James i actually hoped You won't use camel-case notation which i
dislike... :)

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
Jun 29 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
In article <d9v6ss$2acc$1 digitaldaemon.com>, Dejan Lekic says...
James i actually hoped You won't use camel-case notation which i
dislike... :)

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

Could you elaborate a little more? I'm not familiar with camel. Regards, James Dunne
Jun 29 2005
parent reply Dejan Lekic <leka entropy.tmok.com> writes:
methodName(int argSomeVal) and someIntValue are examples of camel-cased
notation, accepted by most developers in D-community, and widely accepted
among JAVA, PHP and C++ developers.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
Jun 30 2005
parent James Dunne <james.jdunne gmail.com> writes:
In article <da0m2l$tgh$1 digitaldaemon.com>, Dejan Lekic says...
methodName(int argSomeVal) and someIntValue are examples of camel-cased
notation, accepted by most developers in D-community, and widely accepted
among JAVA, PHP and C++ developers.

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

Would you rather it be method_name(int arg_some_val) and some_int_value ? =P I'm not forcing any naming convention to be used in the language, so that's entirely up to you. I don't mind the camel-case notation. What don't you like about it? Regards, James Dunne
Jun 30 2005
prev sibling parent James Dunne <james.jdunne gmail.com> writes:
In article <d9v6ss$2acc$1 digitaldaemon.com>, Dejan Lekic says...
James i actually hoped You won't use camel-case notation which i
dislike... :)

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

Could you elaborate a little more? I'm not familiar with camel. Regards, James Dunne
Jun 29 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:d9v39p$2795$1 digitaldaemon.com...
 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.

BTW: why your UDTs cannot have member functions?
 Regards,
 James Dunne 

Jun 29 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
In article <d9v806$2bbh$1 digitaldaemon.com>, Andrew Fedoniouk says...
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:d9v39p$2795$1 digitaldaemon.com...
 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.

BTW: why your UDTs cannot have member functions?

Because that would make them classes. And that leads to asking other questions which eventually turns the whole thing into an object-oriented paradigm, which I'm trying to avoid. The UDTs are mostly for light tasks which make sense to be handled by types. Although it is possible to use a UDT as a lightweight class, it's not recommended to go overkill with it. I'd recommend using UDTs for matrices, vectors, lists, and other types which make sense to have operator overloads and properties defined for them. My goal was to separate data from methods as much as possible. Regards, James Dunne
Jun 29 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:d9vnoh$2tdl$1 digitaldaemon.com...
 In article <d9v806$2bbh$1 digitaldaemon.com>, Andrew Fedoniouk says...
"James Dunne" <james.jdunne gmail.com> wrote in message
news:d9v39p$2795$1 digitaldaemon.com...
 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.

BTW: why your UDTs cannot have member functions?

Because that would make them classes. And that leads to asking other questions which eventually turns the whole thing into an object-oriented paradigm, which I'm trying to avoid. The UDTs are mostly for light tasks which make sense to be handled by types. Although it is possible to use a UDT as a lightweight class, it's not recommended to go overkill with it. I'd recommend using UDTs for matrices, vectors, lists, and other types which make sense to have operator overloads and properties defined for them. My goal was to separate data from methods as much as possible.

Sounds strange for me: From one side it is possible to create methods with signatures of properties and operators and on other side it is not possible to create just methods. Sort of contradiction, no? Andrew.
Jun 29 2005
parent James Dunne <james.jdunne gmail.com> writes:
In article <d9vr67$311b$1 digitaldaemon.com>, Andrew Fedoniouk says...
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:d9vnoh$2tdl$1 digitaldaemon.com...
 In article <d9v806$2bbh$1 digitaldaemon.com>, Andrew Fedoniouk says...
"James Dunne" <james.jdunne gmail.com> wrote in message
news:d9v39p$2795$1 digitaldaemon.com...
 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.

BTW: why your UDTs cannot have member functions?

Because that would make them classes. And that leads to asking other questions which eventually turns the whole thing into an object-oriented paradigm, which I'm trying to avoid. The UDTs are mostly for light tasks which make sense to be handled by types. Although it is possible to use a UDT as a lightweight class, it's not recommended to go overkill with it. I'd recommend using UDTs for matrices, vectors, lists, and other types which make sense to have operator overloads and properties defined for them. My goal was to separate data from methods as much as possible.

Sounds strange for me: From one side it is possible to create methods with signatures of properties and operators and on other side it is not possible to create just methods. Sort of contradiction, no? Andrew.

Sounds like a contradiction at first, but I don't think it is. I'd like to keep it this way because it's what basic types have defined for them, and user-defined types should be no different than basic types. You don't see basic types defining methods, do you? Nope, just operators and properties. If you're not abusing the UDTs, they should be all you really need. Besides, properties can be sort-of wiggled into looking like a method... make it readonly and add some arguments to it. (Note: I don't think the compiler handles arguments to properties just yet, but it will) I may reconsider this, however, if it does bother enough people ;). And yeah, sorry about missing 'const' stuff ;). That one jumped up and bit you in the ass, did it not? =P I'm also missing a few checks on things in the Q code. For example, it is possible to specify a non-constant dimension expression for a static array type and have it compile cleanly. This is obviously a bug, as I haven't incorporated my const-folding code in yet. Regards, James Dunne
Jun 29 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
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.
Jun 29 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
Forgot to mention: as EiC is pretty close to C99 then
it has 'const' already implemented. :)))

Andrew. 
Jun 29 2005
prev sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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
Jun 29 2005
next sibling parent James Dunne <james.jdunne gmail.com> writes:
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
Jun 29 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:d9v1c6$25it$1 digitaldaemon.com...
 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!

EiC is also fast in compilation. bytecode (or P-code - whatever you like) will give you portability and option to cover more platforms at the very begining. Plus only under VM it is possible to build reliable GC. As a next step - native code generation. Idea of using VM is simple: by itself it is pretty compact thing: EiC VM (as also minimal JavaVM) is about 40-90 kb in executable. So it is possible to have a "linker" which will assemble mono executable : vm + attached bytecoded files. So instead of sharing VM and have headaches with VM versions each executable will have it's own VM.
 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!

Yep, this is nice. The only thing: need of intermediate C compiler is not quite popular solution.
 Regards,
 James Dunne 

Jun 29 2005
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
hey you stole my idea :)
well my language is currently only on "paper" and probably will remain that way

I suggest you create a google newsgroup for your Q language.

"This software IS NOT free software; it is a proprietary product."

Do you expect to sell this in the future?  good luck with that
Jul 02 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
In article <da76gs$5fk$1 digitaldaemon.com>, Mark T says...
hey you stole my idea :)
well my language is currently only on "paper" and probably will remain that way

I suggest you create a google newsgroup for your Q language.

"This software IS NOT free software; it is a proprietary product."

Do you expect to sell this in the future?  good luck with that

Yeah I just slipped that in to protect my future decisions, whatever they may be. Eventually it'll probably go open-source, but I don't know. BTW, what was your idea? Regards, James Dunne
Jul 03 2005
parent reply Mark T <Mark_member pathlink.com> writes:
BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.
Jul 03 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...
BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne
Jul 05 2005
parent reply jicman <jicman_member pathlink.com> writes:
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave?  D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.  What you are saying is that D is NOT, nor it will be,
the language of your choice and you're going to create one.  This is harsh and
unprofessional.  It should have been announced in the comp.lang group and the
communication kept there...

Just a thought...

jic


James Dunne says...
In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...
BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne

Jul 06 2005
next sibling parent reply rko <rko_member pathlink.com> writes:
i think you are absolutly right!

rko

In article <dagrps$2cm4$1 digitaldaemon.com>, jicman says...
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave?  D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.  What you are saying is that D is NOT, nor it will be,
the language of your choice and you're going to create one.  This is harsh and
unprofessional.  It should have been announced in the comp.lang group and the
communication kept there...

Just a thought...

jic


James Dunne says...
In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...
BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne


Jul 06 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Q is not designed to be a better D.

rko wrote:
 i think you are absolutly right!
 
 rko
 
 In article <dagrps$2cm4$1 digitaldaemon.com>, jicman says...
 
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave?  D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.  What you are saying is that D is NOT, nor it will be,
the language of your choice and you're going to create one.  This is harsh and
unprofessional.  It should have been announced in the comp.lang group and the
communication kept there...

Just a thought...

jic


James Dunne says...

In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...

BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne



Jul 06 2005
next sibling parent James Dunne <james.jdunne gmail.com> writes:
In article <dah040$2ggt$1 digitaldaemon.com>, clayasaurus says...
Q is not designed to be a better D.

rko wrote:
 i think you are absolutly right!
 
 rko
 
 In article <dagrps$2cm4$1 digitaldaemon.com>, jicman says...
 
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave? D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.



I meant no disrespect. It certainly could be taken as disrespectful, however. For that, I do apologize. All I wanted was some criticism on the language design itself.
What you are saying is that D is NOT, nor it will be, the language of your
choice and you're going to create one.  This is harsh and unprofessional.  It
should have been announced in the comp.lang group and the communication kept
there...



Have you looked at the spec for Q? Like clayasaurus said, it is not designed to be a better D. Releasing specs on a new language that I have designed on the D newsgroup has, in no way, anything to do with my language of choice nor does it imply that D is bad. I certainly do understand how one (and a few have) could come to the same conclusions you did. You are correct in that I should've announced on the comp.lang group.
Just a thought...

jic



Regards, James Dunne
Jul 06 2005
prev sibling parent rko <rko_member pathlink.com> writes:
d is my favorite - i love it. frankly i do not need a discussion about a hobby
in a place like this. me - imbasil - is trying to learn d, loving it and a forum
for other endevours should be at the place of the OTHER endevour.

i think, as a learner, that there should be things d should have, but i think
walter will fix it. soooorrrry for my english -  i try to learn that too.


rko


In article <dah040$2ggt$1 digitaldaemon.com>, clayasaurus says...
Q is not designed to be a better D.

rko wrote:
 i think you are absolutly right!
 
 rko
 
 In article <dagrps$2cm4$1 digitaldaemon.com>, jicman says...
 
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave?  D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.  What you are saying is that D is NOT, nor it will be,
the language of your choice and you're going to create one.  This is harsh and
unprofessional.  It should have been announced in the comp.lang group and the
communication kept there...

Just a thought...

jic


James Dunne says...

In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...

BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne




Jul 06 2005
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dagrps$2cm4$1 digitaldaemon.com>, jicman says...
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave?  D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.  What you are saying is that D is NOT, nor it will be,
the language of your choice and you're going to create one.  This is harsh and
unprofessional.  It should have been announced in the comp.lang group and the
communication kept there...

Just a thought...

jic

I agree, this is not the place for it.. I could perhaps understand if the tool itself was written in D because then it would be like many other D related announcements, but apparently that was not the motivation for the post here. Plus to top it off, from the OP it looks like at least some of the code was based on DMD source, and certainly the design borrows a lot from D. James is (was?) a pretty big fan of D, based on this: digitalmars.D/21518 So I'm not sure James meant the language as something that would neccessarily compete with D anyhow, but nonetheless this was really not a proper place for the announcement or discussion, IMO. - Dave
James Dunne says...
In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...
BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne


Jul 06 2005
parent James Dunne <james.jdunne gmail.com> writes:
In article <dahb0t$2ovl$1 digitaldaemon.com>, Dave says...
In article <dagrps$2cm4$1 digitaldaemon.com>, jicman says...
Folks,

with all due respect to each person that has replied to this thread, why are we
talking about a new language on the D newswave?  D is not even finalized yet,
and we're already talking about a new language (Q).  It's a lack of respect to
Walter and Digital Mars.  What you are saying is that D is NOT, nor it will be,
the language of your choice and you're going to create one.  This is harsh and
unprofessional.  It should have been announced in the comp.lang group and the
communication kept there...

Just a thought...

jic

I agree, this is not the place for it.. I could perhaps understand if the tool itself was written in D because then it would be like many other D related announcements, but apparently that was not the motivation for the post here. Plus to top it off, from the OP it looks like at least some of the code was based on DMD source, and certainly the design borrows a lot from D. James is (was?) a pretty big fan of D, based on this: digitalmars.D/21518 So I'm not sure James meant the language as something that would neccessarily compete with D anyhow, but nonetheless this was really not a proper place for the announcement or discussion, IMO. - Dave

I am very much a fan of D and will continue to develop in it in the future. On another note, I did think it was related to D because I saw a lot of discussion about wanted features for D and I wanted to test them out in my own implementation to see if they are worth-while or not. And, as you can see, the language is very D inspired. But in the end, it is not D related and I should've exercised more vigilance. I was just so happy I had something workin ... I got excited ;).
James Dunne says...
In article <daa1l7$2f39$1 digitaldaemon.com>, Mark T says...
BTW, what was your idea?

my idea: a C style language with modules (not OO) and strong typing, the "compiler" would emit ISO C code, use C linkage, no special library to start (use the standard C libs), no garbage collection, no #define macros target market: embedded/real-time developers still using C license: open-source of some kind I'm sure hundreds of people have a similar concept, at least I started to document this language. Q is more ambitious language than mine. good luck, I will watch on the Google groups.

Those are pretty much all of my goals, except I wanted to add a bit of expressive power to C. I really should make it open-source, cuz it doesn't make sense not to do so when so many other great languages/compilers (better?) are available for free. If you want to work on it with me, I'd be more than happy to allow you access to the code so that we can both realize our ideas. BTW, my design document is assuming a standard C spec document is available. So a lot more documentation must be written describing the C aspects of the language, what Q has changed, and what Q has added. Much like the D specs. What do you have so far in your documentation, if you don't mind me asking? Regards, James Dunne



Regards, James Dunne
Jul 06 2005