[27954] in Perl-Users-Digest
Perl-Users Digest, Issue: 9318 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 20 00:06:08 2006
Date: Mon, 19 Jun 2006 21:05:04 -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 Mon, 19 Jun 2006 Volume: 10 Number: 9318
Today's topics:
Re: call an external c++ program <tadmc@augustmail.com>
Embperl and mod_perl support <hobosalesman@gmail.com>
Re: forks from within a perl daemon process? xhoster@gmail.com
Re: forks from within a perl daemon process? xhoster@gmail.com
Re: forks from within a perl daemon process? <tadmc@augustmail.com>
Re: installing Crypt::DES on ActiveState <mothra@nowhereatall.com>
output unbuffered ? <mkjindal@gmail.com>
Re: question on "make test" <tadmc@augustmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <dima@127.0.0.1>
Re: What is Expressiveness in a Computer Language <cfc@shell01.TheWorld.com>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 19 Jun 2006 16:12:13 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: call an external c++ program
Message-Id: <slrne9e4pd.lj9.tadmc@magna.augustmail.com>
debbie523 <Deb.Fang@gmail.com> wrote:
> I am a new hand in this area,
What area?
> could u give me more details?
Details about what?
You get the details on Perl functions by reading the standard
documentation that comes with perl.
If you don't understand what the docs for the system() function
mean, then ask a question about what the docs for system() say.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 19 Jun 2006 18:34:21 -0700
From: "Hobo Salesman" <hobosalesman@gmail.com>
Subject: Embperl and mod_perl support
Message-Id: <1150767261.782072.59010@c74g2000cwc.googlegroups.com>
How widely is mod_perl and Embperl supported by web hosts? I have to
develop a web application that needs to be portable among web hosts. I
want to use Perl, but only if I can use Embperl/mod_perl. My other
optin is PHP5, very widely supported and a little easier/faster, but
seems kind of like driving a volvo when theres a ferrari in the garage.
Portability is a big issue though, having a client's webhost say they
require payment for a dedicated server to use Embperl would be.... bad.
HS
------------------------------
Date: 19 Jun 2006 23:27:45 GMT
From: xhoster@gmail.com
Subject: Re: forks from within a perl daemon process?
Message-Id: <20060619192827.228$Og@newsreader.com>
"Dave" <dszostek@gmail.com> wrote:
> Hi,
>
> I have a program that I have been running via cron that I thought might
> be better run by running it as a daemon. When I created some test
> daemon programs they all worked. When I placed my program inside of the
> while loop, I noticed that the daemon killed its self somehow. I then
> figured out that it died just after it tried launching a new fork
> process -- and when I commented this out it worked fine.
Presumably it died with a message. What was that message?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 19 Jun 2006 23:53:34 GMT
From: xhoster@gmail.com
Subject: Re: forks from within a perl daemon process?
Message-Id: <20060619195416.303$YK@newsreader.com>
"Dave" <dszostek@gmail.com> wrote:
> Hi,
>
> I have a program that I have been running via cron that I thought might
> be better run by running it as a daemon. When I created some test
> daemon programs they all worked. When I placed my program inside of the
> while loop, I noticed that the daemon killed its self somehow. I then
> figured out that it died just after it tried launching a new fork
> process -- and when I commented this out it worked fine.
>
...
>
> Can anyone provide any insight in to why this is not working and
> perhaps give some advice for what I need to do?
> #!/usr/bin/perl
>
> use POSIX qw(setsid);
>
> &daemonize;
>
> #use forks;
You can't call fork manually (which daemonize does) after "use forks;" is
invoked (which happens at compile time), or things go wonky.
so you can either change "use forks;" to:
eval "use forks";
Or you can take the contents of "sub daemonize {...}" and move them into
a BEGIN block which precedes the "use forks" statement.
There seemed to be some other problems with your test code, so I can't
guarantee that this is your only problem....
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 19 Jun 2006 21:51:47 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: forks from within a perl daemon process?
Message-Id: <slrne9eom3.n3g.tadmc@magna.augustmail.com>
Dave <dszostek@gmail.com> wrote:
> I have a program that I have been running via cron that I thought might
> be better run by running it as a daemon.
What did you observe about its behavior that made you think that?
If it isn't broken, then don't fix it.
If it is broken, then tell what is broken about it.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 19 Jun 2006 09:20:51 -0700
From: "Mothra" <mothra@nowhereatall.com>
Subject: Re: installing Crypt::DES on ActiveState
Message-Id: <4496d6f8@usenet.ugs.com>
Amaninder wrote:
> Hi everyone
>
> I want to install Crypt::DES module for my Net::SNMP::Security::USM. I
> am using ActiveState Komodo version 3.5. I tried the following
> things.
>
If you have 5.8.X series of perl
PPM> install http://theoryx5.uwinnipeg.ca/ppms/Crypt-DES
For 5.6 of perl
PPM > install http://theoryx5.uwinnipeg.ca/ppmpackages/Crypt-DES
Hope this helps
Mothra
------------------------------
Date: 19 Jun 2006 20:48:39 -0700
From: "mkjindal@gmail.com" <mkjindal@gmail.com>
Subject: output unbuffered ?
Message-Id: <1150775319.844220.50110@b68g2000cwa.googlegroups.com>
What is the meaning of "$| = 1; # make output unbuffered" ?
I saw this in one of the earlier perl script but don't know exact
meaning of the same.
- "$|" is the OR of regexp after dollar sign.
------------------------------
Date: Mon, 19 Jun 2006 22:03:01 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: question on "make test"
Message-Id: <slrne9epb5.n3g.tadmc@magna.augustmail.com>
Huub <> wrote:
> What is the best thing to do?
The best thing to do is to spend some tiny bit of effort to find
the solution to your problems *before* asking hundreds of other
people to help.
Have you tried googling for the error message text?
I'm afraid I'm going to have to finally give up on you.
It appears that reform is not forthcoming.
So long!
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 19 Jun 2006 15:08:38 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150754918.338770.89870@i40g2000cwc.googlegroups.com>
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > While I am quite sympathetic to this point, I have to say that
> > this horse left the barn quite some time ago.
>
> I don't think so. Perhaps it's futile to go scouring the world for uses
> of the phrase "dynamic type" and eliminating them. It's not useless to
> point out when the term is used in a particularly confusing way, though,
> as when it's implied that there is some class of "type errors" that is
> strictly a subset of the class of "errors". Terminology is often
> confused for historical reasons, but incorrect statements eventually get
> corrected.
That's fair.
One thing that is frustrating to me is that I really want to build
an understanding of what dynamic typing is and what its
advantages are, but it's difficult to have a productive discussion
on the static vs. dynamic topic. Late binding of every function
invocation: how does that work, what are the implications of that,
what does that buy you?
I have come to believe that the two actually represent
very different ways of thinking about programming. Which
goes a long way to explaining why there are such difficulties
communicating. Each side tries to describe to the other how
the tools and systems they use facilitate doing tasks that
don't exist in the other side's mental model.
> > PS. Hi Chris!
>
> Hi! Where are you posting from these days?
I'm mostly on comp.databases.theory, but I also lurk
on comp.lang.functional, which is an awesome group, and
if you're reading Pierce then you might like it too.
Marshall
------------------------------
Date: Mon, 19 Jun 2006 22:02:55 +0000 (UTC)
From: Dimitri Maziuk <dima@127.0.0.1>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <slrne9e7of.po9.dima@yellowtail.bmrb.wisc.edu>
Yet Another Dan sez:
... Requiring an array index to be an integer is considered a typing
> problem because it can be checked based on only the variable itself,
> whereas checking whether it's in bounds requires knowledge about the array.
You mean like
subtype MyArrayIndexType is INTEGER 7 .. 11
type MyArrayType is array (MyArrayIndexType) of MyElementType
Dima
--
We're sysadmins. Sanity happens to other people. -- Chris King
------------------------------
Date: 19 Jun 2006 19:24:00 -0400
From: Chris F Clark <cfc@shell01.TheWorld.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <sddirmwd90v.fsf@shell01.TheWorld.com>
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > While I am quite sympathetic to this point, I have to say that
> > this horse left the barn quite some time ago.
>
> I don't think so. Perhaps it's futile to go scouring the world for uses
> of the phrase "dynamic type" and eliminating them. It's not useless to
> point out when the term is used in a particularly confusing way, though,
> as when it's implied that there is some class of "type errors" that is
> strictly a subset of the class of "errors". Terminology is often
> confused for historical reasons, but incorrect statements eventually get
> corrected.
Ok, so you (Chris Smith) object to the term "dynamic type". From a
historical perspective it makes sense, perticular in the sense of
tags. A dynamic type system involves associating tags with values and
expresses variant operations in terms of those tags, with certain
disallowed combinations checked (dynamicly) at run-time. A static
type system eliminates some set of tags on values by syntactic
analysis of annotations (types) written with or as part of the program
and detects some of the disallowed compuatations (staticly) at compile
time.
Type errors are the errors caught by ones personal sense of which
annotations are expressible, computable, and useful. Thus, each
person has a distinct sense of which errors can (and/or should) be
staticly caught.
A personal example, I read news using Emacs, which as most readers in
these newsgroups will know is a dialect of lisp that includes
primitives to edit files. Most of emacs is quite robust, perhaps due
to it being lisp. However, some commands (reading news being one of
them) are exceptionally fragile and fail in the most undebuggable
ways, often just complaining about "nil being an invalid argument" (or
"stack overflow in regular expression matcher".)
This is particularly true, when I am composing lisp code. If I write
some lisp code and make a typographical error, the code may appear to
run on some sample case and fail due to a path not explored in my
sample case when applied to real data.
I consider such an error to be a "type error" because I believe if I
used a languages that required more type annotations, the compiler
would have caught my typographical error (and no I'm not making a pun
on type and typographical). Because I do a lot of this--it is easy
enough for me to conjure up a small lisp macro to make some edit that
it is a primary tool in my toolkit, I wish I could make my doing so
more robust. It would not bother me to have to type more to do so. I
simply make too many stupid errors to use emacs lisp as effectively as
I would like.
Now, this has nothing to do with real lisp programming, and so I do
not wish to offend those who do that. However, I personally would
like a staticly typed way of writing macros (and more importantly of
annotating some of the existing emacs code) to remove some of the
fragilities that I experience. I'm not taking avantage of the
exploratory nature of lisp, except in the sense that the exploratory
nature has created lots of packages which mostly work most of the
time.
Now, I will return this group to its much more erudite discussion of
the issue.
Thank you,
-Chris
*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
------------------------------
Date: 19 Jun 2006 16:50:04 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150761004.928251.318340@h76g2000cwa.googlegroups.com>
Chris Smith wrote:
> Joe Marshall <eval.apply@gmail.com> wrote:
> >
> > Chris Smith wrote:
> > >
> > > Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
> > > interject my plea not to abuse the word "type" with a phrase like
> > > "dynamically typed".
> >
> > Allow me to strenuously object. The static typing community has its
> > own set of
> > terminology and that's fine. However, we Lisp hackers are not used to
> > this terminology.
> > It confuses us. *We* know what we mean by `dynamically typed', and we
> > suspect *you* do, too.
>
> I know what you mean by types in LISP. The phrase "dynamically typed,"
> though, was explicitly introduced as a counterpart to "statically
> typed" in order to imply (falsely) that the word "typed" has related
> meanings in those two cases.
They *do* have a related meaning. Consider this code fragment:
(car "a string")
Obviously this code is `wrong' in some way. In static typing terms, we
could say that
we have a type error because the primitive procedure CAR doesn't
operate on strings.
Alternatively, we could say that since Lisp has one universal type (in
static type terms)
the code is correctly statically typed - that is, CAR is defined on all
input, but it's definition is to raise a runtime exception when passed
a string.
But regardless of which way you want to look at it, CAR is *not* going
to perform its usual computation and it is *not* going to return a
value. The reason behind this is that you cannot take the CAR of a
string. A string is *not* a valid argument to CAR. Ask anyone why and
they will tell you `It's the wrong type.'
Both `static typing' and `dynamic typing' (in the colloquial sense) are
strategies to detect this sort of error.
> Nevertheless, I did not really object,
> since it's long since passed into common usage,
Exactly. And you are far more likely to encounter this sort of usage
outside of a type theorist's convention.
> until Torben attempted
> to give what I believe are rather meaningless definitions to those
> words, in terms of some mythical thing called "type violations" that he
> seems to believe exist apart from any specific type systems.
It's hardly mythical. (car "a string") is obviously an error and you
don't need a static type system to know that.
> > > This cleaner terminology eliminates a lot of confusion.
> >
> > Hah! Look at the archives.
>
> I'm not sure what you mean here. You would like me to look at the
> archives of which of the five groups that are part of this conversation?
> In any case, the confusion I'm referring to pertains to comparison of
> languages, and it's already been demonstrated once in the half-dozen or
> so responses to this branch of this thread.
I mean that this has been argued time and time again in comp.lang.lisp
and probably the other groups as well. You may not like the fact that
we say that Lisp is dynamically typed, but *we* are not confused by
this usage. In fact, we become rather confused when you say `a
correctly typed program cannot go wrong at runtime' because we've seen
plenty of runtime errors from code that is `correctly typed'.
> > > If types DON'T mean a compile-time method for proving the
> > > absence of certain program behaviors, then they don't mean anything at
> > > all.
> >
> > Nonsense.
>
> Please accept my apologies for not making the context clear. I tried to
> clarify, in my response to Pascal, that I don't mean that the word
> "type" can't have any possible meaning except for the one from
> programming language type theory. I should modify my statement as
> follows:
>
> An attempt to generalize the definition of "type" from programming
> language type theory to eliminate the requirement that they are
> syntactic in nature yields something meaningless. Any concept of
> "type" that is not syntactic is a completely different thing from
> static types.
Agreed. That is why there is the qualifier `dynamic'. This indicates
that it is a completely different thing from static types.
> Basically, I start objecting when someone starts comparing "statically
> typed" and "dynamically typed" as if they were both varieties of some
> general concept called "typed". They aren't.
I disagree. There is clearly a concept that there are different
varieties of data and they are not interchangable. In some languages,
it is up to the programmer to ensure that mistakes in data usage do not
happen. In other languages, the computer can detect such mistakes and
prevent them. If this detection is performed by syntactic analysis
prior to running the program, it is static typing. Some languages like
Lisp defer the detection until the program is run. Call it what you
want, but here in comp.lang.lisp we tend to call it `dynamic typing'.
> Furthermore, these two
> phrases were invented under the misconception that that are. If you
> mean something else by types, such as the idea that a value has a tag
> indicating its range of possible values, then I tend to think it would
> be less confusing to just say "type" and then clarify the meaning it
> comes into doubt, rather than adopting language that implies that those
> types are somehow related to types from type theory.
You may think it would be less confusing, but if you look at the
archives of comp.lang.lisp you would see that it is not.
We're all rubes here, so don't try to educate us with your
high-falutin' technical terms.
------------------------------
Date: 19 Jun 2006 17:58:22 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150765102.867144.12590@h76g2000cwa.googlegroups.com>
Joe Marshall wrote:
>
> They *do* have a related meaning. Consider this code fragment:
> (car "a string")
> [...]
> Both `static typing' and `dynamic typing' (in the colloquial sense) are
> strategies to detect this sort of error.
The thing is though, that putting it that way makes it seems as
if the two approaches are doing the same exact thing, but
just at different times: runtime vs. compile time. But they're
not the same thing. Passing the static check at compile
time is universally quantifying the absence of the class
of error; passing the dynamic check at runtime is existentially
quantifying the absence of the error. A further difference is
the fact that in the dynamically typed language, the error is
found during the evaluation of the expression; in a statically
typed language, errors are found without attempting to evaluate
the expression.
I find everything about the differences between static and
dynamic to be frustratingly complex and subtle.
(To be clear, I do know that Joe understands these issues
quite well.)
So I kind of agree with Chris, insofar as I think the terminology
plays a role in obscuring rather than illuminating the differences.
On the other hand I agree with Joe in that:
> I mean that this has been argued time and time again in comp.lang.lisp
> and probably the other groups as well. You may not like the fact that
> we say that Lisp is dynamically typed, but *we* are not confused by
> this usage. In fact, we become rather confused when you say `a
> correctly typed program cannot go wrong at runtime' because we've seen
> plenty of runtime errors from code that is `correctly typed'.
Yes; as I said ealier, the horse has left the barn on this one.
The conversation I would *really* like to have is the one where we
discuss what all the differences are, functionally, between the two,
and what the implications of those differences are, without trying
to address which approach is "right" or "better", because those are
dependent on the problem domain anyway, and because I can
make up my own mind just fine about which one I prefer.
The comp.lang.functional and comp.lang.lisp people are probably
two of the smartest groups on usenet. (I do not consider myself
a member of either group.) You wouldn't *think* that conversation
would be *so* hard to have.
Marshall
------------------------------
Date: Mon, 19 Jun 2006 21:26:54 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f0118eb59a614fa9896cd@news.altopia.net>
Joe Marshall <eval.apply@gmail.com> wrote:
> They *do* have a related meaning. Consider this code fragment:
> (car "a string")
My feeling is that this code is obviously wrong. It is so obviously
wrong, in fact, that the majority of automated error detection systems,
if written for Lisp, would probably manage to identify it as wrong at
some point. This includes the Lisp runtime. So far, I haven't
mentioned types.
> A string is *not* a valid argument to CAR. Ask anyone why and
> they will tell you `It's the wrong type.'
Indeed, they will. We're assuming, of course that they know a little
Lisp... otherwise, it may be entirely reasonable for someone to expect
that (car "a string") is 'a' and (cdr "a string") is " string"... but
I'll ignore that, even though I haven't yet convinced myself that it's
not relevant to why this is colloquially considered a type error.
I believe that in this sense, the 'anyone' actually means "type" in the
sense that you mean "type". The fact that a static type system detects
this error is somewhat coincidental (except for the fact that, again,
any general error-detection scheme worth its salt probably detects this
error), and orthogonal to whether it is considered a type error by our
hypothetical 'anyone'.
> Both `static typing' and `dynamic typing' (in the colloquial sense) are
> strategies to detect this sort of error.
I will repeat that static typing is a strategy for detecting errors in
general, on the basis of tractable syntactic methods. There are some
types of errors that are easier to detect in such a system than
others... but several examples have been given of problems solved by
static type systems that are not of the colloquial "It's the wrong
type" variety that you mention here. The examples so far have included
detecting division by zero, or array bounds checking. Other type
systems can check dimensionality (correct units).
Another particularly interesting example may be the following from
Ocaml:
let my_sqrt x = if x < 0.0 then None else Some(sqrt(x));;
Then, if I attempt to use my_sqrt in a context that requires a float,
the compiler will complain about a type violation, since the type of the
expression is "float option". So this is a type error *in Ocaml*, but
it's not the kind of thing that gets intuitively classified as a type
error. In fact, it's roughly equivalent to a NullPointerException at
runtime in Java, and few Java programmers would consider a
NullPointerException to be somehow "actually a type error" that the
compiler just doesn't catch. In this case, when the error appears in
Ocaml, it appears to be "obviously" a type error, but that's only
because the type system was designed to catch some class of program
errors, of which this is a member.
> It's hardly mythical. (car "a string") is obviously an error and you
> don't need a static type system to know that.
Sure. The question is whether it means much to say that it's a "type
error". So far, I'd agree with either of two statements, depending on
the usage of the word "type":
a) Yes, it means something, but Torben's definition of a static type
system was wrong, because static type systems are not specifically
looking for type errors.
or
b) No, "type error" just means "error that can be caught by the type
system", so it is circular and meaningless to use the phrase in defining
a kind of type system.
> I mean that this has been argued time and time again in comp.lang.lisp
> and probably the other groups as well.
My apologies, then. It has not been discussed so often in any newsgroup
that I followed up until now, though Marshall has now convinced me to
read comp.lang.functional, so I might see these endless discussions from
now on.
> In fact, we become rather confused when you say `a
> correctly typed program cannot go wrong at runtime' because we've seen
> plenty of runtime errors from code that is `correctly typed'.
Actually, I become a little confused by that as well. I suppose it
would be true of a "perfect" static type system, but I haven't seen one
of those yet. (Someone did email me earlier today to point out that the
type system of a specification language called LOTOS supposedly is
perfect in that sense, that every correctly typed program is also
correct, but I've yet to verify this for myself. It seems rather
difficult to believe.)
Unless I suddenly have some kind of realization in the future about the
feasibility of a perfect type system, I probably won't make that
statement that you say confuses you.
> > An attempt to generalize the definition of "type" from programming
> > language type theory to eliminate the requirement that they are
> > syntactic in nature yields something meaningless. Any concept of
> > "type" that is not syntactic is a completely different thing from
> > static types.
>
> Agreed. That is why there is the qualifier `dynamic'. This indicates
> that it is a completely different thing from static types.
If we agree about this, then there is no need to continue this
discussion. I'm not sure we do agree, though, because I doubt we'd be
right here in this conversation if we did.
This aspect of being a "completely different thing" is why I objected to
Torben's statement of the form: static type systems detect type
violations at compile time, whereas dynamic type systems detect type
violations at runtime. The problem with that statement is that "type
violations" means different things in the first and second half, and
that's obscured by the form of the statement. It would perhaps be
clearer to say something like:
Static type systems detect some bugs at compile time, whereas
dynamic type systems detect type violations at runtime.
Here's one interesting consequence of the change. It is easy to
recognize that static and dynamic type systems are largely orthogonal to
each other in the sense above. Java, for example (since that's one of
the newsgroups on the distribution list for this thread), restricting
the field of view to reference types for simplicity's sake, clearly has
both a very well-developed static type system, and a somewhat well-
developed dynamic type system. There are dynamic "type" errors that
pass the compiler and are caught by the runtime; and there are errors
that are caught by the static type system. There is indeed considerable
overlap involved, but nevertheless, neither is made redundant. In fact,
one way of understanding the headaches of Java 1.5 generics is to note
that the two different meanings of "type errors" are no longer in
agreement with each other!
> We're all rubes here, so don't try to educate us with your
> high-falutin' technical terms.
That's not my intention.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Mon, 19 Jun 2006 21:31:37 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f011a01ffcb49649896ce@news.altopia.net>
I <cdsmith@twu.net> wrote:
> Static type systems detect some bugs at compile time, whereas
> dynamic type systems detect type violations at runtime.
PS: In order to satisfy the Python group (among others not on the cross-
post list), we'd need to include "duck typing," which fits neither of
the two definitions above. We'd probably need to modify the definition
of dynamic type systems, since most source tend to classify it as a
dynamic type system. It's getting rather late, though, and I don't
intend to think about how to do that.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
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 9318
***************************************
