ASCII input

[JackDesBwa]

Quite ironically, asciidots does not seem to support ascii input.
Or have I missed something ?

This prints ascii based on (\n-separated) list of numbers:

.->#?-\
  \#a$/

$ echo -e "66\n69\n78" | asciidots example1.dots
B
E
N

Aborted!

With ascii input, this code is lost. It outputs \0 followed by \n.

$ echo "BEN" | asciidots example1.dots | hexdump -C

Aborted!
00000000 00 0a |..|
00000002

It might be useful to have a primitive that read one char of input and store its char number (https://docs.python.org/2/library/functions.html#ord) as dot value (exactly the opposite of $a#).
Thus the program could take any arbitrary input.

As a side effect of this small example, we see that it might be useful to test for EOF as well.

[Aaron Janse]

Thanks for the feedback!

I have given this some thought in the past, but couldn't decide whether it should be a language-level feature (i.e. defining a new asciidots input char) or an interpreter-level feature (i.e. a command-line flag).

I'm inclined towards making this an interpreter-level feature since if I define a new char for ascii input, I'd eventually define a char for arrow keys, then for mouse interaction, and so on. I'd end up with lots of characters reserved to do almost exactly the same thing.

I do see considerable merit in supporting ascii input, though.

Here are some of my ideas (feel free to suggest completely different solution, btw):

• add an "ascii input" flag to the reference interpreter (this one)
• let people create their own forks, which support ascii input
• create fork myself that lets asciidots communicate with higher-level processes via special stdout commands (for example,§a could switch to ascii input mode, §k could let asciidots detect arrow keys, etc)
• give in and add a special char for ascii input. I have already done this for ascii code output (i.e. $a#), and I kinda regret it.

Regarding EOF support, I think that this is very important. Now that you brought that up, EOF support is the first thing on my todo list for asciidots.
I'll open up a separate github issue for EOF discussion.

Once again, thanks for the feedback.
I'd love to hear what you think of the ideas I have so far. Feel free to criticize or suggest new ones.

Happy asciidots(-ing?) 😃

[JackDesBwa]

From my point of view, the functionality is fundamental as it allows to compose asciidots scripts with any other program (through a pipe for example). Also, it might be useful to use both modes (e.g. asking characters for a name, and number for age) in the same program. Therefore, I would tie it to the language itself.

Regarding few character set, the solution is usually composition ; although it might be done without, using a really powerful set such as in befunge (37 commands: https://en.wikipedia.org/wiki/Befunge#Befunge-93_instruction_list) which works remarkably well thanks to stack principle. Asciidots uses multiple dots which is probably a powerful idea to be explored as well.

Composition should be done properly though. Given the way asciidots works (user POV), I think modifiers is a way to consider: dots will pass through a modifier and affect the next operation except if it is another modifier whose effect will cumulate (or replace if incompatible). I do not know if it is better to consider immediate action (i.e. forget modifiers if there is no operation just after) or maintain these modifiers along path with a reset modifiers command.

In fact, it is quite what vi commands do. For example we can see hjkl are operations (respectively left, down, up, right) whose can be altered by modifiers. Alone, they just change cursor position, but with d (seen here as a modifier) it will delete in that direction so that dh will delete one character which is the one at left of cursor ; and modifiers can be combined so that 2dh will do 2 deletion to the left.

Note that consistency is really important to simplify reading and thus writing.
I notice you used modifiers both before (#?, @?) and after ($a#, $_) commands.
Too keep the logic, I would propose #a? for reading raw input (even if I would have personally preferred a modifier to read numbers with raw being the default)

Hope my thoughts will help.

[Aaron Janse]

Sounds great!

I'll make #a?/@a? set a dot's value/address based on ascii input.

I might consider binding special keys to ascii values (i.e. those >128), but I haven't given it much thought so far.

We'll need to figure out how to implement a prompt for key presses such that the user doesn't have to press enter each time they want to input a character.
Getting ascii input from the shell's stdin should be much easier.

Thanks for the feedback, and for your great followup comment, btw.

[JackDesBwa]

I would strongly advice to not reserve numbers for special keys (at least bellow 256) and propose another modifier instead. Actually, by not restricting input to ascii range, you get the ability to deal with binary inputs for free.

For the second part, this quick test I made might be a good starting point, although it would be nice to add some code to record termios configuration before and restore it after ; according to the documentation, this version only works on unixes:

import sys, tty
tty.setraw(sys.stdin)
print(sys.stdin.read(1))

[Aaron Janse]

You make a good point about not reserving numbers (esp. below 256) for special keys.
I didn't think of this, and now I definitely agree.

Another thing is that I don't feel very comfortable about adding another modifier. I'm afraid of feature bloat, where the language becomes difficult to learn because it has too many "features".

Related to #55, we need to figure out a way to specify special values for EOF, etc.
Maybe negative values?
Maybe values above 256?

Something completely different?

I'm open to any and all ideas.