[Oberon] Procedure variables and local procedures

Diego Sardina 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
 block.

 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
 map.
 ****

 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
 noticeable.



 --
 Diego Sardina



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171001/9a8dd0f1/attachment.html>


More information about the Oberon mailing list