[Linker]

Hello.

Could you add some static typing into MiniD? I think that in some cases it is really needed: this would improve code safety, maybe speed

Take a look at ABAP: http://en.wikipedia.org/wiki/ABAP
Old code mostly uses dynamic typing, but all code that non-SAP programmers should use (BAPI, etc.) uses static typing so that you can't pass unexpected parameters when calling functions, etc.

Imagine a situation: you have tons of gamecode for an RPG, and then you notice that when your character is equipped with level 25 hammer and tries to fight an ogre of level 4, the game crashes due to incorrect parameter type. Now imagine that you're not the one who wrote the code, -- you let game designers do it.

Best regards.

[JarrettBillingsley]

I've had an idea for MiniD 2 for parameter type constraints which would look something like:

[Linker]

Returning to ABAP experience, I think that something like:

[csauls]

[r.lph50]

This is sort of off-topic but if we are talking about function signatures.. it would be awesome to have a type (or even just fancy symbol) that made whatever was passed as an argument into a syntax tree rather than a MiniD value. By syntax tree I'm jealously looking at: ParseTree.

(Oh and I haven't yet said: great work on the 1.0 release )

[doob]

I think the syntax should be as Linker suggests, maybe you can add the "or" thing like this:

[JarrettBillingsley]

There are two issues that have been brought up: the syntax and whether the check should be done at runtime or not.

The "x : int" syntax has the nice advantage that it's backwards compatible with old MiniD code. Since the type constraints are optional and delimited by a colon, MiniD 1 code (and especially code that uses these "reserved words" as parameter names, i.e. "function toInt(string)" or something) will compile fine. I suppose "x : Foo" isn't really ambiguous either, so the 'instanceof' wouldn't be necessary. On the other hand, if there is enough of a push for the more traditional C-style parameter syntax, I suppose I could make a clean break for MiniD 2. Which seems to be looming closer than I would have imagined

Secondly, the issue with trying to do compile-time typechecking is that you cannot, in the general case, know what a symbol refers to at compile time. Some other languages (like D) bind a function or class to a given name, and you cannot reassign what that name refers to ever. In MiniD, class and function declarations are nothing more than syntactic sugar for assignments of new class or closure objects into local or global variables. Variables are always mutable, and as such, you can reassign what a variable refers to at runtime. Furthermore, you don't know anything about the environment in which a given piece of code is being run, so symbol references that appear to reference nothing at all might be entirely legal once the code has been loaded into the proper environment.

Because of all that, and because variables themselves are not typed, you cannot tell if a given function call is valid at compile time. Either the name of the function hasn't yet been assigned a value, or that name refers to nothing at all, or if it's an object method you have no clue where to look up the method signature, etc. etc. etc. Basically typechecking has to be done at runtime. Introducing a special syntax for it can offer possibilities for optimization (i.e. parameters of non-user-defined types could be checked with a bitmask) that the current assertion method cannot. Furthermore, since these checks are often only needed when testing code, they can be disabled (probably by a compiler flag) when the code has been sufficiently tested to be pretty damn sure that it doesn't have any errors.

As I've mentioned before, the very dynamic nature of MiniD makes for some rather interesting design restrictions. There are some really cool language features, but some of them just can't fit into MiniD without a massive redesign of the language, in both its design and its philosophy.