My punctuated attempt at updating ShenSharp continues.
I'm running into a few last speed bumps and cannot find documentation
on them. I'm using the 38.1 release as provided by Bruno on GitHub;
Eventually I'll look to copy the 38.2 package from the site.
There are a few functions that I do not have definitions for. That's
fine, I can implement them in the runtime, but they seem to be extant
in the declarations but only used during initialisation now. The
culprits:
- interror
- list
- shen.pprint
Are there definitions or specifications for these out there somewhere?
In addition, ShenSharp thinks that foreign is a function it needs to
have, but as I understand it that form is something like a tag and we
can simply unwrap the form during read/deal with CLR calls as
appropriate. Am I on the right track?
I encountered these functions bringing init.kl back into the build. Is
that still a necessary step? Feels like it given all the runtime
information unavailable without it, but I can't quite tell what the
process from Shen to KL to a port looks like these days.
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/CACy6W0AiiES030RvQ-e%3DR8Gc3pyuYLnkAhMuaNO%2BYdQikOA5mg%40mail.gmail.com.
It looks like shen.pprint and interror left the scenesome time back but were left in the declarations fileI'd ignore those entries. I'll remove them in the next release.'list' is a type operator; not a function. 'foreign'is indeed a tag.I know nothing of init.kl. I have no such file in my distribution.
MarkOn Sunday 12 May 2024 at 13:07:53 UTC+1 jacc...@gmail.com wrote:My punctuated attempt at updating ShenSharp continues.
I'm running into a few last speed bumps and cannot find documentation
on them. I'm using the 38.1 release as provided by Bruno on GitHub;
Eventually I'll look to copy the 38.2 package from the site.
There are a few functions that I do not have definitions for. That's
fine, I can implement them in the runtime, but they seem to be extant
in the declarations but only used during initialisation now. The
culprits:
- interror
- list
- shen.pprint
Are there definitions or specifications for these out there somewhere?
In addition, ShenSharp thinks that foreign is a function it needs to
have, but as I understand it that form is something like a tag and we
can simply unwrap the form during read/deal with CLR calls as
appropriate. Am I on the right track?
I encountered these functions bringing init.kl back into the build. Is
that still a necessary step? Feels like it given all the runtime
information unavailable without it, but I can't quite tell what the
process from Shen to KL to a port looks like these days.
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/aa7b8620-79f5-4173-9e4f-e0f002379815n%40googlegroups.com.
Thanks for the help. I ended up hacking on the shenlanguage.org
distributions after sending that email, which leads me to my first
actionable question and the rest of the below.
Is there a way to pretty-print KLambda? Debugging init.kl with its
long long lines proves difficult.
My second question was how that file is generated, but I had simply
skipped over the relevant Makefile rules. See the very end of this
email, though.
Bruno Deferrari wrote:
> What I see is that [interror, ...] are still referenced when building the arity table, so I guess that is what is causing the issue.
The arity table is what I found first, but I think it's not exactly
the case. See
> you shouldn't be seeing `foreign` when you are processing KLambda.
I see this form in init.kl (38.2 version from GitHub now)
(shen.set-lambda-form-entry (cons foreign (lambda Y1096 (foreign Y1096))))
As far as I can tell the earlier instances of "foreign" are symbols in
cons cells in the arity table. This is what I think is getting picked
up as an application. There are similar instances of the other problem
symbols below that block of consing (which I believe is the arity
table).
> If ShenSharp made use of it in previous versions you still need it, otherwise you will need to do all the evaluation of the initialization code at runtime. What init.kl gives you is an entry-point function to the initialization code that you can compile ahead of time (it sounds like extra work but it actually simplifies things for ports and helps with performance).
> ...
> Re: process for ports, it is probably simpler now because there are fewer things to worry about (much of what the port had to do for handling functions is now handled by the Shen->Kl compiler for example). But for ShenSharp it is likely that it already contains some of the logic that is not needed anymore, along with optimizations that make assumptions that are not true anymore.
I'm curious about simplification and performance, but that feels like
a fork of this thread. For now, I'll lay out how ShenSharp builds
itself as I understand it. A compiler translates KLambda to F# code,
which becomes part of a runtime assembly which is capable of running
all of Shen. It does depend on having shen.initialise available, and
thus skips any toplevel forms other than defuns. I want to refactor
this to record all toplevel forms, even the ones we don't currently
compile. Without fixing that, I can get a half-working REPL by
hardcoding the skipped (set ...)s into the runtime. So I'm moving down
the pathway of using the official website's package and eliminating
the hack.
Finally, I'll revisit my pseudo-question about the init.kl build from
above. shen.initialise throws the wrenches already mentioned, but it
also requires the <-dict and dict-> functions, which ShenSharp got
from dict.kl before. That's another file which exists only in the
GitHub distribution.
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/CACy6W0BkKXmghtmYjhYBy9wZvtQg2n3CPvrhVgvVwwx8ScRGNg%40mail.gmail.com.
--
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/CACy6W0AV1V-9M7JGgEjKGo1g%2BZ3wc8zKY9fgBVoZK65Zg8%3DuwA%40mail.gmail.com.
Bruno Deferrari wrote:
> Yes, same as init.kl, dict.kl is not part of the original distribution. What it does is to allow the underlying platform to use its own hash tables and hashing primitives which are usually much faster than the default portable ones.
I was under the impression that the dict-function situation was the
opposite: dict.shen contains the portable implementation which can be
shadowed. In any case, what's relevant for porting is not dict.shen
but the fact that the website's .kl files don't use dict functions
while the ones on GitHub do. Where do they get inserted from?
> While it is not ideal that it references a function that doesn't exist, that is still something that needs to be supported in a full implementation
> ...
> Btw, you see this in init.kl, but it is not the source of the issue. You would have to still execute this code somehow to recover the runtime state required by Shen, init.kl is just a dump of the code that performs that.
OK, I can't claim to understand it fully without hacking on the
underlying Shen code, I get the gist. However, what has happened is
that this issue did not crop up in the 22 kernel but does in 38. I
could bisect to see exactly where the regression is, but since
interror exists in the old initialiser's arity collection, the
breakage I'm seeing has *something* to do with changes to the rest of
the initialiser.
> The simplification is that it already does what you want to do here. The performance advantage comes from the fact that this setup allows you to compile everything ahead of time (to the target bytecode or language) and allows you to start the system without a single call to `eval`.
Sounds like the ShenSharp compiler targeting 22.4 didn't actually
target a sufficient subset of KLambda, then?
What I'm hearing is that
the initialisation function does some compilation lifting into
KLambda, but while an older version of ShenSharp used it and passed
tests, it can no longer build its F# output successfully.
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/CACy6W0DAWRjg1CG_BzJz21PmpQc7evP5%2Bq8Kt7w3%2BY9_Ng_G_g%40mail.gmail.com.
Bruno Deferrari wrote:
> Do you see any special-casing for interror somewhere else in the ShenSharp compiler? Maybe there was some code specific to it, "foreign" is a new symbol.
No, AFAICT the only special-case in the compiler is for cd, which has
a fully F# implementation. Well, that and the skipping of non-defuns.
The new issue with interror/foreign/etc. is that they appear in
initialise-lambda-forms and not only as data in the arity forms. I
admit that I'm a bit thrown by the differences between make.shen on
GitHub and make.shen in the tarball from GitHub. "lambda-forms" does
not appear in the tarball except in init.kl, as far as I can find. And
while make.shen (tarball, not GitHub) references the function
(shen.initialise-lambda-forms), it doesn't contain the definition.
It seems to me that there are several interacting runtimes and I don't
understand their relationship.
I want to create a F#/Shen 38 runtime. To do so I need KL files
generated from/reflecting a working Shen runtime. The ones on the Shen
site are from the bundled CL implementation and the ones on GitHub are
generated by a Scheme implementation. Is that correct?
My instinct is to choose a source of truth to branch the F# runtime
from, but the docs on porting are slightly unclear. I expect that the
KL files from the website are sufficient for a working environment if
I implement non-defun compilation, but init.kl, which does that
lifting for me, includes KL generated from somewhere unclear and
breaks the ShenSharp compiler.
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/CACy6W0DxONd7ovhBAi6h_FLVoR9jDk-g3xNWkoB%3D%2B49znY0rHQ%40mail.gmail.com.
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/CACy6W0Cn7wz2KejyP7WA6FPNvnv%2B3XKJEZ_TqDOJow1vhVdA_Q%40mail.gmail.com.