[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] llvm IR target

From: mobi phil
Subject: Re: [Tinycc-devel] llvm IR target
Date: Wed, 12 Mar 2014 14:36:53 +0100


first about boost preprocessor: There is this
framework called cos, that has some interesting approach to object oriented c.
http://ldeniau.web.cern.ch/ldeniau/oopc.html  (preciselly http://sourceforge.net/projects/cos/)
This framework uses macros similar to BOOST. And wrote from scratch my
ones, but what I did was more like in cos.

Unfortunately all went well well until I realized that I need to carry over 
type information for type safety, and that was impossible with macros. 

Given an _expression_ (not yet 100% decided about the syntax)

$[MyClass]object := @(new, $MyClass);

[MyClass] on the left side specifies the type as attribute
$MyClass on the right side is a global factory

later I want something like

$[MyOtherClass]otherObject := @(now, $MyOtherClass, $object)

need to carry over (during compilation) the type of $object
for type checking (polymorfism etc)

the @(....) "decorator" is a function call. (I call decorators all the extensions)

Another option is to just pull out the TCC parser into a separate
piece of code. The actual parser code is fairly straightforward, so
once copied into another project/sub-project/file it should be fairly
easy to extend. If your extensions are going to have similar syntax to
existing TCC constructs (e.g. if class/object declarations are similar
to structure declarations) then you should even be able to copy&paste
syntax forms. From that point you would just need to provide the
function that the parser actually calls. I assume that this would also
be a good way to dip your toes into compiler design without jumping
into the deep end all at once.

Indeed, thanks for suggesting, was thinking yesterday after spending 2 hours
to hack the tcc... Was trying to understand how to build into the existing 
tcc source  both "direct" compilation using my decorators.

As you may have noticed the syntax is a bit special. Uses '@' and '$'.
@ for decorators, and $ for referencing decorator instances. (These are
supposed to be more than objects)

The reason to use these is that the parsing/grammar would be easier
and the syntax will be also more visible (though a bit more typing)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]