4 ms·

> Data never changes, but we have the possibility to create a new version of the data. Well, it depends on what you mean by data. To avoid ambiguity it is bett

> Data never changes, but we have the possibility to create a new version of the data. Well, it depends on what you mean by data. To avoid ambiguity it is better to talk about data values and data objects which have different properties. This can be formalized as follows [1]: o data values are modelled via mathematical tuples – tuples are immutable o data objects are modelled via mathematical functions (one field is a function from this reference to the field value) - functions are supposed to be mutable (In reality of course we meet quite different situations, for example, struct is mutable and objects can be immutable.) [1] Concept-oriented model: Modeling and processing data using functions https://www.researchgate.net/publication/337336089_Concept-oriented_model_Modeling_and_processing_data_using_functions https://www.researchgate.net/publication/337336089_Concept-o...

shwestrick 6y ago
What do you mean by "functions are supposed to be mutable"? Perhaps you are just pointing out that the output of the function (and therefore the value of the field...?) will change as the input changes? If mathematical tuples are immutable, then surely mathematical functions are immutable as well ;)
- conceptoriented 6y ago
  Function is a mapping between two sets (of values). This mapping between values is mutable although the values are not.
  - louthy 6y ago
    Functions are a mapping between a domain and a codomain, the mapping absolutely isn’t mutable, the definition of the function is the relationship between the domains. If I have a function: int Add1(int x) => x + 1 I would expect the domain and codomain to be immutable; I would also expect that x+1 to not turn in x/2 randomly also
    - conceptoriented 6y ago
      > the mapping absolutely isn’t mutable Assume f: X -> Y. We can now map x_1 to y_1 f(x_1)=y_1. And then change this same function by mapping x_1 to y_2: f(x_1)=y_2. Thus we can easily modify functions. Moreover, we do it constantly when we modify object fields in OOP. It is probably easier to comprehend if a function is represented as a table which we modify. In contrast, we cannot modify data values (mathematical tuples). Say, x=42+1 means that a new value 43 is created rather than the existing value 42 is modified. > I would expect the domain and codomain to be immutable; No. Domains, codomains and any set can well be modified by adding or removing tuples. What is immutable are values (in the sets).
      - kingdomcome50 6y ago
        Can you expand upon this? Perhaps the difference between "re-mapping" the function: f(x_1)=y_2 and "re-mapping" the value: x=42+2 How is the former different than the latter? And by what mechanism is the former achieved? I understand what you are saying, but how does one simply "change this same function"? Redefine it? To be clear, I'm not suggesting you are incorrect. I just don't fully understand what you are getting at.
      - louthy 6y ago
        > Assume f: X -> Y. We can now map x_1 to y_1 f(x_1)=y_1. And then change this same function by mapping x_1 to y_2: f(x_1)=y_2 They would be different functions, the first being the identity function: x => x, the second being: x => x + 1 > Thus we can easily modify functions. Moreover, we do it constantly when we modify object fields in OOP This isn't the case. A field with a different value in it just means the object is a different value. If the object is passed to a static function, then the domain is the full set of possible values that the object can hold (this is known as a product-type, you multiply the total possible values of each of its component parts to find out the size of the domain). If it's passed to a method then there's an additional implicit argument: `this`, which is the same as a static function with an additional argument that takes the object. The function is the same. Global (or even free variables) should also be considered part of the domain: i.e. it's akin to implicit arguments that are being passed to the function. > No. Domains, codomains and any set can well be modified by adding or removing tuples. This also isn't the case. If a function is defined that takes an integer and returns a boolean value: Int → Bool then the domain is the set of integers, the co-domain is True and False. You can't pass a tuple to a function that takes an Int and therefore dynamically increase the size of the domain. Even in dynamic languages the codomain is effectively `top`, the type that holds all values, and therefore the domain is all values and the codomain is all values, which makes them immutable still. Now maybe I am misunderstanding you, but this is how all of the mainstream statically and dynamically typed languages work. Perhaps there's some edge-case language that I'm missing here that allows types to be extended, which would be interesting in its own right.
  - FridgeSeal 6y ago
    Functions might be isomorphic to one-another, that doesn't make the function itself mutable.
- prostodata 6y ago
  Here is one possible implementation of the concept-oriented model of data for data processing. It heavily relies on functions and operations with functions and is an alternative to purely set-oriented approaches like map-reduce or join-groupby (sql): https://github.com/prostodata/prosto https://github.com/prostodata/prosto - Functions matter!

shwestrick 6y ago

What do you mean by "functions are supposed to be mutable"? Perhaps you are just pointing out that the output of the function (and therefore the value of the field...?) will change as the input changes? If mathematical tuples are immutable, then surely mathematical functions are immutable as well ;)

conceptoriented 6y ago
Function is a mapping between two sets (of values). This mapping between values is mutable although the values are not.
- louthy 6y ago
  Functions are a mapping between a domain and a codomain, the mapping absolutely isn’t mutable, the definition of the function is the relationship between the domains. If I have a function: int Add1(int x) => x + 1 I would expect the domain and codomain to be immutable; I would also expect that x+1 to not turn in x/2 randomly also
  - conceptoriented 6y ago
    > the mapping absolutely isn’t mutable Assume f: X -> Y. We can now map x_1 to y_1 f(x_1)=y_1. And then change this same function by mapping x_1 to y_2: f(x_1)=y_2. Thus we can easily modify functions. Moreover, we do it constantly when we modify object fields in OOP. It is probably easier to comprehend if a function is represented as a table which we modify. In contrast, we cannot modify data values (mathematical tuples). Say, x=42+1 means that a new value 43 is created rather than the existing value 42 is modified. > I would expect the domain and codomain to be immutable; No. Domains, codomains and any set can well be modified by adding or removing tuples. What is immutable are values (in the sets).
    - kingdomcome50 6y ago
      Can you expand upon this? Perhaps the difference between "re-mapping" the function: f(x_1)=y_2 and "re-mapping" the value: x=42+2 How is the former different than the latter? And by what mechanism is the former achieved? I understand what you are saying, but how does one simply "change this same function"? Redefine it? To be clear, I'm not suggesting you are incorrect. I just don't fully understand what you are getting at.
    - louthy 6y ago
      > Assume f: X -> Y. We can now map x_1 to y_1 f(x_1)=y_1. And then change this same function by mapping x_1 to y_2: f(x_1)=y_2 They would be different functions, the first being the identity function: x => x, the second being: x => x + 1 > Thus we can easily modify functions. Moreover, we do it constantly when we modify object fields in OOP This isn't the case. A field with a different value in it just means the object is a different value. If the object is passed to a static function, then the domain is the full set of possible values that the object can hold (this is known as a product-type, you multiply the total possible values of each of its component parts to find out the size of the domain). If it's passed to a method then there's an additional implicit argument: `this`, which is the same as a static function with an additional argument that takes the object. The function is the same. Global (or even free variables) should also be considered part of the domain: i.e. it's akin to implicit arguments that are being passed to the function. > No. Domains, codomains and any set can well be modified by adding or removing tuples. This also isn't the case. If a function is defined that takes an integer and returns a boolean value: Int → Bool then the domain is the set of integers, the co-domain is True and False. You can't pass a tuple to a function that takes an Int and therefore dynamically increase the size of the domain. Even in dynamic languages the codomain is effectively `top`, the type that holds all values, and therefore the domain is all values and the codomain is all values, which makes them immutable still. Now maybe I am misunderstanding you, but this is how all of the mainstream statically and dynamically typed languages work. Perhaps there's some edge-case language that I'm missing here that allows types to be extended, which would be interesting in its own right.
- FridgeSeal 6y ago
  Functions might be isomorphic to one-another, that doesn't make the function itself mutable.
prostodata 6y ago
Here is one possible implementation of the concept-oriented model of data for data processing. It heavily relies on functions and operations with functions and is an alternative to purely set-oriented approaches like map-reduce or join-groupby (sql): https://github.com/prostodata/prosto https://github.com/prostodata/prosto - Functions matter!