[LLVMdev] Integer handling

[OvermindDL1]

On Mon, Sep 29, 2008 at 8:49 PM, Matt Giuca <mattgiuca at gmail.com> wrote:
> /* snip */

The language I am making is not a traditional scripting language, it
is designed for heavy math work.  It has not classes, the basic data
structure is a struct, yet even those are only used to pass messages.
It is using the Actor-Oriented model, not Object-Oriented.  I have
been creating it to deal with taking the heavy computations and
'offloading' them from the main program in such a way that it can take
advantage of multiple cpu cores, or even multiple computers, in a more
transparent way, so I was intending for it to be pretty low-level
regardless (it is not designed to be a standard scripting language, if
I want a 'pretty' easy-to-use scripting language then I always bind in
Python).

You still gave me thoughts to munch on though.  It could be more
widely useful for others if I made the most complex data structures
able to be referenced by names instead of types, but that introduces
message complexities like requiring the end-points in the system to
have the same code loaded (which the Actor model does not require) to
be able to link the names with a relevant data structure (might look
at Erlang for an interpreted implementation of the Actor model).

Looking at it, the Actor model (since it is so ancient) really has no
documentation on any higher level types (even strings do not exist,
just arrays to store 'string-like' things).  I should see about coming
up with some 'obvious' higher-level constructs to see if they would
fit in well with the system.  I do not want anything complex as that
just makes message passing more difficult.

But for note, in the Actor model there are no global variables (there
is no global state at all actually, unlike near every other language
in existence), there are no pointers (as you might accidentally try to
send a pointer in a message, which 'might' work if the end-point actor
was on the same system, but that is not definite).  The only
'pointer-like' constructs are in function arguments, and only to local
variables on the actor's stack, since those are very controlled.

By keeping the type system based on the actual types it allows
arbitrary message passing to any other actor without needing to load
any code relating to the actors, you can just send a structure with
the appropriate ID and format and it will 'just work' as the pattern
matching will ensure the other actor handles it correctly, or it gets
dumped with a message stating no match.  I guess I could have 'message
header' files to define message types and allow those to be transfered
across systems.  A 'name' for a structure would still generally be
larger then the type description of that actor when serialized though,
which kind of defeats the purpose unless some method was put in to
match message struct names with some sort of global identifier
database across the whole system that is synced on all machines.
Problem with that is if two systems setup a connection between them,
that could be a lot of data to have to sync up, which could cause
mismatches in the mean time, which again makes it sound like that type
matching is safer again.  If I did have the message name itself
transfered and did not mind it taking up extra bandwidth there could
still be issues if another user created a message of the same name but
a different type, how would it match it, where-as the Erlang style of
ID's and pattern matching of the types is still safer...

So many things to consider...