Perhaps a C-syntax front-end for Lowtalk would be interesting? http://forum.world.st/Re-ANN-Lowtalk-a-new-Smalltalk-dialect-that-could-eventually-replace-Slang-td4966907.html
cheers -ben On Wed, 17 Oct 2018 at 19:37, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > 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 >> >>> >> >>
