The Mud Connector

Author Topic: new LPMud Server and Modernized LPC implementation  (Read 1520 times)

Bradley Newton Haug

  • New to TMC
  • *
  • Posts: 1
    • View Profile
new LPMud Server and Modernized LPC implementation
« on: August 14, 2018, 12:01 AM »
Submitted for your approval:

my name is bradley newton haug, my online ‘handle’ in the late 80s/early 90s on muds and irc was morpheus.
I have designed and created the following.

Described here are a number of systems that have been designed,
and are now approaching alpha/code complete that may be of some interest to the lpmud community. 

TL:DR = Apollo is a modernized LPC and runtime. 
Prometheus could be described as a new form of LPMud Server
that smokes anything in existence standing still.  Details below.


The Compiler.
   Apollo is implemented as a lexerless, hand-written, recursive-descent parser built functionally in C++ rather than imperatively, it most cases within reason, if it compiles, it runs, though correctness is up to the programmer. Source is parsed and arranged into an attribute-rich asymmetric syntax tree, which is then used for rigorous semantic checking before emitting bytecode which is then stored in the prototype and consumed by a custom-built virtual machine after an object is cloned.  The compiler is integrated into the prototype class, and is considered part of the runtime with the principle reason and benefit being easy access to the error handler, which collects syntax/parse, as well as semantic, errors and stores them within the prototype object for reporting, logging, or perusal.  Assembly can be dumped from the prototype as well.

   A large test suite has been developed to ensure adherence to design specifications.  When there was choice between compile time over runtime speed, I always choose the former.  The compiler has another code generation path as well, and that is an AST walk to native code via LLVM, taking my virtual machine completely out of the loop.  This can produce from a large complex system a single binary executable that runs with C++ speed, though some of the benefits the bytecode/vm configuration are lost, which makes the native compilation path acceptable mostly for deployment and not necessarily for development. 
   

The Prometheus Server.
   Prometheus is the name given to the Apollo runtime when contained within a server configuration.  Elements of experimental Bell Labs operating systems Plan 9 (from outer space), and Inferno are present in the way the runtime (and thus server) interact with the outside world.  The concept of a ‘file’ while present as such through the lens of a user or programmer exists internally only as a data structure, the main components of which are: a key which represents a ‘filename’ (I call it keyspace), and a body: representing source code.  Possible prometheus configurations, depending on administrator whim, include running from a filesystem, as is traditional for LPMuds, while saving state and object dumps to again, a filesystem.  Other possible configurations include running from a number of key/value database while saving to the same, or to a filesystem, or to both, or syncing to another prometheus installation (or cluster) and requesting prototypes, or objects over the wire.  You can even email it a file.  It may become apparent to some astute readers that prometheus is more than just a mud server.  Most of these options require little more than program options on the command line.  It looks like an LPMud from inside, has a mini unixy dev environment, and soon now, even a pico-like editor.

The Apollo Runtime
   Residing within the prometheus server is the runtime.  Base functionality is provided with a set of system kfuns (a nod to dgd), I chose to use the term because I don’t like the term ‘function’ or ‘efun’. Neither do I use the term ‘lfun’.   All ‘functions’ written in Apollo are known as methods, this is to distinguish system level functionality from prototype/object provided functionality to a beginning user.  Methods.  Kfuns.  The kfun system is easily extendable, and a lookup system is provided whereby on a kfun call, the functionality is (according to configurable options) pulled into a table local to the prototype (and thus all its clones), the first call hits the ‘master’ table, every subsequent call hits the local table.  This has implications beyond just speed.  The runtime is also hybrid, meaning there is a one-to-one toll-free connection from the apollo side to the C++ side.  It is possible to create prototypes not only with Apollo source, but with C++, assuming certain classes have been inherited and certain rules followed (which can be checked at compile-time).  This allows for a C++ side prototype to be inherited by an Apollo-side prototype and vice-versa, with everything just working.  Both apollo-side and C++-side are equal in the eyes of the runtime.  Pick your poison.

 The Server.
   Prometheus is the name given to the runtime when configured as a standalone server.  This is not a requirement for using Apollo, as the components compromising prometheus are available as a static library for inclusion in anything that greases easily with the C/C++ world.  As I mention below, the Apollo language and runtime can do more than just act like a hot rodded LPMud, and while purveyors of the ‘mudspace’ may not care, I am certain they/you/whomever will enjoy the functionality provided as a consequence of being part of a larger family of components.

Theory
   These components taken with others not mentioned, are part of a platform called Mythoi.  Whose chief design goal was to create a configurably jailed and optionally secure (and again, optionally) fully deterministic runtime for a language with features capable of running within a jailed micro-operating system for the purposes of creating complex agent-based AI and numeric analysis systems collaboratively.  The entire platform is a concrete representation of my work in cognitive science and mathematics, whose scope is beyond this document.  TL;DR = it also makes one hell of a mud server.


License
   The entire mythoi platform contains no GPL code, nor any code under private agreement such as tenure or employment, and has been written in its entirely from scratch.  It requires only the clang and boost runtimes.   It is not ported (though I’ll mention something regarding one of my needs and requests from the community at the end of this) from anything.  Concepts have been borrowed from not only several LPMud servers, but from experimental language, runtime, and operating system corporate and academic projects, but never code.  The compiler and runtime and server will be made available for non-commercial use, an ‘indie’ level license will be offered for commercial, but not corporate level, use with a generous ceiling not unlike the way unreal engine licensing has been structured, though not required as much of a percentage.  Corporate and institution level licensing will be available with negotiated terms. 


Some preliminary information:


Note: most of everything here is already approaching alpha, though some elements are
subject to change.


Types

void
   void is a placeholder for a lack of type.  Used in methods with no return value. 
   There is nothing like void casting in Apollo, nor is there any dynamic checking anywhere.


bool
   can hold the value true or false, and is more than just a typedef or define. 

int
   int is backed by either a 64 bit integer, or an integer not unlike python’s, One is
   small and fast, the other can contain as large as numbers as you have
         memory for. 

real
   Real is our floating float number, again, backed by a double, or a scientifically useful
      and accurate representation that is slower.  Both of these types are one or the
       other, chosen at compile-time, invisible in their backrground use, though objects
   accessing data written with higher precision will lose that precision because it’s not magic. 
   It’s not a great idea to switch this around.  Speed/memory or science, pick one.

string
   string is backed by std::string, with most functionality and handling exposed.


mapping
   Mapping behaves at least exactly as per LPC with additional functionality, but never
   falling below the expectations of a programmer familiar with LPC.  If an Apollo mapping
   fails to function as an LPC mapping would, I want to know about it.  Borrows some          
   concepts from NSDictionary as well.

object
      as in LPC, object is a reference to a cloned prototype.

list
    List exists to facilitate functional programming elements within an otherwise imperative           
   language, lists can also be thought of as tuples, or as sequences, immutable, with the          
   runtime offering ways to iterate generically.  Lists can hold disparate elements of any    
   Apollo type.  Notably missing is TCO or lazy eval, if you want that, go use haskell.  This          
   is Apollo.

array
   This is the homogenous container to the heterogeneous list.  They are typed, and can          
   only contain elements of the declared type.  They are backed with a std::vector and          
   stored    sequentially in memory for speed.  Most of the kfuns dealing with lists can be          
   fed an array, but you will get a list back.
   
node
   this type is used for graphs and trees.

I have a function pointer type, but I’m not sold on specific yet, there are many ways to do
lambdas and closures and I’m waiting until I have some time to test before making a decision.
Right now it's like LDMUD's.


Pseudo-types

auto
   a declarative way to ask for type deduction.  Works as modern C++ does.

variant
   This is like the LPC ‘mixed’ type, but is really (like auto) only a semantic hint as Apollo          
   uses a fully deducing type system.  This is a duck type within a otherwise strongly           
   typed system. 

dice
   this is an odd bird designed to fulfill the role of access to quick and easy randomness          
   without participating in what many beginning programmers consider an obtuse dance           
   with modulo and casting and demon sacrifices   It can be used any place an int literal is    
   used, as an expression.  It contains a (small) positionally significant postfix              
   mini-language used as follows: k for keep, d for drop, h for high, l for low, v for value.       

   So, 3d6 works exactly as one would expect, it acts as an int literal that evaluates to
   the result of 3 six-sided dice.  Postfix operators are as mentioned, so 4d6DL1 means
   roll 4 6 siders and drop the lowest 1.  12d6kv3 means roll 12 6s and evaluate to
   the number of 3s rolled.  Takes me about 5 minutes to add more, so ideas are welcome.

   related is the dice switch language construct which is like a combination of dice and          
   and a switch/case statement, which I included because of the value of having a             
   combination switch case and random selector.  Used as follows: 
   dice a = 1d6{ x, x, x, x, x, x};   where x can be any expression, evaluating to any Apollo          
'   type, and it does not have to be the same.     This may seem like an odd use case to          
   include directly into a language, but randomly selecting a value from a table, is such
   a common practice I wanted it available to beginners.  It is not syntactic sugar either,
   it is a statement.


Dice types
   d2,d4,d6,d8,d10,d12,d20,d30, and d100 are, as one would expect, dice types known to
   the compiler. 


Type Modifiers

   const  <— worth mentioning, that yes, there is a const type modifier.
   array - this is how we declare an array, as a typemod against a type,
      so, array int a = ({1,2,3,4,5}); optionally, array<int>
      
   nosave - do not save
   public
   private
   protected - all 3 of these are for inherence exposure and control
   final - as in java
   
preprocessor

typedef - called typedef, but works more like a C++ alias.
import - for pulling in sets of kfuns
Inherit - as in LPC
define works as in C/C++

comments are // and /* */

pragmas - prototype level source hints to the compiler and runtime

   daemon     clone only once.
   nosave      on the prototype level
   secure      no use for MUDS, for other configs
   deterministic   of no use for MUDS
 


Mythoi has been in private design and development for over 25 years (with a heavy push the last couple years), right now it looks like I’ll have a release (of at least some parts) before the end of the year, but it comes out when it’s done.   I will mention here also that console/text is a development phase, one of many, that I will be hitting over the next 2 years.  It is already possible to create z-machine, infocom type games, as well as roguelikes, with mythoi, and I’m not stopping there, mythoi has many phases in the pipe. I should also mention we’ll be hiring early next year. 


if you are a mudlib developer, and are used to hiding from creators begging for your expertise, I could use some advice on kfuns, i.e. what to expose, what you need.  What you’d like to see in a driver.  Prometheus is almost there as barebones, that’s why I’m taking the time to write this instead of working.  I have this idea to take the Dead Souls public domain release and port it, but I kind of want something more barebones, like what was that.. melville?  I don’t remember.

or maybe something completely new, who knows?  Or maybe someone has a mudlib I can use, or they want to port to a shiny new server..

any comments, questions, concerns,
and or flames may be directed to me at bradleyhaug@gmail.com 

please include LPMUD in the subject, so I won’t miss it,
also be sure to mark flame mail with *#@&^&^$ so I can delete it without reading it.

I look forward to hearing from you.

best regards
bnh (morpheus)

PS Reese/Descartes, if you're out there, this is the system we discussed a few decades ago.  It's almost done.