Le 21 août 07 à 13:24, Nicolas Roard a écrit : > On 8/20/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: >> Here is my thoughts on script language for Etoile: >> >> The choices for script languages are: >> (1) very similar to Objective-C. >> (2) provide something Objective-C doesn't have. >> >> StepTalk would be the best choice for (1). >> So the discussion would be focused on (2). >> The most popular languages, like Ruby, Python, Perl, >> are mostly OOP and redundant to Objective-C. >> All you get is another syntax and their libraries. >> Nu falls into the same situation where you don't >> get anything more except the syntax. >> >> So for option (2), I would say Io is a good candidate. >> It is proto-type and provides concurrency, >> which is very different from Objective-C.
Agreed. >> The core of Io seems to be more stable now >> and I think we can start port it again. >> What I learn from porting other applications >> is that it is hard to track the changes. >> So in the end, it becomes a fork. >> >> In that case, we can just fork Io and uses >> Foundation for most of the basic data structure (string, array, >> etc). >> In that case, we can get most of Io without the redundancy. I don't think we need to fork Io, the problem is just they need an active maintainer for ObjcBridge. When I submitted my patches to fix ObjcBridge, some people expressed interest about them (Cocoa devs iirc). My patches haven't been applied probably because I didn't really insist and more importantly they weren't based on latest git repository but a three months old snapshot. I plan to resubmit my patches and become directly involved in Io ObjcBridge support, unless someone takes this position. Maintaing an Io fork would be far more work than just maintaining ObjcBridge directly in Io project. As you outline it Io is more stable now. So I think it's probably time to get rid of our own Io build system (as you had advocated it :-). In future, I would like to add the possibility to use the bridge in a transparent manner by removing proxies and having all objects accessible by the same memory address on both Io and Objc side. If the Objc runtime is improved by David and its JIT Smalltalk has true prototype support and a very flexible parser/lexer architecture, we might try implement Io messaging and syntax in Smalltalk. Actually it isn't probably worth the investment because we would surely loose parts of the flexibility of Io runtime. The reverse would surely be easier, I mean writing an Io mode where Smalltalk syntax and semantic replaces Io syntax and some semantic. For that sort of stuff something like Pepsi could be better choice, take a look at: <http://www.piumarta.com/pepsi/>. I have been playing a bit with it and it's really cool. I'm going to make some advertising right now :-)… Pepsi is a Smalltalk dialect written in itself (like Self language) which includes a minimal object model under the hood and everything you can think to create a new language (like multiple backends for code generation). The minimal object model only defines messaging, this makes possible to implement any kind of object languages very easily. There are three very nice features: - you can mix C and Smalltalk together (if you use the C compiler backend) - Smalltalk classes and objects are in fact prototypes - built-in transparent language bridge support. For now unless David has doubts about its Smalltalk, supporting both Io and David's Smalltalk is a probably the way to go. In future we may eventually fiddle with Pepsi. > As you say, in the end it usually becomes a fork, so we better be > careful. > It also depends on what we /want/ to have. > > Personally I don't care that much about scripting capacity per itself > -- I mean, yeah, it's cool and is useful to bind apps together, but > StepTalk already provides an excellent architecture for that and is > available Now :-) > > What I am much more interested in is a more dynamic language to write > applications. Why ? well, objc is great, but more dynamism is better, > and we can provide that kind of dynamism with a "script" language > while it's (mostly) doable but much harder with objc. In particular, I > want to be able to inspect objects at runtime, change methods at > runtime, provide good refactoring tools, etc. Well, I have already something similar to this in Container: any UI objects (called layout items) and their related model objects can be inspected and modified at runtime. Layout items can represent other layout items (in other words the latter layout items play a model object role), this allows Inspectors to be inspected and modified at runtime too. In the process of writing EtoileUI/Container, I have discovered the framework architecture makes very easy to implement this kind of features. At this time, I haven't written all the code to support UI object edition at runtime, but once finished it means a rudimentary Gorm will be available in each Étoilé application. By rudimentary, I mean without very tailored inspectors and possibility to serialize UI modifications. These features would be interesting to add. The possibility to save UI modifications made at runtime is something I would specially like to have. We could do it by tagging modified UI objects and handling nib loading in our own way when needed. Right now, in addition to UI object oriented inspector, I'm writing code to use the same inspector with a developer layout where you can view objects in term of ivars and methods and browse the object graph by double-clicking an ivar for example (like in Self language development environment). > It could be done with > objc but with great effort, while it'd be fairly easy to provide such > an environment with an interpreted language. Not sure of that anymore but interpreted languages are nice that's true :-) > With that particular approach in mind, I think we have three good > candidates for Etoile: > - David's smalltalk JIT > - Something based on StepTalk (eg similar to the gorm palette I wrote) > - io > > Io is neat, and we had a bridge that allowed us to write applications > before -- so it'd be conceivable to use it. But... we don't really > care about using a io third party libraries that io gives, and keeping > track to Io seems to be a certain amount of work (considering it's > broken atm). Io vm is really small (around 10000 lines of code). Io works but there is a memory corruption when message travels back from Objc to Io which makes any delegate-based applications crash. > Something using StepTalk Smalltalk implemention would be trivial to > do; but it's not the fastest thing ever, and we'd only care anyway > about the smalltalk implementation in that case, not the full > steptalk. That left David's implementation, and imho that'd be the > better suited thing for us: > - small, only provides what we need > - will be reasonably fast with JIT > - and fully integrated to the objc runtime I'm personally in favor of providing two interpreted languages by default in Étoilé… Smalltalk and Io. I don't think it's very hard to support both when the foundation for live development is here. Moreover Io has a more generic object model and runtime, Smalltalk is just a subcase of Io ;-) I also think Io provides a better foundation for an Étoilé shell when you consider its syntax and its optional ObjC syntax support. In Io shell, you can type code like: view = [[NSView alloc] initWithFrame: NSMakeRect(0, 0, 100, 100)]; imho this is shiny ;-) Cheers, Quentin. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
