ZERO
07-15-2012, 05:32 PM
Sourcemod 2 is on the way. This will result in major reprogramming of most mods to take advantage or new features and better performance:
Why?
The original SourcePawn compiler is extremely old. It was written by ITB CompuPhase in the 1990s and was originally based off a 1984 journal submission. It is nearly impossible to maintain. The binary format (".smx") is also archaic and inflexible, inhibiting almost any modern language feature or performance improvement.
Tell me more!
SourcePawn 2 runs plugins directly from source. That means you can drop ".sp" files in your plugins folder and they just work. Offline syntax and type checking is also supported. There are no plans to remove .smx support, however, .smx files will not be able to take advantage of SourcePawn 2.
My goal is to support enough SourcePawn language features that 70% of plugins on the forums will work. From there I'll evaluate what features are remaining and whether they're worth adding. In this initial prototype, enough features are working to write very simple plugins, though #include does not work so you must declare natives manually.
Here are the known language features I have not implemented, but will implement:
Const with non-refs
Array literals
Float comparison
Non-branching comparison
Global variables
Dynamic arrays
#include <>
Array slicing
Float comparisons
Booleans
The any: tag
Optional semicolons
Chained relational operators
Ternary expressions
Passing functions as variables/parameters
SortCustom2D, SortStrings
Very limited, specific uses of #if and #define
Eventually, if/as the language reaches maturity, I will start adding new language features that people have been requesting:
Resizable arrays
Global dynamic arrays
Structs
Classes
Closures/nested functions
Discriminated unions
Dynamic types
First-class FFI
SourcePawn 2 includes garbage collection. I've implemented a very basic garbage collector that only runs on map changes. For most use cases I've managed to maintain SourcePawn's performance and memory guarantees surrounding arrays, which is great.
Aside from that, the entire architecture is much more amenable to high-powered performance optimizations than SourcePawn 1. Although the implementation right now is simple (GC is not realtime, and the execution mode is an interpreter), the entire architecture is geared toward making an advanced GC and an optimizing JIT very easy.
Now for the bad part:
There are many language features I will not implement. They are either too difficult to support in a modern design, or they are inherently bad features that may impede progress. Next to each I've listed what the eventual replacement will be:
Enum structs (replacement: actual structs)
#pragma semicolon (replacement: none, semicolons cannot be required)
#define X Y (replacement: use "const" or "static const")
#define X() ... (replacement: none, use functions)
#pragma (none, #pragmas are unneeded and will be ignored)
funcenum (replacement undecided)
Anything in <functions.inc> (replacement: module system like Java/C#)
Variadic arguments (replacement: alternate syntax I can talk about later)
Using String: as a non-array tag (replacement: none)
Tag mismatches as warnings (replacement: none, these are bugs)
#include "" ("use" keyword)
Enums with non-uniformly typed values (replacement: none, these are bugs)
Naming enums "Float", "String", "bool", etc. (replacement: none, these are bugs)
#pragma semicolon (replacement: none, semicolons cannot be required)
http://nooooooooooooooo.com/vader.jpg
Programing without semicolons!? IMPOSSIBLE!!!!!!!!!!!!!
https://s3.amazonaws.com/data.tumblr.com/tumblr_lwdap8GGU51qzr075.jpg
Why?
The original SourcePawn compiler is extremely old. It was written by ITB CompuPhase in the 1990s and was originally based off a 1984 journal submission. It is nearly impossible to maintain. The binary format (".smx") is also archaic and inflexible, inhibiting almost any modern language feature or performance improvement.
Tell me more!
SourcePawn 2 runs plugins directly from source. That means you can drop ".sp" files in your plugins folder and they just work. Offline syntax and type checking is also supported. There are no plans to remove .smx support, however, .smx files will not be able to take advantage of SourcePawn 2.
My goal is to support enough SourcePawn language features that 70% of plugins on the forums will work. From there I'll evaluate what features are remaining and whether they're worth adding. In this initial prototype, enough features are working to write very simple plugins, though #include does not work so you must declare natives manually.
Here are the known language features I have not implemented, but will implement:
Const with non-refs
Array literals
Float comparison
Non-branching comparison
Global variables
Dynamic arrays
#include <>
Array slicing
Float comparisons
Booleans
The any: tag
Optional semicolons
Chained relational operators
Ternary expressions
Passing functions as variables/parameters
SortCustom2D, SortStrings
Very limited, specific uses of #if and #define
Eventually, if/as the language reaches maturity, I will start adding new language features that people have been requesting:
Resizable arrays
Global dynamic arrays
Structs
Classes
Closures/nested functions
Discriminated unions
Dynamic types
First-class FFI
SourcePawn 2 includes garbage collection. I've implemented a very basic garbage collector that only runs on map changes. For most use cases I've managed to maintain SourcePawn's performance and memory guarantees surrounding arrays, which is great.
Aside from that, the entire architecture is much more amenable to high-powered performance optimizations than SourcePawn 1. Although the implementation right now is simple (GC is not realtime, and the execution mode is an interpreter), the entire architecture is geared toward making an advanced GC and an optimizing JIT very easy.
Now for the bad part:
There are many language features I will not implement. They are either too difficult to support in a modern design, or they are inherently bad features that may impede progress. Next to each I've listed what the eventual replacement will be:
Enum structs (replacement: actual structs)
#pragma semicolon (replacement: none, semicolons cannot be required)
#define X Y (replacement: use "const" or "static const")
#define X() ... (replacement: none, use functions)
#pragma (none, #pragmas are unneeded and will be ignored)
funcenum (replacement undecided)
Anything in <functions.inc> (replacement: module system like Java/C#)
Variadic arguments (replacement: alternate syntax I can talk about later)
Using String: as a non-array tag (replacement: none)
Tag mismatches as warnings (replacement: none, these are bugs)
#include "" ("use" keyword)
Enums with non-uniformly typed values (replacement: none, these are bugs)
Naming enums "Float", "String", "bool", etc. (replacement: none, these are bugs)
#pragma semicolon (replacement: none, semicolons cannot be required)
http://nooooooooooooooo.com/vader.jpg
Programing without semicolons!? IMPOSSIBLE!!!!!!!!!!!!!
https://s3.amazonaws.com/data.tumblr.com/tumblr_lwdap8GGU51qzr075.jpg