Tag: prismscript

Prismscript updates expected this week

I need to start posting more regularly, so here are some words.

Prismscript should be getting a somewhat significant change to its Interpreter initialiser, in that some specialised config options will be dropped and a new interpreter_location=None parameter will be added. If provided, it must be a string that will give the interpreted script a scoped reference to the interpreter’s config-object, which will allow for tuning and behavioural options to be configured based on scripting logic.

How this will work is that the interpreter will expose a get_config() method that returns the new config-object, and this object will expose attributes like preemptable (a boolean value that causes the interpreter to yield after each statement, so that the caller can easily trigger script-asynchronous events without crazy threading solutions), and things like recursion_limit (an integer, bounded by a caller-set maximum, that will let script-code set its own tolerances). There’s a good chance some form of exception-handling will be added, too.

Additionally, a yield keyword will be added to the language proper, allowing for the script to yield of its own volition where needed. The yielded value will be wrapped in a special object, though the semantics have not yet been decided.

After these changes are in place and testing has occurred, versioning will increase to 1.1.0, which is when the first release archive should be published.

Creating a scripting language: branching out

While the language being developed was originally conceived of for work, I’ve realized that it can be easily adapted as a control language for a not-yet-ready-to-disclose game-related project I’m working on.

As such, it’s been given the name “prismscript”, and development will likely proceed under that title, and in that direction. (Since it’ll have more contributors and exposure that way, which should help to keep it healthy)

Creating a scripting language: establishing order

Previously, the grammatical structure for the language was completed, but it still doesn’t actually do anything useful. This article isn’t going to change that.

Rather, this article will serve as the hand-off point from the grammar to the interpreter, which will be the next part I’ll write. If you want to get access to the source and see how to use it, this is all you really need to read, but the stuff that came before was pretty cool, so you might want to at least skim it when you have time. (more…)

Creating a scripting language: establishing structure

In the previous article, a lexing ruleset was established, but lexing by itself does nothing to describe the actual structure of a language. It’s more like outlining its phonology, closed lexical categories, and maybe its basic morphology, but it does nothing to express how these things relate to each other; that’s the role of the language’s syntax, which is what will be described here. (In most compsci literature, this stuff is all called the grammar, and I will be using the terms interchangeably) (more…)

Creating a scripting language: establishing a foundation

Anyone who’s trawled through my projects knows that I love Python: it’s simple, it’s flexible, it does almost everything well, and it just works. It’s also a very good fit for this project, since part of the system driving it is being implemented using Boost, which means that Boost.Python is just a small step away for setting up a cross-language control structure. (Before anyone complains, I’ll freely concede that something like Haskell is an ideal candidate for building a new language from scratch, but I’m cheating and using an existing compiler-compiler to skip the parts functional languages are best at)

Within the realm of Python, a number of good compiler-compilers exist, with each having its own pros and generally very few cons (some are implemented in C, some offer great insight into the compilation process). Of what’s available, I decided to use David Beazley’s excellent PLY, for its extensive documentation, maturity, clear expression methodology, and portability (I need to be able to support Windows, too, unfortunately). (more…)

Creating a scripting language

As part of a revitalisation project for a complex system at work, I’ve concluded that one of our sustainability requirements could be best served through use of a specialised, extensible, implementation-independent scripting language.

Since programming language theory is something that’s always interested me, I wanted to make what I’m learning accessible to anyone else who might find it beneficial. Chances are this mostly includes computer science students encountering recursive-descent parsing for the first time or those in an entry-level compiler-construction class, so I’ll be writing towards that knowledge-set, but anyone sufficiently curious should be able to follow along. (more…)