Suneido Language

Programming language of/for the SuneidoPlatform.

Homepage of Suneido is

There is an on-line forum for the discussion of Suneido at

What is the itch that this language scratches?

Um, C++, Java, and C# all suck horribly?

The itch for me, as the instigator of this project, was to have a free, open source, integrated platform for developing and deploying information systems. I like C++ and Java just fine. But they're complex (C++ especially) and they're not complete solutions. You still need a database, and a user interface, and networking. Look at all the pieces Microsoft would have you use to build an application - Visual C++, Visual Basic. SQL Server, COM, DCOM, COM++, .Net ... Even if you don't mind the cost and licensing, there's a huge amount of complexity there. And if you do run into a bug, you're out of luck. All-in-one solutions like Suneido have their own weaknesses, but it can handle many applications and at least it's manageable. -- AndrewMcKinlay

I think now you explained why you created a new platform, but wasn't the question why a new language was needed? Does the language have special support for the integrated nature of the SuneidoPlatform? I searched for it, but couldn't find it so far. A counter example: The Erlang/OTP platform (see ErlangLanguage) also contains a DBMS (MnesiaDatabase). The query language for Mnesia is a part of the Erlang language. This way you can use arbitrary Erlang expressions within a Mnesia query. (They only should be side-effect free.) When I saw how much the Suneido DBMS is integrated into the Suneido platform, I expected similar features in the Suneido language - did I miss something? -- HelmutEnckRadana

Why another language?

I wanted something simpler and more dynamic than CeePlusPlus or JavaLanguage, but with a syntax that would be familiar to C++ and Java programmers (unlike LispLanguage or SmalltalkLanguage). PythonLanguage or RubyLanguage are close, and perhaps could have been (should have been?) used. I'm not familiar with Erlang, I'll have to check it out. You can use a subset of SuneidoLanguage expressions in SuneidoDatabase queries, and the database rules and triggers are written in the Suneido language as well. There are a number of other language-database integrations that would not have been so easy using an existing language. For example, rules are a feature of Records and are used in user interfaces and reports as well as in the database.

The bottom line, I guess, is that with the typical arrogance of a programmer, I thought I could make something better than what was out there. :-) -- AndrewMcKinlay

I think an advantage of the Suneido language over Ruby is, that functions are first class objects. And an advantage over Python is, that there are no restrictions on the definition of anonymous functions.

Anonymous functions and block closures

Suneido functions seem to be similar to the old-style Python functions (before lexical closures were added to Python). Suneido does have lexical closures, but in the form of Smalltalk-like blocks. Blocks with parameters and functions are quite similar concepts - is there more than a historic reason that there is a difference between these in Suneido? Would there be any drawback, if block objects and function objects were the same and you could use block syntax to define functions? -- HelmutEnckRadana

Good question, I've wondered that myself. The difference, at the moment, is that blocks are lexically scoped and have access to their containing function's variables, whereas functions don't. But I don't see any major problems with making nested functions lexically scoped, the same as blocks. I'd lean towards keeping the two syntaxes even if they were equivalent, because the block syntax seems more natural for control structure type usage, whereas the function syntax seems better for top level use.

Currently, Suneido cheats with the lexical scoping of blocks. Blocks re-use their containing function's stack frame, keeping their own parameters separate by altering the names. This has some subtle side-effects, for example, variables used only within a block are still visible to the surrounding function. -- AndrewMcKinlay

I'm thinking about possible negative consequences of this "cheating". I don't see any problem in a variable being assigned to only within a block and being evaluated afterwards in the surrounding function.

But I'm wondering about the effect on garbage collection. Let's say a local variable in a function references a large data structure. In this function a block is created. There is no reference to the large data structure in the block. A reference to the block is returned within the result of the function, and this block will live for a long time, but the large data structure isn't accessable anymore after the function which created the block returns. Will the garbage collector be able to reclaim the space allocated to the objects of the large data structure? -- HelmutEnckRadana

You're right, but this would be the case with or without the "cheating". If the block had it's own stack frame, it would still reference it's "parent" frame and therefore prevent the garbage collection. This is where it's nice to be able to use a "function" that isn't lexically scoped, instead of a "block" (or closure). Another option is to be "garbage collector friendly" and clear the reference to the large data structure before returning the block from the function. -- AndrewMcKinlay

See also: SuneidoPlatform SuneidoDevelopmentEnvironment SuneidoDatabase
CategoryProgrammingLanguage CategorySoftwareTool

View edit of August 5, 2004 or FindPage with title or text search