1.98.0

Features

• Support . separated names in meta values. E.g., name some.module. This makes writing references declarations much more natural.
• Support is, new, ~ (type cast) and static calls with qualified names (Prexonite namespaces)
• Remove println("$EXPR = ") = wrapper from REPL (the generated byte code becomes easier to understand)

Breaking Changes

• AstTypecheck: replace file-line-column constructor with ISourcePosition constructor. This means Prexonite code using psr\macro needs to construct instances using ast3 instead of ast.
• AstGetSetStatic: replace file-line-column constructor with ISourcePosition constructor. This means Prexonite code using psr\macro needs to construct instances using ast3 instead of ast.
• AstConstant: constant is now readonly
• AstTypecheck not longer has an IsInverted property. As a result, AST factory UnaryOperation no longer automatically handles partial application of ? is not T. There is no replacement.
• In Prexonite Script 2, object creation, type checks, type casts and static calls require the import of sys.* (or sys.rt.builtin.* or prx.core.rt.builtin.*)
• Removed the concept of type expressions from the language. This means you can no longer pass e.g., ~String, i.e. the concept of the type String, as a type parameter to another type. This feature has not been used at all since the inception of Prexonite. Constant and dynamic value parameters are still supported.
• built-in types (or any registered PTypes) are no longer privileged over "fallback" functions. That means a locally defined is_String function will supersede the built-in is String implementation. (Previously, custom type operations were only used as a fallback if the type isn't registered)
• Type operations need to be declared at compile-time. For Prexonite 1, the loader automatically will declare symbols for each registered type. For Prexonite 2, symbols will have to be declared (e.g., by providing a companion module).
• Use / as the separator for module name versions. The , was used in analogy to .NET assembly names, but as Prexonite Script itself uses /, it's weird to have the Prexonite Engine use a difference character.

Bug fixes

• name psr::pattern:test/2.0; now results in an error ( : instead of :: )
• ArgumentNullException for println(?*) (incomplete binary expression). It's now a proper error.
• Proper error handling for accidental use of :: in namespace declarations.

Internal Changes

• Run test suite in parallel

1.97.0

PRX-8 Copy interpreter directive into output

If an application has an interpreter directive, it will get copied into the final output.

This probably won't get used much, but it's easy to add.

Also:
 - Make newline used for output configurable
 - Change newline used for output to be just `\n` on all platforms. Part of my ongoing crusade to ban all use or `\r\n` :P But it's also crucial to make the interpreter directive work out of the box. `\r` gets interpreted as part of the command line on Linux.

v1.90

The first step on the way to Prexonite 2, which is defined by three rather large features:

Shared code

The Prexonite 1.90 runtime and compiler support sharing in-memory code with multiple applications. This in and itself may sound rather dull, as it only seems to come in handy in REP-loop and plugin-scenarios. It actually solves two problems that have plagued Prexonite since its inception:

• A limited namespace for (physical) functions names
• Code duplication when two imported libraries use the same third library

Two independent libraries can now define

function open 

without having to resort to hard-to-debug shadow ids or cumbersome idioms like

function my_library_open as open

In addition, modules (the shared part of an application) are identified by a name and a version number (major.minor.build.revision, major and minor are mandatory, no associated semantics)

Unfortunately, this new features changes some of the core assumptions in both the Prexonite Script compiler and the Prexonite runtime. This also entails a number of breaking changes in the API. At least most of these also actually break your source code forcing you to adapt : )

On the other hand, it paves the way for making offline-compiled Prexonite applications useful. The quest for a blazingly fast start-up time for Prx.exe has just begun.

Namespaces

Prexonite Script just got support for namespaces, making the limited symbolic namespace mostly a thing of the past. Namespaces are primarily a compiler feature. With the exception of reflection, they have no influence on the execution of a Prexonite program. Nonetheless, namespaces will change the way Prexonite Script is written.

namespace your.awesome.tool
  import sys.text, // same as sys.text(*)
         sys.seq(*, not map, to_list => all)
{
  namespace internal
  {
    function hello() { println("hello"); }
  } //by default, everything is exported
  function is_awesome() { internal.hello(); }
}  export(*, not internal); //export everything except internal

// the main function must not be inside a namespace, for now
function main() { your.awesome.tool.is_awesome(); }

Namespaces can also re-export symbols from other namespaces. See Prexonite/prxlib/sys.pxs for examples of this.

Standard Library

Plans

Modules (shared code) and namespaces together enable something that I wanted to provide for a long time: A standard library for Prexonite Script. Up until now that was not really feasible because of the tight namespaces and the large amount of time Prexonite needs to compile a large-ish library.

That last part may come as a surprise, but if you compare the startup-time of programs that use psr\macro.pxs with ones that don't, you will quickly see where this will lead with libraries that are larger than psr\macro.pxs. True, macro.pxs is not exactly standard, as its implementation heavily relies on macros, but I have no reason to believe that future libraries, including a "standard library" won't rely on macros, especially with my plans to move more hardwired compiler-functionality into macros.

Current state

A standard library as described above has yet to be implemented, however, the necessary mechanisms are in place and are being used to provide symbols for commands that exist today. They mostly live in the sys namespace, though some of them have been put into separate namespaces. See Prexonite/prxlib/sys.pxs for details on where to find what.