That's a thought. My proof-of-concept has commands move(direction), turn(direction), and put(character), as well as write(string, moves) that takes a string of characters and interleaves them with a string of moves.
One thing to do early on, I think, is collect a representative sample of ASCII-art challenges that we can test our ideas on.
I also think reflect will be useful, with arguments that determine the direction of reflection, and flags or versions for 1) whether the axis of reflection gets duplicated or not, and 2) whether characters get intelligently changed in the reflected version (e.g. swapping > for <)
Maybe, but only if ! as "translate < to >, [ to ], etc." was a useful command in any other contexts. If its usefulness is mainly limited to reflections, then ! could be a metacommand that could do something different when applied to other commands.
@ASCII-only I'm not an expert in codepages, but so far I like the Jelly codepage because it has all 10 decimal superscript digits, allowing for numbers in the code to be distinct from numbers in the data.
@DLosc I think it depends, if we have too many commands to fit in the other chars (e.g. if we have too many arithmetic commands) it's gonna be shorter to just have quoting I think
SnakeEx, 200 bytes
The right language for the job... sort of.
m:{v<>}{r<RF>2P}{r<R>2P}{h<RF>1P}{w<>}{l<RF>2P}{l<R>2P}{h<.>1}
w:{u<>P}{v<>}
v:{e<L>}{u<R>1}
u:.*{e<>}
e:.$
r:[^ ]+
h:([^ ] )+
l:({c<.>}[^ ])+{c<.>}
c:{b<B>}(. )+{x<>LP}{s<>}
b:.{s<>}
s:[^\!-\~]*$
x:.
SnakeEx is a language from the...
Probably half of that is ensuring there's nothing but spaces before the hexagon, nothing but spaces after the hexagon, no extra lines above or below, etc, etc. It was a bit of a pain TBH.
@ASCII-only Oh I was just rambling on about my own language, sorry. I'll stop now. It's just a little weird to me since this language sounds really similar. (Although yours sounds more advanced)
@DJMcMayhem I'm interested to look at V now, though. At least, it can give us ideas for this project, and at best, if it is really good, why reinvent the wheel?
@ASCII-only This feels to me like overengineering to fit a few unusual testcases. Most ASCII art is pretty rectangular, so I think we should start there.
@DLosc Yeah, diagonal directions are vital, the tent one needs them as well
@DLosc It's less common (plus I'd prefer to have no flags because it's weird posting bytecount and sometimes might stuff up the leaderboard) so having the hexagon namespace character at the start of the program should be fine IMO
@DJMcMayhem That's actually possible with one byte
@DLosc Well, if you ever want to look into V more, or you're looking for inspiration, it's got a chat room where I'd be happy to answer any questions you have. It's pretty late, so I'm gonna go to bed now, but I'm really curious to see what you guys come up with!
We will have rotate, and may want toroidal move for this, but idk how to make the vertical toroidal move for the 3-face stack wrap to the far right face
I'm think we'll always need direction so print will be print(direction, length[, character=one of /\-|]), or print(direction, string), we may want print2d(direction, length[, character][, fill][, rhombus]) and print2d(direction, string[, fill][, rhombus])
This way we can do a string cube with back going up and to the right with print2d(0b01001010, 0x01000000, input) (assuming directions are every 45 degrees clockwise from north, the second arg will possibly be a mandatory argument with boolean command variations
We need to decide on the syntax, because I think we need string print with length as well for things like this
Not sure if we want to have intersections (i.e. an option for print to print + and X where two lines cross, IDK if there are appropriate characters for different combinations)
this one would need hexagon mode, print 4 with radius input, direction 0b11111100, print 3 with radius input, with flag corners_only, decrement input, print 6 with radius input
I think we should have a toggle char for box chars for fun
Like what we might do for hexagon mode
Definitely not gonna help for any challenge though
for this I can't think any good, general ways to do it, any builtins we introduce will probably just be a waste of characters
The "print in multiple directions at once" idea is not something I had thought of, but I think it's promising, can be applied in multiple challenges.
The idea of multiple cursors is also intriguing--I'd say let's design it with one cursor first, and then see whether allowing multiple cursors ends up saving bytes (by simplifying algorithms) or costing bytes (by requiring more-complicated cursor management commands).
(And "print in multiple directions" seems more straightforward with multiple cursors.)
"Option for print to print + and X where two lines cross"--sounds cool but unnecessary in 95% of problems--low priority.
Hexagon mode: I'll stick to rectangular mode and let you work on that. :P It will be a useful feature if hexagon-themed challenges keep cropping up, but let's just say there's a reason I haven't tried to learn Hexagony.
This would need hexagon mode, write string, all six directions, fill (can also be applied to ractangle mode)
For this I think we can just do a triangle, reflect on the NE/SW axis, merging the edge, do the same for vertical and horizontal axes
The direction byte for reflect will have three bits for the 8 directions, the axis will be that way from the pointer, and perpendicular to the stated direction (I don't think we need multiple directions)
This does bring up a question: we've talked about writing stuff on an infinite plane (what I've been mentally calling a "canvas"). Do we want to have the ability to create multiple canvases, draw different stuff to each of them, copy/reflect/rotate them, and then stitch them together somehow?
@ASCII-only I don't know that a tape will produce very golfy code. Either stack or store-stuff-in-variables (I assume that's what you mean by "scope") for me.
@ASCII-only I think it might, particularly on that draw-an-intersection problem you linked. The vertical road section could be generated once, and then conditionally stitched above and/or below the center section based on input.
But I should probably apply my own label to the idea: "cool, not that useful, low priority" :P
Consider a non-empty string of correctly balanced parentheses:
(()(()())()((())))(())
We can imagine that each pair of parentheses represents a ring in a collapsed telescopic construction. So let's extend the telescope:
( )( )
()( )()( ) ()
()() ( )
...
I'm thinking the latter. The former is interesting, but seems like it would take up too many bytes trying to describe what should be selected and moved at each step.
The parentheses problem, for one. Turns out you need to go down whenever you have two ( in a row, and up whenever you have two ) in a row. That's way easier with regex than any other method I've thought of yet.
Legend: Ḟ is for loop, ċ is a variable, ị reads input, İ is if, ⁼ is equality testing (prefix operator), ⁽⁾ are like curly braces, and ṆṢẸẈ are movement commands.
Could shave one byte with single-byte command for "move south-east," which seems probable.
This of course hand-waves the question of exactly how ị works--here, it evidently is able to read a multi-character string.
The dangling else is a problem in computer programming in which an optional else clause in an if–then(–else) statement results in nested conditionals being ambiguous. Formally, the reference context-free grammar of the language is ambiguous, meaning there is more than one correct parse tree.
In many programming languages one may write conditionally executed code in two forms: the if-then form, and the if-then-else form – the else clause is optional:
if a then s
if b then s1 else s2
This gives rise to an ambiguity in interpretation when there are nested statements, specifically whenever an if...