there will be no remap of variable names, this is a strict compiler if you can even call it a compiler. Your variable names will stay exactly the same in the C side , a concern here was that Pharo would not allow to have names like "my_personal_function". All the praise to Pharo it actually allows for such naming for methods.
So no this is going to be a very stupid compiler, there will be minimum amount of magic involved if not any at all and what you read in Smalltalk will be compiled exactly the same in C. I am now playing with RBParser for handling the parsing of the smalltalk code and I am impressed how flexible and elegant it is. Kudos to the devs behind it. Here is the begining of Magnatar exp := (RBParser parseExpression: 'Morph call_my_function'). sel := exp selector asString. classname := exp receiver name asString. Transcript open;clear. Transcript show: classname ; show:'.' ; show:sel;show:'()';cr. Damn that was too easy :D On Wed, Oct 17, 2018 at 2:06 PM Thierry Goubier <thierry.goub...@gmail.com> wrote: > Le mer. 17 oct. 2018 à 12:39, Dimitris Chloupis > <kilon.al...@gmail.com> a écrit : > > > > About your last part on platforms, I will be providing a way to inline C > code so one can you use C macros to detect the platform and generate code > accordingly. Or this could happen via a pragma too, it should not be an > issue. This also a reason why I previously talked about an "in place" > annotation and why specially named variables was my first choice instead of > pragmas. I am also not a big fan of pragmas syntax which for me at least > deviates from standard smalltalk syntax style. But as I said I am not > against their usage at all. > > > > Generally because this is no an afternoon project obviously, I will be > relying on C code inling at first for special corner cases and then I will > implement them as annotations the more the project moves forward. > > Having a way to do the same as what asm inline is in gcc, but for > hand-written C inside your Smalltalk derivative is cool: remap > variable names, etc, so that your C generator handles all the > interface between the inlined C and the surrounding Smalltalk. > > Same if you also add platform-dependent customisation for generation. > > Thierry > > > On Wed, Oct 17, 2018 at 1:30 PM Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > >> > >> Hello Allistair > >> > >> I have used Slang only once and it was generating code that was indeed > readbale but my aim is for more finer control over the output. Lets say I > want import a specific C header file or I want a string to map to custom C > type I created etc. So yes Slang is by no mean a bad tool at all its just > is not designed with making source output that is undetectable as > autogenerated by a human. But I will have to give it a more serious try > because it may be closer than I initially thought. > >> > >> I am not against the usage of pragmas, and indeed are an excellent way > to annotate stuff , my only concern is when I may want to annotate in place > for some weird reason , but that may be doable with pragmas as well too. > >> > >> Smalltalk code that is 100% smalltalk should be able to execute , you > mention however the execution of external C functions , problem is that in > my case that code does not live in DLLs but in an executable so no I am not > amaing to that level of execution. > >> > >> Also I have an easier solution for this too, when I made the CPPBridge, > which is a Pharo library that allows the usage of C++ libraries from Pharo, > I used a shared memory bridge to communicate back to Pharo giving the > ability of both function calls and callbacks. If I really want to capture > execution I can do it like this which is the exact opposite of what you do, > instead of the VM capturing the executable it will be the executable > capturing the VM if that makes any sense. This makes things far easier. As > a matter of fact not only my CPPBridge does this it also allows to extend > the pharo image file because it uses memory mapped files for the shared > memory which like pharo image files are memory dumps. So there is a lot > potential in that department. > >> > >> However my main goal is to use Smalltalk code execution to make sure > the prototype works on a basic level, there will be a C cide in this > project obviously which will act like a runtime that will provide live > coding features. This is also a library I made in C that does this through > the usage of DLLs that rebuilds and reloads dynamically. > >> > >> So I dont really need the VM to execute my code to check that is > working cause the C compiler and the live coding runtime can handle this. I > could even hook in the Pharo debugger, I have done this with my Atlas > library that allows to use Python library from Pharo by sending the python > error back to Pharo debugger where it triggers an error and the debugger > pops to allow you to do your usual live coding magic and basically resends > the code back to python. Because of my C livecoding library I can do this > with C too. My only concern is how the C/C++ compiler reports errors > because obviously it known that it kinda sucks on this. But hey I cannot > make C better :D > >> > >> Generally speaking the tools I am making are not designed for general > consuption but designed to solve my own problems. Of course I like to share > them because there is always the chance for someone to find them useful as > it has happened with Atlas for example. Plus as happened with Atlas one can > take my code and adjust it to his or her personal needs. > >> > >> On Wed, Oct 17, 2018 at 1:04 PM Alistair Grant <akgrant0...@gmail.com> > wrote: > >>> > >>> Hi Dimitris, > >>> > >>> As someone currently learning to use Slang (i.e. not an expert), I've > >>> added my 2c below... > >>> > >>> On Wed, 17 Oct 2018 at 11:06, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > >>> > > >>> > Thierry you have done it !!! you just gave a very easy solution to > my problems. > >>> > > >>> > Yeap Slang is quite close to what I am thinking, unfortunately > Clement told me to stay away from it because the code is ugly and specially > used for VM only. If I remember also correctly it does not generate > readable C code either. But the idea as a concept is very close to what I > imagine. > >>> > >>> I've found the C code produced to be quite readable, but that is > >>> probably influenced by the fact that I have read the slang first. > >>> > >>> > >>> > As a matter of fact you mentioning Slang made I have an epiphany > that I dont have to create a new syntax at all, instead I could use > specific variables or methods to provide type annotation. Thus like Slang I > can use regular Smalltalk code that avoids changing types but without the > need for type inference (although I am not excluding this either). > >>> > > >>> > So yes I am definetly want to move to the direction that Slang goes > so I can fully utilise the Pharo IDE and minise code that I have to write. > >>> > > >>> > So basically I am thinking write code as you always write in Pharo > and either > >>> > a) Have special dictionary variables in each method that provide > static type annotations for the arguments of the methods, its return type > and local variables > >>> > >>> Slang uses method pragmas to define the variables types. This seems > >>> to work quite well. > >>> > >>> > >>> > b) Have special methods that provide such dictionaries seperately. > >>> > > >>> > Or probably both. This way I can write 100% Smalltalk code and use a > very small compiler to read those dictionary variables for the type of the > variables and functions/structs (essentially a class will be output for a C > struct with pointers to functions for methods and variables for instance > variables). Why invent a whole new language when everything I need already > Pharo provides ? > >>> > I could also use special variable dictionaries for all sort of > things like generation of header files, generation of CMake files for > automatic building. > >>> > > >>> > Also I like to use the way UFFI is doing C function signatures by > using symbol arrays. > >>> > > >>> > So thank you all for inspiration it looks like all I need is Pharo > AST methods (which I can from the AST packages) and SmaCC. > >>> > So yeap looks like Magnatar will be a new Slang afterall, I will > keep you posted. > >>> > > >>> > Also this also opens the possibility of autowrapping the generated c > code back to Pharo through UFFI, so one can use C code as if its Pharo > code. I can leverage the TalkFFI project that does this already. Seems all > the pieces have fallen in their place. > >>> > > >>> > Keep the suggestions and advice coming, you guys are inspirational :D > >>> > >>> Do you intend that the Smalltalk code can be executed? This will > >>> likely increase the complexity quite a bit. In the VM simulation we > >>> end up creating a XSimulation subclass that provides the framework for > >>> executing the smalltalk code, e.g simulating functions that are only > >>> in C. > >>> > >>> There is also the problem of platform differences. Slang doesn't > >>> really handle them well (pragmas can be used to indicated that methods > >>> should only be compiled on certain platforms, and #ifdef type code can > >>> be used, but it isn't enough). It would be nice to have a class that > >>> provides cross platform functionality, and then platform specific > >>> classes as required. > >>> > >>> HTH, > >>> Alistair > >>> > >
