ConteX programming language

The concept is something I personally have never seen before, but it works fine in this language. Before telling what sequences really are and how they are used, I must present the set of dillemas I was hit with in the designing of this language.

When I first made CX, I had few harsh and stiff rules in my mind. One of those rules were about the 'set' command, being the central way of constructing things upwards from the foundation. set would take a list containing 1 string, then one of anything. The string that set would take would be put into the context that the user is currently in (right know, you are stuck in the 'prim' context). Functions are in included in the scope of 'anything', so they were to act just like strings, numbers, or any literal. To build a function, a person would set ["theName" {the quote}] , then whenever the person refers to theName, the quote would be executed.

This has a problem. You've set["theName" { the quote }], and now you aren't getting { the quote } back when you mention theName. In other words, the evaluator was made to execute any quote that a word contextualized to. I thought of it as an ugly thing, but I couldnt find a better way. The other options were:

-just make theName refer to { the quote } so that saying theName doesn't execute it , but returns it. Now use eval theName, and you can continue. The problem with this is that you'd have to eval every damn function. That is tedious. Also notice that eval itself would have to be eval'd if I wanted it to be concidered a function- now you can't do anything, unless you have some kind of inconsistancy.

-just leave things the way they are: if I set["x" {+[2 3]}] x=> 5 . This was the ugly status quo and I can find more reasons it should not BE. It is inconsistant, number one, because when I set "x" to anything else, and later use x, that something else can replace the x and the code will work fine. For example, if I set["x" {+[3 4]}] , then later say +[x 3], the x in the list for addition should expand to [ {+[3 4]} 3 ] , which would make the '+' function fail because one of the list nodes is NaN.

-The BEST solution is to make a switch on the quote to say whether or not it should execute on contextualization or not. imagine if I had the primitive: 'switchOn' and 'switch Off'. When you pass switchOn the quote, the quote is turned 'on', and when something contextualizes to it, it is executed, not referred to. set["x" switchOn {+[2 3]}] , now x => 5. then, set["x" {+[2 3]}] , now x => {+[2 3]} . now, set["y" switchOn x], y => 5 ! Isn't that beautiful?

I've almost explained it all, but there are small things that need to be fixed in the last option. First of all, we have not seen switchOff. let's try it.

set["x" switchOn {+[2 3]}]
x => 5
set["y" switchOff x]
y => {+[2 3]}

I know. It looks fine for a second, but remember that I want complete consistancy, or as much as possible. On the definition of "y" , switchOff x would really 'expand' to switchOff 5, because x was switched on, and when something contextualizes to a switched on quote, it is evaluated, remember?

So now, I evince to you the best way. Sequences. The final conclusion uses most of the concept just explained in the previous paragraph, but is polished with a different kind of switchOff and different names for those functions. Rather than explaining all that stuff, I'll just re-write the 4 lines of CX code , using the final concept:

set["x" unquote {+[2 3]}]
x => 5
set["y" quote "x"]
y => {+[2 3]}

I called them unquote and quote to give the user the concept that the actions are really being taken on the braces around the quote. In other words, unquote takes away the braces on a quote, and quote puts them back on! The quotes are are "switched on" are called sequences, becuase they are just sequences of words, just like a quote, but these sequences of words have no " { " and " } ". They are bare, and when you use a word that contextualizes to a sequence, it is as though you typed the sequence out manually. You must use unquote to produce sequences. The new switchOff, quote, takes a string to escape the inconsistancy mentioned before.

NEATO ay? Ok, it's not perfect, but it's damn near close.

unquote {+[2 3]} => + [ 2 3 ]

Should it have returned 5? I chose no. This would be the last dot of inconsistancy. The same sequence can be given to the evaluator and we don't get 5. This is because of a new rule about sequences: The only way to evaluate a sequence is to have a word contextualize to it. Think about this: when the hell would you unquote a quote and want it to evaluate anyway? You could just type out the damn sequence. Conclusion is that we've gained the advantage of quoting/unquoting at the cost of a small inconsistancy that has no disadvantage.