~rabbits/uxn

2 2

String literal trick, & thoughts on string escapes

Kira Oakley <kira@eight45.net>
Details
Message ID
<ZussKhyJ/3VbbI2l@debian>
DKIM signature
pass
Download raw message
Hi fellow Varvarians!

I wanted to share a little trick of mine for inlined string literals,
which I (or someone else) may have already shared here or elsewhere:

    |0100
    PRINT "Hi! 0a 00
    PRINT "How 20 "goes 20 "it? 0a 00
    BRK

    @PRINT ( -- )
      STH2r
      &loop
        LDAk
        DUP ,&print JCN
        POP INC2 STH2 JMP2r
      &print
        EMIT
        INC2
        ,&loop JMP

    @EMIT ( char -- )
      #18 DEO
      JMP2r

I like it for one-off cases, because I can put the string literals where
they are used.


Writing this, I was also thinking about the possibility of escapes for
uxntal string literals. What if one could, instead of

    PRINT "How 20 "goes 20 "it? 0a 00

write

    PRINT "How\ goes\ it?\n\00

?

The idea is adding the escapes "\ ", "\n", and "\xx" to encode spaces,
newlines, and, finally, any byte (hexidecimally).

Devine: I'm also curious if there's a story behind why string literals
aren't C-like, in, i.e. being terminated by a '"'. Was it to simplify
parsing?

Warmth & Hot Tea,

~ Kira
Details
Message ID
<9645185e-3dc7-49ea-8339-ff2f32ab9976@100r.co>
In-Reply-To
<ZussKhyJ/3VbbI2l@debian> (view parent)
DKIM signature
pass
Download raw message
I remember this trick, I had a copy of your technique in my notes, I 
think you might have shared it with me over mastodon, but it's nice that 
there is now a copy here.

Postfix function is breaking my mind haha, I have a real hard time 
parsing this because I've been so neck deep in postfix uxntal.

The reason why we don't have strings proper is only because I didn't 
want to complexify parsing, I considered it for a bit, but the parsing 
technique with uxn is generally about saving a token(a white-space 
terminated string) in memory and figuring out its length and type, there 
are no tokens that are walked-through except for comments, which are 
just not saved at all during parsing.

In some cases where I really didn't want to be bothered to write the 
extra " before a string, which is equivalent to \ before space, I would 
do something like "This_is_a_sentence $1, and strip out the underscore 
during printing/drawing. It works alright, unless you're printing 
something with underscores of course :)

I love seeing you messing around with strings, is this for a specific 
project that you have in mind?

Dll

On 2024-09-18 12:38, Kira Oakley wrote:
> Hi fellow Varvarians!
> 
> I wanted to share a little trick of mine for inlined string literals,
> which I (or someone else) may have already shared here or elsewhere:
> 
>      |0100
>      PRINT "Hi! 0a 00
>      PRINT "How 20 "goes 20 "it? 0a 00
>      BRK
> 
>      @PRINT ( -- )
>        STH2r
>        &loop
>          LDAk
>          DUP ,&print JCN
>          POP INC2 STH2 JMP2r
>        &print
>          EMIT
>          INC2
>          ,&loop JMP
> 
>      @EMIT ( char -- )
>        #18 DEO
>        JMP2r
> 
> I like it for one-off cases, because I can put the string literals where
> they are used.
> 
> 
> Writing this, I was also thinking about the possibility of escapes for
> uxntal string literals. What if one could, instead of
> 
>      PRINT "How 20 "goes 20 "it? 0a 00
> 
> write
> 
>      PRINT "How\ goes\ it?\n\00
> 
> ?
> 
> The idea is adding the escapes "\ ", "\n", and "\xx" to encode spaces,
> newlines, and, finally, any byte (hexidecimally).
> 
> Devine: I'm also curious if there's a story behind why string literals
> aren't C-like, in, i.e. being terminated by a '"'. Was it to simplify
> parsing?
> 
> Warmth & Hot Tea,
> 
> ~ Kira
Kira Oakley <kira@eight45.net>
Details
Message ID
<ZuzW4erDb6LpOSPu@debian>
In-Reply-To
<9645185e-3dc7-49ea-8339-ff2f32ab9976@100r.co> (view parent)
DKIM signature
pass
Download raw message
On 09/19  17:25, Hundred Rabbits wrote:
> Postfix function is breaking my mind haha, I have a real hard time parsing
> this because I've been so neck deep in postfix uxntal.

:)

> The reason why we don't have strings proper is only because I didn't want to
> complexify parsing, I considered it for a bit, but the parsing technique
> with uxn is generally about saving a token(a white-space terminated string)
> in memory and figuring out its length and type, there are no tokens that are
> walked-through except for comments, which are just not saved at all during
> parsing.

That's reasonable! I find it a bit annoying, but not a big deal.

> In some cases where I really didn't want to be bothered to write the extra "
> before a string, which is equivalent to \ before space, I would do something
> like "This_is_a_sentence $1, and strip out the underscore during
> printing/drawing. It works alright, unless you're printing something with
> underscores of course :)

Haha, CURSED. O__O

> I love seeing you messing around with strings, is this for a specific
> project that you have in mind?

Alas, no. I was just playing around for fun, looking at some old uxn
programs of mine, perhaps for a bit of inspiration. Felt in the mood
after reading your recent article, but nothing has struck me yet.

~ Kira
Reply to thread Export thread (mbox)