Re: circumflex/caret --> scoped crm114 script variables

On Thu, Feb 26, 2009 at 2:35 AM, Paolo <[email protected]> wrote:
> On Thu, Feb 26, 2009 at 12:38:35AM +0100, Ger Hobbelt wrote:
> ...
>>
>> And to answer Paolo at the same time: no extra memory cost whatsoever.
>> (Unless you count a few integers per variable as major storage cost --
>
> depends on design, wasn't asking about any actual implementation, just
> reasoning about threading. I see it's not that tricky to keep track of
> scope/level, then use same-name vars in same buffer/vht, but for threading
> I'm afraid we need to dupe the buffer(s), else something wicked might
> occur - and locking buffer(s) doesn't sound sane.
>
> If threading is on list at all, that is.

Not planned. Not even considered. Too much effort for a language
that's low profile anyway.

Threadsafe is another story though (did I mention global variables?)
-- when the interpreter can be brought to a state of code where it
doesn't expect vht, csl, abp and all the other fine globals any
longer, we can have a threaded / threadsafe implementation. But then,
still, one script will execute in one thread. If you want async
execution of particular bits[*], one could use syscall, but the
current way is forking, i.e. running async in a _copy_ of the script /
interpreter, and I don't consider putting any additional effort in
that.
If vanilla's going to get it, so will I, but I won't be the one doing
the bleeding edge there.

[*] What was that language for the T800 again? ... Ah, yeah. OCCAM,
that was it. Well, crm114 script isn't going to share the realm of
OCCAM, unless someone else picks that up and then you'd have some
great with those bound variables, for one!


As it is, language design wise, crm114 script isn't exactly the
easiest thing you'd want to land on a programmer, plus it's got a few
current limitations (number of args, no notion of structured data,
which is another thing needed to manage larger applications' source
code, etc.) which don't entice me to, say, write a pipeline-optimizing
compiler for it which can schedule instructions which can be executed
in multiple threads, thus utilizing current CPUs more much better than
current single thread crm114.
20 years ago, I'd be nuts enough to do it if nudged the right way, but
then it would have been a power trip to show it could be done, just
like crm114 script itself is a proof of concept and ability. Now, I've
better uses for my time.

Running multiple instances of crm114 script in a server? Sure, I can
see that happen. One instance per thread, so no locking needed, ever,
but then you'd have to ditch the globals in the C code. I've looked at
it; even tried to do it, but it simply cost too much time (and made
the code uglier than it already was, to my taste), so that was aborted
when I asked myself: "Ger, what the heck are you doing?"
(The remnants are still in GerH: csl being passed around and that sort
of thing. Alas, rewriting this thing from the ground up using, say,
ANTLR or other LL/LR parser gens, is doable. (I prefer ANTLR over, for
instance, bison, as error handling and recovery is much, much nicer
and properly conceived in the former, while in the latter, as in all
yacc-derivatives, it tastes rather more like an afterthought.)
Getting the classifiers performing well [for my purposes] is WAY, WAY
more important than getting some script language dragged into the
threadsafe 21st century.

This language work you see the last few days is not because I like it
(I do, nevertheless), but because there was enough /agony/ over the
existing state of affairs to bump that 'nice to have' item to the top
of 'got to have', since I'm writing my test scripts, at least
partially, in crm114 script now.


Popping back to topic: crm114d won't have crm114 script aboard.
I'd rather integrate an 'established' script language, when such a
need arises. Say LUA, or something like that.
crm114 script, in my opinion, is what's holding back crm114, instead
of helping it into the limelight. It nice, it's cute, but it's not
geared for production level software engineering. So it's going.
What crm114's got going for it are its classifiers and the ease with
which you can switch and test with them. In a client-server setup,
there's no need for crm114 script server side: crm114 as is can act as
a client, while the server does classifiers in a big way.
The server is the multithreaded (probably even distributed) beast; the
client can be anything from rude single thread to sophisticated
multithread, but you can have your own choice in what client to use.
The client-server protocol is the only thing that binds you. (Which I
intend to be like HTTP / SMTP / ...: simple Q&A, so telnet and SSH can
serve as clients to that, if need be. No need to go through crm114
script any longer to get at the manna: the classifiers.)






-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H