[Readding list cc] On 13 July 2013 07:12, Mikel Forcada <m...@dlsi.ua.es> wrote: > Sergio, Jimmy, all: > > Thanks for your help. I am, however, still a bit confused. > > Jimmy says that "it's no less counterintuitive to pass <clip> when you want > <b>.". Well, I was just passing positions and hoping that pos="n" accessed > the blank between the lexical units at pos="n" and pos="n+1", as this is > what you do when you don't use macros:
I'll take a step back here, and admit that "no less counterintuitive" is simply incorrect. I was swept up in the moment a little; what I really meant is that both are counterintuitive (albeit, to different degrees) and if we are to consider this a bug, then the correct resolution would be to do what is intuitive: to allow <b> as a parameter to macros. The correct++ resolution would be to allow anything that can appear in <out> to be used as a parameter to a macro. I will, however, defend my previous position, to a limited extent: i.e., while they are counterintuitive to a different degree, I think that degree is smaller than you perhaps do. The missing piece of information here is that the blank following the last <pattern-item> is never accessible[1]; with this in mind, I consider forcing people to think of <b> as existing between <clips>s a positive. [1] I had always speculated that the reason for the 'pass 2 clips to access 1 blank' change was because this had previously _not_ been true, and the superblanks following the final pattern-item were being silently discarded. > inside the <action> of a rule, <b > pos="2"/> is the blank between the 2nd and the 3rd lexical unit. I was > thinking of pos as positional information, not particularly referring to > lexical units or blanks. And this is what I had in mind when I invented > Morphtrans, the precursor of our current language, which started, basically, > as an XML rendering of Morphtrans. I never wrote rules for Morphtrans, so, > probably, this worked the same (I would have to ask Alicia Garrido, > interNOSTRUM programmer). > > Since I am dealing with superblanks one by one, I can always pass the two > positions to my macros, but I would like to know if this is how I should do > it now and forever. I am worried about superblank management (sometimes it > breaks the validity of HTML or RTF) and I wanted to write some guidelines on > how to do this in general, by learning on my eng–kaz example. > > I also don't know what the patch is for. I assume it does not change the > current semantics. No, it's a guard against a fairly common out-of-bounds error. > If there is a way to reconcile the current semantics and > a semantics that uses pos transparently for lexical units and superblanks, > so that to access a superblank I just need to pass a position, I'd vote in > favour of changing that way. > > In any case, once we all agree on a semantics, it should be documented, I > think. Assuming the wrong semantics made me waste time (and, hey, I kind of > invented the language!!), until Fran came along and told me that I had to > pass two pos's and it worked. apertium-preprocess-transfer-bytecode-j has some macro-specific warnings (including this one), and is the closest thing we have to lint for transfer. -- <Sefam> Are any of the mentors around? <jimregan> yes, they're the ones trolling you ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
