Talk:1L AOI

Reflections

Why are reflections considered problematic? They seem perfectly well defined, and they seem to work exactly like reflections in Blackbox, except of course being conditional. --Chris Pressey 05:06, 18 December 2010 (UTC)

When I originally said "they will most likely be trouble", I didn't really mean problematic per se. Instead, I was referring (I believe, it has been years) to the fact that they may cause confusion for an interpreter. A non-issue I guess - Hiato 15:35, 13 February 2011 (UTC)

Indeed, I had made a wild guess that this section might even date from the original Angle of Incidence 1L proposal; IIUC, in it, each deflection was supposed to cause a side-effect of some kind, and a reflection could be equally well considered as either two left deflections or two right deflections. Left unaddressed, that would certainly be problematic. --Chris Pressey 23:09, 13 February 2011 (UTC)

Some Problems

In trying to implement this language, I noticed a couple of problems.

One is that the precedence of the two "modes" of operation of + isn't specified. That is, in:

    +
>>>+

... I don't know if I should increment at MP first, and then check for deflection, or if I should check for deflection first, then increment MP.

I would propose to fix this by specifying that the + under the CP should be executed first, and only after that should we check for deflection. No good reason for this order -- it just seems more natural.

The other, more serious problem is that it is not possible to achieve an arbitrary effect at an arbitrary point. If the CP is travelling north or south, it can only move the MP -- it can't change any cells on the tape. If the cell under MP contains zero, no deflection can happen, and you can't change direction to east or west, so you can't change that cell so that it no longer contains zero. So, once you have gone past the last of the touched cells, you can't do anything except keep moving the MP in the same direction. (I'm assuming cells that haven't been touched contain zero -- this isn't specified, here or in 2L, but it seems almost ubiquitous for brainfuck-like languages.)

I encountered this when running the example program -- it wants to turn right at TL0, but TL0 contains 0 so it can't. The spec says TL1 always contains non-zero, but that doesn't help for modifying TL0. (There is also a small bug in the example program, a missing blank line, but that's easily accounted for.)

It's possible I missed a detail when I rewrote the article, but I don't think so, as Hiato's version is pretty explicit: "If the Memory Pointer cell is non-zero, the Command Pointer will turn away from the +, otherwise, it will proceed straight."

I would propose to fix this by making only one kind of deflection (say, left) conditional on non-zero, while the other kind (say, right) is conditional on zero. You can always turn one direction by turning the other three times. This would remove the possibility of direct reflections, though (a pretty minor loss, I think). (By "left deflection" I mean the deflection that results in the CP turning 90 degrees to the left.) --Chris Pressey 16:52, 7 February 2011 (UTC)

Correcting myself: 2L does specify a tape initially filled with zeroes. Also, to clarify/summarize the above problem: once a cell contains zero in 1L_AOI, it is impossible to change it, because it is impossible to have the MP stop on it. --Chris Pressey 18:50, 7 February 2011 (UTC)

After giving it some thought, I would like to change my proposal for how to fix the problems with conditional deflection. I propose that left deflection is conditional (in the same way all deflections currently are) while right deflection and reflection are both unconditional. This is because otherwise achieving an unconditional deflection is quite possibly impossible.

I would also like to give (1L_AOI + my proposals) the provisional name 1L_AOI_EU until such time as these proposals are incorporated into the language (if ever.) --Chris Pressey 00:30, 9 February 2011 (UTC)

Actually, now I'm thinking that my first proposal for fixing deflection is more "2L-like" and, since this language is intended to "retain much of the visual feel" of 2L, maybe that's a better fit. To match 2L, it should be "right deflections only happen on nonzero; left deflections only happen on zero." If it works in 2L, it ought to still work here (knock on wood.) Actually, the situation where you would reflect in Blackbox, is equivalent to 2L's +:

 2L     1L_AOI_EU

            +
>>\+     >>\
  v        v+

That would make 1L_AOI_EU very close to 2L (you could probably translate 2L programs to it, fairly mechanically; turn all #s into +s, +s into pairs of +s, and adjust spacing as appropriate.) --Chris Pressey 17:07, 11 February 2011 (UTC)

Actually, I don't see why I should be worried about having the deflection directions "match 2L". The behaviour of going north vs. south over a + is already reversed from 2L. (Maybe this was derived from Gregor's original interpreter, which also mixed them up?) --Chris Pressey 06:27, 12 February 2011 (UTC)

In no particular order of response: Yes, they (north vs south) are reversed due to Gregor's interpreter. I agree on the matter of the order of precedence with the CP and MP (CP first). In the spirit of the North/South reversal, I will happily incorporate your 1L_AOI_EU proposal with the modification that "right deflections happen only on zero; left deflections happen only on non-zero". I'm fairly confident this will have no adverse effects on the language, aside from making it difficult to translate 2L into 1L. Perhaps this is a silly insistance? Do change it if you think so. Anyway, thanks for the re-write and contributions, I will modify the page shortly. -- Hiato 15:35, 13 February 2011 (UTC)

MP table

I believe that the reworked MP state-transition table will prevent irrecoverable situations (like the one above) from arising again. As for whether or not it preserves whatever modicum of TC this language may have had, I am not sure. This will require further investigation. Oh, and the example is now broken. EDIT: I went for this over the 1L_AOI_EU spec as I felt it was simpler in one key way: the direction in which the CP deflects is solely dependant on the contents of the cell under the MP. Direction plays no role in this decision, making programming somewhat more consistent and easier to do. -- Hiato 16:14, 13 February 2011 (UTC)

Thanks for the update. I implemented and experimented with the new semantics, but unfortunately, unless I missed something, they don't solve the problem. To wit: for the MP to be moved to a new cell, the CP must be travelling down or right; if the MP is now over this new cell and it contains zero, the CP cannot change direction, thus must continue to move down or right -- so it can only move the MP to another new cell. It still cannot change the cell that contains zero. --Chris Pressey 23:04, 13 February 2011 (UTC)

Arg, yes, you are -- as always -- correct in this matter. I'm not sure how I overlooked that. It would seem I designed my solution to solve only one problem and not to prevent further ones. The next two days are entirely full for me, so I will not be able to work on this issue. Feel free to edit it to the 1L_AOI_EU spec, however I would prefer a simpler solution (by the dependency-metric-type thing; above) -- likely to come as a result of manipulating the MP table. It is, however, possible that all permutations (yes, all 24 of them) are 'broken' in this respect. The more I think about this, the more it seems to be true. I will investiagate further as time allows. -- Hiato 20:20, 14 February 2011 (UTC)

Why yes -- every statement I have ever made has been correct, including this one! No, seriously, I did have to implement it and test it before I realized it -- if I was really awesome I would've just seen the truth of it right away, I suppose. Anyway, I agree, I think all permutations have this property. I wouldn't feel quite right incorporating the 1L_AOI_EU solution into 1L_AOI itself without knowing that you haven't abandoned the search for some more agreeable alternate, so I'll happily wait on that. --Chris Pressey 23:15, 25 February 2011 (UTC)

No null output?

Looking at the IO spec for this, I don't see any way of outputting the null character. If TL0 is zero, it will input instead. This is not normally very important, but if someone wanted to do binary instead of ASCII IO, they would be limited. Maybe have decrementing TL1 always be output and incrementing it always be input. This would allow outputting the null character without any more reserved tape cells. —Maharba 04:40, 23 June 2011 (UTC)