From: Shriramana S. <sa...@gm...> - 2012-08-06 07:04:21
|
Hi Martin -- thanks for your reply. On Mon, Aug 6, 2012 at 9:09 AM, Martin Hosken <mar...@si...> wrote: > One option might be to add a slot attribute .glyphid or somesuch that could be tested: > cons > geminate / cons _ {glyphid == @1.glyphid}; Another option might be to allow some kind of foreach construct in the language. But perhaps that would be somewhat deviating from the existing language model. And without LHS referencing, it still would not be useful for much more than geminates. (Neither would glyphid slot attributes.) Although, honestly I cannot imagine what real case other than geminates would need to be supported. In my Tamil Brahmi GDL, I had to do 18 series of: KA + clsVowelSigns -> KA-series NGA + clsVowelSigns -> NGA-series and so on. (But that was because the glyph developer had made pre-composed glyphs which I realized later are not necessary.) But if GDL had for and treated classes like arrays, we could always use a two dimensional array: for x = 1 to 18: for y = 1 to 12: cons[x] vs[y] > syllable[x][y] ;-) > #define GEM(x, y) x > y / x _ > GEM(g_a, g_a_gem); > GEM(g_b, g_b_gem); > etc. Well if it came to typing everything out, this is only a little less cumbersome than the full version. I'm sure right now we can use Python (or some such scripting language) to output the requisite statements using *its* for loop. -- Shriramana Sharma |