diff --git a/doc/LPC/lwobjects b/doc/LPC/lwobjects
new file mode 100644
index 0000000..f9559c8
--- /dev/null
+++ b/doc/LPC/lwobjects
@@ -0,0 +1,72 @@
+CONCEPT
+        lwobjects
+
+INTRODUCTION
+        Lightweight objects are a cross between regular objects and structs.
+        Like regular objects they are build from programs (.c files) and
+        encapsulate data und functions. Like structs they are automatically
+        destructed, they can be copied and saved.
+
+        As with regular objects its variables are hidden from outside
+        objects, its functions can be called with call_other() and related
+        efuns.
+
+        Lightweight objects are passed by reference.
+
+
+DEFINITION
+        Lightweight objects are created from a program, i.e. an LPC file.
+        This file needs to have the pragma
+
+            #pragma lightweight
+
+        to allow being used as a lightweight object. This pragma implies
+        the no_clone pragma (which can be overridden with the clone pragma).
+
+        There are no restriction on the program itself. It can inherit
+        other programs. Those programs don't need to have that pragma,
+        but the compiler might warn about unsuitable programs.
+
+
+USAGE
+        A lightweight objects is created by calling the efun new_lwobject():
+
+            lwobject lwo = new_lwobject("/obj/foo");
+
+        The efun new_lwobject() will load the file to create a blueprint
+        from it (which is a regular object) and then creates a lightweight
+        object therefrom.
+
+        The efun can be given optional arguments that are passed to the
+        H_CREATE_LWOBJECT driver hook.
+
+        Functions of the lightweight object can be called with the efuns
+        call_other() and its companions and operators:
+
+            lwo->fun();
+            lwo.fun();
+
+
+MISCELLANEOUS
+        Only declarative casts to lwobject are possible, there is no
+        conversion of any other type to lwobjects available (therefore
+        there is no to_lwobject() efun).
+
+        Support for lightweight objects is signaled by the macro
+        __LPC_LWOBJECTS__.
+
+        Lightweight objects have a UID and EUID and therefore can also
+        do file operations or create new objects themselves.
+
+        Lightweight objects can be serialized with save_value(), so
+        any outside program can inspect its variables. To really hide
+        variable contents they must be nosave.
+
+
+HISTORY
+        Lightweight objects were introduced in LDMud 3.6.5.
+
+
+SEE ALSO
+        structs(LPC), new_lwobject(E), call_other(E), configure_lwobject(E),
+        lwobject_info(E)
diff --git a/doc/LPC/pragma b/doc/LPC/pragma
index 21d4881..a1cfa99 100644
--- a/doc/LPC/pragma
+++ b/doc/LPC/pragma
@@ -6,11 +6,19 @@
         several compilation options. Multiple options can be selected
         in one #pragma directive by separating them with commas.
 
-        no_clone: The blueprint object can't be cloned.
         no_inherit: The program can't be inherited.
         no_shadow: The program can't be shadowed (similar to declaring
                 all functions as 'nomask').
 
+        clone: The blueprint object can be cloned (default, implies
+                no_lightweight).
+        no_clone: The blueprint object can't be cloned.
+
+        lightweight: Lightweight objects may be created from the
+                blueprint (implies no_clone and warn_lightweight).
+        no_lightweight: Lightweight object cannot be created from it
+                (default).
+
         init_variables: Clone variables are initialized by __INIT().
         share_variables: Clone variables are initialized from the
                 blueprint.
@@ -35,6 +43,7 @@
                   - arguments on function calls,
                   - return values of functions,
                   - assignment to variables,
+                  - declarative type casts,
                   - restoration of values to variables or struct members.
                 Don't confuse this with strong/strict_types, they only
                 check at compile time.
@@ -86,6 +95,17 @@
                 mudlib code - in general one should fix the warnings,
                 not turn them off.
 
+        warn_unused_variables: Warn about variables that are not used.
+                If will warn about variables never written to, variables
+                never read from or variables never used at all.
+                This applies to local variables and private global variables.
+        no_warn_unused_variables: Turn off warn_unused_variables
+                (the default).
+
+        warn_lightweight: Warn about efuns that are not suitable for
+                lightweight objects.
+        no_warn_lightweight: Turn off warn_lightweight.
+
         When an object is compiled with type testing (#pragma
         strict_types), all types are saved of the arguments for that
         function during compilation.  If the #pragma save_types is
diff --git a/doc/LPC/types b/doc/LPC/types
index e104951..15f98a6 100644
--- a/doc/LPC/types
+++ b/doc/LPC/types
@@ -5,8 +5,8 @@
 
     Variables can have the following types:
 
-    o int       An integer. Normally full 32 bits signed, yielding a
-                range of at least -2,147,483,648 to 2,147,483,647. The
+    o int       An integer. Normally 32 bits or 64 bits signed, yielding
+                a range of at least -2,147,483,648 to 2,147,483,647. The
                 exact available range is given by the predefined
                 macros __INT_MIN__ and __INT_MAX__.
 
@@ -95,7 +95,23 @@
                 unicode escape sequences.
 
     o object    Pointer to an object. Objects are always passed by
-                reference.
+                reference. The type specification can include a program
+                name that is a mandatory inherit of the given object:
+
+                    object "/std/room" var;
+
+                This program name is only verified during runtime when
+                runtime type checks are activated. See pragma(LPC).
+
+    o lwobject  Pointer to an lightweight object. Similar to objects
+                lightweight objects are always passed by reference.
+                The type specification can include a program name that
+                is a mandatory inherit of the given object:
+
+                    lwobject "/lwo/data" var;
+
+                This program name is only verified during runtime when
+                runtime type checks are activated. See pragma(LPC).
 
     o array     Pointer to a vector of values, which could also
                 be an alist. Arrays take the form ({ n1, n2, n3 })
@@ -120,9 +136,9 @@
                 create the closure as ({ ..., foo, ... })
 
     o float     A floating point number in the absolute range
-                __FLOAT_MIN__ to __FLOAT_MAX__ (typically 1e-38 to 1e+38).
-                Floating point numbers are signified by a '.'
-                appearing, e.g. '1' is integer 1, but '1.' is
+                __FLOAT_MIN__ to __FLOAT_MAX__ (typically 2.2e-308 to
+                1.8e+308). Floating point numbers are signified by
+                a '.' appearing, e.g. '1' is integer 1, but '1.' is
                 floating-point 1 .
 
     o mixed     A variable allowed to take a value of any type (int,