<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Phil,</p>
<p>Thanks! I was alluding to a past suggestion to use OMeta and Dan
Amelang's Nile, when they were released back in 2008 as part of
VPRI, in Squeak Kernel classes to reduce overall complexity of
compilation and graphics rendering.</p>
<p>And yes, the generated code would be free of any OMeta deps - in
this case it's simply used as compilation pipeline that transforms
input code through various compilation stages (AST->AST with
optimized special sends->bytecode). </p>
<p>It would simplify overall architecture and would perhaps permit
to use compiler as service for e.g. syntax highlighting or some
other stuff that requires analysis of source code.</p>
<p>Currently, it seems like, one has to separately implement parser
for syntax styling etc.</p>
<p>I'm using OMeta for my bachelor thesis (in very very early
stages, defense is in Feb next year) which is about custom high
level dynamic streaming language. Pretty much bringing access to
high performance computations on CPU & GPU to Cuis, without
leaving comfort of it :). <br>
</p>
<p>I'm going to use it for all stages of compilation (parsing,
optimizing, generating etc.).</p>
<p>Too early to talk to about details but since I'm going to write
the thesis, the language is going to be released at least in some
usable state :) Hopefully more.</p>
<p>Cheers,<br>
Michał<br>
</p>
<div class="moz-cite-prefix">On 11.04.2024 08:05, Phil B wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAMJMOeiE-GjWOTHwOgPB-GA7uREeB9_M0-ACPqUGRbEAcY1A+g@mail.gmail.com">
<div dir="ltr">Hi Michał,
<div><br>
</div>
<div>I'm still around... just been busy with other things.
Thanks for your interest and efforts! I'll take a look at
your changes though it will probably be this weekend before I
can get to it.</div>
<div><br>
</div>
<div>As far as making Cuis a first-class citizen: that's not
likely to happen, nor would it be desirable. (I experimented
with that and the result was not good... there's too much of
an impedance mismatch)</div>
<div><br>
</div>
<div>Regarding the other areas you touched on:</div>
<div>1) Debugging: there should be a more robust OMeta parser
(i.e. a subclass of OMeta2) to better catch more errors (esp.
recursion) at parse/compile time, when possible. It's
entirely possible that the syntax needs to be extended to
support this.</div>
<div>2) Performance: assuming you're talking about runtime
performance where you have a parser being called repeatedly
you probably want to look at creating a parser that targets
(i.e. emits) code for a more performant parser (there's no law
that says OMeta has to always target OMeta!) as OMeta's PEG is
going to have relatively poor runtime performance vs other
parser approaches, especially if you have any recursion in
your parser and/or the input to your parser is characters
(i.e. parsing data files at runtime, for example.) I believe
that's still an open problem with PEGs. (not sure as I haven't
kept up with the state of the art on this)</div>
<div>3) Cuis compiling etc: use OMeta to emit Cuis/Smalltalk
code that is used anywhere in the image, sure... as long as
said emitted code is free of OMeta dependencies. Put another
way: if your generated code is in a subclass of OMeta2 and
calls the parsing engine it would probably not be safe enough
to use as an image-level dependency, if your generated code is
*not* in a subclass of OMeta2 you might be fine.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Phil</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2024 at
4:37 PM Michał Olszewski via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" moz-do-not-send="true" class="moz-txt-link-freetext">cuis-dev@lists.cuis.st</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
all,<br>
<br>
I fixed OMeta package from pbella so now it works again for
Cuis 6.3 <br>
(>6291). Yay! I made a couple of tests with the grammar
definitions and <br>
syntax highlighting and so far it's kind of back to the
working state:<br>
<br>
<a href="https://github.com/michalo1334/OMeta-Cuis" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/michalo1334/OMeta-Cuis</a><br>
<br>
Just requested pull to original repo: <br>
<a href="https://github.com/pbella/OMeta-Cuis" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/pbella/OMeta-Cuis</a>
but not sure if the author is still <br>
active in the community.<br>
<br>
However, in OMeta-derived classes it incorrectly highlights
instance <br>
variables in red and displays := instead of <-. If someone
has time to <br>
take a quick look at the Shout styler code, would be great.
Right now <br>
it's an ugly fix so that there is any highlighting at all -
it's nice <br>
to see a colored text.<br>
<br>
And then there is the problem to make OMeta first class
citizen <br>
(debugging, improve performance, maybe even use it for Cuis
compiling & <br>
code generation machinery?).<br>
<br>
Cheers,<br>
Michał<br>
<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>