[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 26 16:56:38 1993 
Subject:pop9x and orthogonal procedures 
From:Ian Rogers 
Volume-ID:930327.01 

There was a discussion on the Poplog internal mail alias recently about
the completeness (ie. coverage) of -datalist-. This generated the
following message from Adrian Howard. He doesn't seem to be around at
the moment so I'll forward it - no doubt he'll approve (famous last
words, slap slap :)

Will pop9x be fixing the bugs in Pop11's coverage? It would be a Good
Thing imho.

Ian.

------ cut ----- snip -----

If the generic procedures are going to work on all objects then I think
Harry's suggestion that datalist(3) = [] is more correct. Simple objects
don't have contents. Also you would have to write more specific code when
you bottom out. Compare:

    define rec_appdata(s, p);
        p(s);
        if is_structure(s) then
            applist(datalist(s), p);
        endif;
    enddefine;

with

    define rec_appdata(s, p);
        p(s);
        applist(datalist(s), p);
    enddefine;

As a first guess I would say the generic procedures should operate as
follows on a simple data object X.

    datalength(X) = 0
    length(X) =     0

    appdata(X) =    erasenum(%2%)
    mapdata(X) =    erase
    ncmapdata(X) =  erase
    copy(X) =       identfn
    copdata(X) =    identfn
    explode(X) =    erase
    datalist(X) =   [] ([% explode(STRUCT) %])
    fill(X) =       identfn
    allbutfirst(X) =mishap
    allbutlast(X) = mishap
    last(X) =       mishap

I don't think we can really change the behaviour since there are almost
certainly user programs out there that rely on these procedures to do
their type checking for them.

We have two concepts of simple structures in Pop-11:

    a) The -issimple-/-iscompound- divide depending on whether we
    access the object via a pointer.

    b) The class_field_spec(KEY) == false divide which depends on
    whether the structure has "contents."

The generic data-structure procedures basically operate on the (b)
distinction. Procedures make this more complex since:

    o class_field_spec(procedure_key) == false yet they have fields
    we can access (-pdnargs-, -pdprops-, -pdpart- etc.)

    o Complex data structures are built from procedures. All the
    following are all "procedures" yet give radically different
    behaviour when passed to -datalist-:

        identfn.datalist=>
        ;;; MISHAP - BAD ARGUMENT FOR EXPLODE

        identfn(%1%).datalist=>
        ** [1]

        (identfn <> identfn).datalist=>
        ** [<procedure identfn> <procedure identfn>]

        newarray([1 2]).datalist=>
        ** [undef undef]

        newassoc([[a b]]).datalist=>
        ** [[a b]]

Ideal worlds solutions:

    o Composites, closures, arrays, and properties all have different
    keys. -pdprops- etc work like normal record field access procedures.
    Radical change to Pop-11... cannot do it.

    o Composites, closures, arrays, and properties are subclasses of a
    procedure class in an OO Pop environment. Again... a radical change.

Now... back to reality.

In addition to -is_structure- we probably want -is_simple_procedure- as
well, defined as

    define is_simple_procedure(p); lvars p;
        isprocedure(p) and not(
            isclosure(p) or ispcomposite(p)
            or isarray(p) or isproperty(p)
        );
    enddefine;

-is_structure- can then be defined as:

    define is_structure(s); lvars s;
        class_field_spec(s.datakey)
            or isprocedure(s) and not(is_simple_procedure(s));
    enddefine;

How is Pop9x handling this sort of confusion :-) ?

aids