Blog
The Sapphire Language
Regular readers of this blog may have noticed a few cryptic references to two projects we have underway - one is called Amethyst, the other is called Sapphire. Up to now we’ve been silent on the details of these two projects. The time has come to spill a few beans about Sapphire...
Sapphire is the name of a new programming language. It has a Ruby-like syntax - but much simplified. The overriding design principle of Sapphire is that the language should be consistent, unambiguous and deeply object oriented. In order to achieve this we have removed many constructs from Ruby: whereas Ruby often has many alternative ways of accomplishing the same effect, Sapphire aims to have one way of doing one thing.
See also: Ruby, Sapphire and Amethyst (27th July, 2007)
The syntax of Sapphire is much stricter than that of Ruby. For example, commands (method calls without parenthesis) are not available. A method name without parentheses is not a method-call but a method-reference. Methods can be assigned to variables and passed as arguments. Lambda methods (nameless methods implemented as blocks) are assigned in a similar manner and these are first class objects. A lambda method is always an instance of the Block class and it has the same independent existence as any other type of object.
Our implementation of object orientation is more rigorous than that of Ruby. We have gone back to the fundamental principles of object orientation epitomised by Smalltalk. This means, for example, that encapsulation and data-hiding is enforced. There are a number of ways of breaking encapsulation as a ’side effect’ in Ruby; this is not allowed in Sapphire.
Another important feature is the ability to assert expected types and ranges. If a method can only operate successfully on string arguments, say, and should always return an array, you may specifically assert that the ingoing arguments are strings and the returned value is an array. You may also assert that values fall within specific ranges (for example that an integer must be between 1 and 100). These assertions are not required and type violations may be optionally treated as errors, warnings or may be ignored. So Sapphire does not ‘remove’ duck-typing and it does not demand type declarations. Its type assertions are there as development and debugging tools - aimed at finding and trapping potential bugs as an integral part of program development rather than having to rely solely on testing.
So, in brief, these are the design principles of Sapphire:
A simple, consistent, unambiguous syntax
Rigorous object orientation
Everything (even blocks and methods) are objects
A high degree of modularity/encapsulation
Optional object type checking via assertions
We plan to define a clear specification of the Sapphire language and to make this publically available at an early stage. This will begin when we release the ANTLR grammar of the first draft of the Sapphire syntax later this month. Our own implementation of Sapphire will be developed for .NET (running on the Dynamic Language Runtime) and will be supported by a programming environment code-named Amethyst. If other developers are interested in implementing Sapphire for other platforms, we would be very pleased to work with you, so please get in touch!
For a background to the Smalltalk version of Object Orientation, see: Ruby The Smalltalk Way
Note: Sapphire is not intended to complete with Ruby but to complement it. SapphireSteel Software remains completely committed to supporting Ruby and Microsoft’s IronRuby as a primary goal. Moreover, it is our aim to ensure that our implementation of Sapphire is able to cooperate closely with other .NET languages including IronRuby.
-
Is Sapphire going to be a .NET language? Please say yes!
-
Yes!
Well, that is to say, that our implementation of Sapphire will run on the DLR (the Dynamic Language Runtime) for .NET. The language definition, however, does not specify a platform so, in principle, Sapphire could be implemented on other platforms. But we only have plans to implement Sapphire on .NET.
-
-
-
A previous comment brought that to my attention. It’s unfortunate that the same name has been chosen for an unrelated project. We have been talking about our preparations for Sapphire for some time now and for a product to be called ’Sapphire In Steel’ - the first mentuion was, indeed, in the ’About’ section of our original Project Blog in early 2006:
Sapphire is the name of a programming project currently in development. We shall, at a later date, provide more information on Sapphire In Steel on this site.
-
-
“whereas Ruby often has many alternative ways of accomplishing the same effect, Sapphire aims to have one way of doing one thing.”
Welcome to Python minus tabs =P
-
Coincidences are fun!
Three weeks ago, Daniel J Berg also announced a new programming language, also based on Ruby, also named Sapphire.
jwm
-
An unfortunate coincidence of names. We have been mentioning the Sapphire project since 2006, however ;-)
best wishes
Huw
-