Change to handling of datamaps in Harlowe?

oakandsage

The following code:

(set: $char to (datamap: "Cute", 4, "Wit", 7))
(print: $char's Wit)
$char's Wit

used to print:
[quote]7
7

Now it prints:

[quote]7
's Wit

Is this intentional?

tlm

I would assume so. The reason is that when you don't use print, it tries to print just $char and not the whole expression. However, $char isn't exactly something that can be printed in the first place, so you end up with an empty space instead.

oakandsage

What's odd is that it did handle "'s" outside print statements in an earlier build, allowing for odd statements like

$character's name's brother's name is $character's brother's name

which was either terrifying or awesome or both. Just wondering whether this is a deliberate move towards enforcing more readable syntax or accidental.

I suppose the print-required syntax for the above would be

(print: $character's name)'s brother's name is (print: $character's brother's name)

which does seem more readable to me.

L

It was previously deliberate, but I made that decision during development when it still used the JS dot-property notation. After release I decided that since it was unpleasantly unexpected to have, say, "$variable's on the run" in passage prose be treated as a property access, it shouldn't be usable in that context.

(Having $variable be treated specially in passage prose is kind of a dice-game with legibility in itself, based entirely on the understanding that the $ sigil opens a variable name and a non-letter-non-numeric character terminates it.)

oakandsage

Right yes. It makes sense to me. I feel like (while it is somewhat of a dice-game) people are reasonably used to mentioning $variables in text. I agree that $variable's a bit tricky.

It would possibly be nice to have a shorter, documented* equivalent of (print:) so that, as in Twine 1, one could mention <<$variable>>s in words quickly, and (print:$variable's property) without being so verbose ( and imperative ) ... that's not high priority though. Mostly I just wanted to know how I should be planning to write things from now on.

(* I say 'documented' because at one point, [single brackets] without a <hook tag| seemed to force evaluation, but it wasn't entirely reliable and I'm pretty sure I was a terrible person for trying to take advantage of it)

greyelf

oakandsage wrote:

as in Twine 1, one could mention <<$variable>>s in words quickly

Technically <<$variable>> was/is the short form of the <<display "passage_name">> macro and not the <<print>> macro, it just happened that if <<$variable>> failed to find the passage it was asked to display then it evaluated/printed out the value of whatever was passed to the macro.

It has been pointed out that I was incorrect.

oakandsage

Ermmm. Yes, thanks.
(I actually didn't know that. I thought I had to type out 'display' in twine1. *facepalm*)

TheMadExile

greyelf wrote:

Technically <<$variable>> was/is the short form of the <<display "passage_name">> macro and not the <<print>> macro, it just happened that if <<$variable>> failed to find the passage it was asked to display then it evaluated/printed out the value of whatever was passed to the macro.

That has never been true (even from the first commit).  The <<$variable>> shorthand form never checks the $variable's value against passage names (the macro processor never looks up the value, period).  The order of operations is:
[list type=decimal]
If the first word of the macro invocation is a valid macro name, then the macro is invoked.
Else if the first character is a dollar sign '$', then it's assumed you're trying to print a $variable and <<print>> is invoked.
Else if the first word is a valid passage name, then it's assumed you're trying to display a passage and <<display>> is invoked.
Else, then an error is rendered for the user.