Talk:Ozone

Author's Comments

This is the first of my language experiments that I think is original enough and of decent enough quality to show. This language could do with some slight revisions. This mainly because I had to implement some ridiculous kludges since I couldn't figure out what else to do. The big two would be these:

Kludge 1

It only outputs as numbers. I wanted to be able to simply go through a string with a display/pop/loop construct, so I couldn't have separate commands to display as ASCII and as a number. I considered having it tag chars versus numbers, but first it would completely wreck the idea of having everything in the program be a stack, and second I have absolutely no idea how you would go about implementing that, so I scrapped it. So it was a toss-up between output as ASCII and output as numbers. On a purely practical level it would be ridiculously difficult to handle display of numbers if it was ASCII-only output. On a personal level, I think numbers take precedence over characters anyway. If you have any suggestions for a more elegant way to handle this, they would be greatly appreciated, as I am certainly open to revisions. Set 19:14, 9 February 2008 (UTC)

you should output as ASCII chars. Other esolangs have no problem with this when editing numbers, and it's far more flexible. -Elliott who is not logged in 21:01, 9 February 2008 (UTC)

Do you have any recommendations for how to handle numbers if I output as ASCII? For example, when I have 65 in a stack, that would output as "A." But in some situations I would want an output of 65. Similarly, if I stored the number 1 in a stack and tried to output it, I'd get at SOH (I think...).

you write special code to display numbers. elliott 21:32, 9 February 2008 (UTC)

The big problem I have with using ASCII as default output is that I then cannot easily output the numbers in my stacks. I guess I could write something to change a stack of numbers into a stack with the ASCII values of those numbers, if it came to it. Or I could go back to having separate commands to output ASCII and numbers, but then I cannot just loop through a stack to display it.

There is probably a really easy solution to this problem, but I'm rather new to language design, so I don't know what it would be. Thanks for your input, by the way. Set 21:27, 9 February 2008 (UTC)

Okay, I ended up going back to the original idea and adding having separate commands for displaying the value as a character and as a number. I figure that it's a lot more important for the language to actually make sense than it is for it to be 'ideologically pure' and to hold to my original standards. The output of the stack value as a number is complete syntactical sugar, as I could have just written special code for displaying numbers instead, like Elliott suggested, and it would have been completely equivalent. But I figured I'd trade a bit of purity for a bit of usability. Thanks for stimulating some ideas, Elliott. Set 17:30, 10 February 2008 (UTC)

Kludge 2

Numerical commands can take both the number and the ASCII value of a numeral. Because of this, you can't actually use the numbers that happen to be the same as the ASCII values for a numeral. Personally, I think that's flat-out stupid, but I can't think of a better way to do this. I guess I could require that they take only the numbers, but then my code would be loaded with {} left and right, making it really inelegant. Because of this, I think the best solution would be to modify the way that the language handles lists and character sets, but so far I haven't found a better solution. I am still working on it though. This one should be easier to fix than the other. Set 19:04, 9 February 2008 (UTC)

Okay, I think I've dealt with this one. Now, even within character strings, numbers are treated as numbers rather than as ASCII values, and numerical commands no longer take the ASCII value as well as the number. It's still not great, but it is a much better fix than before, in my opinion. If you have any further suggestions, I'm open. Set 19:23, 9 February 2008 (UTC)

Interp

I am going to write an interp for this. -elliott 18:27, 10 February 2008 (UTC)

Paradigm and computational class

This looks like it may be a concatenative language, or at least something similar. It may therefore be possible to prove it Turing-complete by compiling Underload into it. (Many of the commands map 1-1; I'm not entirely sure what m does (does it duplicate the top item?).) The main issue seems to be compiling Underload's *, but that might be possible with some kind of loop in Ozone that was effectively a stack-concatenating subroutine. (S would be harder, but not needed for Turing-completeness.) --ais523 10:54, 11 February 2008 (UTC)

It does seem that Ozone is pretty similar to Underload. Umm, I must not have been clear enough about what m does, because even I now realize that it's quite pointless. It was supposed to push the top element down so that you could work on a new element atop the stack, and I'm not sure why I thought that was a good idea. I already have a perfectly command which pushes things onto the stack. I suppose I shall get rid of it.

Yeah, implementing * would be tricky. Off the top of my head, the only way I see of doing it is some sort of copy-and-push loop. If the stacks were separated out, concatenating them would be relatively simple, but since they aren't, it might not be. To make sure I have a grasp of *: Let's say I theoretically had a stack with elements (1,2,3). If I run an analogue of * on it, will I get (1,3,3)? That was the impression I got from Underload's Fibonacci program (which I like, by the way). Set 22:55, 12 February 2008 (UTC)

It's more like if you run * on ("x","xx","xxx"), you get ("xxx","xxx"); it concatenates the top two stack elements. (In Underload: (xxx)(xx)(x)* is equivalent to (xxx)(xxx).) The stack elements can themselves be strings in Underload, which can be evaluated as programs. I think that v might be able to do something similar, but am not sure if I understand the spec too well. (* does addition of numbers if they are represented as strings in unary, as they are in the Fibonacci example.) --ais523 14:39, 13 February 2008 (UTC)

I don't know that I can do that with just v. v just pushes a list onto the top of the stack. Since strings are handled as individual characters, rather than as single stack elements, it seems this will be difficult. I can't think of a way in Ozone to represent your stack with the strings ("x","xx","xxx") as anything but a stack ("x","x","x","x","x","x") with the program handling in such a way as to display or execute "x", "xx", or "xxx". Yeah, the string handling is kind of, well, nonexistent. It's a bit like the "array of chars" paradigm without the "array". So, doing it this way would be a matter of changing the way the program handles the stack rather than the actual content of the stack, which doesn't sound either functional or fun.

I could store strings into their own stacks, which would then make string-handling simpler, but they'd no longer be stack elements that could be pushed or popped. Set 20:53, 16 February 2008 (UTC)

Ah, it makes things substantially harder if you can't have strings or stacks as stack elements; that's a major difference which means direct compilation probably wouldn't work. You could push two nested copies of vn(<...>) followed by the code for Underload's a to implement Underload's (); then most operations would be easy apart from duplicate (:) and wrap (a), because they would have to detect what on the Ozone stack being used to represent the Underload stack corresponded to the top element of the Underload stack, which would be nontrivial and involve matching brackets. (I take it that it is possible to put (, ), < and > in an Ozone string notation as long as they are properly matched?) It should still be possible to do the compilation, though; I might work on it at some point when I'm not busy. --ais523 09:02, 19 February 2008 (UTC)

The v** instruction

All the instructions can theoretically work on any stack, but this doesn't: since the language does not allow argument separators, how could I distinguish between

v112  |  this means: push stack 2 on stack 11

and

v112  |  this means: push stack 12 onto stack 1

?
I'm asking that because I'm trying to write an interpreter. --(this comment by OberoN at 15:56, 29 September 2012‎ UTC; please sign your comments with ~~~~)

In lieu of a more complete specification, since the language allows whitespace, and doesn't say that whitespace is allowed inside an integer literals, I think it would be reasonable to assume that whitespace isn't allowed inside integer literals. Thus you could parse as follows: v11 2 means push stack 2 on stack 11, v1 12 means push stack 12 onto stack 1, and v112x, where x is not a parenthesis, is a parse error. Chris Pressey (talk) 16:43, 29 September 2012 (UTC)

Self-modifying?

Shouldn't this be in the category of self-modifying languages? It's only loop structure is the ability to push code on stacks and execute them. If I understand it well, it's much worse than just that: it cannot even be parsed before being interpreted! Consider the program:

(v4(<A>)
 v42(<B>)
 v0(<c4>)
 2)

What does it do? My guess, after the v** instruction is executed, stack 0 has become ['c', '4', '2'] which seems to mean "print the top character of stack 42" and not "print the top character of stack 4". Though if programs are pushed to stack 0 as a list of character, I guess they should be written as (< ... >) rather than just ( ... ). I guess then the execution of an Ozone program would sound like executing the code "v 0 program e 0". Well, my opinion on this is that it sounds like a VERY interesting language (and I mean VERY), but it's hard to understand how it works exactly and could benefit from more explanations. --Koen (talk) 20:49, 29 September 2012 (UTC)

Note that I am not sure what the instruction v0* actually do. I assumed it would pop itself out of stack 0 first, then only push * onto stack 0. This seems to contradict "This will interpret the top item as a command, then pop it and continue all the way through the stack."; however, if the command really is popped only after it has been executed, how does the Hello, Word! example work? It ends with v02. How can the 'v' be popped if it's been buried under the content of stack 2? Also, are the arguments popped as well? For instance the '0' and the '2' in this example. Besides, if pushing stack 2 onto stack 0 stops the "v02" from being popped, and assuming v0* doesn't destroy stack * while pushing it (it isn't specified whether a stack is destroyed when used as a list for v), then I suspect the Hello World program is in fact an infinite loop "push stack 2 onto stack 0, print "Hello, World!", push stack 2 onto stack 0, ...". --Koen (talk) 21:00, 29 September 2012 (UTC)

The language is really not that well-described. Things that jumped out at me while I was considering what you say: the phrase "This will interpret the top item as a command, then pop it and continue all the way through the stack" is used to describe the e instruction. It is not stated that execution of the main program works the same as execution by e. It would of course be reasonable to assume it does. None of the example programs contain an e instruction. I highly suspect "interpret the top item as a command, then pop it" was not intended to be worded that way; pop-then-execute is so much less bizarre. (As you point out, what if the command put other stuff on the stack? Does "pop" then mean "remove the command from the stack even though it is now below a bunch of other stuff?)

This is not an uncommon situation with this wiki: half-designed esolangs are half-written up, then the author (the only person who can say what was really intended) goes off and does other things with their life, possibly never to return, leaving everyone else with no definitive answers. If this language is ever to be implemented or proved Turing-complete, those gaps will have to be filled in in some way, but short of editing the article to clarify what is meant (which I'm not comfortable with because I don't assume to be able to read User:Set's mind), that would have to be in a derivative language. ("Ozone++", anyone?) Chris Pressey (talk) 00:02, 30 September 2012 (UTC)