[Ohrrpgce] Improvement to plotstrings

[James Paige]

Fair enough :)

?"goes to take a nap"

On Saturday, March 3, 2018, Ralph Versteegen <teeemcee at gmail.com> wrote:

> On further thought, it just seems best to use $"..." for this, because $
> is used for everything else involving plotstring IDs, including $=, $+,
> $==, which is already perfectly consistent. And I should instead pick a
> different syntax for expanding embed codes, since that has nothing to do
> with plotstring IDs. We can decide that later, but we have no shortage of
> options for it.
>
> On 4 March 2018 at 07:52, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> I kinda like ?"" because it is inexplicable ;)
>>
>> But I am also quite happy with @""
>>
>>
>>
>> On Sat, Mar 3, 2018 at 3:50 AM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 4 March 2018 at 00:49, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> 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)
>>>>
>>> Err, actually if you use it on a subscript you get a closure, not a
>>> constant.
>>>
>>>
>>>> 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-motherh
>>>>>> amster.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20180303/8b33c73e/attachment.html>