June 29, 2005
James i actually hoped You won't use camel-case notation which i dislike... :)

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

June 29, 2005
"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


June 30, 2005
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
June 30, 2005
"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


June 30, 2005
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
June 30, 2005
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
June 30, 2005
"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.


June 30, 2005
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
June 30, 2005
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

June 30, 2005
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