1. We have some of the pieces for that coming together. We have a large array of programming language parsers with PetitParser and SmaCC (Java, C#, Python, JavaScript?, R?) (some of them proprietary, however: C, ADA) and they can be used for styling (thanks Usman for showing me how) and probably completion.
This could probably fit in the current text editor just about fine, but a better one wouldn't hurt. That the current text morphs sees everything as smalltalk source code isn't hard to correct :) 2. and 3. Same. Once you abstract a bit some of the IDE building blocks, you can store code anywhere you want: even at the Pharo IDE level, a code pane is just a text editor with a specific way of saving code, which could be changed in a snap. However, I wouldn't be too much into emulating a language: it may be a very heavy and complex endeavour. Running behind a Pharo based IDE the interpreter or the compiler of a language X (R, Python) looks to me a more reasonable proposition. I'm currently looking at leveraging some of the IDE stuff I have and the SmaCC infrastructure to be able to build experimental IDEs for non-Smalltalk languages and external DSLs. Write or get a SmaCC parser for a language and you would have an IDE core building blocks ready for reuse and customization. Thierry 2014-09-04 14:18 GMT+02:00 Torsten Bergmann <[email protected]>: > Hi Phil, > > if there is something I would like to see our Pharo ecosystem and ST in > general moving > towards is to such a "multilanguage"/"multisourcecode"/"flexible > ressources" kind of > thing. Even when this could not be a short term goal I would like to see > this > in the long term. > > Regarding integration of different resources > ============================================ > 1. we need a better text editor and not only doing Smalltalk > completion/styling > but have this pluggable as well > => if I'm not mistaken this is what TxText project partly is > caring about > > If I remember correctly in VW there were browser plugins to the > browsers code > pane allowing you for instance to directly edit XML as a tree and > styling > while the XML text it is stored in a method, etc. > > Similar to Eclipse where depending on the content type one or more > different > pluggable editors could be used. > > 2. it should be possible to store and save different code/text formats as > source for methods > => you can already do it similar to Seaside by just returning > Strings > => maybe a pragma could be used > foo > <language: #JavaScript> > ^'alert("hi");' > => the selector could/should be decoupled from the method body to > be more flexible, > not only in editing > (interesting idea and already in Moose, see Tudors talk from > ESUG 2014 > > https://www.youtube.com/watch?v=LKVPJU3W5Ys&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X&index=94 > ) > especially at the beginning of video 3/3. > > 3. we should think about where the source code (Smalltalk or not) is > stored, it should be > more flexible as well > > => there already was a discussion of integrating the source file > into the image > Pharo4.0 but I would additionally also like to integrate the > other way around (why not > edit an external file (CSS, JavaScript, XML, ...) linked as a > method in the system > with the internal Smalltalk tools) > So one could imagine a method like this where the string is > stored in an external file. > > zincMustacheTemplate > <language: 'HTML' external: 'index.html'> > > ^'<html><body><head><title>{{AppTitle}}</title></head></body>' > > Many other ideas come to mind. > > Regarding the integration of multiple languages: > ================================================ > As we all know we have our image and VM provides a dynamic object system > and > Smalltalk is only a language that is built into it. So can be others and > we would > open up more. > > There are many examples of this already in the Smalltalk world: > - VisualAge for Java was implemented and running inside of VisualAge for > Smalltalk > using all the tools > - running Java inside of Smalltalk/X > - C Source code of the VM can edited and changed in Smalltalk/X tools > - JavaScript on top of VW as seen on ESUG 2014, > https://www.youtube.com/watch?v=ZGAMCz62OM0 > - Helvetia (http://scg.unibe.ch/research/helvetia) > > Helvetia could be a starting point for Pharo here, also parser frameworks > like PetitParser, ... > Many things are already possible from the meta side. > > Maybe one could port the MIT licensed JavaScript implementation from VW to > Pharo > and try out if our infrastructure (Compiler, Parser, source code editing) > could > really be made pluggable. Would open up Pharo also to JavaScript > developers and > maybe realign better with Amber. > > So many things we could do to reduce the friction between Smalltalk and > the outside world > ... but lots of work if done right. > > Bye > T. > > > > > > > > >
