Double Quotes For Name Property

Authoring Inform 6
1

Silly question here perhaps but I’m re-investigating Inform 6 and reacquainting myself with it. I created an object like this from the IBG:

Object bird "baby bird" forest
with
  name "baby" "bird" "nestling",
  description "Too young to fly, the nestling tweets helplessly."
;

I belatedly realized that I used double-quotes for the name property as opposed to single quotes. This does, however, work.

Is there harm in doing this? The DM4 says:

What’s not clear is why the attempt is specifically made to stick to single quotes. Is that just to make things distinct? Or is there a reason beyond that for doing so? Is the “single worst-designed bit” because there is no real distinction between single and double quotes? Or because there is a distinction but it’s not clear when and where it applies?

1 Like
2

To the best of my knowledge, single quotes are dictionary words, whereas double quotes are strings. These would normally be stored in different places. For the name property, I suspect that the compiler probably transforms the latter into the former. @zarf will know.

3

On this same theme, the IBG shows having to do this:

name 'bird^s'

The text explaining this says:

But given what the DM4, it’s not clear why we don’t just do:

name "bird's"

To be sure, the compiler does give a warning when you do this:

Obsolete usage: use the ^ character for the apostrophe in "bird's"

But the double-quote approach seems so much simpler to introduce to people than introducing the ^ – which is already used to indicate new line – as now being a way to replace a character, but only in single quoted strings. Actually, that last part isn’t even entirely true. You can do this:

name "bird^s"

Note: double-quotes but with the ^ character. That compiles without warning.

It is interesting that it’s called “obsolete usage”, which seems to imply the double-quoted approach came first perhaps.

One of the things I always had trouble with in teaching TADS 3 was people getting hung up on the difference between value strings (single quotes) and what it calls self-printing strings (double quotes). This is particularly true when they came from most other languages where the quote style doesn’t matter unless you are using quotes within quotes.

1 Like
4

This makes sense, because you should be using single quotes for dictionary words and you can’t have a new line in a dictionary word, as that wouldn’t make sense.

The other exceptions are 'birds//p' (to indicate that birds can be referred to as plural) and 'b//' to escape a single character word so that it is not seen as a character constant.

The '//p' usage is actually very clever. Imagine you have two birds, a 'cockatoo' and a 'galah'. If you use 'birds//p' for the name property for both objects, then you can say GET BIRDS to get both birds at the same time.

5

Yep, I get some of the rationale. But that still leads me back to the DM4 that I quoted:

What I’m trying to figure out is if there’s a necessity to use single quotes. For example, you can do this:

name "birds//p",

And it works just fine to do “TAKE BIRDS” and get both birds. Note I’m not using single quotes.

6

Dictionary words can be specified in the name property, in any other property, in arrays, as a value for a variable, in code etc. In one of these cases (the name property) you can use double quotes, and the compiler will essentially change them to single quotes for you. In all the other cases, you have to use single quotes.

E.g.

Array my_funny_data --> 
  'hello' "Well hello to you, Sir!"
  'goodbye' "Goodbye indeed!";

There is no way the compiler could guess what should be considered as dictionary words here and what should be considered strings, if you didn’t have different notations for them.

I consider the option to use double quotes in the name property a mistake in the design of the Inform language. In example code and documentation for PunyInform, we never use or mention this option. Developers are better off getting used to always using single quotes for dictionary words.

3 Likes
7

A quick test shows that changing name 'carpet' to name "carpet" results in a compiled game which is byte for byte identical (cmp game1.z5 game2.z5). I think that the compiler is silently adjusting it to which ever way is correct.

1 Like
8

Irrespective of whether the compiler allows it (which I suspect is for backward compatibility with some ancient version of Inform prior to Inform 6), you should always use single quotes, especially in an educational setting, where you should be teaching best practice.

Double quotes also allows multiple words separated by spaces, which is wrong. If you do this with single quotes, I think the compiler gives a warning or error.

9

Yes … but why is it a best practice? That’s what unclear. (And people in my classes are like me: skeptical by nature of claims. They want to know why something must be the case, particularly if it’s another bit to learn.) This is even more so since the canonical manual says it only “tries” to be consistent but that the strings can be used interchangeably.

I do see what you’re saying about the double quotes and spaces. For example, you can do this:

name "nest twigs"

The compiler doesn’t complain. But it doesn’t work as you expect. Then again, this compiles without warning as well:

name 'nest twigs'

So you could make the same mistake with both and not know it.

Yeah, that’s interesting. And in that example, what might you be doing with that array that requires the distinction? For example, why might I have an array that stores dictionary words and regular strings? (These are the kinds of questions my classes ask if I give examples like this.)

10

The PunyInform extension for cheap scenery uses this, for example. E.g. (PunyInform/howto/cheapscenerydemo.inf at master · johanberntsson/PunyInform · GitHub). Here, it’s used to say "if the player types EXAMINE SHELVES, print the string “They’re full of books.” as a reply.

11

Two more cases where you need to write dictionary words in single quotes, which authors aren’t unlikely to encounter:

A: Writing a parse_name function.

B: Using a class which requires dictionary words to be put in properties other than name, e.g. (https://github.com/johanberntsson/PunyInform/blob/master/howto/adjectives.inf#L85)

12

Got it. This is great stuff. Thank you!

1 Like
13

On a side note, while dictionary words and strings are enitrely different entities, stored in different parts of memory in the Z-machine, a value may be both a valid dictionary word and a valid string address, so an application where you store both dictionary words and strings in the same array requires strict rules as to what kind of value can be expected in each position. Lots of fun :slight_smile:

14

It’s a relic of a very, very old predecessor of Inform, where the single-quotes-for-dictionary-words syntax wasn’t yet established and the “name” property was the one place you would be writing dictionary words amidst normal code (as opposed to grammar lines). It’s persisted for compatibility reasons, but you can’t use this syntax anywhere except in a “name” property. Which means, even if you’re using a different property (not called “name”) to do exactly the same thing—maybe you switch from looking at “name” to looking at “alt_name” when you pass an object through the transforming machine—suddenly double-quotes mean strings instead of dictionary words and everything crashes and burns.

It should have been removed from the language ages ago, but I6 is a series of iterative improvements on what was originally a very simple assembler, so it has a lot of hacks and quirks in its syntax that it wouldn’t have if it were redesigned today.

So why is it best practice to avoid it? Because it’s a very narrow exception, and as soon as you try to use it anywhere outside this one specific circumstance, you’ll have learned a bad habit that won’t work any more.

3 Likes
15

Got it. That’s perfect framing right there. Much thanks!

1 Like
16

The question has been well answered now, but I’ll add a few footnotes.

I will quibble about this point. One of the goals of I6 is to keep compiling very old I6 source code.

Perhaps double-quotes in a name property should generate a warning, but I’m not sure it would benefit more people than it would annoy at this point.

Inside a name property, double quotes are treated exactly as single quotes. So name "that^s" gives you an apostrophe. name "x y" gives you a dict word with a space in it. (There’s no warning for this, sorry.)

Actually, now that I look, there’s one funny exception to the exception: name "x" gives you a one-letter dict word. To do this with single quotes, you need the unintuitive notation name 'x//'. In some sense double quotes are easier for this one case, but I don’t recommend that anybody remember that information.

6 Likes
17

Little point to that, I think, unless it were genuinely going to be removed from the language at some future date, which seems unlikely now.

Part of the issue I think is that the canonical documentation has not moved beyond the last version of DM4, which still highlights the possibility of using double quotes. If that possibility had been quietly dropped from DM4, by now few people would probably realise that it existed.

I will note that in order to maintain backward compatibility of evolving syntaxes it’s not unusual for deprecated usages to persist in the compiler/interpreter beyond their useful lifespan for new code, but at the same time to be quietly dropped from documentation to avoid pointless confusion to new users.

One can see an obliquely similar thing in human languages. In English for example the words ‘thou’ and ‘thee’ and ‘thy’ are widely understood, and required for reading some archaic writings, but form no part of modern English idiom and their existence is unlikely to be highlighted as part of a modern ‘English as a foreign language’ course.

1 Like