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

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:

http://www.digitalmars.com/drn-bin/wwwnews?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:

http://www.digitalmars.com/drn-bin/wwwnews?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