This is the reference distribution for Castile, an unremarkable programming
-The current version of Castile is 0.2-
PRE. It is not only subject to change,
+The current version of Castile is 0.2. It is not only subject to change,
it is pretty much *guaranteed* to change.
Unlike most of my programming languages, there is nothing that could really
be described as innovative or experimental or even particularly unusual
about Castile. It is not a particularly comfortable programming experience,
-often forcing the programmer to be explicit and verbose. It is influenced by:
+often forcing the programmer to be explicit and verbose.
+The reference implementation is slightly less unremarkable than the language
+itself, if only for the fact that it compiles to three different target
+"stackmac". (A stackmac emulator ships with this distribution.)
+Castile's influences might include:
* **C**: Most of Castile's syntax follows C, but it is generally more
permissive (semicolons are optional, types of local variables and return
system (where `struct`s are the only types with name equivalence) which
can be applied statically. It has function values, but not closures.
-* **Pascal**: All local variables used in a function must be declared at
- the start of the function body.
* **Rust**: There is a union type, to which values must be explicitly
promoted (with `as`) and extracted (with `typecase ... is`.) This is
like Rust's `Enum`, which is (to quote its tutorial) "much like the
* **Eightebed**: A few years back I realized that pointers that can
assume a null value are really a variant type, like Haskell's `Maybe`.
- Of course, in most languages, the property of being null isn't
- captured by the type; you can dereference a pointer in C whether it's
- valid or not. In Castile, this is captured with a union type which
- includes `void`, and `typecase` generalizes Eightebed's `ifvalid`.
+ Of course, in most languages with pointers, the property of being null
+ isn't captured by the type; you can go ahead and dereference a pointer
+ in C or Java, whether it's valid or not. In Castile, this is captured
+ with a union type which includes `void`, and `typecase` generalizes
-* **?**: Expressions (statements) within a block must have void type,
- except the final expression, which is returned as the result of the
- block. Local variables are mutable, but arguments and globals
- are not, and neither are the fields of structs. There are no pointers.
- (These features are not really original, but it's hard to say what
- languages I'm taking them from. Many of them seem to be a result of me
- coming to some kind of C/Rust/functional language compromise. I'll
- say more when I have a more developed idea of what type/memory safety
+* **Pascal**: All local variables used in a function must be declared at
+ the start of the function body. (This may change to something more
+ Python-like in the near future.)
+* **Ruby**: The last expression in a function body is the return value
+ of that function; no explicit `return` is needed there. (But unlike
+ Ruby, and more like Pascal or linted C, all *other* expressions in
+ statement position within a block must have void type.)
+* **Erlang** (or any other purely functional language): There are no
+ language-level pointers; sharing, if it happens at all, must be
+ orchestrated by the implementation. Global variables and function
+ arguments are not mutable, and neither are the fields of structs.
+ (However, local variables *are* mutable.)
+Some lines of research underneath all this are, if all we have is a relatively
+crude language, but we make it typesafe and give it a slightly nicer type
+system, does it suffice to make programming tolerable? Do tolerable ways of
+managing memory without a full garbage collector present themselves? Does
+having a simple compiler which can be target many backends provide any
Also unlike most of my programming languages (with the exceptions of ILLGOL
-and Bhuna), it was "designed by building" -- I wrote an interpreter, and
-the language it happens to accept, I called Castile.
+and Bhuna), Castile was largely "designed by building" -- I wrote an
+interpreter, and the language it happens to accept, I called Castile.
I wrote the interpreter in a very short span of time; most of it was done
within 24 hours of starting (but consider that I ripped off some of the
scanning/parsing code from ALPACA.) A few days later, I extended the
-that, I added a Ruby backend (why not, eh?)
+that, I added a Ruby backend (why not, eh?), and over the next few days,
+the stackmac backend and emulator.
This document contains what is as close as there is to a specification of
the language, in the form of a Falderal test suite. The interpreter and all
any attempt to execute code which would have resulted in a type failure,
will result in a crash. Note, however, that this only applies to the
evaluator, not any of the compiler backends. Compiling Unchecked Castile
can result in a compiled program with undefined behaviour.