[27994] in Perl-Users-Digest
Perl-Users Digest, Issue: 9358 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 23 14:05:55 2006
Date: Fri, 23 Jun 2006 11:05:07 -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 Fri, 23 Jun 2006 Volume: 10 Number: 9358
Today's topics:
Cached and cloned CVs <bol@adv.magwien.gv.at>
DESTROY isn't called <bol@adv.magwien.gv.at>
Re: Find repeating substring <peace.is.our.profession@gmx.de>
Re: Find repeating substring <thundergnat@hotmail.com>
Re: Help with worthy project ? <hooper1@optonline.net>
Re: Native language versions <tzz@lifelogs.com>
Re: Native language versions <hjp-usenet2@hjp.at>
Re: question on Net::LPR / Unix::Login <wblock@wonkity.com>
Re: question on printing to /dev/lp <David.Squire@no.spam.from.here.au>
Re: question on printing to /dev/lp <"v.niekerk at hccnet.nl">
Re: Saying "latently-typed language" is making a catego <cdsmith@twu.net>
Re: Saying "latently-typed language" is making a catego <cdsmith@twu.net>
Re: Saying "latently-typed language" is making a catego <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is a type error? <cdsmith@twu.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 Jun 2006 18:20:04 +0200
From: "Ferry Bolhar" <bol@adv.magwien.gv.at>
Subject: Cached and cloned CVs
Message-Id: <1151079604.908518@proxy.dienste.wien.at>
Hi, Perlfolks,
while looking at the docs (perlguts / perlhacks / perlintern), I encountered
sometime an expression "cached CV or "cloned CV" and about CV
generation numbers (PL_generation and PL_sub_generation).
Can someone explain me their purpose? And perhaps give some
examples wherein cached/cloned CV's are used to show me their use?
MTIA & kind greetings,
Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
------------------------------
Date: Fri, 23 Jun 2006 18:33:50 +0200
From: "Ferry Bolhar" <bol@adv.magwien.gv.at>
Subject: DESTROY isn't called
Message-Id: <1151080431.98779@proxy.dienste.wien.at>
Hi,
please have a look at this code (it isn't mine, rather taken from a book):
sub later (&) {
bless shift, 'Later';
}
sub Later::DESTROY {
$_[0]->();
}
print "Begin\n";
{
print " Begin of block\n";
my $object = later {print " End of block\n"};
print " In block\n";
}
print "End\n";
When running this code, it yields:
Begin
Begin of block
In Block
End
so the code printing " End of block" doesn't get executed.
I understand that a coderef is given as argument to later()
and it is blessed into class "Later". So, in the block, later()
returns an object which is assigned to a lexical. At the end
of the block, the lexical disappears and so, because the
object isn't longer referenced, its DESTROY method
should be called, which gets passed the object as argument
and, because this is still a code reference, runs this code
with the ->() operator.
However, this isn't the case. DESTROY doesn't run.
Does someone know why not?
Greetings, Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
------------------------------
Date: Fri, 23 Jun 2006 17:11:48 +0200
From: Mirco Wahab <peace.is.our.profession@gmx.de>
Subject: Re: Find repeating substring
Message-Id: <e7h0it$1bl$1@mlucom4.urz.uni-halle.de>
Thus spoke Mike (on 2006-06-23 16:46):
>> Ho hum. I was bored so I farted around with this for a bit.
>>
>> Not particularly elegant or fast but...
>
> Bored? I am relatively easily impressed. Performance will continue to
> be a problem if my users want to be able to pull these index trees
> real-time.
Your (full) data set seems to be not larger than 2 or 3MB?
What would you consider 'realtime'? On a decent machine,
tree-building-during-line-read should be manageable
in (very) few seconds (am I wrong here?).
At what point are you with that? Can you push (per
personal e-mail or via http-link to the group) a
complete data set? What are the occassional line
breaks in your example lines? Are they intended?
Regards
Mirco
------------------------------
Date: Fri, 23 Jun 2006 11:58:00 -0400
From: thundergnat <thundergnat@hotmail.com>
Subject: Re: Find repeating substring
Message-Id: <Kb-dnQlpLfUVkgHZnZ2dnUVZ_tWdnZ2d@rcn.net>
Fixed a few errors.
Reformatted to reduce memory usage by not slurping in the
whole data file at once.
use warnings;
use strict;
my $partline = '';
my $prefix = '';
my $prev = '';
my $tab = ' ';
my $level = 0;
my @step;
while ( my $line = <DATA> ) {
chomp $line;
$line = "$partline $line" if length $partline;
if ( $line =~ /\D$/ ) {
$partline = $line;
next;
}
else {
$partline = '';
}
$line =~ s/(\w+('\w+)?)/\u\L$1/g;
( $level, $prefix, $prev ) =
buildtree( $level, $prefix, $line, $prev );
}
buildtree( $level, $prefix, $prefix, $prev );
sub buildtree {
my ( $level, $prefix, $next, $prev ) = @_;
my $common = greatest_common_prefix( $prev, $next );
if ( $common eq $prefix ) {
$prev =~ s/^\Q$prefix\E\s*//;
print $tab x $level, $prev, "\n";
}
elsif ( length $common > length $prefix ) {
$prev =~ s/^\Q$common\E\s*//;
my $trim = $common;
$trim =~ s/^\Q$prefix\E\s*//;
push @step, $trim;
print $tab x $level, $trim;
$level = @step;
if ( $prev !~ /[ \p{Alpha}]/ ) {
print "\t$prev\n";
}
else {
print "\n", $tab x $level, $prev, "\n";
}
$prefix = $common;
}
elsif ( length $common < length $prefix ) {
$prev =~ s/^\Q$prefix\E\s*//;
print $tab x $level, $prev, "\n";
my @newstep;
my $test = $next;
for (@step) {
last unless $test =~ s/^\Q$_\E\s*//;
push @newstep, $_;
}
$level = @step = @newstep;
$prefix = $common;
}
return ( $level, $prefix, $next );
}
sub greatest_common_prefix {
no warnings 'uninitialized';
my ( $first, $second ) = @_;
my @first = split ' ', $first;
my @second = split ' ', $second;
my @gcp;
for (@first) {
$_ eq shift @second ? push @gcp, $_ : last;
}
return join ' ', @gcp;
}
__DATA__
ABLATION ENDOMETRIAL (HYSTEROSCOPIC) 68.23
ABLATION HEART (CONDUCTION DEFECT) 37.33/2
ABLATION HEART (CONDUCTION DEFECT) WITH CATHETER 37.34/2
ABLATION INNER EAR (CRYOSURGERY) (ULTRASOUND) 20.79/4
ABLATION INNER EAR (CRYOSURGERY) (ULTRASOUND) BY INJECTION 20.72
ABLATION LESION HEART BY PERIPHERALLY INSERTED CATHETER 37.34
ABLATION LESION HEART ENDOVASCULAR APPROACH 37.34
ABLATION LESION HEART MAZE PROCEDURE (COX-MAZE) ENDOVASCULAR
APPROACH 37.34
ABLATION LESION HEART MAZE PROCEDURE (COX-MAZE) OPEN (TRANS-THORACIC)
APPROACH 37.33
ABLATION LESION HEART MAZE PROCEDURE (COX-MAZE) TRANS-THORACIC
APPROACH 37.33
ABLATION PITUITARY 7.69
ABLATION PITUITARY BY COBALT-60 92.32
ABLATION PITUITARY BY IMPLANTATION (STRONTIUM-YTTRIUM) (Y) NEC 92.39
ABLATION PITUITARY BY PROTON BEAM (BRAGG PEAK) 92.33
ABLATION PROSTATE (ANAT = 59.02) BY LASER, TRANSURETHRAL 60.21
ABLATION PROSTATE (ANAT = 59.02) BY RADIOFREQUENCY THERMOTHERAPY 60.97
ABLATION PROSTATE (ANAT = 59.02) BY TRANSURETHRAL NEEDLE ABLATION
(TUNA) 60.97
ABLATION PROSTATE (ANAT = 59.02) PERINEAL BY CRYOABLATION 60.62
ABLATION PROSTATE (ANAT = 59.02) PERINEAL BY RADICAL CRYOSURGICAL
ABLATION (RCSA) 60.62
ABLATION PROSTATE (ANAT = 59.02) TRANSURETHRAL BY LASER 60.21
ABLATION PROSTATE (ANAT = 59.02) TRANSURETHRAL CRYOABLATION 60.29
ABLATION PROSTATE (ANAT = 59.02) TRANSURETHRAL RADICAL CRYOSURGICAL
ABLATION (RCSA) 60.29
ABLATION TISSUE HEART - SEE ABLATION, LESION, HEART 0
ABLATION VESICLE NECK (ANAT = 60.02) 57.91
------------------------------
Date: 23 Jun 2006 08:52:34 -0700
From: "GHBoom" <hooper1@optonline.net>
Subject: Re: Help with worthy project ?
Message-Id: <1151077954.698612.251320@i40g2000cwc.googlegroups.com>
>
> I suggest the first thing you do is to compile your code with warnings enabled
> and fix all the warnings that appear (I got 17 when I did it.) And after that
> compile your code with warnings *AND* strict enabled and when it finally
> compiles without producing any messages from warnings and strict then you may
> find people taking your request more seriously.
>
>
> John
> --
> use Perl;
> program
> fulfillment
John
Thanks for the suggestions, but whether to take this seriously
or not should have nothing to do with what i wrote now. Im not a full
time programer,
I try as much as I can, I try to learn more every day,
I also know my limitations.
This is the reason why im looking for help in the first place....
Have a great day.
GHBoom
------------------------------
Date: Fri, 23 Jun 2006 11:09:08 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Native language versions
Message-Id: <g69irmrq57v.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 22 Jun 2006, corff@zedat.fu-berlin.de wrote:
Tad McClellan <tadmc@augustmail.com> wrote:
>
>> I suppose we'd need some character other than "m" for m// then too?
>
> Most certainly. I suggest //i for m// (i as in itchi, to be matching).
> Note that the object predicate order is typical of Japanese. In contrast,
> the //i modifier of Perl (an attribute, that is), should be rendered
> in Japanese as m// (for m as in mushi, to ignore).
Why stop there? Just write the operators in Unicode :)
Ted
------------------------------
Date: Fri, 23 Jun 2006 19:56:17 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Native language versions
Message-Id: <10ah7e.509.ln@teal.hjp.at>
corff@zedat.fu-berlin.de wrote:
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> : > Ian <nisbeti@googlemail.com> wrote:
> : > : Has anyone tried translating the command set of Perl into other
> : > : languages (French, Japanese, Arabic etc.), so that native speakers do
> : > : not need to learn any English in order to program, then writing a
> : > : suitable compiler?
>
> : In perl you don't need a separate compiler for that: You can write a
> : filter module. See Lingua::Romana::Perligata for a filter module which
> : implements Latin syntax (including declensions and
> : position-independence) for Perl.
>
> Which is a nice thing to have, but have we ever heard that the Vatican
> uses this module extensively?
No, I don't think so. It's an interesting case study, but of little
practical value. Latin is a dead language - nobody speaks it as their
first language, and the set of people who do speak it, are interested in
programming and don't speak even a little bit English is probably very
small. Conway probably chose Latin because its syntax is so different
from most current programming languages. If you can implement a
programming language based on Latin, you can probably implement one
based on any living language, too.
> : > No, this approach is completely impractical and not even of any academic
> : > interest.
>
> : I don't think this would be impractical at all. I don't know Japanese or
> : Arabic, but I don't think parsing a computer language based on Japanese
> : or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
> : is quite hard - "only perl can parse Perl" as the saying goes). At least
> : your examples don't look hard to me.
>
> No, that's right. You _can_ do it, but is it practical?
I think I misunderstood you when you wrote "impractical". I thought you
meant that it is extremely difficult to do. But it seems you only meant
that the result would be of little practical use.
So about the practical use:
For a general purpose programming language: Probably not. "Real
programmers" value the ability to share their programs all over the
world too much. Maybe China will have supplanted the USA as the leading
superpower in 50 years and we will all learn Chinese and create new
programming languages based on Chinese grammar (which AFAIK is
positional, too) and writing. But not now.
For embedded languages in applications or as shell/command languages:
I think so. More and more people use computers which don't have an IT
background. They want their computer to talk to them in their native
tongue and they want to talk *to* their computer in their native tongue.
English-based programming languages are an additional hurdle which keeps
these people from programming - the other hurdle are GUIs. I started
using computers around 1983. At that time, most of the documentation was
English, the normal user interface was a command line interface which
consisted of vaguely English words ("ls" isn't English, but it is easy
to memorize as shorthand for "list") and the command line language
(whether that was Basic on home computers, command.com's language on DOS
or shell) also served as a script language. Programming was natural.
Now people have GUIs, but programming languages are textual (yes, you
can "record macros", but is that programming?). That's a major gap to
cross. Their applications are all in their native language, but
programming languages are based on English: That's another major gap. I
think it is necessary to close both gaps so that ordinary users get back
where they were 20 years ago: Where they can "teach" the computer to
things, so that they don't have to do them themselves.
> Is it still Perl?
No. Definitely not. It is a different language which can be translated
into perl and can use Perl modules.
> : There are probably a lot more people who program Excel than any other
> : programming language. There are of course other factors which make Excel
> : attractive to non-programmers (not least that it doesn't *look* like a
> : programming language), but I wonder whether translating the function
> : names doesn't contribute to its popularity. There is a surprising number
> : of people who don't understand basic English (even though they learned
> : it in school).
>
> While I stay with you that this feature may have contributed to the popularity
> of Excel, I've seen a number of cases where a file with scripts written in the
> German version wouldn't execute on the English version Excel. This was quite
> a few years ago, though, maybe things have changed.
I think that's still the case (but I don't know: I don't use Excel) and
it is sometimes a problem. However the majority of Excel users doesn't
care as they don't share their spreadsheets with people who speak
different languages.
hp
--
_ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
|_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
| | | hjp@hjp.at | würde.
__/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
------------------------------
Date: Fri, 23 Jun 2006 16:19:14 -0000
From: Warren Block <wblock@wonkity.com>
Subject: Re: question on Net::LPR / Unix::Login
Message-Id: <slrne9o542.307p.wblock@speedy.wonkity.com>
Huub <"v.niekerk at hccnet.nl"> wrote:
>>> RemoteServer => '10.0.0.2 DeskJet520',
>> ^^^^^^^^^^^
>> That doesn't look right. Try it with just the IP address or hostname,
>> but not both.
>
> That is the server-IP followed by printqueue.
Net::LPR wants the queue name in send_jobs. In your original code, you
had
$lp->send_jobs('lp');
So you're trying to connect to a host named '10.0.0.2 DeskJet520' and
then printing to a queue of 'lp' on that host. Use '10.0.0.2' for
RemoteServer and $lp->send_jobs('DeskJet520');
Additionally, StrictRFCPorts needs to be 0 for normal users on my
system. Here's the test adaptation I used of your code on my FreeBSD
6.1, Perl 5.8.8 system:
use Net::LPR;
my $lp = new Net::LPR (
StrictRFCPorts => 0,
RemoteServer => 'laser',
RemotePort => 515,
PrintErrors => 0,
RaiseErrors => 1,
);
my $data = "Testing\f";
$lp->connect() or die "Can't connect: ".$lp->error();
my $jobkey = $lp->new_job();
$lp->send_jobs('raw');
$lp->job_mode_text($jobkey);
$lp->job_send_control_file($jobkey);
$lp->job_send_data($jobkey, $data, length($data));
$lp->disconnect() or die "Can't disconnect: ".$lp->error();
Notes:
'laser' is the DNS hostname of a laser printer with a JetDirect card;
some lpr/lpd setups may insist that there is a reverse DNS for an IP
address.
JetDirects will accept pretty much anything as a queue name, but 'raw'
is a special one that causes the job to be printed unfiltered. A real
lpd will want an actual, existing queue name.
>> If the local system has a printcap definition for that printer, you
>> could just open a pipe to lpr and write the data there.
>
> You mean like this?
>
> open my $lp, '|-', qw/lpr -PDeskjet520/ or die "can't fork lpr: $!";
>
> This complains about not having any data to print. lpr wants the name of
> a printjob, which I don't have.
That code works here:
open my $lp, '|-', qw/lpr -Plaser/ or die "can't fork lpr: $!";
print $lp "This is a test document.\f";
close $lp;
--
Warren Block * Rapid City, South Dakota * USA
------------------------------
Date: Fri, 23 Jun 2006 16:11:19 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: question on printing to /dev/lp
Message-Id: <e7h0an$qu8$1@news.ox.ac.uk>
Huub wrote:
>> No. $LPR is the filehandle that is bound to the pipe.
>>
>
> OK.
>
>> There is no filename. You have a pipe, not a file. Anything you print
>> to the filehandle $LPR will be sent via the pipe to the command 'lpr
>> -Pprinter'.
>>
>> Consider this command line version:
>>
>> >cat myfile.ps | lpr -Pprinter1
>>
>> Here the output of the command 'cat myfile.ps' is piped into the input
>> of the command 'lpr -Pprinter1'.
>
> So if I put the open function first, and then this:
>
> print($LPR," Contr. 2007\n");
>
> it should pipe the string to the printer?
Close, but you have the syntax for using filehandles with print wrong.
It should be:
print $LPR "Some string";
The comma will break it... this stuff is in the documentation: perldoc
perlfunc
... and of course, as others have said, you have to send the printer
something it can understand, e.g. postscript.
DS
------------------------------
Date: Fri, 23 Jun 2006 17:33:33 +0200
From: Huub <"v.niekerk at hccnet.nl">
Subject: Re: question on printing to /dev/lp
Message-Id: <449c06e9$0$9086$e4fe514c@dreader29.news.xs4all.nl>
Thank you very much. The print command was something I thought had taken
from CPAN, but now it's working. The printer accepts ASCII, so all is
finally working. Thank you (all) for your patience.
------------------------------
Date: Fri, 23 Jun 2006 09:19:51 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <MPG.1f05b47d3b0b14599896e8@news.altopia.net>
Patricia Shanahan <pats@acm.org> wrote:
> Vesa Karvonen wrote:
> ...
> > An example of a form of informal reasoning that (practically) every
> > programmer does daily is termination analysis. There are type systems
> > that guarantee termination, but I think that is fair to say that it is not
> > yet understood how to make a practical general purpose language, whose
> > type system would guarantee termination (or at least I'm not aware of such
> > a language). It should also be clear that termination analysis need not
> > be done informally. Given a program, it may be possible to formally prove
> > that it terminates.
>
> To make the halting problem decidable one would have to do one of two
> things: Depend on memory size limits, or have a language that really is
> less expressive, at a very deep level, than any of the languages
> mentioned in the newsgroups header for this message.
Patricia, perhaps I'm misunderstanding you here. To make the halting
problem decidable is quite a different thing than to say "given a
program, I may be able to prove that it terminates" (so long as you also
acknowledge the implicit other possibility: I also may not be able to
prove it in any finite bounded amount of time, even if it does
terminate!)
The fact that the halting problem is undecidable is not a sufficient
reason to reject the kind of analysis that is performed by programmers
to convince themselves that their programs are guaranteed to terminate.
Indeed, proofs that algorithms are guaranteed to terminate even in
pathological cases are quite common. Indeed, every assignment of a
worst-case time bound to an algorithm is also a proof of termination.
This is, of course, a very good reason to reject the idea that the
static type system for any Turing-complete language could ever perform
this same kind analysis.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Fri, 23 Jun 2006 09:59:34 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <MPG.1f05bdcdada1826b9896e9@news.altopia.net>
Vesa Karvonen <vesa.karvonen@cs.helsinki.fi> wrote:
> I think that we're finally getting to the bottom of things. While reading
> your reponses something became very clear to me: latent-typing and latent-
> types are not a property of languages. Latent-typing, also known as
> informal reasoning, is something that all programmers do as a normal part
> of programming. To say that a language is latently-typed is to make a
> category mistake, because latent-typing is not a property of languages.
It's pretty clear to me that there are two different things here. There
is the set of reasoning that is done about programs by programmers.
This may or may not have some subset called "type reasoning", depending
on whether there's a real difference between type reasoning and any
other reasoning about program behavior, or it's just a word that we've
learned from early experience to use in certain rather arbitrary
contexts. In either case, then there are language features that look
sort of type-like which can support that same reasoning about program
behavior.
It is, to me, an interesting question whether those language features
are really intrinsically connected to that form of reasoning about
program behavior, or whether they are just one way of doing it where
others would suffice as well. Clearly, there is some variation in these
supporting language features between languages that have them... for
example, whether there are only a fixed set of type tags, or an infinite
(or logically infinite, anyway) set, or whether the type tags may have
other type tags as parameters, or whether they even exist as tags at all
or as sets of possible behaviors. Across all these varieties, the
phrase "latently typed language" seems to be a reasonable shorthand for
"language that supports the programmer in doing latent-type reasoning".
Of course, there are still problems here, but really only if you share
my skepticism that there's any difference between type reasoning and any
other reasoning that's done by programmers on their programs.
Perhaps, if you wanted to be quite careful about your distinctions, you
may want to choose different words for the two. However, then you run
into that same pesky "you can't choose other people's terminology" block
again.
> A programmer, working in any language, whether typed or not, performs
> informal reasoning. I think that is fair to say that there is a
> correspondence between type theory and such informal reasoning. The
> correspondence is like the correspondence between informal and formal
> math.
I'd be more careful in the analogy, there. Since type theory (as
applied to programming languages, anyway) is really just a set of
methods of proving arbitrary statements about program behaviors, a
corresponding "informal type theory" would just be the entire set of
informal reasoning by programmers about their programs. That would
agree with my skepticism, but probably not with too many other people.
> An example of a form of informal reasoning that (practically) every
> programmer does daily is termination analysis.
Or perhaps you agree with my skepticism, here. This last paragraph
sounds like you're even more convinced of it than I am.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Fri, 23 Jun 2006 17:10:17 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <449c1f4c$0$662$bed64819@news.gradwell.net>
Pascal Costanza wrote:
> Sorry, obviously I was far from being clear. ACL2 is not
> Turing-complete. All iterations must be expressed in terms of
> well-founded recursion.
How expressive does that end up being for real problems ? I mean obviously in
some sense it's crippling, but how much of a restiction would that be for
non-accademic programming. Could I write an accountancy package in it, or an
adventure games, or a webserver, with not too much more difficulty than in a
similar language without that one aspect to its type system ?
Hmm, come to think of it those all hae endless loops at the outer level, with
the body of the loop being an event handler, so maybe only the handler should
be required to guaranteed to terminate.
-- chris
------------------------------
Date: Fri, 23 Jun 2006 10:55:30 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f05caefbb39e8189896ea@news.altopia.net>
Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
> That was the point of my first sentence (quoted above). I take it, and I
> assumed that you shared my view, that there is no single "the" type system --
> that /a/ type system will yield judgements on matters which it has been
> designed to judge.
Yes, I definitely agree.
My point was that if you leave BOTH the "something" and the response to
verification failure undefined, then your definition of a dynamic type
system is a generalization of the definition of a conditional
expression. That is (using Java),
if (x != 0) y = 1 / x;
else y = 999999999;
is not all that much different from (now restricting to Java):
try { y = 1 / x; }
catch (ArithmeticException e) { y = 999999999; }
So is one of them a use of a dynamic type system, where the other is
not?
> Incidentally, using that idea, we get a fairly close analogy to the difference
> between strong and weak static type systems.
I think, actually, that the analogy of the strong/weak distinction
merely has to do with how much verification is done. But then, I
dislike discussion of strong/weak type systems in the first place. It
doesn't make any sense to me to say that we verify something and then
don't do anything if the verification fails. In those cases, I'd just
say that verification doesn't really exist or is incorrectly
implemented. Of course, this would make the type system weaker.
> I wonder whether that way of looking at it -- the "error" never happens since
> it is replaced by a valid operation -- puts what I want to call dynamic type
> systems onto a closer footing with static type systems.
Perhaps. I'm thinking some things over before I respond to Anton. I'll
do that first, and some of my thoughts there may end up being relevant
to this question.
> b) I want to separate the systems of reasoning (whether formal or informal,
> static or dynamic, implemented or merely conceptual, and /whatever/ we call 'em
> ;-) from the language semantics. I have no objection to <some type system>
> being used as part of a language specification, but I don't want to restrict
> types to that.
In the pragmatic sense of this desire, I'd suggest that a way to
characterize this is that your type system is a set of changes to the
language semantics. By applying them to a language L, you obtain a
different language L' which you can then use. If your type system has
any impact on the set of programs accepted by the language (static
types) or on any observable behavior which they exhibit (dynamic types),
then I can't see a justification for claiming that the result is the
same language; and if it does not, then the whole exercise is silly.
> Of course, we can talk about what kinds of operations we want to forbid, but
> that seems (to me) to be orthogonal to this discussion. Indeed, the question
> of dynamic/static is largely irrelevant to a discussion of what operations we
> want to police, except insofar as certain checks might require information
> which isn't available to a (feasible) static theorem prover.
Indeed, that is orthogonal to the discussion from the perspective of
static types. If you are proposing that it is also orthogonal with
respect to dynamic types, that will be a welcome step toward our goal of
a grand unified type theory, I suppose. I have heard from others in
this thread that they don't believe so. I am also interested in your
response to the specific example involving an if statement at the
beginning of this reply.
--
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 9358
***************************************
