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