You got it. Write out ragel implementations in some generic algol-like language, then translate that to the various languages that ragel supports. The coder writing the translator does not need to understand ragel semantics in depth, only the mapping from the intermediate language to the target language.
Adrian ------Original Message------ From: ragel-u...@jgoettgens.de Sender: ragel-users-boun...@complang.org To: ragel-users ReplyTo: ragel-users Subject: Re: [ragel-users] additional plans for 7.0 Sent: Mar 9, 2013 4:13 PM I see your point. I'd tend to think that the source code is unlikely to look like human written code anyway. So why not use to s.th that is closer to the machine (20 different branch instructions may even look cool). In a way one would always have to think in terms of s.th like an assembler language and the translations to a higher level language would be for practical purposes only. Do you have s.th. like the following in mind? An abstract loop declaration could be mapped in C++ either to individual statements or s.th. that uses an STL algorithm (e.g. for_each). In a way there would be a bunch of higher level building blocks, maybe sometimes with more than 1 option for a single language. So the intermediate language would specify the algorithm essentially in terms of these building blocks. jg _______________________________________________ ragel-users mailing list ragel-users@complang.org http://www.complang.org/mailman/listinfo/ragel-users _______________________________________________ ragel-users mailing list ragel-users@complang.org http://www.complang.org/mailman/listinfo/ragel-users
