Re: With the Macrame macro system, Perl may now be a Lisp.
On 7 Dec 2007, at 23:31, Andy Lester wrote: [snip] mantra CPAN thrives because of the unfettered uploading of shit, not in spite of it. /mantra [snip] ++ ** Inf Adrian
Re: With the Macrame macro system, Perl may now be a Lisp.
A. Pagaltzis schreef: Most of the modules that give me the heebie jeebies just never took off; I never had to install IO::All or Spiffy, say. I love those, so I am unable to understand any objections. -- Affijn, Ruud Gewoon is een tijger.
Re: With the Macrame macro system, Perl may now be a Lisp.
* Guy Hulbert [EMAIL PROTECTED] [2007-12-07 22:45]: Academic thinking again. CGI is highly successful. It *was* highly successful. * Jenda Krynicky [EMAIL PROTECTED] [2007-12-08 02:25]: If you live long enough you see every victory turn into defeat, but that doesn't mean it was not a victory originaly. And the original premise of the subthread was that we should not be putting defeats on the CPAN. In light of your statement that all victories turn into defeats in the long run, I think we can safely conclude that the premise was false. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: With the Macrame macro system, Perl may now be a Lisp.
* Dr.Ruud [EMAIL PROTECTED] [2007-12-08 13:50]: A. Pagaltzis schreef: Most of the modules that give me the heebie jeebies just never took off; I never had to install IO::All or Spiffy, say. I love those, so I am unable to understand any objections. Nor do you need to. We can perfectly happily disagree. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: With the Macrame macro system, Perl may now be a Lisp.
Guy Hulbert wrote: I think you can count something as successful if it gets to 1.0 or if the author says it works (i.e. if in v 0.17 he says that the next version will be 1.0 but never actually does the final release then we can count that as a success). You'd better not use Data::Compare then, or anything that uses anything that uses anything that uses it, cos it's only version 0.17 and I'm *not* going to make the next version (if there is one) 1.0. But it's successful enough that a fair number of people rely on it. And that's after they took the time to read the documentation and try the code out, instead of just judging it by the version number. -- David Cantrell | Godless Liberal Elitist
Re: With the Macrame macro system, Perl may now be a Lisp.
--- Guy Hulbert [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 15:26 -0600, Jonathan Rockway wrote: BTW, I like the term failed experiment. Isn't everything a failed experiment? Should we remove CGI.pm from the CPAN because CGI.pm-style code is a failed experiment in writing web applications? Academic thinking again. CGI is highly successful. It's highly successful in the way that COBOL* is highly successful: for a while it was the main game in town and if you wanted to play, that's what you played. Now that CGI.pm is old and outdated (even Lincoln Stein has admitted that he'd write it differently today), we're largely stuck with it for legacy issues. Inertia is not the same thing success. Cheers, Ovid * I'm an ex-COBOL programmer and I know exactly what I'm talking about here. -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: With the Macrame macro system, Perl may now be a Lisp.
On Sat, 2007-12-08 at 00:30 +0100, A. Pagaltzis wrote: * Guy Hulbert [EMAIL PROTECTED] [2007-12-07 21:50]: CPAN is also littered with failed experiments. So is the fossil record. Good thing nature didn’t quit experimenting a billion years ago. Note that I understand your concern. But, I see two possible I am unconcerned. I just adjust my behaviour to deal with it. It's just a PITA when looking to see if something has been done before. outcomes: Macrame fizzles out, without getting much use; -- --gh
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, Dec 07, 2007 at 03:45:26PM -0500, Guy Hulbert wrote: On Fri, 2007-12-07 at 14:28 -0600, Jonathan Rockway wrote: On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 I do. I do, so that's at least 3 people. experiments have been quite successful; for example, Moose. macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. I think you could be a bit more charitable in your interpretation of Bill's opinions. He certainly didn't manage to control you very well. Because perl modules can install their own dependencies, his concern is other people affecting *his* choices. One particular problem can be that if something you use adds a dependency on something else you weren't previously using, so you can reach the situation where upgrading to fix a bug will also bring in something new that you didn't want (for valid local policy reasons). Nicholas Clark
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 6, 2007 7:22 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Bill Ward # on Thursday 06 December 2007 16:23: Cute experiment, but I REALLY hope nobody tries releasing useful modules to CPAN that depend on this... Cute comment, but I really hope nobody puts any stock in it. What skin is it off of your nose if a useful module uses something you're afraid of? Sorry to be snarky. What I was getting at was that I need to support Perl modules in a production environment, and experiments like this may be academically interesting but introduce levels of instability and inefficiency that are not consistent with that environment. If modules that we need to use are based on it, then I have a difficult decision as to whether the module is wotrh that risk just so Perl can be written in a more Lisp-like manner. Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. And from a Perl advocacy perspective, instead of making Perl more attractive to the hordes of Lisp programmers out there, I think we should be more interested in making Perl 5 attractive for real world uses.
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 7, 2007, at 5:30 PM, A. Pagaltzis wrote: * Guy Hulbert [EMAIL PROTECTED] [2007-12-07 21:50]: CPAN is also littered with failed experiments. So is the fossil record. Good thing nature didn’t quit experimenting a billion years ago. mantra CPAN thrives because of the unfettered uploading of shit, not in spite of it. /mantra xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: With the Macrame macro system, Perl may now be a Lisp.
* Guy Hulbert [EMAIL PROTECTED] [2007-12-07 21:50]:
CPAN is also littered with failed experiments.
So is the fossil record. Good thing nature didn’t quit
experimenting a billion years ago.
Note that I understand your concern. But, I see two possible
outcomes: Macrame fizzles out, without getting much use; in the
grand scheme of things this is the most likely. In that case it
doesn’t matter whether it’s problematic or not. Or it takes off
unexpectedly, resulting in lots of people beating on it and
ironing out the worst kinks. In that case you can probably have
more confidence in it.
Most of the modules that give me the heebie jeebies just never
took off; I never had to install IO::All or Spiffy, say. So I
don’t worry, and neither should you.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 20:54 +, Nicholas Clark wrote: One particular problem can be that if something you use adds a dependency on something else you weren't previously using, so you can reach the situation where upgrading to fix a bug will also bring in something new that you didn't want (for valid local policy reasons). All I'm saying is that you can't control what other people do. People experimenting with Perl 5 aren't going to stop simply because someone on the mailing list says it might make his job harder. If dependencies are a big problem for your business, learn to fix the CPAN modules, or don't depend on them at all. I get upset when arguing about this because I have never had a problem, and I depend on a metric fuckton of CPAN modules. (I'm sure a nit has come up from time to time, but I just send a patch to the author and it's fixed forever.) BTW, I like the term failed experiment. Isn't everything a failed experiment? Should we remove CGI.pm from the CPAN because CGI.pm-style code is a failed experiment in writing web applications? Should we all stop using emacs because elisp's lack of static scope is a failed experiment? Should we forget about java because single inheritance is a failed experiment? Should we stop using Perl because TMTOWTDI is a failed experiment? To be clear, my point is that everyone thinks differently. What you consider failure many consider success. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 6, 2007, at 20:30, David Nicol wrote: I'm sort of stuck on how much records of line numbers of expanded rewrites to keep and how to encode them into the filename portion of the #line comment. In practice, debugging macros is maddening if you can't locate where the macro is being used and where it was defined. Sometimes the macro definition is at fault, and sometimes it's being used incorrectly. Filter::Template (source code filter for macros) does it this way: # line $line_number template $name (defined in $template_file at line $template_def_line) invoked from $filename Every line of the expanded template is preceded by a # line $invocation_line entry, which ensures that a warn() or die() messages are nice, but totally mucks with Perl's debugger. The problem there is that Perl stores the source code as an array using line numbers as offsets. Only the last line at a particular line number will display in the debugger. Around the time I wrote this, I kinda wished for non-integer line numbers. A 10-line expansion could have line numbers 14.1 through 14.10, with the original invocation as a comment on 14.0. -- Rocco Caputo - [EMAIL PROTECTED]
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: On Dec 6, 2007 7:22 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Bill Ward # on Thursday 06 December 2007 16:23: Cute experiment, but I REALLY hope nobody tries releasing useful modules to CPAN that depend on this... Cute comment, but I really hope nobody puts any stock in it. What skin is it off of your nose if a useful module uses something you're afraid of? Sorry to be snarky. What I was getting at was that I need to support Perl modules in a production environment, and experiments like this How do you support Perl modules in a production environment ? My preference is to not allow developers near the production servers and my clients (in theory) make the developers test the code on the staging server. Any modules available system wide, I build individually (or get from the o/s - debian). I try to avoid CPAN because of automatic dependency import. may be academically interesting but introduce levels of instability and inefficiency that are not consistent with that environment. If modules that we need to use are based on it, then I have a difficult decision as to whether the module is wotrh that risk just so Perl can be written in a more Lisp-like manner. Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. And from a Perl advocacy perspective, instead of TMTOWTDI. You are way way too late for this. making Perl more attractive to the hordes of Lisp programmers out there, I think we should be more interested in making Perl 5 attractive for real world uses. I'm switching to python wherever practical. DRY is much less chaotic. -- --gh
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 14:28 -0600, Jonathan Rockway wrote: On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 I do. experiments have been quite successful; for example, Moose. CPAN is also littered with failed experiments. The great thing about Perl is you can choose what to use. Don't like True but it is also a weakness in some environments. macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. I think you could be a bit more charitable in your interpretation of Bill's opinions. He certainly didn't manage to control you very well. Because perl modules can install their own dependencies, his concern is other people affecting *his* choices. Regards, Jonathan Rockway -- --gh
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 experiments have been quite successful; for example, Moose. The great thing about Perl is you can choose what to use. Don't like macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
Cute experiment, but I REALLY hope nobody tries releasing useful modules to CPAN that depend on this... On Nov 29, 2007 9:51 PM, David Nicol [EMAIL PROTECTED] wrote: Macrame 0.08 finally passes a variety of tests and has been uploaded. Please harangue it via rt.cpan.org.
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 6, 2007 6:23 PM, Bill Ward [EMAIL PROTECTED] wrote:
Cute experiment, but I REALLY hope nobody tries releasing useful
modules to CPAN that depend on this...
Thank you
After it has line number support it will be more practically useful.
I'm sort of stuck on how much records of line numbers of expanded rewrites to
keep and how to encode them into the filename portion of the #line comment.
imagine:
#line 1000 fileF.pl
use Macrame; # line comments apply to the next line; this is line 1000
macro cheddar {cheese}
warn cheddar;
macro warn_wisconsin { warn cheddar}
warn_wisconsin;
__END__
the easiest thing is to keep line number information that
is available during lexing and output the line number
whenever it changes in the stringification:
#line 1002 fileF.pl
warn cheese;
#line 1003
warn cheese;
__END__
next tricky is to have an macros inherit their line numbers
from wherever they are invoked, giving
#line 1002 fileF.pl
warn cheese;
#line 1004
warn cheese;
__END__
even if the warn_wisconsin macro is several lines long
is it worth the trouble to have warnings inside macros show
a full expansion history as a debugging aid? That's the current
goal for the next release, with a history syntax of appending
something to the filename portion of the eventual comment:
#line 1002 fileF.pl
warn cheese;
#line 1004 fileF.pl:1003
warn cheese;
__END__
when macros start appearing in different files from where
they are expanded, the debugging comments will start
looking something like
#line 765 applicaiton.pl:maclib.pm:8970:234:basic_macros.pm:22
--
Common sense has prevailed
Re: With the Macrame macro system, Perl may now be a Lisp.
* David Cantrell [EMAIL PROTECTED] [2007-12-03 23:35]: If I ever need to do that, I'll run my code through the C pre-processor before releasing it. The C preprocessor is (surprise!) really bad at understanding Perl syntax. All the source filter modules on CPAN aren’t very good at parsing Perl either, but at least they’re specifically targetting it, so they tend to get more common cases right than the CPP which readily breaks the simplest things. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: With the Macrame macro system, Perl may now be a Lisp.
On Sat, Dec 01, 2007 at 05:51:27PM +0100, Jenda Krynicky wrote: Premature optimization is the root of all evil. OTOH, being able to inline functions could be nice, yes. If I ever need to do that, I'll run my code through the C pre-processor before releasing it. -- David Cantrell | Cake Smuggler Extraordinaire While researching this email, I was forced to carry out some investigative work which unfortunately involved a bucket of puppies and a belt sander -- after JoeB, in the Monastery
Re: With the Macrame macro system, Perl may now be a Lisp.
From: David Nicol [EMAIL PROTECTED]
On Nov 30, 2007 7:24 PM, Jenda Krynicky [EMAIL PROTECTED] wrote:
I'm missing the reason-for-being of the module it its docs. I read
the whole documentation and the test script and I still don't get it.
What is it supposed to be used for?
Sorry, Jenda
polymorphic functions / more complex prototypes
Any examples?
creating new syntax without dealing directly with unlexed source
Looking at the KNOWN BUGS it doesn't look like this works too well.
Any examples of a new syntax that you would like to be able to
create? So that we can see how close would we be able to get without
using source filters.
inlining small oft-used code snippets without all those pesky function calls
Premature optimization is the root of all evil.
OTOH, being able to inline functions could be nice, yes.
perl advocacy to Lisp snobs (':)')
snobs can't be convinced. No matter the kind.
Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
Re: With the Macrame macro system, Perl may now be a Lisp.
On Sat, 2007-12-01 at 23:36 +0100, Jenda Krynicky wrote: Yes, I know it is a source filter. And has all the problems of source filters ... that is it can misunderstand something, transform your source code in completely unexpected way and cause next to impossible to find bugs. As such it needs to do something really really important to warrant the danger. This is why I've been ignoring it :) Even the simplest of simple filters like Filter::EOF can go massively wrong. (Multiple packages in a file? You're fucked.) Source filters should be considered a failed experiment, like pseudohashes. IMO, Devel::Declare is the right way to do this sort of thing. Messy code, but much safer to use (and more tests; the test shiped with Macrame scares me with how little it covers). Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
From: David Nicol [EMAIL PROTECTED] Macrame 0.08 finally passes a variety of tests and has been uploaded. Please harangue it via rt.cpan.org. I'm missing the reason-for-being of the module it its docs. I read the whole documentation and the test script and I still don't get it. What is it supposed to be used for? Sorry, Jenda = [EMAIL PROTECTED] === http://Jenda.Krynicky.cz = When it comes to wine, women and song, wizards are allowed to get drunk and croon as much as they like. -- Terry Pratchett in Sourcery
Re: With the Macrame macro system, Perl may now be a Lisp.
On Nov 30, 2007 7:24 PM, Jenda Krynicky [EMAIL PROTECTED] wrote:
I'm missing the reason-for-being of the module it its docs. I read
the whole documentation and the test script and I still don't get it.
What is it supposed to be used for?
Sorry, Jenda
polymorphic functions / more complex prototypes
creating new syntax without dealing directly with unlexed source
inlining small oft-used code snippets without all those pesky function calls
perl advocacy to Lisp snobs (':)')
--
wheels reinvented while-U-wait
With the Macrame macro system, Perl may now be a Lisp.
Macrame 0.08 finally passes a variety of tests and has been uploaded. Please harangue it via rt.cpan.org.
