[Ohrrpgce] Improvement to plotstrings

[Ralph Versteegen]

On 3 March 2018 at 17:07, James Paige <Bob at hamsterrepublic.com> wrote:

> 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.
>

But the use of ? is inexplicable.
I considered @"literal" earlier and discarded it, but on second thoughts it
could be a good choice. @ produces the ID of a script or global variable,
and here it would be the ID of a string literal. What I didn't like at
first is that I want to extend @scriptname to return a callable function
object, not just a script ID, like so:
  subscript, squareof, x (...)
  func := @squareof
  show value(func(10))
However, @globalname would still return an ID, and in all three cases @ is
returning a handle (to a constant object, even) so I guess it's not a false
commonality. They are three different things, so @ isn't single operator,
but maybe it's better to use the same syntax for similar semantics than
invent a unique syntax in each case.



>
>
> On Fri, Mar 2, 2018 at 6:28 PM, Ralph Versteegen <teeemcee at gmail.com>
> 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/sl_lookup.py 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 at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180304/b0f724fb/attachment.html>