lib/y_nelson.rb in y_nelson-2.3.0 vs lib/y_nelson.rb in y_nelson-2.3.2

@@ -15,42 +15,39 @@
 require_relative 'y_nelson/zz_point'
 require_relative 'y_nelson/dimension_point'
 require_relative 'y_nelson/agent'
 require_relative 'y_nelson/dsl'
 
-# YNelson is an implementation of a cross between Ted Nelson's Zz structure, and
-# the functional Petri net (FPN). The resulting data structure, which combines
-# the qualities of FPNs with those of relational databases, I refer to as Nelson
-# net throughout this text.
+# YNelson is an implementation of a cross between Ted Nelson's Zz structure,
+# and a specific type of universal Petri net (PN), to whose creation I put
+# particularly large amount of design considerations. The resulting data
+# structure, combining the qualities of the said PN with those of a relational
+# database, I refer to as Nelson net.
 # 
-# A Nelson net, from a certain point of view, is as a genralization of a
-# spreadsheet software. In his explanations of Zz structures, Ted Nelson makes
-# wide use of metaphors well known from spreadsheets: cells, ranks, rows,
-# columns, cursors, selections... Nelson net, as implemented here, adds
-# "formulas" to the mix: Spreadsheet "formulas" are simply represented by FPN
-# transitions.
+# A Nelson net can be viewed as a genralization of a spreadsheet. Ted Nelson
+# does note similarities between zz structures and spreadsheets and makes wide
+# use of spreadsheet metaphors in his terminology: cells, rows, columns, ranks,
+# cursors, selections... Nelson net arises by adding spreadsheet "formulas" to
+# the mixture, which are nothing else than PN transitions.
 # 
-# Nelson net disposes of the arbitrary constraints on FPNs, and also extends the
-# plain orthogonal structure of spreadsheet "cells", as can be seen in the
-# existing spreadsheet implementations:
-# 
-# 1. Both places and transitions of the FPN take part in zz structure.
-# 2. Formula-based transitions are upgraded to standalone FPN transitions.
-# 
-# The implications of the differences of a zz structure from ordinary
-# hyperorthogonal structures have been, to a degree, explained by Ted Nelson
-# himself. There is a growing body of literature on zz structure applications,
-# including the applications in bioinformatics.
+# From spreadsheet software implementations, we are used to various constraints
+# regarding the available PN transitions. In Nelson nets, these constraints are
+# removed by the Nelson nets being based on the said formally defined universal
+# PN. Also, the plain globally orthogonal structure of rows/columns/sheets
+# typical for spreadsheet implementations is generalized to the locally
+# orthogonal zz structure with unlimited number of dimensions. The generalization
+# is as follows:
 #
-# As for functional Petri nets, their power in computing is well recognized (eg.
-# Funnel, Odersky 2000). FPNs are sometimes just called functional nets, because
-# Petri originally described his nets as timeless and functionless. However, in
-# special-purpose applications, such as biochemical applications, to which I
-# incline, it is appropriate to honor Petri, who designed his nets specifically
-# with chemical modeling in mind. In biochemistry, it is common to call
-# functional nets Petri nets (Miyano, 200?).
+# 1. Both places and transitions of the PN are zz objects.
+# 2. The way the spreadsheet is based on PNs is properly formalized.
 # 
+# Luckily, Ted Nelson and his crowd already put energy into explaining the ins
+# and outs of zz structures. There is a growing body of literature on this,
+# including zz structure applications in bioinformatics. And I add to this my
+# explanation of the extended PN type that I designed and implemented in YPetri
+# gem (gem install YPetri), which is a dependency of YNelson.
+# 
 module YNelson
   # Singleton class of YNelson is a partial descendant of YPetri::World. It
   # aspires to be a database that represents the world. More specifically, it
   # mixes in most of the YPetri::World methods, and provides interface, which
   # is a superset of YPetri::World interface. The difference is, that while
@@ -98,5 +95,128 @@
   # Atypical initialize call.
   initialize
 end
 
 puts "YNelson: Nelson net domain model and simulator. ⓒ 2013 Boris Stitnicky"
+
+
+# ===========================================================================
+# !!! TODO !!!
+# 
+# Refactoring plans
+# 
+# When 'y_petri' is required, class Module will gain the capacity to respond
+# to y_petri DSL commands (#Place, #Transition etc.).
+# 
+# This will allow syntax such as:
+#
+# # syntax 1
+# 
+# module Foo
+#   P1 = Place()
+#   P2 = Place()
+#   P3 = Place()
+# end
+#
+# module Bar
+#   T1 = Transition s: { P1: -1, P2: 1 }
+# end
+#
+# module Baz
+#   T2 = Transition s: { P2: -1, P3: 1 }
+# end
+#
+# In this syntax, there are two questions:
+# 1. Which world will the defined nodes belong to?
+# 2. Which net(s) will they be automatically included in?
+#
+# The goal here is to be able to construct things like:
+#
+# class Foobar
+#   include Foo
+#   include Bar
+# end
+#
+# object = Foobar.new # Object with state defined by a net consisting
+#                     # of Foo and Bar modules
+#                     
+# object.net          # YPetri net
+# object.state        # state of the object's net
+# 
+# A different possibility would be to use the block syntax:
+#
+# # syntax 2
+# 
+# quux = net do
+#   include "Foo"
+#   Place "A", marking: 42
+# end
+#
+# (Since net do A = Place( m: 42 ) end does not work -- constant gets
+# defined in the callers scope.)
+# 
+# The question is, which world will the nodes defined by syntax 1 go to?
+# I think that the world should be defined either:
+#
+# 1. explicitly
+# 
+# module Foo
+#   self.y_petri_world = Bar
+# end
+#
+# 2. implicitly
+#
+# module Foo
+#   A = Place() # will automatically connect Foo with the default world
+# end
+# 
+# module Foo::Bar
+#   A = Place() # will search nesting and connect Foo::Bar with the world of Foo
+# end
+# 
+# As for +YPetri::Net+ block constructor, the block should be module-evalled in
+# the nascent instance (whose class descends from Module), but +include+ in it
+# should be peppered so as to admit also Place and Transition arguments and to
+# make the first include decide implicitly the world of this net.
+#
+# X = net do
+#   include Foo::A
+#   include Foo::Bar
+# end
+#
+# Other than that, the world would have to be either defined explicitly
+#
+# X = foo_world.net do
+#   # ...
+# end
+#
+# or implicitly by Module#net, taking the module's world as the net's
+# world, as in module definition.
+#
+# So Module#net would go somehow like:
+#
+# class Module
+#   def net &block
+#     x = Net.new
+#     x.y_petri_world = y_petri_world # of the receiver
+#     x.module_exec &block
+#     return x
+#   end
+# end
+#
+# Object.y_petri_world is automatically created. World is not a module class.
+#
+# #net called outside a module should create a Net belonging to the
+# Object.y_petri_world.
+#
+# ===========================================================================
+
+
+# ===========================================================================
+# !!! TODO !!!
+# 
+# Refactoring plans: Modules themselves should be ZZ objects, but not
+# before yzz is refactored so as to allow to give the zz properties to
+# already existing objects.
+#
+# It is a question whether all the objects should be zz objects, and the
+# probable answer is actually yes.