Ok. Then I guess you can do something like Slang, which is used for the VM. Slang is a restrictive Smalltalk compiling to C.
The slang compiler parses the code using the Smalltalk Compiler parser, then translate the Smalltalk AST to its own AST, do some manipulation based on pragmas available in Slang methods and inlines different things based on a closed world (you can know what method is called at each send site) / frozen state assumptions (The value of literal variable will not change). Some selectors are specifically mapped to C instructions / macros, for example #cppIf:ifTrue: maps to #IFDEF, or bitShift: maps to signed long bitShift. Comment are translated from Smalltalk to C and they are really useful. Another interesting thing is that due to inlining part of the allocation / deallocation can be avoided. You can't really use Slang directly as its implementation is tied with the VM (each time we have a slang bug in the vm code, we choose to either change the slang compiler or the slang code depending on how much work is each task). I am not saying that slang is a nice language and that you should do something similar. Slang is horrible. But in the case of the VM is has some significant advantages over C++ and method templates. 2016-02-16 11:30 GMT+01:00 kilon.alios <kilon.al...@gmail.com>: > "Hi Kilon, > > the way your are explaining it, it seems you are trying to build a > Smalltalk-like syntax in C++ via templates? > > It could make moving a software architecture from Smalltalk to C++ > significantly easier (and open maybe some opportunities). > > Thierry" > > Bingo ! You get it ! > > Thats what is all about about moving code from Pharo to C++ and NOT > reimplementing Pharo in C++ as some people assumed. Yes if I can go for > smalltalk-syntax that would be a fair compromise, ideally i want to keep > Pharo syntax intact and introduce C++ features like static types , pointers > etc through the use of pharo objects. > > For example I can make an object to represent a C++ int, what stops me from > taking pharo class variable make it initialise with that int object then > later on use a string instead ? > > Nothing, my compiler wont even complain, but when you turn it to C++ code > and try to compile it you will get C++ errors. > > On the subject of templates, again there wont be magical transormation of > dynamic types to C++ templates at least not in the start since C++ expect > to > be explicity about the use of a template that will carry on to my tool as > well. That means that the pharo code will have to be explicit and leave > nothing to chance like a C++ coder does. > > Essentially you coding C++ using pharo syntax or pharo like syntax > depending > on how succesful I will be with this. Also creating readable code is a must > do. > > For example I have taken a look at chicken and gambit scheme that take > scheme (lisp variant) and turn to C and then call the c compiler to make > the > machine code executable. The problem is that C code is unreeadable because > it tries to emulate dynamic types etc. My goal is so not to retain Pharo > features and dynamism but rather to produce C++ that is not only readable > but proper C++ code with comments , good names, etc. > > My thinking however is like this: > > 1) Prototype in Pharo and make sure it works well using all the features > and > tools of pharo (dynamic types, GC, live coding, live debugging etc) > 2) convert your code to my language that looks a lot like pharo but with > all > the C++ features leaving no ambiguities for the compiler > 3) use my compiler to turn a specific fragment of code to C++ > 4) go back to to (1) > 3) > > > > -- > View this message in context: > http://forum.world.st/Compiling-Pharo-to-C-tp4877775p4877838.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >
