Hi guys,<div><br></div><div>My apologies for not introducing what a Kaysian transform is. It's basically</div><div>a technique discovered by Michael Kay (long time XPath / XSLT guy, wrote/leads</div><div>Saxon) for efficient set intersection and difference with XPath. It's a neat little efficiency</div>
<div>trick. It's documented in the following (page 3), with other neat tricks:</div><div><br></div><div><a href="http://www.xml.org//sites/www.xml.org/files/xslt_efficient_programming_techniques.pdf">http://www.xml.org//sites/www.xml.org/files/xslt_efficient_programming_techniques.pdf</a></div>
<div><br></div><div>On the schemey/lispy approach? I like it. If the structures are reasonably stable with respect to</div><div>change over time then some artful hiding behind accessor functions is good enough. I do it myself</div>
<div>for things like gen_server state (accessors) or process options (mutators). I agree with Joe too.</div><div>If a parse transform compiles away some inefficiency (human or systemic) then that's a better</div><div>
accessor.</div><div><br></div><div>But would I maintain the structures for a family of complex financial derivative instruments</div><div>in erlang today and/or represent them as erlang records? No, not with the same accessors and/or</div>
<div>code generators I'd be happy to write and use for other isolated tasks. The reason is simple. The</div><div>number of, complexity of, frequency of change, and continuous arrival and departure of newly</div><div>invented structures would mean a lot of maintenance and upheaval. It's a significant source of pain</div>
<div>in capital markets and the problem is not exclusive to any one language. At some point you're</div><div>going to end up compromising and accept a certain level of maintenance.</div><div><br></div><div>So maybe there isn't one perfect solution. Maybe there's a few good partial solutions and each</div>
<div>is optimal given a certain presumed level of maintenance. But to presume all environments are</div><div>dealing with fairly trivial structures like the examples thus far, or that they are few in volume,</div><div>or that the frequency of change of those structures is low? That is an auto selection problem.</div>
<div><br></div><div>I see more than one good approach but no right one here.</div><div><br></div><div>Cheers,</div><div><br></div><div>Darach.</div><div><br></div><div><br></div><div><div class="gmail_quote">On Sat, Jan 26, 2013 at 10:15 AM, <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">I wrote:<br>
<br>
<br>
> So I don't _want_ to write AXP.a.x.p because that code<br>
> frightens me with its fragility. The only x.a.b or<br>
> x->a->b I could find in a quick find+grep over my own<br>
> C code on this laptop were two lines in some code to<br>
> handle doubly linked lists.<br>
<br>
</div>Imagine me with egg all over my face.<br>
Somehow that find+grep missed an entire directory,<br>
containing a project with lots of code by me and<br>
nobody else, containing hundreds of examples of<br>
what I said I didn't do.<br>
<br>
Some of the code is actually benign. It's not *really*<br>
spanning multiple records. I have a lot of tagged unions,<br>
struct Thingy {<br>
enum Thingy_Tag tag;<br>
union {<br>
int i;<br>
Unique_String s;<br>
...<br>
} u;<br>
}<br>
and occurrences of thingy->u.s really count as a single<br>
field reference.<br>
<br>
However, there were also about 300 lines containing<br>
foo->bar->ugh and I have spent a couple of hours<br>
fixing as many of them as I could.<br>
<br>
In many cases, the code was (to my mind) simplified<br>
and clarified by introducing<br>
gvar const o = m->owner;<br>
... o->whatever ...<br>
instead of m->owner->whatever, because it turned out<br>
that o was actually used several times in a function<br>
containing such a double step. Simply, if I was using<br>
foo->bar->ugh I was almost always _also_ using<br>
foo->bar->zoo and/or plain foo->bar itself. Before C<br>
compilers got good at optimising, this change would<br>
also have made the object code smaller and faster;<br>
even these days, C's aliasing rules probably mean there's<br>
some benefit there.<br>
<br>
I've spotted this in other people's Erlang code too.<br>
Function bodies that contain lots of field references<br>
can often be shortened (and to my mind simplified) by<br>
replacing field references by pattern matching in the<br>
head.<br>
<br>
Of the rest, quite a few would have benefited from<br>
virtual fields, had C supported them. Some of the<br>
ones that are left would have been simpler and easier<br>
for the compiler to type-check had I *not* been using<br>
C format strings. (The whole program basically doubled<br>
in speed when I stopped using <stdio.h> for most I/O;<br>
the only stdio code left is for error messages.)<br>
<br>
But to me the most interesting thing was recalling,<br>
as I worked over the code, that these had been the<br>
most error prone parts of the program. foo->bar->ugh<br>
really _had_ been a warning sign that I had not<br>
understood years ago when writing this stuff.<br>
<br>
Not only that: the foo->bar->ugh antipattern turned up<br>
a lot in code that needs a rewrite in order to hold<br>
Unicode in certain internal data structures, and I'd<br>
been putting that off and putting it off because fixing<br>
this stuff was so scary. I hadn't understood _why_ it<br>
was scary, but now I think I do.<br>
<br>
Why has it taken me so long to learn not to be so stupid?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>