 Suneido language
started 11/26/2001; 10:04:14 AM - last post 11/30/2001; 2:08:09 PM
|
|
Andrew McKinlay - Suneido language 
11/26/2001; 10:04:14 AM (reads: 820, responses: 7)
|
|
|
|
Chris Rathman - Re: Suneido language
11/26/2001; 9:32:05 PM (reads: 736, responses: 0)
|
|
|
The post is quite topical to LtU - Welcome.
I did go out and download Suneido. Just had to add another shape example. :-)
There are some interesting things - dynamic wise - in the language. Just looking at it from an OOP perspective, I figure that the Class and Inheritance mechanism needs to be polished - it's close but still not quite there.
Anyhow, thanks for the links.
|
|
Ehud Lamm - Re: Suneido language
11/27/2001; 6:05:20 AM (reads: 758, responses: 0)
|
|
|
One more "let's make everything first class" language, no? Doesn't look exciting, but maybe I missed somethng.
But obviously ok for LtU, of course.
|
|
Andrew McKinlay - Re: Suneido language
11/27/2001; 8:28:16 AM (reads: 759, responses: 0)
|
|
|
Yes, in many respects Suneido is just "yet another OO language". But the goal of the project wasn't really to break new ground with language design (or to make something exciting). Almost the opposite, since I wanted something that would be familiar and easy to learn. My original concept was to create something with the feel of Smalltalk and Lisp but the more familiar syntax of C/C++/Java. Our larger goal was to create an integrated system including the language, database, IDE, and application framework, in which the language is obviously just one component.
Suneido's language was relatively simple to implement, and yet has turned out to be quite adequate to our needs. The standard library (which includes the IDE) is about 45,000 lines of Suneido code and we've successfully developed several applications of 10,000 to 20,000 lines of code. The basic implementation architecture has turned out quite well. For example, it was relatively easy to add Smalltalk-like blocks which have turned out to be quite a useful feature.
One of the amazing things (to me) is how easy it has become, with the current state of the art, to create something like the Suneido language.
I agree the class/inheritance model perhaps needs a little work - I'm not totally happy with it.
Thanks for the feedback, I'm always looking for new ideas.
|
|
Chris Rathman - Re: Suneido language
11/27/2001; 9:42:58 AM (reads: 705, responses: 0)
|
|
I agree the class/inheritance model perhaps needs a little work - I'm not totally happy with it. From my limited understanding, Suneido feels much more like a object prototype language (at least from an OOP perspective). In this class of languages would fall languages like Self, JavaScript, and Lua. So, it's possible that you could use a prototype mechanism for working with objects. That said, I don't find the definition of the class structures to be very approachable in these prototype languages, though they definitely have some flexibility. Anyhow, the first decision to make is whether you want to form objects based on a prototype scheme, or whether you want to use a class based approach.
Just dragging in some discussion from a thread over on your website: :-)
Any specific ideas on the class / inheritance issue? It should be relatively easy to fix it so you can derive from "anonymous" classes. (Although in practice, it's not usually a problem to put the classes in a library.) And obviously, private members should work properly in anonymous classes. What else do you have in mind? Not sure if I understand the stumbling block that you described in terms of anonymous classes. As I see it, inheritance is a matter of some lookup scheme where the objects trundle through a hierarchy searching for a property or method that is closest to the surface. Anonymous classes are really no different than Named classes, except you don't have the advantage of having a name lookup. However, the anonymous class probably has a reference pointing to it - i.e. a variable that points to the unnamed class. Wouldn't it be possible to grab a reference to the subclass via indirection? Some sort of indirection such as:
circle = class : shape -- normal subclassing
circle = class : x.class -- subclass based on vars class
In either case, you wind up with the same problem that you have currently with classes that are not defined globally. Specifically, if the base class is redefined, you still point to the previous class definition - not the new one (If I understand your problem correctly). The way Smalltalk handles the quandry is through the becomes: mechanism - substituting references in mass when the class is recompiled. Might be worth pursuing implementing becomes: or something similar to solve the problem of definitions that change.
|
|
Andrew McKinlay - Re: Suneido language
11/27/2001; 11:42:58 AM (reads: 704, responses: 0)
|
|
|
A precursor to Suneido was more prototype based. I used to think this was the way to go. However, experience has shifted my thinking on this. But there may be some leftover "prototype" influence in Suneido.
The issues with anonomyous classes are more implemenation details, there's no big problem. (Other than the modifying the base class issue.)
I thought most Smalltalk's had moved away from using "becomes"? My understanding was that it was easy to implement with an object table, but more problematic with direct pointer implementations.
|
|
Chris Rathman - Re: Suneido language
11/27/2001; 2:19:46 PM (reads: 717, responses: 0)
|
|
|
My view of the prototype influence is probably biased due to the use of the object merge to simulate the inheritance in the limited example I did. Other than problems of not allowing methods to call the pseudo superclass, the merge actually works pretty good. Which brings me to a related question: When you merge two objects and the same method is defined, it looks like you cast out the access to the first method while leaving the second. Is there a way to access the shadowed method?
I thought most Smalltalk's had moved away from using "becomes"? My understanding was that it was easy to implement with an object table, but more problematic with direct pointer implementations Ok, so I shouldn't try to write about headier topics whilst in the middle of some other chores - unfortunately that seems to be a permanent state for me these days. :-)
As I recall, the ST method of choice is probably the dictionary - most likely optimized for vtable lookups. Which brings me to another possible scenario for the anonymous classes - give 'em names - perhaps system generated names - or perhaps just some value that would be useful in the lookup. Still be anonynomous from the users standpoint but might make life easier to treat named and unnamed classes the same.
|
|
Ehud Lamm - Re: Suneido language
11/30/2001; 2:08:09 PM (reads: 718, responses: 0)
|
|
|
|
|
|