I'm sitting here working on a cgi script - in Perl, because the server
it lives on doesn't have Lisp. And I just realized that for sometime
now all my Perl code has started looking like Lisp. I mean both the
indentation, the way I'm piling up ')' and '}' at the end of lines,
and in the long variable and function names. It seems to make it much
easier to write and debug Perl.
Now, if there was just someway to write this Perl in Lisp I'd be
really happy.
Or, at least some way to disable the way the Perl edit mode in emacs
takes over C-M-h so I can't use it for kill-word-backwards like I do
in everything else. !?
-jeff
In article <······························@cunningham.net>,
Jeff Cunningham <·······@cunningham.net> wrote:
> I'm sitting here working on a cgi script - in Perl, because the server
> it lives on doesn't have Lisp. And I just realized that for sometime
> now all my Perl code has started looking like Lisp. I mean both the
> indentation, the way I'm piling up ')' and '}' at the end of lines,
> and in the long variable and function names. It seems to make it much
> easier to write and debug Perl.
I suggest this is a bad idea. When you're writing in Perl, you'll
probably be better off in the long run if you adopt the Perl community's
coding styles. You're occasionally going to have to show your code to
other Perl programmers, or someone else will take over the project, and
they're going to have as hard a time dealing with your ideosyncratic
style as we here often have when people post poorly-indented Lisp code,
or put their parens on separate lines like C code. Coding is not a
solitary activity, it's a communication device, so you should be
sensitive to your readers, and it's not just the compiler/interpreter.
I recently read an essay suggesting that language standards should
incorporate coding style (an extension of Python's use of indentation as
its way of indicating code structure, in place of most languages bracing
or begin/end keywords), so that compilers can enforce it. It sounds
whimsical, but he's probably correct that the gain from using one style
of another is minimal, while the productivity costs from having to deal
with multiple styles can be significant. If any particular style can
really be determined to have a big benefit (pretty unlikely), that's the
one that should be codified in the spec; but in the usual case where
none has a significant benefit, pick the most popular one and make it
the standard.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
On Sat, 10 Sep 2005 15:23:58 -0400, <······@alum.mit.edu> wrote:
> In article <······························@cunningham.net>,
> Jeff Cunningham <·······@cunningham.net> wrote:
>
>> I'm sitting here working on a cgi script - in Perl, because the server
>> it lives on doesn't have Lisp. And I just realized that for sometime
>> now all my Perl code has started looking like Lisp. I mean both the
>> indentation, the way I'm piling up ')' and '}' at the end of lines,
>> and in the long variable and function names. It seems to make it much
>> easier to write and debug Perl.
>
> I suggest this is a bad idea. When you're writing in Perl, you'll
> probably be better off in the long run if you adopt the Perl community's
> coding styles. You're occasionally going to have to show your code to
> other Perl programmers
Just the other day I needed to write a web dataminer, and reluctantly
employed perl (lack of time to master cl-ppcre, lack of a date
manipulation lisp lib, etc). I also noticed that my lisp work had
improved the perl coding. I thought it was some of the best perl code
I had written, and I'm leaving it in the lisp style. It was easy to
read and debug, and thus maintain by the person most likely to get
that task. Once the code is running and effectively in use, I can
spend the conversion time.
I have found that people than can only 'read code' if it is in a
'specific style' rarely have anything useful to add. c.l.l. sees
dozens of examples of poor formatting, and I haven't seen that stop
anyone yet. Furthermore, when someone new comes along to maintain,
the 'not invented here' syndrome strikes, regardless of code clarity.
--
You can always tell a really good idea by the enemies it makes.
On Sat, 10 Sep 2005 13:34:21 -0700, GP lisper wrote:
> I have found that people than can only 'read code' if it is in a
> 'specific style' rarely have anything useful to add. c.l.l. sees dozens
> of examples of poor formatting, and I haven't seen that stop anyone yet.
> Furthermore, when someone new comes along to maintain, the 'not
> invented here' syndrome strikes, regardless of code clarity.
I can't count how many times I've handed off functional code I've written
(some of it pretty good, well commented code, too), only to have the
handoffee never even look at it and go off and write their own. Most
coders hate using other people's code - probably because it makes them
feel like flunkies.
One big benefit I'm seeing in writing lisp is is causes me to focus my
thinking differently. The differences in my Perl aren't just indentation
and placement of parens, there's an organizationsl difference I'm seeing
as well that's making it easier to debug.
-jeff
GP lisper wrote:
> I have found that people than can only 'read code' if it is in a
> 'specific style' rarely have anything useful to add. c.l.l. sees
> dozens of examples of poor formatting, and I haven't seen that stop
> anyone yet.
Anybody competant can read code formatted almost any way in almost any
language. The issue is the extra time it takes people to understand
code written in a style they are not used to. For example, I can read
C code with hungarian notation and StudlyCaps fine, but sometimes it
takes me longer to understand it than when I read more normal C code.
In article <···········································@teranews>,
GP lisper <········@CloudDancer.com> wrote:
> I have found that people than can only 'read code' if it is in a
> 'specific style' rarely have anything useful to add. c.l.l. sees
> dozens of examples of poor formatting, and I haven't seen that stop
> anyone yet. Furthermore, when someone new comes along to maintain,
> the 'not invented here' syndrome strikes, regardless of code clarity.
It's not that they can *only* read code in that style, it's that they
can more *easily* read it. They don't have to waste brain cells trying
to reform your code in their minds, when they could actually be trying
to help you.
The folks who post poorly-formatted code here don't know any better (or
they're using interfaces that mess things up on them). We go out of our
way to help them, but we frequently point out their style mistakes
because we want them to become better members of our community.
I think Real Programmers should be able to use almost any language
that's reasonable and available (if your employer wants to get the most
out of you they'll make your preferred choices available, but there are
often constraints that make it difficult), and adapt to the prevailing
style of that community (not just the language community, but also your
organization -- if they've adopted Hungarian notation, use it while you
campaign against it). I've done significant amounts of programming in
at least a half dozen languages (BASIC, Assembler, PL/I, COBOL, Lisp,
Perl, and various Unix shells are the ones that I can think of off the
top of my head), and I've never once felt the need to program one
language in the prevailing style of another. There's a whole mind-set
associated with a language, and the coding style is part of it. If you
don't fully immerse yourself into that environment, I wouldn't be
surprised if you're ending up with poor code as well (and Perl is *very*
easy to write bad code in). I remember once I was rewriting a C program
in Perl, and the C program had clearly been written by a Lisper -- it
made much more use of linked lists than any ordinary C programmer ever
would, rather than using arrays and realloc(); linked lists are great in
Lisp because we have so many built-in features that work with them, but
in C it just made the program more complex. Luckily I was able to
recognize all the abstract operations that were actually going on, and
rewrite the program at this level, but it took a little while to wrap my
head around the original program because it was such a chimera.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> I recently read an essay suggesting that language standards should
> incorporate coding style (an extension of Python's use of indentation as
> its way of indicating code structure, in place of most languages bracing
> or begin/end keywords), so that compilers can enforce it. It sounds
> whimsical, but he's probably correct that the gain from using one style
> of another is minimal, while the productivity costs from having to deal
> with multiple styles can be significant. If any particular style can
> really be determined to have a big benefit (pretty unlikely), that's the
> one that should be codified in the spec; but in the usual case where
> none has a significant benefit, pick the most popular one and make it
> the standard.
The last thing I need is for the Perl compiler to be yelling at me for
cuddling my elsifs. I get enough of that from other Perl coders who
don't seem to appreciate the scarcity of vertical space.
--
You should maybe check the chemical content of your breakfast
cereal. --- Bill Watterson
Barry Margolin <······@alum.mit.edu> writes:
> I suggest this is a bad idea. When you're writing in Perl, you'll
> probably be better off in the long run if you adopt the Perl community's
> coding styles. [...]
It might be a good idea to contaminate perl programmers with the
superior lisp style.
In any case, most of what you call style could be taken care by the
tools: emacs indents automatically the sources to show it according to
the user's preferences. It could be extended to move punctuation,
even to upcase/downcase and do other compiler-invariant transformations.
--
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
Barry Margolin <······@alum.mit.edu> writes:
> In article <······························@cunningham.net>,
> Jeff Cunningham <·······@cunningham.net> wrote:
>
> > I'm sitting here working on a cgi script - in Perl, because the server
> > it lives on doesn't have Lisp. And I just realized that for sometime
> > now all my Perl code has started looking like Lisp. I mean both the
> > indentation, the way I'm piling up ')' and '}' at the end of lines,
> > and in the long variable and function names. It seems to make it much
> > easier to write and debug Perl.
>
> I suggest this is a bad idea. When you're writing in Perl, you'll
> probably be better off in the long run if you adopt the Perl community's
> coding styles. You're occasionally going to have to show your code to
> other Perl programmers, or someone else will take over the project, and
> they're going to have as hard a time dealing with your ideosyncratic
> style as we here often have when people post poorly-indented Lisp code,
> or put their parens on separate lines like C code. Coding is not a
> solitary activity, it's a communication device, so you should be
> sensitive to your readers, and it's not just the compiler/interpreter.
How strange that in a Lisp newsgroup you could have two people talking
about style, where they only mean the way the characters are arranged
in the file. On that level, I agree with Barry here. In Perl, you
have to pay attention to what lines up with what, where the parens and
curly braces go, how they match, etc., because unlike Lisp, the
superficial syntax isn't regular. Writing Perl that superficially
"looks like" Lisp is a terrible idea, and I would hate to inherit such
a codebase, even more than I would some random Perl codebase.
But there are plenty of deeper lessons you can take with you from Lisp
that will make your Perl code nicer. Using higher-order functions,
for example, semi-functional style, anonymous functions and call-with-
idioms, and dynamic binding. If you're going to use a nonstandard
superficial style, at least use a more classical one, like Lingua
Perligata.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
+---------------
| Barry Margolin <······@alum.mit.edu> writes:
| > Jeff Cunningham <·······@cunningham.net> wrote:
| > > I'm sitting here working on a cgi script - in Perl, because the server
| > > it lives on doesn't have Lisp. And I just realized that for sometime
| > > now all my Perl code has started looking like Lisp. I mean both the
| > > indentation, the way I'm piling up ')' and '}' at the end of lines, ...
| >
| > I suggest this is a bad idea. When you're writing in Perl, you'll
| > probably be better off in the long run if you adopt the Perl community's
| > coding styles.
|
| Writing Perl that superficially "looks like" Lisp is a terrible idea,
| and I would hate to inherit such a codebase, even more than I
| would some random Perl codebase.
|
| But there are plenty of deeper lessons you can take with you from Lisp
| that will make your Perl code nicer. Using higher-order functions,
| for example, semi-functional style, anonymous functions and call-with-
| idioms, and dynamic binding.
+---------------
The lesson from Lisp that has given me the most insight into Perl
was the realization, while reading Sriram Srinivasan's "Advanced
Perl Programming", that Perl's "globs" are almost identical to
"fat" Lisp symbols! ;-} And then all the line-noise started
making sense as simply the various "accessors": ;-} ;-}
*foo == 'foo
$foo == (symbol-value 'foo)
@foo == (symbol-array-value 'foo)
%foo == (symbol-hash-value 'foo)
&foo == (symbol-function 'foo)
FOO == (symbol-stream-value 'foo)
\$foo == (locative (symbol-value 'foo))
O.k., it's not quite that simple, but I do find it a helpful approximation...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Barry Margolin <······@alum.mit.edu> writes:
> In article <······························@cunningham.net>,
> Jeff Cunningham <·······@cunningham.net> wrote:
>
> > I'm sitting here working on a cgi script - in Perl, because the server
> > it lives on doesn't have Lisp. And I just realized that for sometime
> > now all my Perl code has started looking like Lisp. I mean both the
> > indentation, the way I'm piling up ')' and '}' at the end of lines,
> > and in the long variable and function names. It seems to make it much
> > easier to write and debug Perl.
>
> I suggest this is a bad idea. When you're writing in Perl, you'll
> probably be better off in the long run if you adopt the Perl community's
> coding styles. You're occasionally going to have to show your code to
> other Perl programmers, or someone else will take over the project, and
> they're going to have as hard a time dealing with your ideosyncratic
> style as we here often have when people post poorly-indented Lisp code,
> or put their parens on separate lines like C code. Coding is not a
> solitary activity, it's a communication device, so you should be
> sensitive to your readers, and it's not just the compiler/interpreter.
>
> I recently read an essay suggesting that language standards should
> incorporate coding style (an extension of Python's use of indentation as
> its way of indicating code structure, in place of most languages bracing
> or begin/end keywords), so that compilers can enforce it. It sounds
> whimsical, but he's probably correct that the gain from using one style
> of another is minimal, while the productivity costs from having to deal
> with multiple styles can be significant. If any particular style can
> really be determined to have a big benefit (pretty unlikely), that's the
> one that should be codified in the spec; but in the usual case where
> none has a significant benefit, pick the most popular one and make it
> the standard.
>
> --
> Barry Margolin, ······@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
Actually, if I was drawing up a table of pros and cons for perl and
lisp, at the very top would be perl on the 'con' side witht he fact
you can develop such widely different styles in perl - all of which
are legit - in fact you are encouraged to code in whatever style you
are comfortable with. As BM points out, this is not great for
communication and is one reason why I think perl is a great sys admin
tool, but a poor app development tool.
Lisp I would place in the 'pro' column - its very simple syntax means
that to a large extent, you are forced to work with the same style -
while you will see minor differences in style, you can easily reformat
the sources without running the risk of breaking things and everything
looks familir. In perl, its not so simple - some users exploit hidden
variables extensively, others prefer a mroe explicit style, some write
perl which looks like C and others write perl which looks like line
noise, some use prototypes, others don't, some use strict mode others
don't, some prefer 'or', 'and' and 'not' while others prefer ||, &&
and ! (worse yet, they have different precedence) etc.
I've often had to spend sometime getting to grips with someones styles
before I could work out what their code does when its in perl. With
lisp, I've found I can understand at a high level whats going on very
quickly - it may take some time to get the subtler aspects of the
algorithim, but at least my energy is put into the algorithm rather
than coming to grips with a new style.
regards,
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Tim X <····@spamto.devnul.com> writes:
> Lisp I would place in the 'pro' column - its very simple syntax means
> that to a large extent, you are forced to work with the same style -
> while you will see minor differences in style, you can easily reformat
> the sources without running the risk of breaking things and everything
> looks familir. In perl, its not so simple - some users exploit hidden
> variables extensively, others prefer a mroe explicit style, some write
> perl which looks like C and others write perl which looks like line
> noise, some use prototypes, others don't, some use strict mode others
> don't, some prefer 'or', 'and' and 'not' while others prefer ||, &&
> and ! (worse yet, they have different precedence) etc.
I don't quite agree with this. Certainly the complex syntax of Perl
allows more obvious cosmetic style differences. But programming style
goes deeper than that. The simple looking structure of Lisp belies
the fact that there can be as many programming styles as there are
programmers. Paul Graham writes his code one way in ACL and On Lisp.
Peter Norvig writes code a different way in PAIP. Then you have
Keene's examples in OOP in CL. You can freely mix programming
methodologies in Lisp without giving it a second thought.
Maybe an inexperienced Lisp programmer sees nothing but a tree of
parenthesis. But that is not where the style resides in a Lisp
program. Lisp really offers as much freedom of style as prose.
--
You should maybe check the chemical content of your breakfast
cereal. --- Bill Watterson
David Steuber <·····@david-steuber.com> writes:
> Tim X <····@spamto.devnul.com> writes:
>
> > Lisp I would place in the 'pro' column - its very simple syntax means
> > that to a large extent, you are forced to work with the same style -
> > while you will see minor differences in style, you can easily reformat
> > the sources without running the risk of breaking things and everything
> > looks familir. In perl, its not so simple - some users exploit hidden
> > variables extensively, others prefer a mroe explicit style, some write
> > perl which looks like C and others write perl which looks like line
> > noise, some use prototypes, others don't, some use strict mode others
> > don't, some prefer 'or', 'and' and 'not' while others prefer ||, &&
> > and ! (worse yet, they have different precedence) etc.
>
> I don't quite agree with this. Certainly the complex syntax of Perl
> allows more obvious cosmetic style differences. But programming style
> goes deeper than that. The simple looking structure of Lisp belies
> the fact that there can be as many programming styles as there are
> programmers. Paul Graham writes his code one way in ACL and On Lisp.
> Peter Norvig writes code a different way in PAIP. Then you have
> Keene's examples in OOP in CL. You can freely mix programming
> methodologies in Lisp without giving it a second thought.
>
> Maybe an inexperienced Lisp programmer sees nothing but a tree of
> parenthesis. But that is not where the style resides in a Lisp
> program. Lisp really offers as much freedom of style as prose.
>
I think we are at cross purposes here. I agree you can employ many
different programming paradigms using lisp (and perl). However, due to
perl's flexibility/variety of supported syntax, it can be very
difficult to follow code you didn't write. With lisp, while you may
use various paradigms, the simple syntax makes it very quick and easy
to get the basics of what the code does. Admittedly, you may have to
go a grab Keene to read up on lisp objects, or take time to study the
macros the author has used to make his code more domain specific etc.,
but on the whole, you can pick up some lisp code and get a very good
sense for what is going on.
With Perl, I've experienced too many times a situation where it is
very difficult to even understand in high level broad terms what is
going on - in fact, Perl is the worst language for this I've come
across. You often spend so much time trying to follow exactly what is
going on at the code level, you miss the underlying algorithm. Its
very easy to make mistakes because the 'behavior' of the language can
be different depending on how it is used. For example, the difference
in precedence between || and 'or', or the subtle differences between
&subroutine($x) and subroutine($x) or even subroutine $x. You also
need a lot more experience with Perl before you get the same level of
understanding of a piece of code as you do with lisp - this is not to
say lisp doesn't have some important and sometimes difficult to fully
grasp aspects, rather that Perl has far more aspects which don't seem
to have (to me) the same level of logical connections and you often
only realise or find out about some subtle technique after it is
pointed out by someone else.
I've used a lot of perl and in fact, its what finally led me to
lisp. I've worked on a couple of fairly large perl projects which ran
over multiple years and involved many different developers. After that
experience, I'm now very reluctant to embark on a new project which is
to be based on perl and would only consider it if some very clearly
formulated rules are put into place regarding coding style. However,
even with strict procedurres, I've found perl really doesn't scale
well. As a sys admin support tool, I think its great and use it for
such purposes on almost a daily basis. For something quick and dirty
its excellent. However, for something large which will have a long
life requiring maintenance and expansion of functionality and which
will be worked on by a team of people, I wouldn't recommend perl.
Therefore, when I started considering the next project I wanted to
work on, I began to look for something else. I originally looked at
python as people had told me it was good and much better for larger
projects etc. After a fairly short evaluation, I found myself thinking
about Lisp and decided to take another look - I hadn't really ever
done any Lisp - really only just enough to get by when I was working
for a distributed AI research lab. The more I looked at it, the more I
liked it. I started doing a few small programs to solve some of those
annoying little problems we all deal with, but which seldom become
irritating enough for us to bother actually writing code to
solve. Then I read Peter's Practicle Common Lisp book, which finally
convinced me to try using Lisp for my project. So far, things are
looking good. Progress is very slow, mainly because I tend to spend
too much time reassuring myself I undestand things enough to start
designing/coding (always a problem for me with a new language) and
partially because I've got to do this in my spare time, which lately,
I don't seem to have much of. Still, the experience is the main driver
and I have to say, the shift from developing in perl, java, c and c++
to lisp is substantial and requires as much unlearning as learning,
but is the first time I've been excited about coding again in many
many years.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
In article <··············@tiger.rapttech.com.au>,
Tim X <····@spamto.devnul.com> wrote:
> With Perl, I've experienced too many times a situation where it is
> very difficult to even understand in high level broad terms what is
> going on - in fact, Perl is the worst language for this I've come
> across. You often spend so much time trying to follow exactly what is
> going on at the code level, you miss the underlying algorithm.
Which is why I recommend that you stick with common style. Perl is hard
enough to read, you shouldn't make the reader try to navigate your
unusual style as well.
As an analogy, suppose you were trying to read a document in a natural
language that you only have partial fluency in (or maybe it's written in
Italian and you know Spanish, but know that there are lots of
commonalities so you figure you should be able to make do). Then
suppose that it's written with bad handwriting or in a "cute" font. So
now it's both hard to understand *and* hard to read, so you'll probably
just give up unless it's really important.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
On Sat, 10 Sep 2005 10:56:11 -0700, Jeff Cunningham
<·······@cunningham.net> wrote:
>I'm sitting here working on a cgi script - in Perl, because the server
>it lives on doesn't have Lisp. And I just realized that for sometime
>now all my Perl code has started looking like Lisp.
Too bad...
I have similar experience, I once worte C program in Prolog. No
good idea. But this was long ago.
A.L.
Jeff Cunningham <·······@cunningham.net> writes:
> I'm sitting here working on a cgi script - in Perl, because the server
> it lives on doesn't have Lisp. And I just realized that for sometime
> now all my Perl code has started looking like Lisp. I mean both the
> indentation, the way I'm piling up ')' and '}' at the end of lines,
> and in the long variable and function names. It seems to make it much
> easier to write and debug Perl.
>
>
> Now, if there was just someway to write this Perl in Lisp I'd be
> really happy.
>
> Or, at least some way to disable the way the Perl edit mode in emacs
> takes over C-M-h so I can't use it for kill-word-backwards like I do
> in everything else. !?
>
> -jeff
Try M-x cperl-mode for your perl editing. It has mark-defun bound to
C-M-h (which is defined in lisp mode and C-backspace is bound to
backward-kill-word. I think its a better perl editing mode than basic
perl-mode, which seems to be the default 'out of the box' behavior
although both modes are included in standard emacs (from about version
20 onwards I think).
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
On Sun, 11 Sep 2005 11:39:24 +1000, Tim X wrote:
>
> Try M-x cperl-mode for your perl editing. It has mark-defun bound to
> C-M-h (which is defined in lisp mode and C-backspace is bound to
> backward-kill-word. I think its a better perl editing mode than basic
> perl-mode, which seems to be the default 'out of the box' behavior
> although both modes are included in standard emacs (from about version
> 20 onwards I think).
>
> Tim
Wow - that *is* great. Thank you, thank you.
-Jeff
From: Robert Uhl
Subject: Re: My Perl is starting to look like Lisp
Date:
Message-ID: <m3k6hm6jm0.fsf@4dv.net>
Jeff Cunningham <·······@cunningham.net> writes:
>
>> Try M-x cperl-mode for your perl editing. It has mark-defun bound to
>> C-M-h (which is defined in lisp mode and C-backspace is bound to
>> backward-kill-word.
>
> Wow - that *is* great. Thank you, thank you.
Dunno how much you know about emacs, but you can permanently replace
perl-mode with cperl-mode with:
(add-to-list 'auto-mode-alist '("\\.\\([pP][Llm]\\|al\\)\\'" . cperl-mode))
(add-to-list 'interpreter-mode-alist '("perl" . cperl-mode))
(add-to-list 'interpreter-mode-alist '("perl5" . cperl-mode))
(add-to-list 'interpreter-mode-alist '("miniperl" . cperl-mode))
Or you could just do:
(defalias 'perl-mode 'cperl-mode)
Although that'd prevent you from using perl-mode.
--
Robert Uhl <http://public.xdi.org/=ruhl>
[Tobacco] is the passion of honest men and he who lives without tobacco is
not worthy of living. --Moliere
From: Robert Uhl
Subject: Re: My Perl is starting to look like Lisp
Date:
Message-ID: <m3zmqjdut4.fsf@4dv.net>
Jeff Cunningham <·······@cunningham.net> writes:
>
> Now, if there was just someway to write this Perl in Lisp I'd be
> really happy.
This may give you a head start:
http://www.david-steuber.com/snippets/Perl_Is_Not_Lisp/
--
Robert Uhl <http://public.xdi.org/=ruhl>
If your adversary is badly bunkered, there is no rule against your
standing over him and counting his strokes aloud, but it will be a wise
precaution to arm yourself with the niblick before doing so, so as to
meet him on equal terms. --Horace G. Hutchinson, 1886