The fully-qualified typepath of a local type definition would be the fully-qualified path of the procedure plus the local definition of the type - e.g., /ExampleClass above is really of type /proc/some_func/ExampleClass, and is distinguishable from some global type ExampleClass. Local types take precedence over regular types - or perhaps local types must always be fully specified, thus allowing no ambiguity.

Local types are visible outside the procedure they are defined in.

This kind of behaviour can be semi-implemented in DM by writing code like the following:

There's quite a lot between where BYOND currently is and what you'd need to support this. I see no use for what you're describing, but some of the necessary intermediate parts could be useful.

I know it's a bit of a stretch-feature, and it can kind of be written by using ordinary types with a naming scheme so they don't collide, but it is extremely useful for supporting a more functional paradigm. Consider a more useful example:

Personally I've always felt local struct definitions were one of the worst elements of C++. There is little function to them, and they complicate the code something terrible. It generally involves no more effort to write a proper struct, or a proper set of helper functions, than to write a local one and the result is always far clearer.

Regardless, I don't see how this would ever be workable in DM syntax, let alone something that could be easily inserted into the compiler or the interpreter.

My biggest use of local struct stuff has been closure workalikes when I don't have C++0x.

Maybe I should make a seperate feature request for closure/first-class function support. Although one probably already exists...

Functional programming is rarely useful for things other than toy examples. I doubt that this would be very useful to game developers, especially not to DM developers.

I disagree most strongly. While functional programming a-la LISP isn't easy and isn't readily understandable unless you speak LISP, the concept of a closure is incredibly useful, and thinking of common programming tasks as "I have a list, and I want to do this to each of the elements" is often a good way to do it. I've got a lot of code at work that's much clearer expressed as a closure than it would be expressed strictly procedurally, and it's also magically multithreaded by the map() equivalent in use.

I didn't say it's never useful, I said it's rarely useful. Considering how few requests there are for functional programming features in DM, it would be rarely useful.

the concept of a closure is incredibly useful, and thinking of common programming tasks as "I have a list, and I want to do this to each of the elements" is often a good way to do it.

Is the DM method really that complex?

// this:for(var/v in my_list) my_proc(v)

// compared to:apply(my_proc, my_list)

If you want, you can write the apply proc in DM and pass it the path of the proc. If the compiler could figure out that "apply" means "/proc/apply" you could have a cleaner syntax for this. That part could be useful, but that's about it.