[bitc-dev] Opinions wanted: Infix shift operators

[Jonathan S. Shapiro]

On Wed, Jul 28, 2010 at 8:09 PM, Ben Kloosterman <bklooste at gmail.com> wrote:

>
> >That is: a ResourceStream basically acts like a stream, except that (a) it
> fills in the positional blanks, and (b) it does run->time sanity checking.
>
>
> At first this looks ok ,
> >ResourceStream rs = get_Resource(zxx);
> >rs << replacement1 << replacement2;
>
> But this is the same as
>
> rs.Add(replacement1);
> rs.Add(replacement2);
> ...
>
> This internally would result in the string being copied and created each
> time a value is added  and the previous free token removed else how can you
> tell which one was updated,  this kind of state tracking makes me nervous
> for something that can be simple...


I agree that copy-intensive implementations are possible. After all, that's
what pure functional programming languages were made for, right?

In the absence of varargs, however, the copy really is hard to avoid in a
safe language You are either going to eat it in constructing the vector of
"anytype" instances for the varargs call or you are going introduce an
extensible string somewhere. In either case, you are *then* going to do an
additional copy to the outgoing write buffer at the stdio level.

There is another possible implementation, however. One can implement a
ResourceWriter object:

   let rw = ResourceWriter(stream, getResource("englishLanguage {1}
positional {2} string")
   in
     rw << arg1 << arg2;

ResourceWriter is heap-allocated, and internally maintains a progress index
into the originally fetched string. The result is just as efficient as the
original idiom.

A string.FormatN would allow this in a single parse with no mutables. And it
> would handle a large string eg html /xml as well as a small one. It can
> also
> easily check that all parameters have been entered without the counter.
>

Yes, but that requires overload-on-arity, and I've stated three times in
this discussion that I'm not going to take that issue up at the moment. I'm
running near my concept cache capacity, and if I overflow we'll delay the
compiler by a month.

It's a good issue, but it can wait a little bit longer. Also, it may "fall
out" when I re-do the TC instance resolution implementation, and I want to
see if that turns out to be the case. For fixed arity here's an obvious
enough implementation - I'm not worried about that part. It's the varargs
case that I really want to resist at the moment.

shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100728/39c0334a/attachment.html