12 Jun
2006
12 Jun
'06
5:24 p.m.
>> "SIGOURE" == SIGOURE Benoit
<sigoure.benoit(a)lrde.epita.fr> writes:
https://svn.lrde.epita.fr/svn/xrm/trunk
Index: ChangeLog
from SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr>
Add RIVF's equivalent in XRM meta-code.
Usage: xrm-front -i rivf.xpm -o rivf.pm -D
-D stands for --desugar (it will add an additional pass after the
main pipeline to desugar as much as possible everything and perform
constant propagation). This is completely optional.
One thing has been omitted here: support for battery_mode=0 (which is
basically the same thing but without bothering with b[x][y] and
without having to check at every update whether or not we should go
in the OFF state because we run out of power). I omitted this for the
sake of clarity although it's fairly straightforward to add it (since
it's only a matter of commenting out some lines).
It is really nice. However, the M4 solution remains clearer IMHO.
Functions will be most welcome.
13 Jun
13 Jun
4:54 p.m.
New subject: XRM 54: Add RIVF's equivalent in XRM meta-code.
On 2006-06-12, Akim Demaille <akim(a)lrde.epita.fr> wrote:
I don't agree :)
Although I agree it's not *that* good, you can write a single file in XRM
with a nice reading flow. You also benefit from the fact that you're not
carrying around chunks of text, transformations are performed on an AST, many
of them are checked to ensure consistency throughout the pipeline etc.
It doesn't require any scripting skills. You want to write modules, you just
write modules. You don't have to bother with surrounding scripts etc.
I'm not sure that functions will suddenly make it clearer.
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
>>
"SIGOURE" == SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes:
https://svn.lrde.epita.fr/svn/xrm/trunk
Index: ChangeLog
from SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr>
Add RIVF's equivalent in XRM meta-code.
Usage: xrm-front -i rivf.xpm -o rivf.pm -D
-D stands for --desugar (it will add an additional pass after the
main pipeline to desugar as much as possible everything and perform
constant propagation). This is completely optional.
One thing has been omitted here: support for battery_mode=0 (which is
basically the same thing but without bothering with b[x][y] and
without having to check at every update whether or not we should go
in the OFF state because we run out of power). I omitted this for the
sake of clarity although it's fairly straightforward to add it (since
it's only a matter of commenting out some lines).
It is really nice. However, the M4 solution remains clearer IMHO.
Functions will be most welcome.
6787
days inactive
6788
days old
1 comments
2 participants
participants (2)
-
Akim Demaille -
Tsuna