Re: Is this group dying?

On Sep 28, 12:53 am, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
"blytkerchan" <blytkerc...@xxxxxxxxx> wrote in message

news:1190949183.369579.30280@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Sep 27, 8:48 pm, Joe Seigh <jseigh...@xxxxxxxxxx> wrote:
This newsgroup has largely been deconstructed. You have to scrounge
around a bit to find anything interesting nowadays.

The various programming challenges out there have been insufficiently
challenging.
[...]

Well, there was that question about a multi-threaded scripting
language recently. If you want a challenge, that sure looked like one
- though admittedly not necessarily a very hard one once the
application domain for the language is defined...

What do you think - want to define the application domain for an
"ideal" threaded scripting language?
;)

I guess a script object could represent a task, which can be freely
created/joined, and examined for a return value. A task could be driven by a
single thread, or maintain the necessary information (e.g., simple
state-machine) that allows it to reside within the domain of a system
thread-pool/task-scheduler object.

So, you're basically talking about an explicitly multi-threaded (or at
least multi-tasked) scripting language that would have tasks
communicate through message-passing queues.. unless you want to make
the multi-tasking implicit and have those "return values" become
futures.

I can do the scheduler part using a vZOOM
single-producer/consumer unbounded wait-free queue which uses no
interlocking or expensive #StoreLoad or #LoadStore membars. Distributed
multiplexing on the per-thread queuing scheme. Eventcounts for anything that
needs to wait (e.g., a join on a task).

OK, how's about this: one single dispatcher thread and any amount of
worker threads. Each worker thread has an "input" queue and an
"output" queue, reads a task from the input queue (or waits on an
event if there's nothing to do) and, when the task is done, spits it
out on the output queue. The dispatcher queue schedules the tasks to
the different worker threads according to expected load from the task
(which could be as simple as looking at the number of nodes in the
parse tree or the size of the bytecode if we compile it that far) and
balances it to the different threads. Tasks can be spawned by other
tasks but would have to pass through the dispatcher queue for that -
same thing for joining.

From within the scripting language itself, tasks are objects that can
be created (which will have the worker thread add it to its output
queue for dispatching) and joined (which will have the worker thread
pass the current task to the output thread to let the dispatcher join
the two). The task itself can have any payload, which constitutes the
working set of the task, and a single entry point which is either a
script function or a "native" function.

The main script could create multiple tasks which perform concurrent
operations and subsequently join with them and retrieve their various
results.

I'd say the "main script" is just the first task to be launched..

The lexer/parser could be per-script object. That way a script can spawn a
new task and continue on parsing/processing; running concurrently with the
newly created tasks parser.

Actually, I'd have a tendency to go for a two-step execution: lexing/
parsing followed by evaluation. That way, any compile-time errors can
be caught in a nicely clean fashion, an already-parsed state could be
serialized and saved (byte-code, persistent parse-tree or whatever)
and an evaluator can take care of actually evaluating the code
(running it) and keeping track of the context. I've found splitting
the two into two phases (lex/parse followed by evaluation) both cleans
up the implementation and has the advantage of knowing your code is
likely to work without having to run it first.

Not sure this needs to be a scripting language... Can't the script be a
small C application that can be accessed with a link on a web-site? I wonder
if something like 'http://www.dinkumware.com/exam'would be interesting... A
highly concurrent C compiler that receives requests generated by the
internet. The C programs could have a limit on their total size; after all
there suppose to be small scripts... Of course this would never work because
somebody could create a virus far to easily...

IMO, that's more a question of exposing some built-in types in such a
way that a C or C++ program can also use them, and allowing the
interpreter to be extended with plug-ins written in C, through some
"native interface".

The question remains, though: what is the problem domain? We'll need
to answer that to be able to design the syntax and grammar of the
language.

rlc

.

Relevant Pages

  • Re: Which Is The Better Approach To Working With Javascript?
    ... Java SCRIPT runs in the browser exclusively. ... No language is written just for a single environment. ... You have to understand that I come from a hardware background, a huge area that is complately unknown to most 'computer programmers' whose life begins and ends with an interpreter or compiler.. ...
    (comp.lang.php)
  • Re: Newbie
    ... The "=" was highlighted on the second line of script, ... I searched the Help for "VBScript" and found that it is somehow ... scripting language than VBA. ... used by any language that has the ability to call COM libraries. ...
    (microsoft.public.data.ado)
  • Re: internal alias
    ... I liked ksh93 for the regex matching.. ... script without calling it. ... You didn't know that kshis an object-oriented language? ... just an enumeration of features. ...
    (comp.unix.shell)
  • Re: How do i convert text string to hex values as string?
    ... addition is faster than concatenation" is a valid justification for the use ... because QuickBASIC had by far the best string handling ... middle-level language, such as C. ... More in point, however, VBS is a utility script designed for relatively ...
    (microsoft.public.scripting.vbscript)
  • Re: Sound of j and z in Hindi films and songs
    ... "Official Policy" to remove the dots from j-dot etc, ... there was a practice of writing an anuswar on certain words like ... the dictionaries and the script followed later. ... I also notice that the more vibrant a language more tolerant it is. ...
    (rec.music.indian.misc)