This sounds good to me.

I think I like ?"literal" best. Its short, and although every option has
the potential to be confusing, I feel like that is the least confusing. If
some day years from now I am helping somebody debug a script that mixes
old-style plotstrings and plotstring literals with new real strings and
string expansion codes, I feel like ?"" will be easier to tell apart at a
glance from $"" than the other options thus far.

On Fri, Mar 2, 2018 at 6:28 PM, Ralph Versteegen <> wrote:

> ==Informationless introduction==
> Currently, the animation system uses strings for animation and variant
> names, and I'm thinking of using names for other things as well:  handle
> points ("hand", "handle", "stand") and sequence points ("attack", "hit").
> I'm not 100% decided, but I think it would probably be best to use strings
> in scripts as well rather than ID numbers (like slice lookup codes) since
> that requires name editors, new lumps, enums for special names, id->string
> tables for those enums, plotscr.hsd constants, hsi export code, and maybe
> another script like misc/ to keep it all in sync. Which is a
> lot more complexity than just using strings!
> So you would write something like
>   play animation(sl, $0="walk")
> Also, I was looking through my code for Carcere Vicis, which uses a
> preprocessor to spit out HamsterSpeak code, which let me write stuff like:
>    say($"as you drink the", item, $"your whole body starts to tingle")
> (This expands to $NS="as you drink the", etc, where NS is a 'new string'
> script)
> Just making it easy to write string constants solves one of the biggest
> problem with plotstrings.
> ==Proposals==
> I think we should add special syntax which is like $...="..." but doesn't
> require manually specifying a string ID:
> -it returns the ID number for a special immutable string, which can be
> passed to other string commands
> -the engine assigns a string ID >= 100, so that it doesn't clash with
> manually allocated string IDs. It searches existing strings >= 100 for one
> with the desired value, and otherwise increases the number of strings,
> creating a new one. Strings are not garbage collected. No GC is not a
> problem, because you can't create more strings than exist in your script
> source code
> -the string can't be modified, as that would break other uses of the same
> ID. Passing to any script command doing so is an error.
> -strings >= 100 are saved in saves, just like other strings
> -the actual ID assigned to a particular string constant varies between
> different plays, but you will never hardcode an ID >= 100 into your scripts
> -maybe it shouldn't be displayable with showstringat, etc. This isn't
> necessary, but the intention is to use these as literals, not full-blown
> plotstrings. Maybe we should just allow all that, though?
> Call these plotstring literals. This is a temporary solution until we have
> real string literals; they will become obsolete.
> Therefore we can't just use "..." syntax; they're very different.
> As I mentioned before, I want to have a way to expand embed codes in
> strings immediately, and allow you to use names of local variables too. The
> syntax I'm leaning towards is to prefix the string with $, like
>   msg := $"${hp}"
> It's not the easiest to type, but the relationship to $-prefixed embed
> codes seems good. But there are many other options, like python 3's
> f"${hp}". Any other suggestions?
> If we're using $"..." for that, then it can't be used for plotstring
> literals.
> We could use something like $="..." or $?"..." or $$"..." to indicate the
> similarity to $...="...". But the close similarity of these to $"..." seems
> confusing.
> So maybe something different, like ?"...".
> Also, we should add $== as a shorthand for stringcompare. stringcompare is
> horribly verbose.
> Also, if hspeak sees you write something like
>   if(str == $?="")
> then it can throw an error and tell you to use $== instead. Note that
> comparing two plotstring literals with == will work, but comparing a
> plotscripting literal to a mutable plotstring won't!
> _______________________________________________
> Ohrrpgce mailing list
Ohrrpgce mailing list

Reply via email to