[Protium] Master Class #1 (Part 2)

Demonstration - Oblique Strategies

"The Oblique Strategies are a deck of cards. Up until 1996, they were quite easy to describe. They measured about 2-3/4" x 3-3/4". They came in a small black box which said "OBLIQUE STRATEGIES" on one of the top's long sides and "BRIAN ENO/PETER SCHMIDT" on the other side. The cards were solid black on one side, and had the aphorisms printed in a 10-point sans serif face on the other.

...

The deck itself had its origins in the discovery by Brian Eno that both he and his friend Peter Schmidt ... tended to keep a set of basic working principles which guided them through the kinds of moments of pressure — either working through a heavy painting session or watching the clock tick while you're running up a big buck studio bill. Both Schmidt and Eno realized that the pressures of time tended to steer them away from the ways of thinking they found most productive when the pressure was off. The Strategies were, then, a way to remind themselves of those habits of thinking — to jog the mind."         
-- Oblique Strategies

A web-based installation of Oblique Strategies is supplied in the standard Protium install. Using the "Internet Information Services" snap-in, create a virtual directory pointing to C:\protium\Code\prx\os. Specify its default as index.prx, call it 'os', and share the C:\protium\Code\prx\os directory (Microsoft Access is picky about being able to write to databases even when only reading.)

Further information on setting up IIS can be found in the Protium document "C:\protium\bin\plugins\Configuring Windows IIS 5 to use with Protium and Isis.html"

The Protium code in the index.prx file is as follows:

<@ DEFKEYLIT>__Transput|__HTMLTransput</@> <@ SAYPRO></@> <@ SAYDOC> <@ SAYDHD> <@ SAYDTT>Oblique strategies</@> </@> <@ SAYDBD> <@ DEFDBFLIT>os</@> <@ DEFRSTCAP>select * from os where cardid = <@ SAYRANLIT>100</@></@> <@ SAYDPR>Oblique strategy: <@ SAYFLD>message</@></@> </@> </@>

The above code (indented only to more clearly demonstrate document structure) outputs a different strategy each time the page is refreshed. The syllables translate as follows:

<@ DEFKEYLIT>__Transput|__HTMLTransput</@>	define the Transput as HTML
<@ SAYPRO>	output a document prologue. (What is output by the PRO syllable depends on the Transput defined, as is the case for all document related syllables.)
<@ SAYDOC>	Enclose a document.
<@ SAYDHD>	Enclose a document header, in the context of an existing document.
<@ SAYDTT>Oblique strategies</@>	set the document title, in the context of an existing document body and header.
<@ SAYDBD></@>	enclose a document body, in the context of an existing document.
<@ DEFDBFLIT>os</@>	opens this data source, by default a JET/MSAccess database.
<@ DEFRSTCAP>select * from os where cardid = <@ SAYRANLIT>100</@></@>	Open record source defined by captured output.
<@ SAYRANLIT>100</@>	return a random number between 1 and 100.
<@ SAYDPR></@>	enclose a document paragraph, in the context of the existing document.
<@ SAYFLD>message</@>	print the contents of the field called 'message' which, in this context, is part of the 'os' recordset.

Note that the code chooses a strategy based on a random number between 1 and 100. But what if there are more than 100 strategies? Wouldn't it be better if the actual number of records could be found and that used as the basis for the RAN syllable? Two ways of handling this requirement are described below:

<@ DEFKEYLIT>__Transput|__HTMLTransput</@> <@ SAYPRO></@> <@ SAYDOC> <@ SAYDHD> <@ SAYDTT>Oblique strategies</@> </@> <@ SAYDBD> <@ DEFDBFLIT>os</@> <@ DEFRSTLIT>os</@> <@ LETVARSZERST>upper|___</@> <@ DEFRSTCAP>select * from os where cardid = <@ SAYRANVAR>upper</@></@> <@ SAYDPR>Oblique strategy: <@ SAYFLD>message</@></@> </@> </@>

The changed syllables translate as follows:

<@ DEFRSTLIT>os</@>	Select every record in the database.
<@ LETVARSZERST>upper|___</@>	assign to the variable 'upper' the size of the default (marked by three underscores) recordset.
<@ RSTCAP>select * from os where cardid = <@ SAYRANVAR>upper</@></@>	Select a new recordset, capturing the output from RAN but using the variable 'upper' to specify the limit.

<@ DEFKEYLIT>__Transput|__HTMLTransput</@> <@ SAYPRO></@> <@ SAYDOC> <@ SAYDHD> <@ SAYDTT>Oblique strategies</@> </@> <@ SAYDBD> <@ DEFDBFLIT>os</@> <@ DEFRSTLIT>os</@> <@ ACTMOVRANRST></@> <@ SAYDPR>Oblique strategy: <@ SAYFLD>message</@></@> </@> </@>

Rather than get the number of records, simply ...

<@ ACTMOVRANRST></@>

move the record pointer to a random place in the recordset.

This demonstrates the power of idiomatic Protium: short, sweet and to the point.

Questions and Answers

I can't see a main() anywhere. Where's the start?

Protium implements a single-pass code evaluation model. This is quite unlike most other languages which implement double-pass code evaluation: first pass to discover and make a map; second pass to evaluate.

Protium starts at the beginning of a named file, and builds its awareness of context from there. Because of this approach, we may never examine code we aren't interested in.

I keep using the same construction over and over again. Is there a way of abbreviating Protium words?

What you can do is create a compound operator (a concept borrowed from OPS-3). These are defined using the KOP syllable. If you wanted to define LVK as a shorthand for LETVARKEY, for example, then you would code

<@ DEFKOPLIT>LVK|LETVARKEY</@>

Thereafter you would be able to use the abbreviated form, replacing code like

<@ LETVARKEY>MyGuid|__GUID</@>

with

<@ LVK>MyGuid|__GUID</@>

There are other ways of doing this, including UDS (user-defined syllable) and BLK (code block), but this is by far the simplest.

*** End of Part 2 ***

© Copyright Bruce M. Axtens, 2008

[Protium] Master Class #1 (Part 1)

Protium is ...

Protium is essentially, and at heart, a way of finding data in a myriad of locations in a homologous manner, manipulating it in a myriad of ways, and then delivering it to a myriad of displays, in a myriad of [human] languages. A concomitant of that is that data be current, so this also involves updating old data, which means that a similar potential is there for making changes to data.

But the overriding maxim is for a direct equivalence of task to operator at the conceptual level. This means that high-level / low-level language distinctions don't enter in: branching is a single operator, but so is "work out the utility matrix for this complex set of possibilities"; the iteration syllable is at the same level as that of add and of unique-sort.

Influences

"I had as a goal the economy and power of APL (minus the cryptic nature) while having the manipulation power of SNOBOL, the one-for-one power of multimedia-instruction-set assembler (e.g. QUEXAL), the task oriented nature of NODAL, the reality representation characteristics of ATLAS, and the data ordering capabilities of the 'lost languages' (Simscript, Dectab, dBase etc.), [such that] the data is available in a way that ordinary programming languages don't permit.

"The other thing I took from NODAL was JOSS's implicit mixing of code and data, which is much saner than LISP's, and also the way that there was an implicit hierachy of data.

"I also borrowed some control structures from RPG, temporary constructions from Miranda, generators from Icon, multiple outcomes from COMIT and compound operators from OPS-3.

"I rejected the naive form of IO (which bedevilled Algol and Fortran). I think the ability to display is the least-used functionality of programming, only touched on in screenwiping and SOAP.

"The idea of assignment [in most programming languages] is generally also naive - for instance the fact that it is a function has been overblown in functional languages, but ignored elsewhere. So [I implemented] scaling and multiple returns (present in LYaPAS in 1964), multiple assigns (common in FORTRAN, APL and the original BASIC), multiple functional transforms (common in any DSP language, e.g. Faust) as well as the closer knitting of data and code (from FORTRAN and dBase).

"The final point to note is that the entirety of Protium works with a SNOBOL-/COMIT-style success/failure flag, converted to a success / failure / don't-know ternary system. Any operation will set this, but it can be qualified (success, found, quantity more than zero, test type, pattern match, etc.)

"Essentially, the idea was to revisit the nature of the programming task, and learn from where the bounds had been stretched; to try to get a thought-to-line-of-code transference capability, rather than the reductive, ALGOL-ish, 'see-how-small-I-can-get-the-core' approach."

        -- Diarmuid Pigott, personal correspondence, 9 January 2007.

How to Program in Protium

The overall Protium approach to programming is to work out what you want to do, then work out what it is that that would be in Protium terms. Sometimes this is very similar to the conventional way (most of the code examples are conventional in that way to secure familiarity). Sometimes it involves a simple task that is unfamiliar in those terms.

Unlike most other programming languages, Protium does not force the programmer to work in either a top-down / decompositional or bottom-up / compositional way. Either approach can be taken. The art of Protium is in the discovery of the idiomatic form which best describes the solution to the problem.

Workflow in Protium programming is simply this: work out what data you need to solve a problem, then extract it and present it. When there is need to extract data according to a criterion, it is specified in two stages, first the data source, then the record source, in the following hierarchy: Data Source -> Record Source -> Record -> Field -> Subfield. Any number of Data Sources can be open at one time, and any number of Record Sources, but a Record Source will always be subordinate to its Data Source.

Protium supports a number of ways of addressing and participating in memory. Memory is untyped. It is a simple tuple of name => value (read name implies value) which can be late-bind typed using 'typifiers', but is inherently capable of any interpretation. There is one global memory space, but it is lexically divided (using namespaces) to make the equivalents of local, static etc. Memory is synthetic, in that it will create a variable (or a structure) on being first called — variables do not need to be declared nor the type of their content specified.

Protium relies heavily on the concept of aliases: when any complex computational task is invoked the operation is aliased, so that you can switch back to it at any time. Anything can be aliased: branching, looping, switching, creation and use of structures, and interaction with data. These aliases, also known as workareas, have two components: a type and a name.

Alias names can be invoked internally, so a field called 'ChinaCollection => DateOfPurchase' will automatically invoke the aliased workspace called ChinaCollection to fulfil the data request. This means that some very powerful manipulations are possible - such as the much-used scatter/gather (borrowed from FoxPro) to swap data between aliased workspaces.

Implicit in all of this is the idea that, where possible, everything should be invokable with one operator, so DCT (dictionary) without a name is the dictionary currently in scope, and of course implicit in the entire thing is a hierarchy of context - the field is always (unless specified) invoked in the context of the current record or the current recordset (or query or view) of the current database. It is this dependence on context - Protium's context-aware, rather than context-free, grammar - which trips up the beginning Protium programmer. That and the lack of appropriate casting of numerics - all comparisons in Protium are lexical (i.e. 'a' is less than 'c'; 5 is greater than 45000), so comparison syllables must bear an explicit number-cast syllable when a numeric comparison is required.

Conventions

Protium respects the following naming conventions with respect to the file type:

Extension	Meaning
.p	a Protium script in plain text format
.pr	a Protium script in rich text format (RTF)
.pre	a ProtiumWeb script (plain text, HTML or rich text)
.prx	a Protium executable project (plain text, HTML or rich text)
.plb	a Protium library (plain text, HTML or rich text)

The code in a .pre or .prx file can favour HTML (the <BODY>text</BODY> approach) or favour Protium (the <@ SAYDBDLIT>text</@> approach). In the latter it is possible to write <@ DBD>text</@> as Protium will disambiguate where possible, making 'slang' forms possible .

Generally we make two files per website, a default.prx and an index.prx, but of course it could be set up to look for an index.pre, if necessary.

*** End of Part One ***

© Copyright Bruce M. Axtens, 2008