[Cuis-dev] OMeta working again for Cuis 6.3

[Andres Valloud]

That Nile bit is a great example of code reduction.  The demos were 
quite impressive and the whole thing was around IIRC 400 LOC or so.  Ian 
Piumarta's talk re: to build a better mouse trap is also related because 
of the reference to Earley parsers.

On 4/13/24 20:14, Luciano Notarfrancesco via Cuis-dev wrote:
> Hi Michal,
> That’s very interesting. I have a very concrete application for this. I 
> need to compute with tuples, matrices and polinomials over integers 
> modulo a small modulus (say, it fits in a register, or half register). 
> These tuples, polynomials and matrices are stored in arrays (for example 
> WordArrays, 32 bits per entry). The most critical operation is matrix 
> multiplication, since a lot of the rest can reduce to matrix 
> multiplication. I’ve been experimenting with a small external library 
> written in C that converts to floating point, does matrix multiplication 
> with a BLAS library, and converts back to modular integers, and i call 
> it via FFI. Of course I’d prefer to do all in Cuis… so i’m looking 
> forward for your project!
> 
> Regards,
> Luciano
> 
> On Sat, Apr 13, 2024 at 21:13 Michał Olszewski via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> 
>     __
> 
>     Hi Phil,
> 
>     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.
> 
>     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).
> 
>     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.
> 
>     Currently, it seems like, one has to separately implement parser for
>     syntax styling etc.
> 
>     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 :).
> 
>     I'm going to use it for all stages of compilation (parsing,
>     optimizing, generating etc.).
> 
>     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.
> 
>     Cheers,
>     Michał
> 
>     On 11.04.2024 08:05, Phil B wrote:
>>     Hi Michał,
>>
>>     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.
>>
>>     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)
>>
>>     Regarding the other areas you touched on:
>>     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.
>>     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)
>>     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.
>>
>>     Thanks,
>>     Phil
>>
>>     On Wed, Apr 10, 2024 at 4:37 PM Michał Olszewski via Cuis-dev
>>     <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>>
>>         Hi all,
>>
>>         I fixed OMeta package from pbella so now it works again for
>>         Cuis 6.3
>>         (>6291). Yay! I made a couple of tests with the grammar
>>         definitions and
>>         syntax highlighting and so far it's kind of back to the
>>         working state:
>>
>>         https://github.com/michalo1334/OMeta-Cuis
>>         <https://github.com/michalo1334/OMeta-Cuis>
>>
>>         Just requested pull to original repo:
>>         https://github.com/pbella/OMeta-Cuis
>>         <https://github.com/pbella/OMeta-Cuis> but not sure if the
>>         author is still
>>         active in the community.
>>
>>         However, in OMeta-derived classes it incorrectly highlights
>>         instance
>>         variables in red and displays := instead of <-. If someone has
>>         time to
>>         take a quick look at the Shout styler code, would be great.
>>         Right now
>>         it's an ugly fix so that there is any highlighting at all -
>>         it's nice
>>         to see a colored text.
>>
>>         And then there is the problem to make OMeta first class citizen
>>         (debugging, improve performance, maybe even use it for Cuis
>>         compiling &
>>         code generation machinery?).
>>
>>         Cheers,
>>         Michał
>>
>>         -- 
>>         Cuis-dev mailing list
>>         Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>>         https://lists.cuis.st/mailman/listinfo/cuis-dev
>>         <https://lists.cuis.st/mailman/listinfo/cuis-dev>
>>
>     -- 
>     Cuis-dev mailing list
>     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>     <https://lists.cuis.st/mailman/listinfo/cuis-dev>
> 
>