[28029] in Perl-Users-Digest
Perl-Users Digest, Issue: 9393 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 27 14:15:16 2006
Date: Tue, 27 Jun 2006 11:15:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 27 Jun 2006 Volume: 10 Number: 9393
Today's topics:
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <gneuner2/@comcast.net>
Re: What is Expressiveness in a Computer Language <duane@franz.com>
Re: What is Expressiveness in a Computer Language <sleepingsquirrel@yahoo.com>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <deets@nospam.web.de>
Re: What is Expressiveness in a Computer Language <qcd.apprentice@gmail.com>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
WIN32 PPM and perldoc problems jovo.miskin@sciatl.com
Re: WIN32 PPM and perldoc problems <jl_post@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 27 Jun 2006 14:03:27 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <PUaog.484573$xt.282436@fe3.news.blueyonder.co.uk>
Marshall wrote:
> The real question is, are there some programs that we
> can't write *at all* in a statically typed language, because
> they'll *never* be typable?
In a statically typed language that has a "dynamic" type, all
dynamically typed programs are straightforwardly expressible.
In a statically typed, Turing-complete language that does not have a
"dynamic" type, it is always *possible* to express a dynamically typed
program, but this may require a global transformation of the program
or use of an interpreter -- i.e. the "Felleisen expressiveness" of the
language is reduced.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 27 Jun 2006 08:04:49 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151420689.919204.12770@x69g2000cwx.googlegroups.com>
Ketil Malde wrote:
> "Marshall" <marshall.spight@gmail.com> writes:
>
> > There are also what I call "packaging" issues, such as
> > being able to run partly-wrong programs on purpose so
> > that one would have the opportunity to do runtime analysis
> > without having to, say, implement parts of some interface
> > that one isn't interested in testing yet. These could also
> > be solved in a statically typed language. (Although
> > historically it hasn't been done that way.)
>
> I keep hearing this, but I guess I fail to understand it. How
> "partly-wrong" do you require the program to be?
>
> During development, I frequently sprinkle my (Haskell) program with
> 'undefined' and 'error "implement later"' - which then lets me run the
> implemented parts until execution hits one of the 'undefined's.
>
> The "cost" of static typing for running an incomplete program is thus
> simply that I have to name entities I refer to. I'd argue that this
> is good practice anyway, since it's easy to see what remains to be
> done. (Python doesn't seem to, but presumably a serious dynamically
> typed system would warn about references to entities not in scope?)
I'll give you my understanding of it, but bear in mind that I only
program
in statically typed languages, and I in fact do exactly what you
decribe
above: stub out unimplemented methods.
The issue is that, while stubbing out things may not be expensive,
it is not free either. There is some mental switching cost to being
in a state where one writes some code, wants to execute it, but
can't, because of type system constraints that are globally applicable
but not locally applicable to the task at hand, or to the specific
subprogram one is working on right at that moment.
Since I'm very used to doing it, it doesn't seem like an issue to
me, but programmers in dynamical languages complain bitterly
about this. It is my feeling that programming languages should
try to be inclusive, and since this feature is easily enough
accomodated, (as a 'lenient' switch to execution) it ought
to be.
Marshall
------------------------------
Date: 27 Jun 2006 08:08:03 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151420883.426116.288300@b68g2000cwa.googlegroups.com>
David Hopwood wrote:
> Marshall wrote:
> > The real question is, are there some programs that we
> > can't write *at all* in a statically typed language, because
> > they'll *never* be typable?
>
> In a statically typed language that has a "dynamic" type, all
> dynamically typed programs are straightforwardly expressible.
So, how does this "dynamic" type work? It can't simply be
the "any" type, because that type has no/few functions defined
on it. It strikes me that *when* exactly binding happens will
matter. In a statically typed language, it may be that all
binding occurs at compile time, and in a dynamic language,
it may be that all binding occurs at runtime. So you might
have to change the binding mechanism as well. Does the
"dynamic" type allow this?
Marshall
------------------------------
Date: Tue, 27 Jun 2006 11:42:07 -0400
From: George Neuner <gneuner2/@comcast.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <k0i2a2hhibfn7oadjdd753bklcv24darhd@4ax.com>
On Mon, 26 Jun 2006 13:02:33 -0600, Chris Smith <cdsmith@twu.net>
wrote:
>George Neuner <gneuner2/@comcast.net> wrote:
>
>> I worked in signal and image processing for many years and those are
>> places where narrowing conversions are used all the time - in the form
>> of floating point calculations reduced to integer to value samples or
>> pixels, or to value or index lookup tables. Often the same
>> calculation needs to be done for several different purposes.
>
>These are value conversions, not type conversions. Basically, when you
>convert a floating point number to an integer, you are not simply
>promising the compiler something about the type; you are actually asking
>the compiler to convert one value to another -- i.e., see to it that
>whatever this is now, it /becomes/ an integer by the time we're done.
>This also results in a type conversion, but you've just converted the
>value to the appropriate form. There is a narrowing value conversion,
>but the type conversion is perfectly safe.
We're talking at cross purposes. I'm questioning whether a strong
type system can be completely static as some people here seem to
think. I maintain that it is simply not possible to make compile time
guarantees about *all* runtime behavior and that, in particular,
narrowing conversions will _always_ require runtime checking.
>> I can know that my conversion of floating point to integer is going to
>> produce a value within a certain range ... but, in general, the
>> compiler can't determine what that range will be.
>
>If you mean "my compiler can't", then this is probably the case. If you
>mean "no possible compiler could", then I'm not sure this is really very
>likely at all.
Again, the discussion is about narrowing the result. It doesn't
matter how much the compiler knows about the ranges. When the
computation mixes types, the range of the result can only widen as the
compiler determines the types involved.
George
--
for email reply remove "/" from address
------------------------------
Date: Tue, 27 Jun 2006 08:53:44 -0700
From: Duane Rettig <duane@franz.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <o0sllqh9x3.fsf@franz.com>
Ketil Malde <ketil+news@ii.uib.no> writes:
> "Marshall" <marshall.spight@gmail.com> writes:
>
>> There are also what I call "packaging" issues, such as
>> being able to run partly-wrong programs on purpose so
>> that one would have the opportunity to do runtime analysis
>> without having to, say, implement parts of some interface
>> that one isn't interested in testing yet. These could also
>> be solved in a statically typed language. (Although
>> historically it hasn't been done that way.)
>
> I keep hearing this, but I guess I fail to understand it. How
> "partly-wrong" do you require the program to be?
This conclusion is false. To be "wrong", whether partly or fully,
a program needs to specifically not conform to the requirements that
the programmer gives it. You are assuming that only a completed
program can be right. Let me give a counterexample:
Consider this part of a CL program:
CL-USER(1): (defun foo (x)
(declare (optimize speed (safety 0) (debug 0))
(fixnum x)
)
(bar (the fixnum (1+ x))))
FOO
CL-USER(2):
This is of course not a complete program, because the function BAR is
not yet defined. If I try to run it, it will of course get an error.
But does that require then that I call this a "partly wrong" program?
No, of course not; it is not a program; it is a function, and for my
purposes it is completely correct (I've debugged it already :-)
So what can we do with an incomplete program? Nothing? Well, no. Of
course, we can't run it (or can we?). But even before talking about
running the program, we can at least do some reasoning about it:
1. It seems to have some static type declarations (in a dynamic
langiuage? oh my :-).
2. The 1+ operation limits the kinds of operations that would be
acceptable, even in the absence of static type declarations.
3. The declarations can be ignored by the CL implementation, so #2
might indeed come into play. I ensured that the declarations would
be "trusted" in Allegro CL, by declaring high speed and low safety.
4. I can compile this function. Note that I get a warning about the
incompleteness of the program:
CL-USER(2): (compile 'foo)
Warning: While compiling these undefined functions were referenced: BAR.
FOO
NIL
NIL
CL-USER(3):
5. I can disassemble the function. Note that it is a complete
function, despite the fact that BAR is undefined:
CL-USER(3): (disassemble 'foo)
;; disassembly of #<Function FOO>
;; formals: X
;; constant vector:
0: BAR
;; code start: #x406f07ec:
0: 83 c0 04 addl eax,$4
3: 8b 5e 12 movl ebx,[esi+18] ; BAR
6: b1 01 movb cl,$1
8: ff e7 jmp *edi
CL-USER(4):
6. I can _even_ run the program! Yes, I get an error:
CL-USER(4): (foo 10)
Error: attempt to call `BAR' which is an undefined function.
[condition type: UNDEFINED-FUNCTION]
Restart actions (select using :continue):
0: Try calling BAR again.
1: Return a value instead of calling BAR.
2: Try calling a function other than BAR.
3: Setf the symbol-function of BAR and call it again.
4: Return to Top Level (an "abort" restart).
5: Abort entirely from this (lisp) process.
[1] CL-USER(5):
7. But note first that I have many options, including retrying the
call to BAR. What was this call to BAR? I can reason about that as
well, by getting a backtrace:
[1] CL-USER(5): :zoom
Evaluation stack:
(ERROR #<UNDEFINED-FUNCTION @ #x406f3dfa>)
->(BAR 11)
[... EXCL::%EVAL ]
(EVAL (FOO 10))
(TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP)
(TPL:START-INTERACTIVE-TOP-LEVEL
#<TERMINAL-SIMPLE-STREAM [initial terminal io] fd 0/1 @ #x40120e5a>
#<Function TOP-LEVEL-READ-EVAL-PRINT-LOOP> ...)
[1] CL-USER(6):
8. If I then define BAR, with or without compiling it, and then take
that option to retry the call:
[1] CL-USER(6): (defun bar (x) (1- x))
BAR
[1] CL-USER(7): :cont
10
CL-USER(8):
Hmm, I was able to complete the program dynamically? Who ever heard
of doing that? :-)
> During development, I frequently sprinkle my (Haskell) program with
> 'undefined' and 'error "implement later"' - which then lets me run the
> implemented parts until execution hits one of the 'undefined's.
Why do it manually? And what do you do when you've hit the undefined?
Start the program over?
> The "cost" of static typing for running an incomplete program is thus
> simply that I have to name entities I refer to. I'd argue that this
> is good practice anyway, since it's easy to see what remains to be
> done.
Good practice, yes, but why not have the language help you to practice
it?
--
Duane Rettig duane@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
------------------------------
Date: 27 Jun 2006 09:21:57 -0700
From: "Greg Buchholz" <sleepingsquirrel@yahoo.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151425317.853996.5040@b68g2000cwa.googlegroups.com>
Chris F Clark wrote:
> Very impressive. It looks right to me and simple enough to
> understand. I must find the time to learn a modern FP language. Can
> you write a fold for this that prints the data as a binary tree of
> triples? I have to believe it isn't that hard....
{- Refactoring this as a fold is left as an exercise to the reader -}
data Clark a b c = Nil | Cons a (Clark b c (a,a)) deriving Show
clark =
(Cons 42 (Cons 3.14 (Cons "abc"
(Cons (1,2) (Cons (1.2,3.4) (Cons ("foo","bar")
(Cons ((9,8),(7,6)) (Cons ((0.1,0.2),(0.3,0.4))
(Cons (("w","x"),("y","z")) Nil)))))))))
main = print (toTree clark)
data Tree a = Empty | Node a (Tree a) (Tree a) deriving Show
toTree :: Clark a b c -> Tree (a,b,c)
toTree (Cons x (Cons y (Cons z rest)))
= Node (x,y,z)
(toTree (fst (lift_c rest)))
(toTree (snd (lift_c rest)))
toTree _ = Empty
lift_c :: Clark (a,a) (b,b) (c,c) -> (Clark a b c, Clark a b c)
lift_c Nil = (Nil,Nil)
lift_c (Cons (x,y) rest) = (Cons x (fst (lift_c rest)),
Cons y (snd (lift_c rest)))
------------------------------
Date: 27 Jun 2006 09:22:30 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151425350.679754.278820@i40g2000cwc.googlegroups.com>
Marshall wrote:
>
> Yes, an important question (IMHO the *more* important question
> than the terminology) is what *programs* do we give up if we
> wish to use static typing? I have never been able to pin this
> one down at all.
It would depend on the type system, naturally.
It isn't clear to me which programs we would have to give up, either.
I don't have much experience in sophisticated typed languages. It is
rather easy to find programs that baffle an unsophisticated typed
language (C, C++, Java, etc.).
Looking back in comp.lang.lisp, I see these examples:
(defun noisy-apply (f arglist)
(format t "I am now about to apply ~s to ~s" f arglist)
(apply f arglist))
(defun blackhole (argument)
(declare (ignore argument))
#'blackhole)
But wait a sec. It seems that these were examples I invented in
response to the same question from you!
>
> The real question is, are there some programs that we
> can't write *at all* in a statically typed language, because
> they'll *never* be typable?
Certainly! As soon as you can reflect on the type system you can
construct programs that type-check iff they fail to type-check.
> > Perhaps, there is no such beast. Or, perhaps I just can't formulate
> > it. Or, perhaps we have static type checkers which can do
> > computations of unbounded complexity. However, I thought that one of
> > the characteristics of type systems was that they did not allow
> > unbounded complexity and weren't Turing Complete.
>
> The C++ type system is Turing complete, although in practical terms
> it limits how much processing power it will spend on types at
> compile time.
I think templates only have to expand to seven levels, so you are
severely limited here.
> > If you allow Turing Complete type systems, then I would say no--every
> > bug can be reforumlated as a type error. If you require your type
> > system to be less powerful, then some bugs must escape it.
>
> I don't think so. Even with a Turing complete type system, a program's
> runtime behavior is still something different from its static behavior.
> (This is the other side of the "types are not tags" issue--not only
> is it the case that there are things static types can do that tags
> can't, it is also the case that there are things tags can do that
> static types can't.)
I agree. The point of static checking is to *not* run the program. If
the type system gets too complicated, it may be a de-facto interpreter.
------------------------------
Date: Tue, 27 Jun 2006 18:37:22 +0200
From: "Diez B. Roggisch" <deets@nospam.web.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4gd56eF1n07dbU1@uni-berlin.de>
>> The C++ type system is Turing complete, although in practical terms
>> it limits how much processing power it will spend on types at
>> compile time.
>
> I think templates only have to expand to seven levels, so you are
> severely limited here.
You can adjust the iteration-depth. However, as turing-complete implies the
potential to create infinite loops - it enforces _some_ boundary. Otherwise
the user hitting C-c will do :)
Diez
------------------------------
Date: Tue, 27 Jun 2006 11:54:03 -0500
From: QCD Apprentice <qcd.apprentice@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7rnra$m3k$3@news.doit.wisc.edu>
Joe Marshall wrote:
> Marshall wrote:
>> Yes, an important question (IMHO the *more* important question
>> than the terminology) is what *programs* do we give up if we
>> wish to use static typing? I have never been able to pin this
>> one down at all.
>
> It would depend on the type system, naturally.
>
> It isn't clear to me which programs we would have to give up, either.
> I don't have much experience in sophisticated typed languages. It is
> rather easy to find programs that baffle an unsophisticated typed
> language (C, C++, Java, etc.).
>
> Looking back in comp.lang.lisp, I see these examples:
>
> (defun noisy-apply (f arglist)
> (format t "I am now about to apply ~s to ~s" f arglist)
> (apply f arglist))
>
> (defun blackhole (argument)
> (declare (ignore argument))
> #'blackhole)
>
> But wait a sec. It seems that these were examples I invented in
> response to the same question from you!
>
>
>> The real question is, are there some programs that we
>> can't write *at all* in a statically typed language, because
>> they'll *never* be typable?
>
> Certainly! As soon as you can reflect on the type system you can
> construct programs that type-check iff they fail to type-check.
Sorry, but can you elaborate on this last point a little? I think I
missed something.
------------------------------
Date: Tue, 27 Jun 2006 17:17:23 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <DKdog.484675$xt.25388@fe3.news.blueyonder.co.uk>
Marshall wrote:
> David Hopwood wrote:
>>Marshall wrote:
>>
>>>The real question is, are there some programs that we
>>>can't write *at all* in a statically typed language, because
>>>they'll *never* be typable?
>>
>>In a statically typed language that has a "dynamic" type, all
>>dynamically typed programs are straightforwardly expressible.
>
> So, how does this "dynamic" type work?
<http://citeseer.ist.psu.edu/abadi89dynamic.html>
> It can't simply be the "any" type, because that type has no/few
> functions defined on it.
It isn't. From the abstract of the above paper:
[...] even in statically typed languages, there is often the need to
deal with data whose type cannot be determined at compile time. To handle
such situations safely, we propose to add a type Dynamic whose values are
pairs of a value v and a type tag T where v has the type denoted by T.
Instances of Dynamic are built with an explicit tagging construct and
inspected with a type safe typecase construct.
"Gradual typing" as described in
<http://www.cs.rice.edu/~jgs3847/pubs/pubs/2006/siek06:_gradual.pdf> is
another alternative. The difference between gradual typing and a
"dynamic" type is one of convenience rather than expressiveness --
gradual typing does not require explicit tagging and typecase constructs.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Tue, 27 Jun 2006 11:48:53 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f0b1d6c361e87ed989720@news.altopia.net>
George Neuner <gneuner2/@comcast.net> wrote:
> We're talking at cross purposes. I'm questioning whether a strong
> type system can be completely static as some people here seem to
> think. I maintain that it is simply not possible to make compile time
> guarantees about *all* runtime behavior and that, in particular,
> narrowing conversions will _always_ require runtime checking.
Nah, we're not at cross-purposes. I'm discussing the same thing you
are. My answer is that while narrowing conversion are not (by
definition) type-safe, a sufficiently strong type system can remove
these type-unsafe narrowing conversions from a program.
> Again, the discussion is about narrowing the result. It doesn't
> matter how much the compiler knows about the ranges. When the
> computation mixes types, the range of the result can only widen as the
> compiler determines the types involved.
Well, there are certain operations that can reduce the range. For
example, dividing a number that's known to be in the range 6-10 by the
exact constant 2 yields a result that's guaranteed to be in the range 3-
5. That's a smaller range.
That said, though, there is a more fundamental point here. When you
perform a a narrowing type conversion, one of two things must be true:
(a) you know more about the types than the compiler, and thus know that
the conversion is safe, or (b) your code is broken. Exluding the
possibility that you've written buggy code, you must possess some
knowledge that convinces you the conversion is safe. In that case, we
need only allow the type system to have that same knowledge, and the
problem is solved.
(One thing worth pointing out here is that it's quite possible that you
want to do something different depending on the kind of data. In that
case, the sufficiently powerful type system would need to have rules so
that an if statemement creates a modified type environment to take that
into account. This is different from a runtime type check, in that you
are writing explicit code that provides correct program behavior in
either case.)
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Tue, 27 Jun 2006 11:50:03 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f0b1db7c8cc6aab989721@news.altopia.net>
Dr.Ruud <rvtol+news@isolution.nl> wrote:
> > So it seems to me that we have this ideal point at which it is
> > possible to write all correct or interesting programs, and impossible
> > to write buggy programs.
>=20
> I think that is a misconception. Even at the idealest point it will be
> possible (and easy) to write buggy programs. G=F6del!
I agree. I never said that the ideal point is achievable... only that=20
there is a convergence toward it. (In some cases, that convergence may=20
have stalled at some equilibrium point because of the costs of being=20
near that point.)
--=20
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 27 Jun 2006 10:53:41 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151430821.728345.31600@p79g2000cwp.googlegroups.com>
David Hopwood wrote:
> Marshall wrote:
> > David Hopwood wrote:
> >>Marshall wrote:
> >>
> >>>The real question is, are there some programs that we
> >>>can't write *at all* in a statically typed language, because
> >>>they'll *never* be typable?
> >>
> >>In a statically typed language that has a "dynamic" type, all
> >>dynamically typed programs are straightforwardly expressible.
> >
> > So, how does this "dynamic" type work?
>
> <http://citeseer.ist.psu.edu/abadi89dynamic.html>
>
> > It can't simply be the "any" type, because that type has no/few
> > functions defined on it.
>
> It isn't. From the abstract of the above paper:
>
> [...] even in statically typed languages, there is often the need to
> deal with data whose type cannot be determined at compile time. To handle
> such situations safely, we propose to add a type Dynamic whose values are
> pairs of a value v and a type tag T where v has the type denoted by T.
> Instances of Dynamic are built with an explicit tagging construct and
> inspected with a type safe typecase construct.
Well, all this says is that the type "dynamic" is a way to explicitly
indicate the inclusion of rtti. But that doesn't address my objection;
if a typesafe typecase construct is required, it's not like using
a dynamic language. They don't require typecase to inspect values
before one can, say, invoke a function.
> "Gradual typing" as described in
> <http://www.cs.rice.edu/~jgs3847/pubs/pubs/2006/siek06:_gradual.pdf> is
> another alternative. The difference between gradual typing and a
> "dynamic" type is one of convenience rather than expressiveness --
> gradual typing does not require explicit tagging and typecase constructs.
Perhaps this is the one I should read; it sounds closer to what I'm
talking about.
Marshall
------------------------------
Date: 27 Jun 2006 09:29:14 -0700
From: jovo.miskin@sciatl.com
Subject: WIN32 PPM and perldoc problems
Message-Id: <1151425754.317964.309690@i40g2000cwc.googlegroups.com>
I ahve installed Active Perl v5.8.7 build 813 on WindowsXP machine.
Executing PPM gives this output:
C:\Perl\bin>ppm
Unknown or ambiguous command '*'; type 'help' for commands.
C:\Perl\bin>
Executing perldoc gives this output:
C:\Perl\bin>perldoc
Usage: perldoc.bat [-h] [-V] [-r] [-i] [-v] [-t] [-u] [-m] [-n
nroffer_program]
[-l] [-T] [-d output_filename] [-o output_format] [-M
FormatterModuleNameToUse]
[-w formatter_option:option_value] [-F] [-X]
PageName|ModuleName|ProgramName
perldoc.bat -f PerlFunc
perldoc.bat -q FAQKeywords
The -h option prints more help. Also try "perldoc perldoc" to get
acquainted with the system. [Perldoc v3.14]
C:\Perl\bin>perldoc -f gmtime
Syntax error
Bad command or file name
C:\Perl\bin>
I've tried reinstalling Active Perl a few times, but the problem
persisted.
Any idea, what is wrong in my setup, preventing these utlities to
execut properly ?
Thanks in advance !
------------------------------
Date: 27 Jun 2006 10:58:06 -0700
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: WIN32 PPM and perldoc problems
Message-Id: <1151431085.985214.113740@i40g2000cwc.googlegroups.com>
jovo.miskin@sciatl.com wrote:
>
> C:\Perl\bin>perldoc
<snip>
> perldoc.bat -f PerlFunc
> perldoc.bat -q FAQKeywords
>
> C:\Perl\bin>perldoc -f gmtime
> Syntax error
> Bad command or file name
>
> I've tried reinstalling Active Perl a few times, but the problem
> persisted.
This is just a suggestion, but have you tried running perldoc with
the ".bat" extension as mentioned in the output of "perldoc"?
I would try the command:
C:\> C:\Perl\bin\perldoc.bat -f gmtime
and see if that helps.
I hope something works...
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9393
***************************************
