Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

String Manipulation [Feature Request: Harlowe]

I've got an event during my game where the player may learn the gender of another character or continue describing them as an object (reinforcing the sense of inhumanity):
(set: $she to "it")(set: $her to "its")(set: $hers to "its")(set: $She to "It")(set: $Her to "Its")(set: $Hers to "Its")
I feel like this is going to come up a lot. As you set strings you want them to be modified based on the context of where they are in the sentence.

If I could convert a string to lowercase then perhaps that's one way. Or if I could capitalise the first letter easily - that would be more ideal.

If there's a way to already do this that I've missed, that would be great. Or perhaps it could be a feature request as I have a basic workaround already, but some more tools for common occurences like this would be really helpful.


  • Leon has stated that he does not endorse using Javascript-style function calls in Harlowe expressions.

    That being said it is possible to use javascript's built-in String object methods to change the case of text:

    (set: $var1 to "BOB WAS HERE".toLowerCase())
    (set: $var2 to "FRED WAS HERE")

    (print: $var2.toLowerCase())
  • greyelf wrote:

    Leon has stated that he does not endorse using Javascript-style function calls in Harlowe expressions.
    Let me clarify: I don't endorse them as a permanent solution, but for the purposes of filling holes in the API between versions, it's a reasonable thing to do.

    Also I must add that their allowance in current Harlowe is solely due to these syntax structures going unused in the interpreter, so it's possible (but not currently anticipated) that JS property-access and JS function call shaped syntax could be used for something else in some future version.


    WRT basic data manip functions: Harlowe is not naturally an OO language. I decided that from a beginner's perspective, it was confusing having to deal with the subject of a function sometimes being inside the parameters (such as either(str, str2) ) and sometimes being outside (such as str.slice(2)). So, all of the macros are in the same namespace. This means, though, that I have to be especially careful about naming them: (replace:), for instance, is a macro that applies solely to hooks, and as such can't be used for a string value manipulation macro. (I'm not particularly keen on that name in particular, but reasoned that it'd be more common for most users than programmatic string manipulation would be.)

    So, that's one of the things I have to concern myself with. The other thing is making sure I'm designing these macros in the most usable way - is (rewrite: $str, (a:"he", "his", "him"), (a:"they", "their", "them")) good? What if I someday add leftward currying/partials, though - wouldn't (rewrite: "from", "to", $str) be better, insofar as the replacement can then be curried/saved using (set: $theyPronouns to (rewrite: (a:"he", "his", "him"), (a:"they", "their", "them"))) and used by e.g. ($theyPronouns: "He packed his bags")? (This is just an example - I almost certainly won't add currying in that manner because it would eliminate the error messages for missing arguments.) While I could grant myself a lot of latitude in making breaking changes to the API, I want to avoid having to walk back deployed designs as much as possible.

    I understand the necessity of getting these basic utilities out, and you might think the few things I've added already, such as (count:) and (substring:) have already set the template for such macros, but nevertheless I'm still being cautious about adding them without thorough contemplation.
  • I understand that creating a DSL is not an easy and straight forward thing as I have on occasion has to so myself using Ruby, Python, and (in the bad old days) Clipper's pre-processor.

    I admire the effort your putting into getting it right and my only advice is to let languages that came before yours help guide you as yours is not the first to be designed with non-programmers in mind.
Sign In or Register to comment.