[28021] in Perl-Users-Digest
Perl-Users Digest, Issue: 9385 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 26 14:10:15 2006
Date: Mon, 26 Jun 2006 11:10:08 -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, 26 Jun 2006 Volume: 10 Number: 9385
Today's topics:
Re: Test loop <kaz219@gawab.com>
Re: Test loop <aukjan@gmail.com>
Re: Test loop <tadmc@augustmail.com>
Re: Test loop xhoster@gmail.com
Re: What is a type error? <pc@p-cos.net>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language [off- <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language [off- <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Jun 2006 06:05:19 -0700
From: "KaZ" <kaz219@gawab.com>
Subject: Re: Test loop
Message-Id: <1151327119.339680.309910@u72g2000cwu.googlegroups.com>
I found out:
I used double quotes instead of slashes...
------------------------------
Date: Mon, 26 Jun 2006 15:19:47 +0200
From: Aukjan van Belkum <aukjan@gmail.com>
Subject: Re: Test loop
Message-Id: <53f5$449fded4$c2abfc64$9936@news1.tudelft.nl>
KaZ wrote:
> I missed something, but I can't find out what. If you habe any idea
> about this...
>
Maybe an idea to start reading documentation?
'perldoc -f grep' will get you started.
If you don't understand what you are doing, you should try to read the
documentation first before asking questions.
Aukjan.
------------------------------
Date: Mon, 26 Jun 2006 07:46:59 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Test loop
Message-Id: <slrne9vlq3.jvh.tadmc@magna.augustmail.com>
KaZ <kaz219@gawab.com> wrote:
> So, actually, I have another question:
Then you should also have another Subject (ie. start a new thread).
People that know how to read and change files without reopening
will not look for questions they can answer hidden under a Subject
about looping.
Have you seen the Posting Guidelines that are posted here frequently?
> is it possible to open the file
> only once at the beginning of the script (I'm writing a script), search
> it for a line, append lines, without having to close and reopen it?
perldoc -f seek
perldoc -q file
How do I change one line in a file/
delete a line in a file/
insert a line in the middle of a file/
append to the beginning of a file?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 26 Jun 2006 16:02:10 GMT
From: xhoster@gmail.com
Subject: Re: Test loop
Message-Id: <20060626120228.973$wa@newsreader.com>
"KaZ" <kaz219@gawab.com> wrote:
>
> So, actually, I have another question: is it possible to open the file
> only once at the beginning of the script (I'm writing a script), search
> it for a line, append lines, without having to close and reopen it?
> Because opening and closing files a lot of times make the script quite
> slow, as far as I can tell, and I want to process very big files with
> it, so speed matters.
It doesn't take any longer to open a large file than a small one. If the
file is very big, then reading the whole thing in order to do the search is
going to take far more time opening and closing it will. If you are
worried about time, then you need to come up with a better method that
searching through an entire file every time. Use a database or a (possibly
tied) hash. Having said that, you can use "seek" both to rewind a file
handle to the beginning, and to move the file handle to the end.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 26 Jun 2006 19:41:06 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is a type error?
Message-Id: <4gakhiF1m698cU1@individual.net>
David Hopwood wrote:
> Pascal Costanza wrote:
>> Chris Smith wrote:
>>
>>> While this effort to salvage the term "type error" in dynamic
>>> languages is interesting, I fear it will fail. Either we'll all have
>>> to admit that "type" in the dynamic sense is a psychological concept
>>> with no precise technical definition (as was at least hinted by
>>> Anton's post earlier, whether intentionally or not) or someone is
>>> going to have to propose a technical meaning that makes sense,
>>> independently of what is meant by "type" in a static system.
>> What about this: You get a type error when the program attempts to
>> invoke an operation on values that are not appropriate for this operation.
>>
>> Examples: adding numbers to strings; determining the string-length of a
>> number; applying a function on the wrong number of parameters; applying
>> a non-function; accessing an array with out-of-bound indexes; etc.
>
> This makes essentially all run-time errors (including assertion failures,
> etc.) "type errors". It is neither consistent with, nor any improvement
> on, the existing vaguely defined usage.
Nope. This is again a matter of getting the levels right.
Consider division by zero: appropriate arguments for division are
numbers, including the zero. The dynamic type check will typically not
check whether the second argument is zero, but will count on the fact
that the processor will raise an exception one level deeper.
This is maybe better understandable in user-level code. Consider the
following class definition:
class Person {
String name;
int age;
void buyPorn() {
if (< this.age 18) throw new AgeRestrictionException();
...
}
}
The message p.buyPorn() is a perfectly valid message send and will pass
both static and dynamic type tests (given p is of type Person in the
static case). However, you will still get a runtime error.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Mon, 26 Jun 2006 11:49:51 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f09cc2facf5591b98970f@news.altopia.net>
Pascal Costanza <pc@p-cos.net> wrote:
> Consider division by zero: appropriate arguments for division are
> numbers, including the zero. The dynamic type check will typically not
> check whether the second argument is zero, but will count on the fact
> that the processor will raise an exception one level deeper.
Of course zero is not appropriate as a second argument to the division
operator! I can't possibly see how you could claim that it is. The
only reasonable statement worth making is that there doesn't exist a
type system in widespread use that is capable of checking this.
> This is maybe better understandable in user-level code. Consider the
> following class definition:
>
> class Person {
> String name;
> int age;
>
> void buyPorn() {
> if (< this.age 18) throw new AgeRestrictionException();
> ...
> }
> }
>
> The message p.buyPorn() is a perfectly valid message send and will pass
> both static and dynamic type tests (given p is of type Person in the
> static case).
It appears you've written the code above to assume that the type system
can't cerify that age >= 18... otherwise, the if statement would not
make sense. It also looks like Java, in which the type system is indeed
not powerfule enough to do that check statically. However, it sounds as
if you're claiming that it wouldn't be possible for the type system to
do this? If so, that's not correct. If such a thing were checked at
compile-time by a static type check, then failing to actually provide
that guarantee would be a type error, and the compiler would tell you
so.
Whether you'd choose to call an equivalent runtime check a "dynamic type
check" is a different matter, and highlights the fact that again there's
something fundamentally different about the definition of a "type" in
the static and dynamic sense.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Mon, 26 Jun 2006 20:03:02 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is a type error?
Message-Id: <4galqlF1mae4qU1@individual.net>
Chris Smith wrote:
> Pascal Costanza <pc@p-cos.net> wrote:
>> Consider division by zero: appropriate arguments for division are
>> numbers, including the zero. The dynamic type check will typically not
>> check whether the second argument is zero, but will count on the fact
>> that the processor will raise an exception one level deeper.
>
> Of course zero is not appropriate as a second argument to the division
> operator! I can't possibly see how you could claim that it is. The
> only reasonable statement worth making is that there doesn't exist a
> type system in widespread use that is capable of checking this.
...and this is typically not even checked at the stage where type tags
are checked in dynamically-typed languages. Hence, it is not a type
error. (A type error is always what you define to be a type error within
a given type system, right?)
Note, this example was in response to David's reply that my definition
turns every runtime error into a type error. That's not the case, and
that's all I want to say.
>> This is maybe better understandable in user-level code. Consider the
>> following class definition:
>>
>> class Person {
>> String name;
>> int age;
>>
>> void buyPorn() {
>> if (< this.age 18) throw new AgeRestrictionException();
>> ...
>> }
>> }
>>
>> The message p.buyPorn() is a perfectly valid message send and will pass
>> both static and dynamic type tests (given p is of type Person in the
>> static case).
>
> It appears you've written the code above to assume that the type system
> can't cerify that age >= 18... otherwise, the if statement would not
> make sense.
Right.
> It also looks like Java, in which the type system is indeed
> not powerfule enough to do that check statically.
Right.
> However, it sounds as
> if you're claiming that it wouldn't be possible for the type system to
> do this?
No. I only need an example where a certain error is not a type error in
_some_ language. I don't need to make a universal claim here.
> If so, that's not correct. If such a thing were checked at
> compile-time by a static type check, then failing to actually provide
> that guarantee would be a type error, and the compiler would tell you
> so.
That's fine, but not relevant in this specific subplot.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Mon, 26 Jun 2006 14:49:12 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language [off-topic]
Message-Id: <ItSng.481412$xt.283730@fe3.news.blueyonder.co.uk>
Matthias Blume wrote:
> I agree with Bob Harper about safety being language-specific and all
> that. But, with all due respect, I think his characterization of C is
> not accurate.
[...]
> AFAIC, C is C-unsafe by Bob's reasoning.
Agreed.
> Of course, C can be made safe quite easily:
>
> Define a state "undefined" that is considered "safe" and add a
> transition to "undefined" wherever necessary.
I wouldn't say that was "quite easy" at all.
C99 4 #2:
# If a "shall" or "shall not" requirement that appears outside of a constraint
# is violated, the behavior is undefined. Undefined behavior is otherwise
# indicated in this International Standard by the words "undefined behavior"
# *or by the omission of any explicit definition of behavior*. [...]
In other words, to fix C to be a safe language (compatible with Standard C89
or C99), you first have to resolve all the ambiguities in the standard where
the behaviour is *implicitly* undefined. There are a lot of them.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Mon, 26 Jun 2006 10:17:39 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language [off-topic]
Message-Id: <m1d5cwkkto.fsf@hana.uchicago.edu>
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> writes:
> Matthias Blume wrote:
>> I agree with Bob Harper about safety being language-specific and all
>> that. But, with all due respect, I think his characterization of C is
>> not accurate.
> [...]
>> AFAIC, C is C-unsafe by Bob's reasoning.
>
> Agreed.
>
>> Of course, C can be made safe quite easily:
>>
>> Define a state "undefined" that is considered "safe" and add a
>> transition to "undefined" wherever necessary.
>
> I wouldn't say that was "quite easy" at all.
>
> C99 4 #2:
> # If a "shall" or "shall not" requirement that appears outside of a constraint
> # is violated, the behavior is undefined. Undefined behavior is otherwise
> # indicated in this International Standard by the words "undefined behavior"
> # *or by the omission of any explicit definition of behavior*. [...]
>
> In other words, to fix C to be a safe language (compatible with Standard C89
> or C99), you first have to resolve all the ambiguities in the standard where
> the behaviour is *implicitly* undefined. There are a lot of them.
Yes, if you want to make the transition system completely explict, it
won't be easy. I was thinking of a catch-all rule that says:
transition to "undefined" unless specified otherwise. (Note that I am
not actually advocating this approach to making a language "safe".
For practical purposes, C is unsafe. (And so is C++.))
------------------------------
Date: 26 Jun 2006 09:25:16 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151339115.942653.59210@c74g2000cwc.googlegroups.com>
Marshall wrote:
>
> I stand corrected: if one is using C and writing self-modifying
> code, then one *can* zip one's pants.
Static proofs notwithstanding, I'd prefer a dynamic check just prior to
this operation.
I want my code to be the only self-modifying thing around here.
------------------------------
Date: 26 Jun 2006 10:00:32 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151341232.468150.254980@c74g2000cwc.googlegroups.com>
David Hopwood wrote:
> > Joe Marshall wrote:
> >>
> >>I do this quite often. Sometimes I'll develop `in the debugger'. I'll
> >>change some piece of code and run the program until it traps. Then,
> >>without exiting the debugger, I'll fix the immediate problem and
> >>restart the program at the point it trapped. This technique takes a
> >>bit of practice, but if you are working on something that's complex and
> >>has a lot of state, it saves a lot of time because you don't have to
> >>reconstruct the state every time you make a change.
>
> The problem with this is that from that point on, what you're running
> is neither the old nor the new program, since its state may have been
> influenced by the bug before you corrected it.
Yes. The hope is that it is closer to the new program than to the old.
> I find it far simpler to just restart the program after correcting
> anything. If this is too difficult, I change the design to make it
> less difficult.
In the most recent case where I was doing this, I was debugging
transaction rollback that involved multiple database extents. It was
somewhat painful to set up a clean database to the point where I wanted
to try the rollback, and I wanted a pristine database for each trial so
I could examine the raw bits left by a rollback. It was pretty easy to
deal with simple errors in the debugger, so I chose to do that instead.
>
> > Wow, interesting.
> >
> > (I say the following only to point out differing strategies of
> > development, not to say one or the other is right or bad or
> > whatever.)
> >
> > I occasionally find myself doing the above, and when I do,
> > I take it as a sign that I've screwed up. I find that process
> > excruciating, and I do everything I can to avoid it. Over the
> > years, I've gotten more and more adept at trying to turn
> > as many bugs as possible into type errors, so I don't have
> > to run the debugger.
> >
> > Now, there might be an argument to be made that if I had
> > been using a dynamic language, the process wouldn't be
> > so bad, and I woudn't dislike it so much. But mabe:
> >
> > As a strawman: suppose there are two broad categories
> > of mental strategies for thinking about bugs, and people
> > fall naturally into one way or the other, the way there
> > are morning people and night people. One group is
> > drawn to the static analysis, one group hates it.
> > One group hates working in the debugger, one group
> > is able to use that tool very effectively and elegantly.
> >
> > Anyway, it's a thought.
>
> I don't buy this -- or at least, I am not in either group.
>
> A good debugger is invaluable regardless of your attitude to type
> systems. Recently I was debugging two programs written to do similar
> things in the same statically typed language (C), but where a debugger
> could not be used for one of the programs. It took maybe 5 times
> longer to find and fix each bug without the debugger, and I found it
> a much more frustrating experience.
>
> --
> David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
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 9385
***************************************
