Porting: Debugging/tracing Prolog and YACC.

[Jacob MacDonald]

I am once again probing for pointers or helpful directions where
porting is concerned. Of course, the trickiest and failiest bits of
the test suite are Prolog and YACC.

My Prolog is returning incorrect results starting with the call.shen
tests. Even a simple use of consit returns not a value but the unbound
variable.

(1-) (prolog? (consit 1 X) (return X))
Var3

"Var3" seems relatively stable as the output of these tests, though I
haven't peeked at a lot of them individually and deleted them to see
the rest of the suite.

The YACC examples use list, mentioned in some of my earlier messages.
I haven't taken a close reading here, but don't immediately grok the
use of curly brackets or (list). I removed all the curlies from
yacc.shen and that let its tests pass, but doing the same thing in
montague.shen throws errors about a missing left curly. I suppose this
is because of (tc +).

In both cases, I'm not sure where to look for current information
besides the source code. I may be missing something low-level like the
arity definitions or working dictionaries of earlier, but I'm less
confident in my ability to follow the flow of Prolog or YACC code.

Thanks,

Jacob.

[Bruno Deferrari]

Curly braces are for declaring function types, and the typechecker uses prolog. So if prolog is broken in any way, the typechecker will be too.

So for now I would ignore anything related to the typechecker and focus on figuring out what is the issue with prolog, if you are able to fix it it is very likely that the typechecker will get fixed too.

--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/CACy6W0DLGhcqpFjX_bCME9fWoskrtXLAw8ECHVqz5vfJLEHYug%40mail.gmail.com.

--

BD

[Bruno Deferrari]

What is the output of this expression?

(let PV (shen.prolog-vector) 

     Var (shen.newpv PV) 

     Bind (shen.bindv Var "hello" PV) 

  (shen.deref Var PV))

--

BD

[Bruno Deferrari]

And this one:

(let PV (shen.prolog-vector)

     Var (shen.newpv PV) 

     Bind (shen.bindv Var "hello" PV) 

  [(shen.pvar? Var) (shen.lazyderef Var PV) (shen.deref Var PV)])

After a quick look I couldn't find anything special in ShenSharp regarding these but just in case.

--

BD

[dr.mt...@gmail.com]

If you've represented the 46 primitives, you shouldn't have this problem.

I suggest you test the basic list and vector processing primitives under F#.  

I recall Greg Spurrier had some sort of standard test suite for 

testing implementations of KL

Mark

[dr.mt...@gmail.com]

Unfortunately AFAIK Greg's suite runs under Ruby (?).

https://github.com/gregspurrier/klasc/tree/master/spec

We could actually do with a standard set of tests for people to

test their KL primitives.

There is a standard test suite in my Shen download in the 

folder Test Programs (cd to it and type (load "runme.shen")).

You should find your percentage score on that. 100% indicates

a clean implementation.

Mark

[Jacob MacDonald]

Dr. Mark Tarver wrote:
> There is a standard test suite in my Shen download in the
> folder Test Programs (cd to it and type (load "runme.shen")).

That's the test suite I'm seeing the failure in (well, the version
from GitHub, but it seems to be largely the same: contains the same
files).

> You should find your percentage score on that. 100% indicates
> a clean implementation.

The test runner stops when it encounters a failure, so I don't see an
aggregate percentage. Is that itself a regression?

In any case, 25 tests pass before the first call.shen failure and by
mangling the test suite slightly I can get 118 tests to pass.

> We could actually do with a standard set of tests for people to
> test their KL primitives.

The Kl half of ShenSharp has a few tests implemented in F#. I'll
certainly add some regression tests when I figure out the root cause.

> If you've represented the 46 primitives, you shouldn't have this problem.
> I suggest you test the basic list and vector processing primitives under F#.

That's what I figured. I assume there's a subtle bug somewhere;
Yesterday's was because of inconsistent hashing in the dict
implementation, which led to get and put failing for certain symbols.

[dr.mt...@gmail.com]

The test runner stops when it encounters a failure, so I don't see an
aggregate percentage. Is that itself a regression?

In my download on the Shen site - if you have a failure you get

failed; continue? (y/n) y

If you choose y the failure is noted and the tests continue.

At the end you may get

passed ... 133
failed ... 1
pass rate ... 99.25373134328358%

Mark

[Jacob MacDonald]

Bruno Deferrari wrote:

> What is the output of this expression?
>
>
> (let PV (shen.prolog-vector)
>
> Var (shen.newpv PV)
>
> Bind (shen.bindv Var "hello" PV)
>
> (shen.deref Var PV))

"hello"

> And this one:
>
> (let PV (shen.prolog-vector)
>
> Var (shen.newpv PV)
>
> Bind (shen.bindv Var "hello" PV)
>
> [(shen.pvar? Var) (shen.lazyderef Var PV) (shen.deref Var PV)])

[true "hello" "hello"]

Those look rather expected, no?

Is there a way to see the decomposition of prolog? forms into
something like this? Do the symbolic representations live in
*property-vector* like they do for interpreted functions? I noticed
that and the arity of defprolog functions while poking around last
night.

> After a quick look I couldn't find anything special in ShenSharp regarding these but just in case.

Yeah, I'm pretty sure there is no special handling of Prolog forms. My
money's on something in the evaluation model, perhaps ShenSharp's
runtime being too eager in the presence of the S series helpers.

> Curly braces are for declaring function types, and the typechecker uses prolog. So if prolog is broken in any way, the typechecker will be too.
>
> So for now I would ignore anything related to the typechecker and focus on figuring out what is the issue with prolog, if you are able to fix it it is very likely that the typechecker will get fixed too.

That makes sense.

Thanks,

Jacob.

[Jacob MacDonald]

Dr. Mark Tarver wrote:
> In my download on the Shen site - if you have a failure you get
>
> failed; continue? (y/n) y
>
> If you choose y the failure is noted and the tests continue.

True true. I had forgotten that the ShenSharp test runner overrides
y-or-n? with a function that exits. Without that, the results:

passed ... 122
failed ... 12
pass rate ... 91.0447761194029851%

ok
0

run time: 41.0406789 secs

[Bruno Deferrari]

On Tue, May 14, 2024 at 8:10 PM Jacob MacDonald <jacc...@gmail.com> wrote:

Bruno Deferrari wrote:

> What is the output of this expression?
>
>
> (let PV (shen.prolog-vector)
>
>      Var (shen.newpv PV)
>
>      Bind (shen.bindv Var "hello" PV)
>
>   (shen.deref Var PV))

"hello"

> And this one:
>
> (let PV (shen.prolog-vector)
>
>      Var (shen.newpv PV)
>
>      Bind (shen.bindv Var "hello" PV)
>
>   [(shen.pvar? Var) (shen.lazyderef Var PV) (shen.deref Var PV)])

[true "hello" "hello"]

Those look rather expected, no?

Yes, exactly what it should be.

 

Is there a way to see the decomposition of prolog? forms into
something like this?

Like for any other function that you define, for (defprolog some-name ...), you can do (ps some-name) to get the resulting KLambda code:

Shen, www.shenlanguage.org, copyright (C) 2010-2023, Mark Tarver

version: S38.3, language: Scheme, platform: chez-scheme 10.0.0

port 0.35, ported by Bruno Deferrari

(0-) (defprolog consit

  X [1 X] <--;)

(fn consit)

(1-) (ps consit)

[defun consit [V22 V23 V24 V25 V26 V27] [if [shen.unlocked? V25] [let W28 [shen.lazyderef V23 V24] [let W29 [lambda Z30 [do [shen.incinfs] [is! V22 Z30 V24 V25 V26 V27]]] [if [cons? W28] [let W31 [shen.lazyderef [hd W28] V24] [let W32 [freeze [let W33 [shen.lazyderef [tl W28] V24] [let W34 [lambda Z35 [W29 Z35]] [if [cons? W33] [let W36 [hd W33] [let W37 [shen.lazyderef [tl W33] V24] [let W38 [freeze [W34 W36]] [if [= W37 []] [thaw W38] [if [shen.pvar? W37] [shen.bind! W37 [] V24 W38] false]]]]] [if [shen.pvar? W33] [let W39 [shen.newpv V24] [shen.gc V24 [shen.bind! W33 [cons W39 []] V24 [freeze [W34 W39]]]]] false]]]]] [if [= W31 1] [thaw W32] [if [shen.pvar? W31] [shen.bind! W31 1 V24 W32] false]]]] [if [shen.pvar? W28] [let W40 [shen.newpv V24] [shen.gc V24 [shen.bind! W28 [cons 1 [cons W40 []]] V24 [freeze [W29 W40]]]]] false]]]] false]]

(2-) ((foreign scm.pretty-print) (ps consit))

(defun

  consit

  (V22 V23 V24 V25 V26 V27)

  (if (shen.unlocked? V25)

      (let W28 (shen.lazyderef V23 V24)

        (let W29 (lambda

                  Z30

                  [do (shen.incinfs) (is! V22 Z30 V24 V25 V26 V27)])

          (if (cons? W28)

              (let W31 (shen.lazyderef [hd W28] V24)

                (let W32 (freeze

                          [let W33

                            (shen.lazyderef (tl W28) V24)

                            (let W34 (lambda Z35 [W29 Z35])

                              (if (cons? W33)

                                  (let W36 (hd W33)

                                    (let W37 (shen.lazyderef [tl W33] V24)

                                      (let W38 (freeze [W34 W36])

                                        (if (= W37 ())

                                            (thaw W38)

                                            (if (shen.pvar? W37)

                                                (shen.bind! W37 () V24 W38)

                                                #f)))))

                                  (if (shen.pvar? W33)

                                      (let W39 (shen.newpv V24)

                                        (shen.gc

                                          V24

                                          (shen.bind!

                                            W33

                                            (cons W39 ())

                                            V24

                                            (freeze (W34 W39)))))

                                      #f)))])

                  (if (= W31 1)

                      (thaw W32)

                      (if (shen.pvar? W31)

                          (shen.bind! W31 1 V24 W32)

                          #f))))

              (if (shen.pvar? W28)

                  (let W40 (shen.newpv V24)

                    (shen.gc

                      V24

                      (shen.bind!

                        W28

                        (cons 1 (cons W40 ()))

                        V24

                        (freeze (W29 W40)))))

                  #f))))

      #f))

 

Do the symbolic representations live in
*property-vector* like they do for interpreted functions? I noticed
that and the arity of defprolog functions while poking around last
night.

There are vectors used by prolog to store the bindings, created internally with (shen.prolog-vector):

(3-) (head (read-from-string "(prolog? (consit 1 X) (return X))"))

[[[[[lambda V41 [lambda L42 [lambda K43 [lambda C44 [let X [shen.newpv V41] [shen.gc V41 [do [shen.incinfs] [consit 1 X V41 L42 K43 [freeze [return X V41 L42 K43 C44]]]]]]]]]] [shen.prolog-vector]] [@v true [@v 0 [vector 0]]]] 0] [freeze true]]

 

> After a quick look I couldn't find anything special in ShenSharp regarding these but just in case.

Yeah, I'm pretty sure there is no special handling of Prolog forms. My
money's on something in the evaluation model, perhaps ShenSharp's
runtime being too eager in the presence of the S series helpers.

> Curly braces are for declaring function types, and the typechecker uses prolog. So if prolog is broken in any way, the typechecker will be too.
>
> So for now I would ignore anything related to the typechecker and focus on figuring out what is the issue with prolog, if you are able to fix it it is very likely that the typechecker will get fixed too.

That makes sense.

Thanks,

Jacob.

--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/CACy6W0DYA%2BcumGfhkrNTTOVQXk_Sh5sfE4SH50AtokivB7%3D%2Bgg%40mail.gmail.com.

--

BD

[Jacob MacDonald]

Thanks much. I get results that look basically the same, which
continues to point to a buggy primitive somewhere. I have a bad
feeling about freeze, but perhaps that's simply because I don't
understand it.

Bruno Deferrari wrote:
> (defun
>
> consit
> ...

[defun consit [V116 V115 V114 V113 V112 V111]
[if [shen.unlocked? V113]
[let W117 [shen.lazyderef V115 V114]
[let W118 [lambda
Z119
[do [shen.incinfs] [is! V116 Z119 V114 V113 V112 V111]]]
[if [cons? W117]
[let W120 [shen.lazyderef [hd W117] V114]
[let W121 [freeze
[let W122
[shen.lazyderef [tl W117] V114]
[let W123 [lambda Z124 [W118 Z124]]
[if [cons? W122]
[let W125 [hd W122]
[let W126
[shen.lazyderef [tl W122] V114]
[let W127
[freeze [W123 W125]]
[if [= W126 []]
[thaw W127]
[if
[shen.pvar? W126]

[shen.bind! W126 [] V114 W127]
false]]]]]
[if [shen.pvar? W122]
[let W128 [shen.newpv V114]
[shen.gc V114
[shen.bind! W122

[cons W128 []]
V114

[freeze [W123 W128]]]]]
false]]]]]
[if [= W120 1]
[thaw W121]
[if [shen.pvar? W120]
[shen.bind! W120 1 V114 W121]
false]]]]
[if [shen.pvar? W117]
[let W129 [shen.newpv V114]
[shen.gc V114
[shen.bind! W117
[cons 1 [cons W129 []]]
V114
[freeze [W118 W129]]]]]
false]]]]
false]]

> (3-) (head (read-from-string "(prolog? (consit 1 X) (return X))"))
>
> [[[[[lambda V41 [lambda L42 [lambda K43 [lambda C44 [let X [shen.newpv V41] [shen.gc V41 [do [shen.incinfs] [consit 1 X V41 L42 K43 [freeze [return X V41 L42 K43 C44]]]]]]]]]] [shen.prolog-vector]] [@v true [@v 0 [vector 0]]]] 0] [freeze true]]

(2-) (head (read-from-string "(prolog? (consit 1 X) (return X))"))
[[[[[lambda V152 [lambda L153 [lambda K154 [lambda C155 [let X
[shen.newpv V152] [shen.gc V152 [do [shen.incinfs] [consit 1 X V152
L153 K154 [freeze [return X V152 L153 K154 C155]]]]]]]]]]

[Jacob MacDonald]

Dr. Mark Tarver wrote:
> https://github.com/gregspurrier/klasc/tree/master/spec

I ran a few of these in the REPL. The only surprise was 0-ary freeze,
but I'm not sure if that is even supported per the spec.

((freeze) 37)

Shen/Scheme: variable freeze is not bound
ShenSharp: Function "freeze" is not defined

[Bruno Deferrari]

freeze is a special form, the way it is used in those tests is not required to work like that in the same way you don't expect ((if) Test Then Else) to be the same as (if Test Then Else).

--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/CACy6W0AQzFKAwvb_TNzLzD_qppO8StNAJ4UfVtbakF80M1vgug%40mail.gmail.com.

--

BD

[Jacob MacDonald]

That read-from-string example was very helpful. I think there is
something wrong with the way ShenSharp is handling nested lambdas,
provided the transformations described below are supposed to be
behavior-preserving.

See https://github.com/rkoeninger/ShenSharp/pull/9#issuecomment-2111427794
for code snippets; I may add more details here when I get back to it.

The short version is that the nested lambda form returns incorrect
values, but turning the expression into a long let or a
multi-parameter function will return the correct value.

So I think the next step is to debug nested lambdas. I suspect that
the problem is on the F# side. As I understand it, S series Shen does
its own transformation of multi-parameter defuns into lambdas. In
Lisps generally there is a correspondence between nested lambdas and
let forms as well, but I'm not sure if that is exactly the case in
Shen. Do I have this roughly correct?

Jacob.

[Jacob MacDonald]

I've found the minimal (I think) bad case. It doesn't seem to have to
do with freeze, just with let inside lambda.

((/. X (let Y 1 (+ X Y))) 1)

That should be 2, but for me it evaluates to 1. It appears that a let
inside a lambda returns the first bound value without evaluating the
body or any further bindings.

[Jacob MacDonald]

I am down to the YACC issues. The yacc.shen tests error with "list"
undefined while montague does with "t" undefined. Based on Bruno's
help with the last issue, I'm taking a look at <ds>, which is part of
a failure but at the bottom of the tree: No need to worry about which
function the error is in.

(22-) (ps <ds>)
[defun <ds> [V207]
[let W208 [if [shen.hds=? V207 d]
[let W209 [tail V207]
[let W210 [<ds> W209]
[if [shen.parse-failure? W210]
[shen.parse-failure]
[let W211 [shen.<-out W210]
[let W212 [shen.in-> W210]
[shen.comb W212
[type [cons d W211]
[list symbol]]]]]]]]
[shen.parse-failure]]
[if [shen.parse-failure? W208]
[let W213 [if [shen.hds=? V207 d]
[let W214 [tail V207]
[shen.comb W214
[type [cons d []] [list symbol]]]]
[shen.parse-failure]]
[if [shen.parse-failure? W213]
[shen.parse-failure]
W213]]
W208]]]

Checking that against the ps output from Shen/Scheme it sure looks
like the same code, but it's getting executed differently.

By adding logging, I can see that the error I'm seeing comes from the
F# evaluator: Walking the AST we get to the type node and try to look
up both operands. (list symbol) looks like another global call and so
the lookup fails and execution stops.

The way ShenSharp currently handles the type primative seems broken.
It merely ignores its second argument, which is not enough to keep the
AST walker from resolving the symbols on that side. Should the right
half or entire type expression simply be removed from the KL AST when
executing?

[Jacob MacDonald]

If that approach is basically correct (I cribbed from
https://github.com/tizoc/shen-scheme/blob/15db77f6d461c03b617b7427581be74e1741b817/src/compiler.shen#L92),
the test suite passes. What would next steps for certification look
like? There are plenty of refactors and optimizations to make, but I'm
pretty pleased with the test suite, want to put the language through
its paces and see what happens.

[dr.mt...@gmail.com]

In the CL port of Shen the backend to

CL simply swaps out type annotations

 Params [type X _]        -> (kl-to-lisp-h Params X)

It is up to you whether you use the type information

to optimise the object code.

Mark

[dr.mt...@gmail.com]

See attached.

[Bruno Deferrari]

Good job on getting it to pass the test suite. Re: optimizations, I looked at the ShenSharp code very superficially the other day, and yes there seems to be a lot of hanging fruit there (check both that compiler.shen file and overrides.shen in the Shen/Scheme sources, you will find a bunch of basic ideas of what you could start with.).

IIRC Robert started with ShenSharp but after he got something working well he switched to working on ShenScript, and he put more time and effort on optimizing that one.

https://github.com/rkoeninger/ShenScript

 

--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/CACy6W0DArbjLVD6kgb8LkH7XL1x1BLDSm2bz%2BJFYqLksgLd%2Bww%40mail.gmail.com.

--

BD

[Jacob MacDonald]

Bruno Deferrari wrote:
> IIRC Robert started with ShenSharp but after he got something working well he switched to working on ShenScript, and he put more time and effort on optimizing that one.

Just to see if I could, I built ShenScript and tried ShenSharp against
its test suite. I'm not sure how to get an optimized JS build -
there's been some dependency rot - but the speed doesn't seem that
different (albeit ShenSharp fails one of the Shen 22.4 suites).

In other non-scientific testing, it seems like ShenSharp in release
mode is about 10-20x slower than the CL port and 40-50x slower than
Shen/Scheme.

A couple years, Robert made a comment about wanting to rewrite
ShenSharp and maybe dropping F# altogether. The approach would be to
generate CIL instead of source code or an interpreter, and that's more
or less what I'd like to start poking at next.

Moving onto the S series kernel was not painful, so I'm curious about
resurrecting some of the other ports: Someone's trying to patch
shen-elisp, and as I made the PR that upgraded that port to Shen 21 I
may poke my head in next. Not a ton of activity on many of the port
repos, sadly.

What would the steps be in certifying ShenSharp and getting it to a
releasable state? I don't want to fully fork just yet because Robert
seems to be active on GitHub, exclusively on private repositories. But
I don't want to cram too much into one Git branch: I already took us
all the way through .NET 6, which has support through the end of this
year. It's easy enough to make self-contained releases, though: I did
so to test out the REPL in release mode, with no .NET installed on my
machine I did all the compilation in Docker.

[Bruno Deferrari]

On Wed, May 15, 2024 at 6:35 PM Jacob MacDonald <jacc...@gmail.com> wrote:

Bruno Deferrari wrote:
> IIRC Robert started with ShenSharp but after he got something working well he switched to working on ShenScript, and he put more time and effort on optimizing that one.

Just to see if I could, I built ShenScript and tried ShenSharp against
its test suite. I'm not sure how to get an optimized JS build -
there's been some dependency rot - but the speed doesn't seem that
different (albeit ShenSharp fails one of the Shen 22.4 suites).

In other non-scientific testing, it seems like ShenSharp in release
mode is about 10-20x slower than the CL port and 40-50x slower than
Shen/Scheme.

A couple years, Robert made a comment about wanting to rewrite
ShenSharp and maybe dropping F# altogether. The approach would be to
generate CIL instead of source code or an interpreter, and that's more
or less what I'd like to start poking at next.

Personally, I think writing the compiler in Shen itself is much easier than writing it in the target language.

Shen/Scheme's compiler was originally implemented in Scheme itself (and targeted chibi-scheme, later also added support for gauche).

After rewriting it in Shen, I also switched the underlying platform to Chez.

Once the compiler was written in Shen it became much easier to with it and implement further optimizations.

So if you decide to do big reworks in ShenSharp (or even working on a new implementation), consider that option.

 

Moving onto the S series kernel was not painful, so I'm curious about
resurrecting some of the other ports: Someone's trying to patch
shen-elisp, and as I made the PR that upgraded that port to Shen 21 I
may poke my head in next. Not a ton of activity on many of the port
repos, sadly.

It depends on how much work the port is doing in terms of optimizations that make assumptions about how Shen is implemented.

The less assumptions it makes, the easier your job will be. Shen/Scheme was a bit hard to upgrade because of that.

What would the steps be in certifying ShenSharp and getting it to a
releasable state? I don't want to fully fork just yet because Robert
seems to be active on GitHub, exclusively on private repositories. But
I don't want to cram too much into one Git branch: I already took us
all the way through .NET 6, which has support through the end of this
year. It's easy enough to make self-contained releases, though: I did
so to test out the REPL in release mode, with no .NET installed on my
machine I did all the compilation in Docker.

If it works and passes the test suite I think that is enough. I don't remember if there was any specific process, Mark may comment on that.

 

--
You received this message because you are subscribed to the Google Groups "Shen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/CACy6W0DfhcNyBZj96HDNF17MBav_ga-HS%3DXy4RrVLswoqktPZQ%40mail.gmail.com.

--

BD

[dr.mt...@gmail.com]

Jacob:  In other non-scientific testing, it seems like ShenSharp in release

mode is about 10-20x slower than the CL port and 40-50x slower than
Shen/Scheme.

That's about what I'd expect.

Jacob:  What would the steps be in certifying ShenSharp and getting it to a

releasable state? 

Passing the test suite of 134 tests 100% is generally thought as enough.  It's not infallible,

but its largely composed of programs from TBoS and a few legacy programs.

If you pass this suite, any remaining bugs are likely to be easily resolvable.

Bruno: Personally, I think writing the compiler in Shen itself is much easier than writing it in the target language.

Agreed.

M.

[Jacob MacDonald]

Bruno Deferrari wrote:
> Personally, I think writing the compiler in Shen itself is much easier than writing it in the target language.

Glad you brought that up, as it's an idea that floats half-formed in
my head but something I didn't connect to this conversation. The
difficulty there seems to be the incompleteness of the current KLambda
emitter. I could build something in pure Shen with string
concatenation, but that feels like a larger undertaking. Easier to
tighten the extant bootstrap loop, I think. I believe there are
standard techniques for turning interpreters into compilers, but I
don't have them in my fingers. In any case, given a choice between
writing a bunch more F# or a way to write the compiler in Shen, I'll
choose the latter; We'll see if I'm willing to put in the work.