Re: libcrm114: missing the CRM114 language

Corrado <crm114-tRhV7SAp1/[email protected]> writes:

> Hi all,
>
> after some initial playing with libcrm114, I've found myself sorely
> missing... the CRM114 language!

I know a good therapist.  :-)

> in fact using libcrm114 unfortunately means doing without the powerful
> CRM114 language, practically needing to reinvent the wheel every time
> some fancy pre-filtering 'massaging' is required.

Ahhh, I see your point.


> is there any possibility/future plans to (re)implement the language
> within the crm library, one way or another?

Other way around - eventually, at least, to modify the language to
use the library code.  

> I'm wondering if the current JIT compiler [standalone CRM114 binary]
> might be migrated into libcrm, allowing some byte-code to be
> loaded/cached/executed by libcrm, or perhaps some precompiled native
> code for CRM114 programs to be linked together with the C (or
> whatever) program using libcrm.

Well, it's not exactly _byte_ code; more like VLIW code if you
ever heard of that.  

> Does that make any sense?

Sorta.  But there are some architectural issues with the way the
language is (currently) constructed, a lot of which I'd like to
fix, and there's a mismatch between the library semantics and the
language semantics in terms of classifiers.

The language had one _class_ per file, and (I really wanted to) make
it be the case that you could have one class be an OSB class, one class
be a Bayesian, one be a Hyperspace, etc, and they could all play
together.  

But that didn't work out very well.  Almost all the classifiers
require renormalization, and that breaks down when you try to cross
multiple algorithms.  And it broke down even more with the classifiers
that needed more than one file, like SVM and PCA.

So the language is stuck with the syntax of one class per 
file, but the library wants one file with N classes per file and
creation is separate from learning.  

Maybe the right thing to do is to write a new version of the languge,
with:

  scoped variables;
  formal (C-visible) entry points;
  partitioned classifier creation from learning;
  use C's memory allocator rather than the two-block system;
  
Maybe even as a preprocessor rather than as a language.  The
preprocessor sucks in CRM114 next-generation code, and outputs
C code, full of calls to libcrm114, libtre, etc.

But most importantly, it wraps that C code in C-callable functions
so you _can_ call it from C (and call C routines where desired).

Now, this isn't to say it'd be easy; C's coordinate system for
strings is very different (and broken) compared to CRM114.  Conversely,
CRM114 has ONE data type (the overlapped string); it has no
floats, ints, structs, unions, classes... nothing else.

Example: in C, a string is a pointer to a byte; the string extends
till you hit a NULL byte.  Clearly this is not NULL-safe.  In CRM114,
a string is a pointer to a window, an offset within the window (which
may be zero), and a byte count; this is NULL-safe but you can't
call most of the standard library with it.

Example 2: in C, the default (32-bit) hex representation of the integer
42 is 0000002B.  In CRM114, it's a string, somewhere, with "42" in it.

This isn't to say that it can't be done (creation of a string 
processing "overlay" language with good access to libcrm114 and libtre)
but it would require a lot of thought and work.

So- do you want to code?  :)

    - Bill Yerazunis



 

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/