[Oberon] Procedure variables and local procedures
dsar at eml.cc
Sun Oct 1 10:25:50 CEST 2017
> Sorry for my ignorance; how do we achive this in Oberon-07?
> It is similar to:
> char* p;
> p = malloc(1234);
> in C.
Large dynamic strings are better implemented as a list of blocks.
What if you have a really big string and you want to enlarge it?
In the case of a pointer to array, you have to allocate a new
(larger) one, copy the previous one to the new one and destroy
the previous one.
In term of performance this is a nightmare.
In the case of a list of blocks, you have just to append a new
The only problem with a linked list is that indexing is not as
fast as in the case of a pointer to open array. But there are
various ways to improve this.
Just look at "The text system" in Project Oberon 2013, expecially
Text Management. The "piece list technique" is a linked list.
5.2. Text Management
Our choice of an internal representation of text was determined
by a catalogue of requirements and desired properties. The wish
list looks like this:
1.) lean data structure
2.) closed under editing operations
3.) efficient editing operations
4.) efficient sequential reading
5.) efficient direct positioning
6.) super efficient internalizing
7.) preserving file representations
With the exception of 5.), we found these requirements
met perfectly by an adequately generalized variant of
the piece list technique
We conclude that the new aspects do not invalidate the
positive rating given above to the piece technique with
regard to requirements 1.), 2.), 3.), 4.), 6.), and 7.)
in our wish list. However, the requirement of efficient
direct positioning remains. The problem is the necessity
to scan through the piece list sequentially in order to
locate the piece that contains the desired position.
We investigated different solutions of this efficiency
problem. They are based on different data structures
connecting the piece descriptors, among them a piece tree
and a variant of the piece list featuring an additional
long-distance link like in a skip-list.
Eventually, we decided in favor of a simpler solution
that we can easily justify by pointing out that the
typical editing scenario is zooming into a local region
of text, i.e. positioning at an arbitrary location once
and subsequently positioning at locations in its immediate
neighborhood many times.
Therefore, an appropriate solution is caching the most
recently calculated values (pos, piece) of the translation
Just two notes: 1) with pointer to open arrays you have
other drawbacks, such as in the case you enlarge your
string; 2) with modern hardware this problem is less
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon