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