esc@odin.stanford.edu (escape), whosoever that might be, writes:
> Is there any reason why the "use" function does not follow
> directory paths as, for instance, the #include construct of
> C? In other words, if the file top.sml uses dir1/next.sml,
> and dir1/next.sml attempts to use dir2/final.sml, the file
> dir1/dir2/final.sml is not found.
> Has anybody written a version of "use" which behaves more
> intuitively?
Extract from the Poplog SML on-line help file "help compile"
-- Searching for Files ------------------------------------------------
If a filename given to the compiler is not absolute, it need not
necessarily be located in the current directory. When called at
top-level, the compiler will always look first for files in the current
directory, but if not found there, it will then search each of the
directories listed in the variable -Compile.searchpath-. This is
initially set up to contain the names of system library directories, so
that a system library file can be loaded simply by giving its basename,
.....
E.g.
Compile.searchpath;
val it = ref(["$poplocal/local/pml/lib/", "$usepop/pop/pml/lib/"]) :
string list ref
Also, Rance Cleaveland writes:
> Is there a way to determine the size of objects in ML? In particular,
> what I am looking for is a command that one could execute at the
> top-level that, given an expression, would return the storage required
> to contain the result of evaluating the expression. My reason for
> wanting this is that I have an application I am writing that is eating
> heap like crazy, and I want to see why....
Again, in Poplog SML you can (non-standardly) import the "datasize"
function of POP-11.
pop11 ;;; Enter Pop-11
ml_val datasize:'a->int = datasize; ;;; Import the function (at your
;;; own risk if the typespec is wrong)
ml
But note:
datasize [1,2,3,4,5,6,7];
val it = 3 : int
That is, of course, ML structures are bushy (as I remarked yesterday
on comp.lang.functional). So what you are seeing is the first list-cell.
So what you want is more complicated, I suspect. Of course in New Joisey
Procedure Activation Records are taken from the heap (that's the price
of cheap continuations). So heap usage is complicated by this.
Poplog stacks PAR's, so that particular problem doesn't occur.
Here is a version that works for trees in Poplog.
;;; In POP-11
define datasize_rec(Obj);
lvars Obj;
if iscompound(Obj) and not(isnumber(Obj)) and Obj/=[] then
lvars n = datasize(Obj);
appdata(Obj, procedure(Obj1); lvars Obj1;
n+datasize_rec(Obj1) -> n
endprocedure);
n;
else datasize(Obj);
endif;
enddefine;
ml_val datasize_rec:'a->int = datasize_rec; ;;; Bind into SML
(* And in SML *)
datasize_rec [1,2,3];
val it = 12 : int
[Admittedly POP-11 shows its age in some of the inelegancies of syntax
in the above...]
Of course, if the structure is cyclic, you will get a stack overflow.
The only way to mend that (since there is no spare marker-bit) is
to make a POP-11 property that remembers which nodes you have visited.
It could of course get big.
While it -is- possible to compute datasize statically (as is size in C)
it is not of course possible to compute datasize_rec statically.
Robin.
|