> Aha, this I understand; it's clearly stated with no contradictions. It's > another way of saying "that's not how we do things around here". The point of > alot of my notes to this list is that, I'm doing something that is unusual or > new. If I put something out there for folks to ponder over, I welcome > interesting feedback. Maybe I made a mistake. Or perhaps there's a flaw in > the technique. Some intelligent analysis is always welcome. But responding to > tell me that "that's not the convention we follow here" is not helpful.
No, you're misunderstanding me. This isn't something that I want to get into a big argument about, because I don't feel extremely strongly about it, but what I meant by "having meaning alone" is more along the lines of writing code that's not built to satisfy surrounding dataflow, even if that surrounding dataflow is common. To me, it looks more clear if that data flow is written explicitly by shufflers, especially as different invocations of the same word tend to need different surrounding dataflow. But I could be wrong! What contributes to or hurts readability/writability more is conventions. If we decided to make a change to this kind of stack effect, it would make data flow much more difficult to follow if some code followed one convention and other code followed a different convention. This goes for argument order (which there are some general conventions for now) as well as what's returned. To make things easier to scan and understand, if we were to make a change here, it should be as a group and applied throughout the core and packaged libraries. Dan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
