Author Topic: Strings: {} vs "", and underscores  (Read 289 times)

0 Members and 1 Guest are viewing this topic.

Offline ZvikaZ

Strings: {} vs "", and underscores
« on: July 20, 2020, 11:21:50 AM »
1.
In SCICompanion, is there any difference between {} and "" as strings delimiter?
Will they be compiled to the same thing?

2.
What do underscores mean?
For example, after dying, the possibilities are:
Code: [Select]
{Restore}, {Restart} and {____Quit____}



Offline MusicallyInspired

Re: Strings: {} vs "", and underscores
« Reply #1 on: July 20, 2020, 03:09:50 PM »
I believe underscores are just empty character spaces to center the text.
Brass Lantern Prop Competition

Offline OmerMor

Re: Strings: {} vs "", and underscores
« Reply #2 on: July 20, 2020, 04:01:54 PM »
1.
In SCICompanion, is there any difference between {} and "" as strings delimiter?
Will they be compiled to the same thing?

2.
What do underscores mean?
For example, after dying, the possibilities are:
Code: [Select]
{Restore}, {Restart} and {____Quit____}

See here:
http://scicompanion.com/Documentation/Compiler/strings.html

Quote
Currently brace and double-quote strings can be used interchangeably.
Quote
All whitespace between words in a string will be converted into a single space character. If you need to have multiple spaces between words, you can use the underscore character.






Offline Kawa

Re: Strings: {} vs "", and underscores
« Reply #3 on: July 21, 2020, 05:17:02 AM »
Underscores are indeed used as spaces that don't whitespace fold. It's like HTML, really, with _ as  

Historically the difference between {} and "" was that {} would be kept as literal strings in the script resource, and "" would be automagically stored in a text resource and replaced with a tuple. Of course, they stopped using text resources as much when messages were introduced, and later versions of the Sierra compiler did not do the text resource thing, much like SCI Companion.

Practical example:
Code: [Select]
;LSL3 Decompilation
(proc255_4 210 0
(if (proc0_23 3)
{ Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.}
else
{}
)
)

;Original source
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s"
(if (InRoom iWood)
{ Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.}
else
{}
)
)
Where text.210 line #0 is what was originally the "" string.

Offline ZvikaZ

Re: Strings: {} vs "", and underscores
« Reply #4 on: July 21, 2020, 05:32:19 AM »
Underscores are indeed used as spaces that don't whitespace fold. It's like HTML, really, with _ as  

Historically the difference between {} and "" was that {} would be kept as literal strings in the script resource, and "" would be automagically stored in a text resource and replaced with a tuple. Of course, they stopped using text resources as much when messages were introduced, and later versions of the Sierra compiler did not do the text resource thing, much like SCI Companion.

Practical example:
Code: [Select]
;LSL3 Decompilation
(proc255_4 210 0
(if (proc0_23 3)
{ Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.}
else
{}
)
)

;Original source
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s"
(if (InRoom iWood)
{ Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.}
else
{}
)
)
Where text.210 line #0 is what was originally the "" string.

Interesting.
I wander, what was their motivation to have the first string as 'text' resource, and the second string as internal string in the script file.
Any ideas?

Offline Kawa

Re: Strings: {} vs "", and underscores
« Reply #5 on: July 21, 2020, 06:36:40 AM »
Naively, you can't have text resource tuples as a format string parameter.

I don't know about SCI0, which Larry 3 used, but I can confirm that SCI11 can in fact handle them. But unfortunately in this case the if else ruins it.

Y'see, in the Larry 3 code above, it directly returns either a description of the piece of wood or a blank string, right? Those are a single 16-bit pointer to some text, each. If the wood is there, we pass the one value on to Printf. If it's not there, we pass the other. Tuples are two values, which can't be returned like that.

The solution that comes to mind, if SCI0's Format kernel call is also able to do so, is to rewrite it like this:
Code: [Select]
(if (InRoom iWood)
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s" " Beneath its outstretched boughs lies a beautiful piece of wood, probably cut by a native then forgotten.")
else
(Printf "The granadilla is short and graceful, with a gray trunk, and delicately spreading branches.%s" {})
)
Or in tuples:
Code: [Select]
(if (InRoom iWood)
(Printf 210 0 210 1) ;or whatever number it'd assign to the wood part.
else
(Printf 210 0 {}) ;empty string is actually shorter than a text resource tuple here.
)

If I remember correctly, SC would notice the second line is identical to the first and reuse the 210-0 tuple.

Offline lskovlun

Re: Strings: {} vs "", and underscores
« Reply #6 on: July 21, 2020, 06:39:09 AM »
It must be, because a reference to a text resource is a pair of values, whereas an S-expression (that what such an expression is called in LISP) resolves to a single value, a pointer in this case (yes, there are complications to that rule...).

(ninja'd by Kawa)

Offline Kawa

Re: Strings: {} vs "", and underscores
« Reply #7 on: July 21, 2020, 08:21:19 AM »
Worse: not only is your post much shorter than mine, but I'd written a completely different long post explaining why SCI has text resources to begin with before I reread the question, scrapped it all, and wrote the above post instead.


SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.121 seconds with 25 queries.