Fair enough :) ?"goes to take a nap"
On Saturday, March 3, 2018, Ralph Versteegen <teeem...@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 <b...@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 <teeem...@gmail.com> >> wrote: >> >>> >>> >>> On 4 March 2018 at 00:49, Ralph Versteegen <teeem...@gmail.com> wrote: >>> >>>> >>>> >>>> On 3 March 2018 at 17:07, James Paige <b...@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 <teeem...@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@lists.motherhamster.org >>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh >>>>>> amster.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ohrrpgce mailing list >>>>> ohrrpgce@lists.motherhamster.org >>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >>> >> >> _______________________________________________ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> >> >
_______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org