Q. About String Attributes Uses and Abuses

[tajmone]

@thoni56,

I wanted to ask you some advice regarding the use of string attributes in the Italian StdLib translation.

The Alan Manual mentions in Ch.3, under Numeric and String Attributes:

Note that string type attributes are mainly intended for saving string parameters from the player input, like in:

> scribble "Kilroy was here" on the wall

They are not intended for storing long strings of descriptions, especially not as attributes to classes, as they (in the current implementation) require memory and take time to initialise when starting the game.

Yet, the StdLib makes ample use of string attributes (defined on the mygame location) to store verb responses shared across multiple verbs.

I personally find this approach quite useful, and I've take this approach a step further. Not only I've defined as string attributes any message that appears in more than one verb, but also useful snippets which are recurrent in various messages.

The obvious advantage of this approach is that it allows to change a single string attribute in order to tweak the same message in every verb. Another advantage could be less memory consumption. But after having read the above statement, I'm now in doubt ...

What would be a good rule of thumb regarding such a use of string attributes?

• If a rather long sentence is shared across multiple verbs (e.g. appears 4 or 6 times), is it worth it?
• If a short snippet recurs in many places (dozens or more), is it justified to store it as a string attribute?
• Does the above quote from the Manual still apply to present day computers, which are faster and have larger memory?
• What would be the criteria to decide when to use a string attribute in a verb body, and when to use a plain string instead?

Since I'm about to go over the final revision of the Alan Italian module that deals with verb messages stored as string attributes, I'd really benefit from your advice on this. Maybe it's also worth expanding on this in the Alan Manual as well.

Thanks!

[thoni56]

Yes, perhaps a "modern" touch-up is required here. It is still true that long strings "constants" take up memory. More memory than if they were normal strings, since those are kept in the game file and loaded when needed.

This is probably not a problem today. Each character in a string takes just one byte, so even if you would put all the strings in a game in memory that would not cause a problem for todays computers. Unless you define a huge string on some base class, because each attribute is copied into all instances of all subclasses. This is also done at the start of the game, which will take time (again, probably not noticeable with most computers today). This could be avoided by the introduction of some "static" attribute mechanism, but I feel that is just to much trouble and complicating the language, adding to the number of concepts an author would need to understand.

Finally, as the manual states, string attributes was intended for putting smaller strings, primarily from user inputs, to "remember" such things.

With the example from the libraries neither storage or initialization time is an issue since the string attributes are AFAIK on a dedicated instance that does not spawn a lot of sub-classes and instances there of.

With all this I think a update of the manual is warranted. But I think it should still indicate what happens with string attributes (actually all attributes) when intialising and modifying them. So the "tone" of caution could be moderated and the text be made more explanatory of the mechanisms.

[tajmone]

Thanks for the in-depth explanation Thoni! It was really useful for my Library work.

I've opened an issue on the Alan Docs project for this: alan-if/alan-docs#56.

More memory than if they were normal strings, since those are kept in the game file and loaded when needed.

Interesting. You've anticipated a question I was about to ask you, for when studying the ARun sources I've noticed that in various places strings are loaded from the story file, which kind of puzzled me and I wasn't sure if I was understanding the code correctly (i.e. if this was a once only operation, with strings being memoized, or if they get read from disk every time).

I guess that modern OSs are going to do a lot of paging/caching optimizations here, and I wouldn't be surprised if a medium-sized story file gets entirely stored in memory by the OS, to speed up things, while a game with huge in-memory strings ends up being paged on the disk. In any case, the way OSs handle memory and disk I/O today should abstract away any potential issues with string attributes, in both ways.

Intended Design Use vs Creative Real-Case Usages

Finally, as the manual states, string attributes was intended for putting smaller strings, primarily from user inputs, to "remember" such things.

The more I go through the Manual, the more I realize that it might be a good idea to always emphasize the original design intention behind Alan constructs versus the creative applications you'll find in real-case scenarios — string attributes used as a mean to store library/adventure messages (to avoid repetitions) being an example; usage of Locate inside Verbs or Events being another. This could help the reader draw a line between the safe zone and the grey areas of creative uses.

DRY vs WET Adventures Design

Also, this issue of string attributes for storing recurrent messages brings up the topic of DRY vs WET approach in adventures design — which is actually an interesting topic that might be worth expanding on.

[thoni56]

"intention is king", yes. If we can't convey initial intent, users will look at examples and form their own view of what the "normal" usage is, and that is a slippery slop indeed, it's worse than "requirements creep" because you are unaware that it happens.

[tajmone]

@thoni56, I have a final question regarding string attributes in the Italian language module...

To simplify authors' life, the Italian core module exploits the articolo string attribute of every instance to initialize all their required grammar proprieties (i.g. gender, Definite/Indefinite Article, Pronoun, prepositions, etc.). Basically, an author has only to specify the instance's Italian article and the library will deduce the gender, number, required articles and prepositions in the generated output text.

This approach spare a lot of work to the end user, who has only to worry about passing the article as a string, and let the library to do the rest.

The point is that the articolo string attribute is only used for initialization purposes, which leaves behind a useless string attribute on every single game instance.

I was wondering ... if I were to set the articolo attribute to an empty string after initialization, would that improve a game performance and memory consumption?

How would Alan treat an empty string? Would it be a truly null string? Would it save memory?

Is there a way to undefine completely the articolo attribute after initialization is done with?

[thoni56]

Sorry for a late answer. (I've been swamped with planning and running a three day conference.)

The point is that the articolo string attribute is only used for initialization purposes, which leaves behind a useless string attribute on every single game instance.

That is true.

I was wondering ... if I were to set the articolo attribute to an empty string after initialization, would that improve a game performance and memory consumption?

In this case the memory occupied by the strings would be freed and would not be needed any longer.

String attributes in Alan are dynamic in the sense that they are allocated as needed and returned when overwritten with another value.

How would Alan treat an empty string? Would it be a truly null string? Would it save memory?

So if you set a string attribute to some long string that amount of data would be allocated from dynamic memory. If you overwrite that attribute with a string of zero length that "large" amount would be freed and another data area, actually of size zero, would be allocated instead.

Is there a way to undefine completely the articolo attribute after initialization is done with?

No.

But the demands on a modern computer is actually very small. E.g. assume that we have a constant string of 1000 characters that would be the initialized value:

Every c Isa object
    Has s "a one thousand character long string that I will not type all of.....",
End Every.

The i Isa c
End The i.

In this case there will be one instance of that attribute, resulting in a demand of 1000 bytes. If you have a tree of classes and instances of that you would still have to have a 1000 instances to get to 1Megabyte, which today is very small. At the time of Alan's birth we had computer that ran MS-DOS and CP/M with a limitation of 640kb ("Who would ever need more that 640kb of memory!?!?"), so then this was an issue.

We should probably tone this down in the manual in favour of describing the mechanism for dynamics strings, like I described above. Then an author could make an informed decision if this would be an issue. And it probably never will, not until Alan gets a feature of dynamically creating instances...

[tajmone]

Thanks Thoni, your answer was very helpful.

I'll share a few random thoughts on this, as a kind of brainstorming (never know what might come out of it)....

I'm tempted to tweak the Italian core module to set to a null string the articolo attribute of every instance, although this won't be freeing any significant amount of bytes (not even in huge games) for articles have a length of just two characters.

Still, it would be an optimization from the debugging point of view, for it would remove lot's of useless clutter, even if the empy attribute would still be there.

On the other hand, I have to consider if there might be cases where an author might still wish the original articolo attribute to be available either at initialization time (for some custom initializations outside the core module) or even at run-time (for some unforseen usage). In theory, this shouldn't be necessary, for in any case the article could be deduced from other string attributes or proprerties which are set during initialization.

Probably the best thing would be to devise an alternative setup mechanism which doesn't rely on an attribute string for laying down the article. I did try alternative routes but couldn't come up with any better alternative — the articolo approach is, after all, very easy to use for authors, and very close to natural language usage too.

Most IF libraries rely on bitwise operations to handle GNA, but since Alan doesn't provide bit operator and flags I'd have to emulate that in the initialization code via integers math — which itself is not a problem, as long as its usage is goin to look elegant.

The only other approach that comes to my mind is using reference attributes pointing to some hidden instance — but then, it would ultimately consume the same memory of a null string pointer, if I decide to erase the articolo string after initialization; so there won't be any memory gain. Probably this holds true for any kind of attribute.

I think that the current solution is a good balance and compromise between ease of use and resources consumption (and it's been tested thoroughly enough).

Maybe the wisest thing to do would be to just "recycle" the articolo attributes after initialization, and use them to store some library internals (temporary strings, etc.). After all, why not? They are already in place, so they might as well be exploited.