From 15388ed0dbc42d3b321d5ba730b1afc706bed9a5 Mon Sep 17 00:00:00 2001 From: Simon Brooke Date: Wed, 23 Jan 2019 22:24:11 +0000 Subject: [PATCH] Updated regularity (markdown) --- regularity.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/regularity.md b/regularity.md index 287ee08..6a2d1b4 100644 --- a/regularity.md +++ b/regularity.md @@ -5,7 +5,7 @@ A regularity may also have an association of methods, that is, functions which a But, for example, if we have a regularity whose members represent companies, and those companies each have employees, then there might be a method `:payroll` of companies which might internally look like: ``` -(defun payroll (company) +(lambda (company) (reduce + (map do-something-to-get-salary (:employees company)))) ``` @@ -17,4 +17,6 @@ which would be accessed (companies:methods:payroll acme)) ``` -But salary is not a property of a company, it's a property of an employee; so what is this thing called `do-something-to-get-salary`? It's a method on the regularity of employees, so in this example, is is `::shared:pool:employees:methods:salary`. \ No newline at end of file +But salary is not a property of a company, it's a property of an employee; so what is this thing called `do-something-to-get-salary`? It's a method on the regularity of employees, so in this example, is is `::shared:pool:employees:methods:salary`. + +There are issues that I haven't resolved yet about the mutability of regularities and homogeneities; obviously, in order to provide multi-user visibility of current values of shared data, some regularities must be mutable. But mutability has potentially very serious perfomance issues for the hypercube architecture, so I think that in general they should not be.