Programming language of/for the SuneidoPlatform
- classes with inheritance, virtual functions, and private members
- Functions (and classes) are "values" – they can be assigned to variables etc.
- garbage collection
- exception handling
- bool, number, string, date, and object values
- Function arguments can have default values
- Function calls can use named arguments, in which case order is not significant. If a value isn’t supplied for named argument, it defaults to True.
- Variables do not need to be declared, and may contain any type – i.e. Suneido is a dynamically typed language
- Suneido includes all of the C/C++ operators, including assignment operators (e.g. *=), increment, decrement, and bit manipulation, and adds regular expression operators =~ and !~
- Automatic conversions between numbers and strings.
- String concatenation is done with the "$" operator, not by overloading "+". This makes "123" + 456 and 123 $ "456" unambiguous.
- Suneido includes the same control statements as C/C++ if-else, while, do-while, switch, but unlike C/C++ conditions must evaluate to true or false or you’ll get an error. Switches are also slightly different – you can’t "fall through" cases, and cases allow multiple expressions rather than integer constants. There is also a "foreach" statement.
- UnitTest framework available
Homepage of Suneido is http://www.suneido.com/
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.
solutions like Suneido have their own weaknesses,
but it can handle many applications and at least it's manageable.
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
, but with a syntax that would be familiar to C++ and Java programmers (unlike LispLanguage
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
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.
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