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
|