[28099] in Perl-Users-Digest
Perl-Users Digest, Issue: 9463 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 13 14:10:16 2006
Date: Thu, 13 Jul 2006 11:10:06 -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 Thu, 13 Jul 2006 Volume: 10 Number: 9463
Today's topics:
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <rossberg@ps.uni-sb.de>
Re: What is a type error? <dnew@san.rr.com>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <jo@durchholz.org>
Re: What is a type error? <cdsmith@twu.net>
Windows services in PERL harvar007@yahoo.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Jul 2006 08:05:02 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152803102.013470.164540@m73g2000cwd.googlegroups.com>
Andreas Rossberg wrote:
> Marshall wrote:
> >
> > Okay, sure. But for the problem you describe, both imperativeness
> > and the presence of pointers is each necessary but not sufficient;
> > it is the two together that causes the problem. So it strikes
> > me (again, a very minor point) as inaccurate to describe this as
> > a problem with imperative languages per se.
> >
> > [...]
> >
> > Right. To me the response to this clear: give up pointers. Imperative
> > operations are too useful to give up; indeed they are a requirement
> > for certain problems. Pointers on the other hand add nothing except
> > efficiency and a lot of confusion. They should be considered an
> > implementation technique only, hidden behind some pointerless
> > computational model.
>
> Don't get yourself distracted by the low-level notion of "pointer". The
> problem *really* is mutability and the associated notion of identity,
> which explicit pointers just exhibit on a very low level.
>
> When you have a language with mutable types (e.g. mutable arrays) then
> objects of these types have identity, which is observable through
> assignment. This is regardless of whether identity is an explicit
> concept (like it becomes with pointers and comparison of pointer values,
> i.e. addresses).
Hmmm, well, I cannot agree. You've defined away the pointers
but then slipped them back in again by assumption ("objects
of these types have identity".)
First let me say that the terminology is somewhat problematic.
For the specific issue being discussed here, pointers, identity,
and objects are all the same concept. (I agree that "pointer"
connotes a low-level construct, however.) Sometimes I think
of this issue as being one with first class variables. An object
with mutable fields is a variable, and if we have pointers or
references or any way to have two different pathways to
that object/those variables, then we run in to the aliasing problem.
However if the mutable types are not first class, then there
is no way to have the aliasing. Thus, if we do not have pointers
or objects or identity but retain mutability, there is no aliasing
problem.
> Consequently, you cannot possibly get rid of aliasing issues without
> getting rid of (unrestricted) mutability. Mutability implies object
> identity implies aliasing problems.
Mutability by itself does not imply identity. I agree that mutability
plus
identity implies aliasing problems, however.
> On the other hand, pointers are totally a futile concept without
> mutability: if everything is immutable, it is useless to distinguish
> between an object and a pointer to it.
Agreed.
> In other words, pointers are essentially just an *aspect* of mutability
> in lower-level languages.
Again, I disagree: it is posible to have mutability without
pointers/identity/objects.
Marshall
------------------------------
Date: 13 Jul 2006 08:45:49 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152805549.184625.117520@s13g2000cwa.googlegroups.com>
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> Joachim Durchholz wrote:
> >>>> Marshall schrieb:
> >>>>> I can see the lack of a formal model being an issue, but is the
> >>>>> imperative bit really all that much of an obstacle? How hard
> >>>>> is it really to deal with assignment? Or does the issue have
> >>>>> more to do with pointers, aliasing, etc.?
> >>>> Actually aliasing is *the* hard issue.
> >>> Okay, sure. Nice explanation.
> >>>
> >>> But one minor point: you describe this as an issue with "imperative"
> >>> languages. But aliasing is a problem associated with pointers,
> >>> not with assignment.
> >> Aliasing is not a problem if the aliased data is immutable.
> >
> > Okay, sure. But for the problem you describe, both imperativeness
> > and the presence of pointers is each necessary but not sufficient;
> > it is the two together that causes the problem. So it strikes
> > me (again, a very minor point) as inaccurate to describe this as
> > a problem with imperative languages per se.
>
> Sure.
> It's just that I know that it's viable to give up destructive updates.
> Giving up pointers is a far more massive restriction.
Oddly, I feel the opposite. While it's true there are many domains
for which purely functional programming is a fine choice, there
are some domains for which it is insufficient. Any kind of data
managament, for example, requires that you be able to update
the information.
On the other hand, there is no problem domain for which pointers
are a requirement. I agree they are deucedly convenient, though.
> > Right. To me the response to this clear: give up pointers. Imperative
> > operations are too useful to give up; indeed they are a requirement
> > for certain problems.
>
> I don't know any.
> In some cases, you need an additional level of conceptual indirection -
> instead of *doing* the updates, you write a function that *describes* them.
But then what do you do with that function? Let's say I have an
employee database. John Smith just got hired on 1/1/2006 with
a salary of $10,000. I need to record this fact somewhere. How
do I do that without variables? Current-employees is a variable.
Even if I have the space to keep all historical data, so I'm not
deleting anything, I still have to have a variable for the latest
version of the accumulated data. I can solve this without
pointers, but I can't solve it without variables.
> > Pointers on the other hand add nothing except
> > efficiency and a lot of confusion. They should be considered an
> > implementation technique only, hidden behind some pointerless
> > computational model.
> >
> > I recognize that this is likely to be a controversial opinion.
>
> Indeed.
>
> In fact "modes" are a way to restrict pointer aliasing.
I should like to learn more about these. I have some vague
perception of the existence of linear logic, but not much
else. However, I also already have an excellent solution
to the pointer aliasing problem, so I'm less motivated.
> > I heartily support immutability as the default, for these and other
> > reasons.
>
> OK, then we're in agreement here.
>
> >> Some functional languages restrict assignment so that there can exist at
> >> most a single reference to any mutable data structure. That way, there's
> >> still no aliasing problems, but you can still update in place where it's
> >> really, really necessary.
> >
> > Are we speaking of uniqueness types now? I haven't read much about
> > them, but it certainly seems like an intriguing concept.
>
> Yup.
> It's called "modes" in some other languages (Mercury or Clean IIRC).
Cool.
> >> I know of no professional language that doesn't have references of some
> >> kind.
> >
> > Ah, well. I suppose I could mention prolog or mercury, but then
> > you used that troublesome word "professional." So I will instead
> > mention a language which, if one goes by number of search results
> > on hotjobs.com for "xxx progammer" for different value of xxx, is
> > more popular than Java and twice as popular as C++. It lacks
> > pointers (although I understand they are beginning to creep in
> > in the latest version of the standard.) It also posesses a quite
> > sophisticated set of facilities for declarative integrity constraints.
> > Yet for some reason it is typically ignored by language designers.
> >
> > http://hotjobs.yahoo.com/jobseeker/jobsearch/search_results.html?keywords_all=sql+programmer
>
> Oh, right. SQL is an interesting case of getting all the problems of
> pointers without having them ;-)
Oh, pooh. SQL has plenty of problems, sure, but the problems
of pointers are not among its faults.
> Actually SQL has references - they are called "primary keys", but they
> are references nevertheless.
I strongly object; this is quite incorrect. I grant you that from the
50,000 foot level they appear identical, but they are not. To
qualify as a reference, there need to be reference and dereference
operations on the reference datatype; there is no such operation
is SQL.
Would you say the relational algebra has references?
Or, consider the classic prolog ancestor query. Let's say we're
setting up as follows
father(bob, joe).
father(joe, john).
Is "joe" a reference, here? After all, when we do the ancestor
query for john, we'll see his father is joe and then use that to
find joe's father. Keys in SQL are isomorphic to joe in the
above prolog.
> (Some SQL dialects also offer synthetic
> "ID" fields that are guaranteed to remain stable over the lifetime of a
> record.
Primary keys are updatable; there is nothing special about them.
> Seems like SQL is imperative enough that programmers want this,
> else the SQL vendors wouldn't have added the feature...)
I believe you are making a statement about the general level of
education among the user base of data base management systems,
and not a statement about the nature of the relational algebra.
> SQL also has updates.
Yes; SQL is imperative. But no pointers and thus no aliasing.
Plenty of *other* problems, though; no argument there!
> The result: updates with undefined semantics. E.g. if you have a numeric
> key field, UPDATE commands that increment the key by 1 will fail or work
> depending on the (unspecified) order in which UPDATE touches the
> records.
This does not sound correct to me, and in any event does not
appear to illustrate anything about aliasing.
> You can have even more fun with updatable views.
I suppose. Views are something for which the practice has
rushed ahead of the theoretical foundation out of need. The
"right" way to do views is not yet known. Again: plenty of
problems with SQL, but no aliasing. (Actually, there probably
is aliasing with SQL99, since IIUC they've gone ahead and
introduced reference types. (Cue Charlton Heston on the beach
saying "You Maniacs! You blew it up! Ah, damn you!"))
> With a "repeatable read" isolation level, you actually return to a
> declarative view of the database: whatever you do with it, you won't see
> it until you commit the transaction. (As soon as you commit, the
> declarative peace is over and you better watch out that your data
> doesn't become inconsistent due to aliasing.)
Alas, transaction isolation levels are a performance hack.
I cannot defend them on any logical basis. (Aside: did you mean
serializable, rather than repeatable read?)
> Aliasing isn't really related to specific programming practices. If two
> accountants chat, and one talks about the hot blonde secretaire and the
> other about his adorable wife, you can imagine the awkwardness that
> ensues as soon as they find out they're talking about the same person!
Heh, that's not aliasing. That's the undecidability of intentional
function equivalence. <joke>
> The only thing that can really be done about it is not adding it
> artificially into a program. In those cases where aliasing is part of
> the modelled domain, you really have to carefully inspect all
> interactions and never, never, never dream about abstracting it away.
Yes, aliasing introduces a lot of problems. This is one reason
why closures make me nervous.
Marshall
------------------------------
Date: Thu, 13 Jul 2006 17:35:35 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is a type error?
Message-Id: <e95p87$a45id$2@hades.rz.uni-saarland.de>
Marshall wrote:
>
> However if the mutable types are not first class, then there
> is no way to have the aliasing. Thus, if we do not have pointers
> or objects or identity but retain mutability, there is no aliasing
> problem.
Yes, technically you are right. But this makes a pretty weak notion of
mutability. All stateful data structures had to stay within their
lexical scope, and could never be passed to a function. For example,
this essentially precludes object-oriented programming, because you
could not have objects with state (the alternative, second class
objects, would be even less "objective").
Generally, second-classness is an ad-hoc restriction that can work
around all kinds of problems, but rarely with satisfactory results. So I
would tend to say that this is not an overly interesting point in the
design space. But YMMV.
>>In other words, pointers are essentially just an *aspect* of mutability
>>in lower-level languages.
>
> Again, I disagree: it is posible to have mutability without
> pointers/identity/objects.
OK, if you prefer: it is an aspect of first-class mutability - which is
present in almost all imperative languages I know. :-)
- Andreas
--
Andreas Rossberg, rossberg@ps.uni-sb.de
------------------------------
Date: Thu, 13 Jul 2006 17:01:00 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is a type error?
Message-Id: <g%utg.27635$uy3.27536@tornado.socal.rr.com>
Andreas Rossberg wrote:
> Yes, technically you are right. But this makes a pretty weak notion of
> mutability. All stateful data structures had to stay within their
> lexical scope, and could never be passed to a function.
Not really. The way Hermes handles this is with destructive assignment.
Each variable holds a value, and you (almost) cannot have multiple
variables referring to the same value.
If you want to assign Y to X, you use
X := Y
after which Y is considered to be uninitialized. If you want X and Y to
have the same value, you use
X := copy of Y
after which X and Y have the same value but are otherwise unrelated, and
changes to one don't affect the other.
(As almost an aside, the non-scalar data structures were very similar to
SQL data tables.)
If you declare (the equivalent to) a function, you can indicate whether
the paramters matching the arguments are passed destructively, or are
read-only, or are copy-in-copy-out. So you could declare a function, for
example, that you pass a table into, and if it's marked as a read-only
parameter, the compiler ensures the callee does not modify the table and
the compiler generates code to pass a pointer. One could also mark a
variable (for example) as uninitialized on entry, intialized on return,
and uninitalized on the throw of an exception, and this could be used
(for example) for the read-a-line-from-a-socket routine.
The only value that came close to being shared is an outgoing connection
to a procedure; the equivalent of the client side of a socket. For
these, you could make copies, and each copy would point to the same
receiver. The receiving process could change over time, by passing its
end of the socket in a message to some other process (live code
upgrading, for example).
Since everything could be passed as part of a message, including code,
procedures, tables, and "inports" and "outports" (the ends of sockets),
I don't see that it had any problems with first classness.
> OK, if you prefer: it is an aspect of first-class mutability - which is
> present in almost all imperative languages I know. :-)
I disagree. It's entirely possible to make sophisticated imperitive
languages with assignment and without aliasing.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
------------------------------
Date: Thu, 13 Jul 2006 11:03:51 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f202ae3e730d505989791@news.altopia.net>
Joachim Durchholz <jo@durchholz.org> wrote:
> OTOH, isn't that the grail that many people have been searching for:
> programming by simply declaring the results that they want to see?
Possibly.
> No, FPLs are actually just that: compilable postconditions.
This seems to me a bit misleading. Perhaps someone will explain why I
should stop thinking this way; but currently I classify statements like
this in the "well, sort of" slot of my mind. If functional programming
were really just compilable postconditions, then functional programmers
would be able to skip a good bit of stuff that they really can't. For
example, time and space complexity of code is still entirely relevant
for functional programming. I can't simply write:
(define fib
(lambda (x) (if (< x 2) 1 (+ (fib (- x 1)) (fib (- x 2))))))
and expect the compiler to create an efficient algorithm for me. This
is true even though the above is (the LISP transcription of) the most
natural way to describe the fibonacci sequence from a mathematical
standpoint. It still runs in exponential time, and it still matters
that it runs in exponential time; and LISP programmers adapt their so-
called declarative code to improve time bounds all the time. This makes
it harder for me to call it declarative (or "compilable postconditions")
and feel entirely honest.
(Yes, I realize that the above could be optimized in a language that
does normal order evaluation with common subexpression elimination. and
become linear-time. However, that's not true of algorithms in general.
It is not the case that all that's needed to find an efficient algorithm
for something is to plug it into a Haskell compiler and observe what
happens. Or, if that is the case, there are a few CS professors I know
who would be quite interested in hearing so.)
> Computability issues aren't more or less a factor than with other kinds
> of compilers: they do limit what you can do, but these limits are loose
> enough that you can do really useful stuff within them (in particular,
> express all algorithms).
Is it really consistent to say that postconditions allow you to express
algorithms?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Thu, 13 Jul 2006 19:22:15 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is a type error?
Message-Id: <e95vp9$hln$1@online.de>
Marshall schrieb:
> Mutability by itself does not imply identity.
Well, the implication certainly holds from identity to mutability.
The only definition of identity that I found to hold up for all kinds of
references (pointers, shared-memory identifiers, URLs etc.) is this:
Two pieces of data are identical if and only if:
a) they are equal
b) they stay equal after applying an arbitrary operation to one of them.
This means that for immutable objects, there's no observable difference
between equality and identity (which I think it just fine).
For the implicaton from mutability to identity, I'm not sure whether
talking about mutation still makes sense without some kind of identity.
For example, you need to establish that the object after the mutation is
still "the same" in some sense, and this "the same" concept is exactly
identity.
> I agree that mutability
> plus identity implies aliasing problems, however.
Then we're agreeing about the most important point anyway.
>> In other words, pointers are essentially just an *aspect* of mutability
>> in lower-level languages.
>
> Again, I disagree: it is posible to have mutability without
> pointers/identity/objects.
I'm sceptical.
Any examples?
Regards,
Jo
------------------------------
Date: Thu, 13 Jul 2006 11:27:31 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f20306a2cb46ebb989792@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> Hmmm, well, I cannot agree. You've defined away the pointers
> but then slipped them back in again by assumption ("objects
> of these types have identity".)
>
> First let me say that the terminology is somewhat problematic.
> For the specific issue being discussed here, pointers, identity,
> and objects are all the same concept. (I agree that "pointer"
> connotes a low-level construct, however.)
Unless I'm missing your point, I disagree with your disagreement.
Mutability only makes sense because of object identity (in the generic
sense; no OO going on here). Without object identities, mutability is
useless. What's the use of changing something if you're not sure you'll
ever be able to find it again?
You may limit the scope of object identity arbitrarily, even to the
point that aliasing is impossible (though with lexical closure, that
gets even more limiting than it may first appear)... but you're just
trading off power for simplicity, and the really interesting uses of
mutations are those that allow access to specific objects from any
number different bits of code, on a program-wide or at least module-wide
scope. Most mediocre programmers could replace assignment with
recursion if that assignment is limited to local variables of a single
subroutine. I don't necessarily agree that the result will be a better
program despite others' conviction on the matter; however, the
difference certainly isn't worth complicating the language with mutation
unless you're willing to allow the interesting uses of mutation as well.
> Mutability by itself does not imply identity. I agree that mutability
> plus identity implies aliasing problems, however.
We might have a terminological issue, then. I'd tend to say that
mutability definitely does imply identity, but identity doesn't imply
aliasing. Same difference.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 13 Jul 2006 10:56:08 -0700
From: harvar007@yahoo.com
Subject: Windows services in PERL
Message-Id: <1152813368.512910.284680@p79g2000cwp.googlegroups.com>
Hi
I am trying to create a win32 service using the module win32:deamon. I
wrote a simple code and tried to get that running before I went to the
actual one. I am actually able to successfully create the service and
see the same in the Management Console, but when I try to right click
and say Start I get "error :1053 the service did not respond or start
to the control request in a timely fashion"
Can any one please, let me know what might be wrong in this scenario?
Here is my sample code which I was trying to get installed!
use Win32::Daemon;
Win32::Daemon::StartService();
while( SERVICE_START_PENDING != Win32::Daemon::State() )
{
sleep( 1 );
}
Win32::Daemon::State( SERVICE_RUNNING );
unlink( glob( "c:\\temp\\*.tmp" ) );
Win32::Daemon::StopService();
Thanks
Harini
------------------------------
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 9463
***************************************
