>
5. In-place support: the parser needs to recognize the forms
samename =: samename verb noun
samename =: noun verb samename
samename =: verb samename
is there a chance for builtin support for:
assign =: 4 : '(x) =: y'
NB. possibly a foreign that allows =: as a common dyad, that would benefit from
in place support
('myvar' assign u)
and
assignwith
1 : 0
y assign u (y~ [ ]) :: ((i.0)"1) 1
:
y assign x u (y~ [ ]) :: ((i.0)"1) 1
)
myvar
|value error: myvar
0 , assignwith 'myvar'
0
3 + assignwith 'myvar'
3
+: assignwith 'myvar'
6
assignwith might have =.. and =:. primitives?
----- Original Message -----
From: chris burke <cbu...@jsoftware.com>
To: Source forum <sou...@jsoftware.com>
Sent: Wednesday, May 11, 2016 9:54 PM
Subject: [Jsource] Flag changes for new work
From: *Henry Rich* <henryhr...@gmail.com>
Date: 25 April 2016 at 17:56
To: jeng...@jsoftware.com
This is material that has passed between Marshall & me that I am reading
into the record. Marshall has gone to ground working on his thesis, and we
have not reached full agreement on all points here. Comments requested.
1. There will be two types of header blocks: header+data and header-only
(reference headers). Header+data will be the same as now except for the
flags mentioned below; reference headers will look like a header with an
8-byte data area attached. The reference-header data area will contain a
pointer to the header+data.
2. Reference headers can be created and freed as needed. Because the
header+data block does not have access to its reference headers, changes to
the use count in each reference must be reflected in the header+data
whenever a reference-header use count is incremented to 1 or 2 or
decremented to 1 or 0 (the parser will need to know whether a use count is
1).
3. No pointers need to be added to header+data blocks. The following flag
will be added to all headers:
REFERENCEHDR - if this is a reference header
4. Extension operations: this is when x , y executes by copying y into
unused empty buffer space at the end of x, thus avoiding the need to copy
x. This creates a new reference-header in which the data length is longer
than the length in the original header.
Flags needed (these flags can reside anywhere in the flags available to
nouns; for generality they could be in flags used by all types):
BLOCKISEXTENDED: set in the root header block only, when any header block
has extended the data
BLOCKISEXTENDEDHERE: set in the header (whether root or extended) that
holds the longest extension.
BLOCKISEXTENDEDHERE can be set in at most one header that refers to a data
area. A block can be extended if the header has BLOCKISEXTENDEDHERE or if
the root header has (!BLOCKEXTENDED).
5. In-place support: the parser needs to recognize the forms
samename =: samename verb noun
samename =: noun verb samename
samename =: verb samename
and flag the noun blocks to indicate that in-place operation is allowed. A
problem arises: the name to the left of =: is not stacked until after verb
is executed; but the parser must check for name equality before the
assignment target is stacked; thus there will be trouble if verb changes
the name-lookup result, by changing the path or assigning a name.
Verb flags needed (may reside anywhere in the verb flags, or in common
flags for generality):
VERBISNAMESAFE: set if this verb does not affect name lookup. If this flag
is clear, any compound using the name must also have this flag clear.
VERBSUPPORTSINPLACE: set if this verb supports in-place operation and
therefore may modify any argument for which NOUNISMODIFIABLE is set
Noun flag needed:
NOUNISMODIFIABLE: set if the data area will not be needed after the current
execution completes
NOUNISMODIFIABLE will be examined at the same time as the use-count field,
and it would be best if we reserve 3 LSBs of the use-count to hold flags,
of which NOUNISMODIFIABLE will be the first. That will save a few
instructions in the parser and any other place that checks the flags. Code
to increment/decrement the use-count should add/subtract 8. It should be
easy to put an audit in those routines to detect any erroneous use-counts
during development.
----------
From: *Marshall Lochbaum* <mwlochb...@gmail.com>
Date: 25 April 2016 at 18:58
To: jeng...@jsoftware.com
Regarding the extension changes, the headers must be stored in a heap.
The reason for this is that we need to handle deletion of the most
extended header. When this header is deleted, we have to delete elements
in the list that are no longer used--anything less is an effective
memory leak, and will turn into an actual memory leak when the last
header is freed (although the latter problem can be removed by keeping a
count of allocated elements at the high cost of an extra int in every
header).
The operations which J needs to perform on the heap are:
- Insertion (when a new header is created).
- Deletion of an arbitrary element (when it's destroyed).
- Finding whether a given header is the maximum (to see if we can extend
it).
A simple scheme like putting the headers in a linked list and flagging
the maximum will be O(1) to delete a non-maximum header or check for the
maximum, but O(n) for insertions and min-deletions. I don't know enough
about how often these headers would be created in practice to know
whether that is problematic.
Something like a binary heap stored in an array tacked onto the shape
would give us O(log n) insertions but also bump all the other operations
to O(log n). If we figure out how to include the original header, it can
also be stored with a maximum of three values per header: pointers to
the parent and both children, and the number of total headers in the
maximum header (replacing the parent). A Fibonacci heap brings us down
to O(1) insertions but would be complicated to store.
Another complication is that it's also very useful to allow slices that
start at an offset, making operations like }. take constant time. In
this case, we want another heap for the other end of the array, and
possibly a more complicated structure: if we store the first quarter and
last quarter of a long array, then delete the original, we should be
able to delete the elements in between, and extend the first quarter.
Likely we want to just copy the array in some cases, but I don't see a
clear way to distinguish those cases now.
On Thursday I will be done with the thesis, and free to begin actual
work.
Marshall
----------
From: *Henry Rich* <henryhr...@gmail.com>
Date: 25 April 2016 at 19:17
To: jeng...@jsoftware.com
[To list manager: when I replied to Marshall's post, it went to him only.
Please set Reply-To to the list]
I don't see why we need anything extra for extension beyond the flags.
[I am ignoring shared files here. They probably wouldn't participate in
this.]
There is just one data area, attached to the original header+data. If this
is extended, it is extended in the original buffer, up to the maximum
allowed by the size of the initial allocation. If the extension needs more
space than that, it has to copy to a new area, and ceases to be an
extension.
So deleting an extended header is just like deleting any other reference
header. When the use count on the data area goes to 0, it is freed. No
memory leak.
When the header holding the max extension is deleted, the block can no
longer be extended.
Starting at an offset works too: the reference header points to the offset
data, but freeing the block happens only in the header+data, which frees
the entire block when there are no more references.
There needs to be some judgement: you wouldn't want {. longlist to use a
reference header, because that might tie up the whole list when only the
head is active; but we can deal with that, I think.
Henry
----------
From: *Marshall Lochbaum* <mwlochb...@gmail.com>
Date: 25 April 2016 at 20:49
To: jeng...@jsoftware.com
If the data consists of composite nouns (boxes, exact integers, etc.),
then these must also be freed. It's not enough to just free the whole
array once when its last reference is deleted; unused elements have to
be freed as well.
Marshall
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
