stz
I don't like export:. Perhaps something better can be done. There's three scopes of we care about - public stuff that can be imported or used; package stuff that everything in a package can see; private stuff that does not leave the file it is in.
stz
We can name objects locally by assigning it to a variable, eg: person = { name: string, height: distance } We can also specify what kind of object to make with the {} syntax, eg: origin = { vec2 of: float | x: 0, y: 0 } But if we want to export it, suddenly we have to
stz
Do we always need a receiver? the idea behind 'message sends' was that an object is sending a message to another object. It's a fun idea. But sometimes it's awkward to choose one parameter over another, eg: start to: stop do: block This looks
stz
We have to start this story with tail call optimisation. The story of the stack is an interesting one. It is convention to keep the entire history of your call pathway on the stack in most languages. This allows you to debug what went wrong which can be super useful.
stz
Systems level programming and closures. Look, it's not really a Smalltalk if we don't have closures. But that doesn't mean we can't be more specific about how it works. using: 'core/memory' export: [ main | memory allocate: (fixed-array size: 10 of:
stz
We know how to export things and we know during compilation we're running in the compilation-scope-context. So how do we pull things in to that from other compilation-scope-contexts? First we should side-bar and talk about source code management. Smalltalk has always had a long history of doing its
stz
There's two kinds of object instantiation we care about - on the stack and on the heap. On the heap is an act of memory allocation using a memory allocator, while on the stack is a core concept in the language. Currently we have no syntax for declaring
stz
One of the most interesting ideas from Smalltalk was 'literate programming' which has become known also as keyword selectors. Instead of a single magic command followed by a bunch of arguments you place a keyword before each part of a method argument, eg: aGraphicsContext displayLineFrom: start to: stop
stz
C pointers are ... a thing. Not a good thing. But a thing. The name 'pointer' is also ... a thing. What we really have is an address in memory and we get or set things from it. We don't know how much of a thing we have
stz
Multiple return values. Why not? After all we've already thrown out the idea of exceptions so may be we should be looking at other ways to handle errors. One way is to have 'in' and 'out' variables which is something we could totally do.
stz
The name OrderedCollection is too dang long. I'm tired of writing it. So let's not. Really, what's wrong with a short name like list? And if we want something a little fancier than we could even have an ordered list. Why is ordered list
stz
There's no doubt that some parts of the Smalltalk syntax are a little awkward. No programming language is without its quirks. This is a topic we'll likely revisit many times. If it's going to be a Smalltalk then we have to stick with the