Syntactic sugar was Module Name
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: detecting the invoking perl
--- [EMAIL PROTECTED] wrote: Hi All. In the bryar distribution, i write out a bryar-newblog script that sets up a blog in the current directory. There is a bug filed on rt.cpan.org about this script's reliance on /usr/bin/perl. *If* I understand what you're asking, read the docs for: http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.25/lib/ExtUtils/MakeMaker.pm The bug you are referring to appears to be: http://rt.cpan.org/NoAuth/Bug.html?id=6588 bryar-newblog is referenced in the EXE_FILES of the Makefile.PL. and it's shebang line is #!/usr/bin/perl. According to the ExtUtils::MakeMaker docs: If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl. So, if the bug author is still finding the shebang line is wrong, I would suggest either they ran Makefile.PL with the wrong Perl or there is a bug in their ExtUtils::MakeMaker setup. Does this answer the question? Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: detecting the invoking perl
Quoting Ovid [EMAIL PROTECTED]: http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.25/lib/ExtUtils/MakeMaker.pm The bug you are referring to appears to be: http://rt.cpan.org/NoAuth/Bug.html?id=6588 bryar-newblog is referenced in the EXE_FILES of the Makefile.PL. and it's shebang line is #!/usr/bin/perl. According to the ExtUtils::MakeMaker docs: If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl. So, if the bug author is still finding the shebang line is wrong, I would suggest either they ran Makefile.PL with the wrong Perl or there is a bug in their ExtUtils::MakeMaker setup. Does this answer the question? Yes it does. Cool. I was always concerned about this, but haven't had an impetus to find out what the deal was/fix it until i wanted to close out that bug. Thanks Randall and Ovid for the pointers. /me ducks now for not reading the make maker documentation. It never occurred to me that this was install magic. -jason gessner [EMAIL PROTECTED]
Re: Syntactic sugar was Module Name
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
