I'm thinking up of a new programming language, heavily derived from Smalltalk and called 'Whisper'. This is an outline of my current thoughts -- I don't know when or if I'd actually implement the language.
Syntax
Like Smalltalk, almost everything is a message send. There are two kinds of message send in Whisper: binary operators and keyword messages. Binary operators follow the usual Smalltalk tradition:
12 + 8 * 2 -- returns 40
Keyword messages follow syntax like this:
myWindow : drawCircleAt(100, 100) withRadius(50)
Some notes:
myFunc = { x, y | x + y }
When sending a keyword message, and a block is the only argument between parenthesis, the parens can be omitted like so
(x > 5) ifTrue { out : print("yes") } else { out : print("no") }
IDE & Image
As an experiment, the main IDE for Whisper would be completely browser-based with IDE logic running from a web server. Local applications can be written that access local files...etc but the application's UI would still be browser based.
Another, for me much harder experiment is to make everything persistent all the time on an Sqlite database: All program state changes would be by writing to slots in objects, even function activation records or global variables (an idea taken from Self and others), and all slot writes would be trapped and written in the DB.
This would have a very high performance cost, so a lot of design thought should be put into this; by thinking about how to use memory for cache, possibly marking special object as transient, or some other clever method. I'm sure the Lispers, Smalltalkers, Selfers...etc have probably already "killed this problem from research", as the Arabic saying goes, and that I could find an ideal solution in some paper published in 1989..we'll see!
Gradual typing
Fields, method arguments and return values can have optional type declarations, this would allow the JIT compiler to better optimize things and (more importantly for me) allow autocomplete to work. It would also make refactoring safer, for example renaming a method would change the identifiers in all known calls to that method.
This should not change the dynamic nature of the language: The IDE and program are still 'live' and programs are still assembled piecemeal without an edit/compile cycle. There will be situations when calling a method with wrong argument types throws a runtime exception instead of a compiler error, and that's fine for me.
Other goodies
Since I'm now in the dreaming phase and not serious work phase, let's steal some ideas from Lisp, while we're at it:
The first is multiple dispatch. I think this will be useful in certain types of applications like compilers, allow us to think about libraries in new ways (I can imagine a GUI library inspired by the 'lenses' concept from MIT's Haystack project) and allows niceties like the return of traditional syntax:
if(x > 5) do { out: print("yes") } else { out: print("no") }
We can almost fool users into thinking it's Java or C#!
Also, since the syntax is nicely minimal, we could think about adding some metaprogramming...
Since Smalltalk tries to make as much of the program be represented as objects, we can do the same with the program syntax tree itself; and have the AST of each method be a public property of that method.
This would allow us to write code in our own DSL inside a method, code which looks like gibberish to the interpreter but useful for us, since we can write procedures to read the tree from the method and process it in whatever way we like. Possibly layer Common Lisp-style macros on top of this feature.
Looks like a nice language, right? I wish it were already available so that I didn't have to develop it :(
Syntax
Like Smalltalk, almost everything is a message send. There are two kinds of message send in Whisper: binary operators and keyword messages. Binary operators follow the usual Smalltalk tradition:
12 + 8 * 2 -- returns 40
Keyword messages follow syntax like this:
myWindow : drawCircleAt(100, 100) withRadius(50)
Some notes:
- A colon after the object indicates the start of a message send
- A keyword can have zero, one or more values acting as positional arguments
- Normal C-like positional arguments are a special case of this syntax
- The syntax is heavily inspired by the Grace educational programming language, itself inspired - again- by Smalltalk
myFunc = { x, y | x + y }
When sending a keyword message, and a block is the only argument between parenthesis, the parens can be omitted like so
(x > 5) ifTrue { out : print("yes") } else { out : print("no") }
IDE & Image
As an experiment, the main IDE for Whisper would be completely browser-based with IDE logic running from a web server. Local applications can be written that access local files...etc but the application's UI would still be browser based.
Another, for me much harder experiment is to make everything persistent all the time on an Sqlite database: All program state changes would be by writing to slots in objects, even function activation records or global variables (an idea taken from Self and others), and all slot writes would be trapped and written in the DB.
This would have a very high performance cost, so a lot of design thought should be put into this; by thinking about how to use memory for cache, possibly marking special object as transient, or some other clever method. I'm sure the Lispers, Smalltalkers, Selfers...etc have probably already "killed this problem from research", as the Arabic saying goes, and that I could find an ideal solution in some paper published in 1989..we'll see!
Gradual typing
Fields, method arguments and return values can have optional type declarations, this would allow the JIT compiler to better optimize things and (more importantly for me) allow autocomplete to work. It would also make refactoring safer, for example renaming a method would change the identifiers in all known calls to that method.
This should not change the dynamic nature of the language: The IDE and program are still 'live' and programs are still assembled piecemeal without an edit/compile cycle. There will be situations when calling a method with wrong argument types throws a runtime exception instead of a compiler error, and that's fine for me.
Other goodies
Since I'm now in the dreaming phase and not serious work phase, let's steal some ideas from Lisp, while we're at it:
The first is multiple dispatch. I think this will be useful in certain types of applications like compilers, allow us to think about libraries in new ways (I can imagine a GUI library inspired by the 'lenses' concept from MIT's Haystack project) and allows niceties like the return of traditional syntax:
if(x > 5) do { out: print("yes") } else { out: print("no") }
We can almost fool users into thinking it's Java or C#!
Also, since the syntax is nicely minimal, we could think about adding some metaprogramming...
Since Smalltalk tries to make as much of the program be represented as objects, we can do the same with the program syntax tree itself; and have the AST of each method be a public property of that method.
This would allow us to write code in our own DSL inside a method, code which looks like gibberish to the interpreter but useful for us, since we can write procedures to read the tree from the method and process it in whatever way we like. Possibly layer Common Lisp-style macros on top of this feature.
Looks like a nice language, right? I wish it were already available so that I didn't have to develop it :(
هناك 3 تعليقات:
I'm not sure why you want to change the syntax; Smalltalk has its problems but syntactically one of the main things I want are more literals (e.g. for Dictionaries), not to go back to positional arguments. Likewise, why SQlite as the persistency format? You'd have to reinvent yet another ORM, when simply persisting the memory would work fine.
On a more positive note, storing source code as AST all the way is one of our (longish-term) goals in Pharo Smalltalk, and there are already experiments with gradual/optional typing under way. So if you are lazy long enough, you might still get what you want :)
(also, first time I used mixed writing directions, that's a funny experience)
@Damien
(Yeah, having a blog in Arabic an English really familiarizes one with the Bidi algorithm!)
re: syntax, it's a personal taste thing... Smalltalk syntax can be confusing because at times I encounter a chunk of the code in the form of long lines of identifiers separated by spaces, and to know which argument goes where the human reader has to take a moment to parse the code in their head. I prefer instant visual representation of the code structure.
About persistence, I didn't mean SQLite per se; just the concept of having everything persisted automatically (I mixed the idea with implementation detail). I had recently read Alan Kay's original Dynabook paper "a personal computer for children of all ages" and it seems they were talking about something like that, where files and objects are one and the same, seemed tempting. Also one of my goals for Whisper is to have a tool for rapidly creating small utilities, and not having to worry about persistence at all fits with that objective...
BTW, It's really impressive what you guys are doing with Pharo, both the mundane polishing and the ambitious experiments.. big Kudos
!
إرسال تعليق