I created a programming language for manipulating strings called Stringy. It's very different from other programming languages, since you only have one string (for manipulation) and some variables. With the various commands you can manipulate that one string. I created it because it might be useful for some challenges here. (challenged tagged string)

What could I add to this to make it better/more useful for challenges here?

Examples for the language can be found at GitHub at examples.txt. It might be a bit hard to understand though.

  • \$\begingroup\$ First, why not by default append any strings present and have commands to change order of appending (e.g. f sets it to front and b back). Second, if this is for code golf, you can really shorten your command names (there are a lot of characters to use up before you start going to more than single character commands). I'm on mobile right now but I'll try and voice my suggestions more coherently when I can. \$\endgroup\$ – cole Oct 10 '15 at 18:27
  • \$\begingroup\$ What d'you mean, "text" for appending to text? f and b are excellent ideas, I'll try to implement those. The 2-character command names were just to make it easier to understand. I might change those too. \$\endgroup\$ – m654 Oct 10 '15 at 18:29
  • 3
    \$\begingroup\$ There is an ongoing discussion whether questions like this are on topic. I personally think they are way too broad and that we shouldn't use Stack Exchange as an issue tracker (and judging by how rapidly the new answer on the meta post has gained upvotes, that may or may not become consensus). However, as long as the votes don't show a clear consensus I'll refrain from voting to close this, because of my binding mod vote. \$\endgroup\$ – Martin Ender Oct 10 '15 at 18:30
  • \$\begingroup\$ Yeah, sorry, I tried to clarify that in an edit - I'll write down my ideas and get back to you in a more nicely formatted post when I get to my computer. \$\endgroup\$ – cole Oct 10 '15 at 18:30
  • \$\begingroup\$ @MartinBüttner I checked the meta and the most highly-voted comment in a question said that asking questions like this should be OK. And I don't think anybody downvoted the Pyth question... \$\endgroup\$ – m654 Oct 10 '15 at 18:33

OK, I said I'd put my comments into a more comprehensible form so here they are.

  1. Don't separate commands. Having to use ; every time you want to use a different command is costly. My recommendation on the interpreter side is to parse one character at a time and read more if the command necessitates it.

  2. Add regex (to be honest, I don't know much regex -- it's somewhere on my list of things to learn -- but it seems logical to add it)

  3. On the topic of not separating commands with ;, allow for whitespace to be removeable.

  4. Add loops of some sort.

  5. Add conditionals and conditional tests (equals, not, and, or, etc.)

  6. Add a newline reserved character (n, perhaps?)

  7. Add reserved characters for variables

  8. You have uppercase and lowercase commands, why not add a capitalization one (one that capitalizes the string as if it were a sentence and maybe also capitalizes proper nouns that it can identify).

  9. Add a command to count how many instances of a string are in another.

  10. Add a length command to get the length of a string.

  11. Add a terminate/break command.

  12. Add an equivalent of Python's ord and chr functions.

  13. Add a split at numerical value command (splits at a certain length), and add an alternative to that which splits at every multiple of the numerical value (e.g. for a string of length 10 at 3,6,9 if given the argument 3).

  14. Add a duplication command (akin to Python's "String"*x)

You'll notice that some of these involve numbers -- I think that even for String challenges having a way of working with numbers is good. Perhaps have a stack for storing numbers that is accessed when certain commands are used (e.g. the length command pushes the length onto the number stack and then the split at numerical value uses this length to split the stack).

I'll add more ideas as I think of them, but I feel like my suggestions are pushing this in the direction of a more general-purpose golf language. Hopefully this input helps regardless of whether you use it or not.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.