suve / awful

Ugly script language

awful

An ugly, general purpose script language, with an interpreter written in Object Pascal. Licensed under zlib with acknowledgement (see LICENSE.txt).

Gute Gott, warum?

Because I was bored and needed something to occupy my brain with. Also, because it seemed a nice challenge, and because it eventually proved very fun.

I tried to clean up the source somewhat before making the project open to see, but since I didn't make it all in time, some parts of the code may be really hard to read (shoutout to the spaghetti-like parser). Well, hopefully all will get cleaned up with time.

Documentation

All available documentation is currently hosted on my homepage wiki.

Building

To compile, you are going to need Free Pascal Compiler 2.6.2 or newer. awful does not use any additional libraries and should successfully compile using just what's bundled with the compiler.

To build, just run make. I add make clean there because the code uses quite a lot of conditional compiling based on whether making a normal/cgi release, and FPC does not really recognize a file needs to be recompiled because the compile-time symbols have changed.

cd awful
make
make clean
make cgi

Running

If scriptname is ommitted (or -- is used), script file is read from stdin.

awful [-e errfile] [-o outfile] [-i infile] scriptfile [param] [...]

-e (-E)   File to redirect stderr to. File is overwritten (appended to).
-o (-O)   File to redirect stdout to. File is overwritten (appended to).
-i        File to use instead of stdin.

awful's Issues

Embed scalar data in Values

Currently, Values (which represent data inside a script - variables, consts, function results, etc.) operate by virtue of allocating a separate chunk of memory for the data itself and keeping a pointer. While this makes sense for complex types like arrays or files, it is absolutely unnecessary for boolean and numerical types and most likely harms performance.

Rewrite Value code so that booleans, ints and floats are stored inside the Value itself.

Research if it's feasible to somehow achieve this with AnsiStrings.

Change "return" from a function to a construct

It makes absolutely no sense for :return to be a function. It should be !return.

Add Ascii85 functions

It would be nice to have support for encoding and decoding Ascii85 messages.

Allow to launch other programs

It would immensely increase the language's usefulness if there was an :exec function (or maybe it should be an !exec construct?) available that'd make it possible to call other programs.

Things to consider:

• Syntax for passing arguments to called programs.
• Syntax for passing input (stdin) to called programs.
• How to return both the exit status and output (stdout) to the user?
• Should there be a facility to retrieve the error output (stderr) of called program?
• Should there be a facility to retrieve the running time of the called program?

Add key functions for arrays

Since arrays in awful do not have to be continuous, it would be useful to have functions that allow to:

• get a list of all the keys (indexes) set in an array
• retrieve the first (least) set key in an array
• retrieve the last (greatest) set key in an array

Stdio buffering issues

Stdio is read in buffered mode, and then in turn, the interpreter does some buffering of its own on top of the data read. This creates a lot of subtle errors where the interpeter misbehaves, e.g. it's expecting an extra newline and thus blocking on a :readln call.

See if switching to unbuffered stdio will allow to fix this, or come up with some other solution.

Add push & pop functions for arrays

In other languages, arrays are commonly used as a simple stack/queue, by virtue of the language providing functions that allow to easily add (or remove) an element from the start (or end) of an array. This would be a useful addition to awful.

Rewrite the parser

The parser is currently a big ball of mud and spaghetti with a lot of long functions and sub-functions. I'd be good to separate this into a larger number of mostly independent functions.

Add a !global construct

Currently functions have unfettered access to variables in higher scopes - be it the program's globals, or the caller's variables. This is a really stupid design decision that should be changed.

Proposed solution:

• Limit functions to accessing only their local variables (and args/statics)
• To use global variables, one must explicitly declare their use with !global $varname
• The construct should probably be limited to the function's top-level scope (can't be put inside !if or loops)

Things to consider:

• Should !global $var and !global &var be equivalent, or should the first one create a copy of the global variable in local scope (instead of adding a reference)?
• What should happen when a function calls !global &var and &var hasn't been yet set?