stz public, package, and private

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.

Since we're sending messages to the compilation scope context we don't need to specify an export for each and everything. That'll get tiresome very quickly. Instead we can change the mode of operation.

public
[ a dot-product: b | $T, $T -> $T | a x * b x + a y * b y ]

package
package-secret = 'this is in package scope'

private
[ a dut-prudoct: b | $T, $T -> $T | a x * by + a y * b x ]

That's the first change. Good bye export:. The other advantage here is that an import: will act within the current scope mode. We are therefore able to 'inherit' methods with a specialised import instruction that re-maps types.

import: 'core/sequenceable' where: array inherits: sequenceable

Okay, that's a bit of a guess. We'll see how that shakes out down the road. Inheritence is a thing that might need some consideration.

I'm also starting to question adding names in to {}. It's not like the signature of a method. And given we're executing inside of a scope we might give ourselves some lee-way and allow compilation scope context to somehow know about assignments. It can therefore know what is assigned inside public, package, and private.

We'll figure out how we do that later. But that solves the problem I raised last post about having more than one way of doing things. That's never a good idea.

Next up - naming files. I suggested we use package-class.stz as the filename. But given class names can contain -'s that doesn't work. The moment we add core-ordered-list.stz we can't tell the difference between packages, subpackages, or classes that have a - in them.

So let's fix that and follow the namespace syntax. A simple dot will suffice: core.ordered-list.stz

Soon we will need to try and understand the type system. After all compilation runs in an interpreter of stz which means we can implement the majority of the type system (may be all of it?) in stz too. If the type system never needs parametric types or inheritance then we can build up to the powerful meta programming we deserve.