Talk:Lenguage

Unless I'm missing something, you can't start a Lenguage program with a + or series of +s as the resulting number would be the same as if the command weren't there. This could be fixed with a leading 1 perhaps. - --Rottytooth (talk) 18:24, 17 September 2017 (UTC)

Or to invert the bits, so that ] is now 000 and + is now 111. --Zzo38 (talk) 19:27, 17 September 2017 (UTC)

Yeah, that makes sense! Or perhaps to Huffman encode it, like Spoon --Rottytooth (talk) 16:45, 19 January 2018 (UTC)

Practical problems trying to use Lenguage

After trying to actually use Lenguage, I've discovered an unusual issue: it's literally impossible to input an EOF into the program. This causes it to not be I/O-complete in the usual sense (where EOF is a sort of input that can be reacted to).

The Lenguage reference interpreter refuses to take input from anything other than a terminal; and it does so using raw input only. In other words, the bytes sent via the terminal connection are the bytes that the program sees. Most sorts of terminal don't have any out-of-band way to send EOF (this is the reason why most programs don't use raw input, but rather allow the kernel to interpret control characters sent via the terminal connection). This in turn means that it's hard to provide input "directly" to a Lenguage program: you have to create a separate encoding via which you can specify where the input ends.

One possible alternative would be to use a serial terminal, which can send a "break" character (sort-of the equivalent of an EOF) by purposely misencoding the signals it would normally send. My reading of the terminal API is that doing this would cause the Lenguage interpreter to exit via SIGINT.

On another note, the Lenguage interpreter attempts to open the file containing the program, and read from it to count the characters. Given the potential size of such files, this is a bad idea; a better option would be to ask the filesystem how large it is. Many filesystems nowadays can efficiently represent very large files if they contain nothing but NUL bytes. Unfortunately, there's still often a cap at 2⁶⁴ bytes (filesystem APIs often don't allow larger numbers to be transmitted), so we're limited to programs no longer than 21 brainfuck commands. Perhaps using a more efficient language than brainfuck would be a good idea here. --ais523 19:12, 27 February 2019 (UTC)