<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 March 2018 at 00:49, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 3 March 2018 at 17:07, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>This sounds good to me.<br><br></div>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.<br></div></div></blockquote><div><br></div></span><div>But the use of ? is inexplicable.<br></div><div>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:<br></div><div>  subscript, squareof, x (...)<br></div><div>  func := @squareof<br></div><div>  show value(func(10))<br></div><div>However, @globalname would still return an ID, and in all three cases @ is returning a handle (to a constant object, even)</div></div></div></div></blockquote><div>Err, actually if you use it on a subscript you get a closure, not a constant.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 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.<br><br></div><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-3515908767570714973m_-5820090996383556705h5">On Fri, Mar 2, 2018 at 6:28 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-3515908767570714973m_-5820090996383556705h5"><div dir="ltr"><br>==Informationless introduction==<br><br>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").<br>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!<br><br>So you would write something like<br>  play animation(sl, $0="walk")<br><br>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:<br>   say($"as you drink the", item, $"your whole body starts to tingle")<br>(This expands to $NS="as you drink the", etc, where NS is a 'new string' script)<br>Just making it easy to write string constants solves one of the biggest problem with plotstrings.<br><br>==Proposals==<br><br>I think we should add special syntax which is like $...="..." but doesn't require manually specifying a string ID:<br>-it returns the ID number for a special immutable string, which can be passed to other string commands<br>-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<br>-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.<br>-strings >= 100 are saved in saves, just like other strings<br>-the actual ID assigned to a particular string constant varies between different plays, but you will never hardcode an ID >= 100 into your scripts<br>-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?<br><br>Call these plotstring literals. This is a temporary solution until we have real string literals; they will become obsolete.<br>Therefore we can't just use "..." syntax; they're very different.<br><br>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<br>  msg := $"${hp}"<br>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?<br><br>If we're using $"..." for that, then it can't be used for plotstring literals.<br><br>We could use something like $="..." or $?"..." or $$"..." to indicate the similarity to $...="...". But the close similarity of these to $"..." seems confusing.<br>So maybe something different, like ?"...".<br><br>Also, we should add $== as a shorthand for stringcompare. stringcompare is horribly verbose.<br>Also, if hspeak sees you write something like<br>  if(str == $?="")<br>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!<br><br></div>
<br></div></div>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>