Re: [Datadraw-user] New DataDraw computer language - Grail

[Bill C. <bi...@bi...>]

Hi, Richard.

I like the 'on' statement.  DataDraw already has destructor a
> Bill, everybody,
> 
> Richard again.
> 
> I notice a mistake in my closure example.  What if the mutate variable
> (called closure_var in my example) gets used by two subroutines?  the
> first one who get destroyed will `cascade' delete the var and the
> other wont be able to use it anymore.
> 
> Well after `cascade' and `mandatory', I guess it is time for a new
> decorator.  I would call it `parasitism' for now. (I was tempted by
> `garbage_collected' but that would be overwhelming.)  `Parasitism'
> mean here that child can live as long as it gets one of its host
> Parent alive.

Could that be implemented with reference counts?

> Regarding module parameters and relationship decorators, we have up to
> now:
>       * relationship directionality: mutual, parent_only, child_only
>       * relationship termination behavior: separation, mandatory,
>         cascade, and now parasitism
>       * data structure keying information: hash key, comparison
>         function...
>       * be my guess: invent your own
> `parent_only' and `child_only' are destructive and intimately related
> to the internal data structure of the relationship.
> 
> Relationship termination behavior is another story.  they are
> constructive and independent of the internal data structure.
> Therefore they could probably be defined separately.
> 
> decorator relationship.cascade(Parent parent, Child child)
>     on Parent.destroy()                      # `on' event driven
> engine... becomes inline
>         safe foreach parent.clabel(child)    # where do I get this
> label??
>             delete child

I don't know... C++ and some other languages go to great efforts to make
generic code work with declarations, rather than just generating the
code, like the 'reuse' statement.  Module parameters seem pretty simple
as a concept compared to relationship decorators.  To change
functionality in a base module, I'd rather focus on extensions to the
'reuse' concept.

For example, if 'cascade' was not already a parameter to modules, what
if we allowed the user to redeclare the module with the parameter?  For
example, you copy and past the old module declaration, and any functions
you want to edit, and simply make them look the way you want.  The 42
compiler would make such edits when it sees redefinition of classes,
functions, or modules.  I feel that patching an author's code is far
more common than extending it through inheritance, or other mechanism,
so why not directly support patches?  In this case, we would have:

    "Add debug, cascade, and mandatory as a module parameters."
    module LinkedList(bool cascade, bool mandatory)

    if !childonly
        inline Child.destroy(Child child)
            Parent parent = child.plabelParent
            if debug
	        assert !mandatory || parent != null
	    if mandatory || (cascade && parent != null)
	        parent.removeClabelChild(child)

To add reference counting, we'd need to modify.  We need to detect when
a variable of a given class type is written to, and decrement the
reference count of whatever it use to refer to, and destroy the object
if the ref count reaches zero.  We could override the get/set methods
for class members.  We could convert all assignments, even to local
variables, to get/set functions.  Then we'd need to generate ref count
code for each set function that assigns to the given type.

If we could get this to work with strings, vectors, dynamic array, and
matrices, it'd be a good step.  I think this will be more natural once
all the mirror classes are defined.  Then we can write code to make
these kinds of transformations directly in a 42 library.  With syntactic
extension, you could even write that library, and invoke it with syntax
similar to what you defined above.  Then, we could bicker about the
value of your syntax for a while and decide if it makes it into the
default library, or just your add-on.

Bill