Syntactic sugar was Module Name

2004-12-29 Thread khemir nadim
Hi Alberto,

Terrence Brannon [EMAIL PROTECTED] wrote in message news  RULES foo
  aa==bb
  cd==ef
  ENDRULES

 I don't get it. Are you just creating syntactics sugar for:

 my %rules =
( aa = 'bb',
  cd = 'ef'
  );

 Terrence Brannon wrote:
 your original post said something about regular expressions.
 RULES foo
 a(b+)c==c$1a!!length($1)5
 ENDRULES
 
 so, abbbc gets cbbba if the number of b greater than 5.

  I believe you can do everything that this module does using
  Parse::RecDescent.
 You can do everything any module does using Perl... don't get your point.
 Alberto.

I must admit I share Terrence's view.

In my opinion, Syntactic sugar that brings no new functionality is best
avoided (YMMV)
and if you need something for a specific application, the module shall not
be presented as
a module implementing some generic functionality. Read me right, I believe
it's OK to have
application specific modules but if the app is not generaly available, maybe
th emodule is
better kept out of CPAN.

Perl gives the possibility to ondent and present data in many ways, maybe
you should think
of letting perl do the dirty job for you.

Now this is not only theoretical chat, I have first hand experience I want
to share with you.
We have discussed build system and build tools together on another thread;
Instead for going
for a new syntax or writting a parser for a known syntax, I used perl  to
define rules.

Here are some example:

AddRule [VIRTUAL], 'project', [ 'all' = 'msf/all' ], BuildOk('Project
built.') ;

AddRule 'c_objects', [ '*/*.o' = '*.c' ] ,
   %CC %CFLAGS %CDEFINES ... %FILE_TO_BUILD -c %DEPENDENCY_LIST

Those look like make rules but are perl functions. Then I can do much more
complicated stuff
if I want to:

AddRule 'rule_3',
   [ AndMatch(qr\.c$, NoMatch(qr/xx/)) = '$path/$basename.h'] ;

Of course the AddRule function has to be written and maintained but I leave
the parsing _and_
error reporting to perl.

In the example bellow I forget a dot to concatenate strings

AddConfig 'EXTRA_LDFLAGS'= GetPerlEmbedConfig('LDFLAGS_INCLUDE')  .
GetPerlEmbedConfig('LDFLAGS') ;

I get:
String found where operator expected at './Pbsfile.pl' line 4, near )  
(Missing operator before  ?)

Had I written an own parser, I'd have to handle this too.

Here is another example (real life too):
I had a module that allowed me to have configs in this format:

SMED_FORMAT_CLASSES
olive_green 202 255 112 ...
grey 128 128 128
unwanted_separator black cyan
upper_case default olive_green

SMED_FORMAT_CLASSES

then the module did some magic to have all conversions done properly etc...

I now do it this way:

AddConfigTo  'colors' =
olive_green = [202, 255, 112]
grey= [128, 128, 128]
...

AddConfigTo  'colors_tuples' =
   unwanted_separator = ['black', 'cyan'] ,
   upper_case   = [[0, 0, 0] , 'olive_green']
  ...
NormalizeColorTupless('color_tupless') ;

Don't get fooled by the 'AddConfigTo' (It does configuration checking)
in a simpler case using a hash directely would have been best.

The setup time for writting a config files is longer but it takes very
little time
to _not_ write a module. Once setupn it doesn't take any longer to add
config.

One extra benefit I got from this is that the config can be real object
would I decide
so:

AddConfigTo  'colors' =
olive_green   = \GetRandomColor

I still would need to check what I get in the config but I do not need to
update any parser.

IMHO, if you are going to run something in perl, it's best to write it in
perl.

Cheers, Nadim.

PS: I agree that Parse::RecDescent is too slow to be usable but writtin a
proper parser
is often worth the time compare with an ad-hoc one.









Re: Syntactic sugar was Module Name

2004-12-29 Thread Alberto Manuel Brandao Simoes
Khemir, check the module and its generated code. I don't think it is 
syntactic sugar. If it is, every module on cpan is.

Of course I can write is as a function that receives the rules and 
returns the function reference. That is what the module does in its 
internals, but the code readability really decreases.

Sincerelly,
Alberto.

khemir nadim wrote:
Hi Alberto,

Terrence Brannon [EMAIL PROTECTED] wrote in message news  RULES foo
aa==bb
cd==ef
ENDRULES
I don't get it. Are you just creating syntactics sugar for:
my %rules =
  ( aa = 'bb',
cd = 'ef'
);

Terrence Brannon wrote:
your original post said something about regular expressions.
RULES foo
a(b+)c==c$1a!!length($1)5
ENDRULES
so, abbbc gets cbbba if the number of b greater than 5.

I believe you can do everything that this module does using
Parse::RecDescent.
You can do everything any module does using Perl... don't get your point.
Alberto.

I must admit I share Terrence's view.
In my opinion, Syntactic sugar that brings no new functionality is best
avoided (YMMV)
and if you need something for a specific application, the module shall not
be presented as
a module implementing some generic functionality. Read me right, I believe
it's OK to have
application specific modules but if the app is not generaly available, maybe
th emodule is
better kept out of CPAN.
Perl gives the possibility to ondent and present data in many ways, maybe
you should think
of letting perl do the dirty job for you.
Now this is not only theoretical chat, I have first hand experience I want
to share with you.
We have discussed build system and build tools together on another thread;
Instead for going
for a new syntax or writting a parser for a known syntax, I used perl  to
define rules.
Here are some example:
AddRule [VIRTUAL], 'project', [ 'all' = 'msf/all' ], BuildOk('Project
built.') ;
AddRule 'c_objects', [ '*/*.o' = '*.c' ] ,
   %CC %CFLAGS %CDEFINES ... %FILE_TO_BUILD -c %DEPENDENCY_LIST
Those look like make rules but are perl functions. Then I can do much more
complicated stuff
if I want to:
AddRule 'rule_3',
   [ AndMatch(qr\.c$, NoMatch(qr/xx/)) = '$path/$basename.h'] ;
Of course the AddRule function has to be written and maintained but I leave
the parsing _and_
error reporting to perl.
In the example bellow I forget a dot to concatenate strings
AddConfig 'EXTRA_LDFLAGS'= GetPerlEmbedConfig('LDFLAGS_INCLUDE')  .
GetPerlEmbedConfig('LDFLAGS') ;
I get:
String found where operator expected at './Pbsfile.pl' line 4, near )  
(Missing operator before  ?)
Had I written an own parser, I'd have to handle this too.
Here is another example (real life too):
I had a module that allowed me to have configs in this format:
SMED_FORMAT_CLASSES
olive_green 202 255 112 ...
grey 128 128 128
unwanted_separator black cyan
upper_case default olive_green
SMED_FORMAT_CLASSES
then the module did some magic to have all conversions done properly etc...
I now do it this way:
AddConfigTo  'colors' =
olive_green = [202, 255, 112]
grey= [128, 128, 128]
...
AddConfigTo  'colors_tuples' =
   unwanted_separator = ['black', 'cyan'] ,
   upper_case   = [[0, 0, 0] , 'olive_green']
  ...
NormalizeColorTupless('color_tupless') ;
Don't get fooled by the 'AddConfigTo' (It does configuration checking)
in a simpler case using a hash directely would have been best.
The setup time for writting a config files is longer but it takes very
little time
to _not_ write a module. Once setupn it doesn't take any longer to add
config.
One extra benefit I got from this is that the config can be real object
would I decide
so:
AddConfigTo  'colors' =
olive_green   = \GetRandomColor
I still would need to check what I get in the config but I do not need to
update any parser.
IMHO, if you are going to run something in perl, it's best to write it in
perl.
Cheers, Nadim.
PS: I agree that Parse::RecDescent is too slow to be usable but writtin a
proper parser
is often worth the time compare with an ad-hoc one.



--
Alberto Simões - Departamento de Informática - Universidade do Minho
,,__
   ..  ..   / o._)   .---.
  /--'/--\  \-'||...' '.
 /\_/ / |  .'  '..' '-.
   .'\  \__\  __.'.' .'  ì-._
 )\ |  )\ |  _.'
// \\ // \\
   ||_  \\|_  \\_ Perl Monger
   mrf '--' '--'' '--'www.perl-hackers.net