[28017] in Perl-Users-Digest
Perl-Users Digest, Issue: 9381 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 26 03:05:38 2006
Date: Mon, 26 Jun 2006 00:05:05 -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: 9381
Today's topics:
Re: Another newbie question <tadmc@augustmail.com>
Making the simple impossible and the impossible unthink xfx.publishing@gmail.com
Re: Need Search::Binary examples <tadmc@augustmail.com>
new CPAN modules on Mon Jun 26 2006 (Randal Schwartz)
Re: Regexp problem <dont@like.spammers>
Regular Expression Generator <jeremyje@gmail.com>
Re: Running another program in daemon server <janicehwang1325@yahoo.com>
Re: What is Expressiveness in a Computer Language <john.thingstad@chello.no>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 25 Jun 2006 23:47:07 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Another newbie question
Message-Id: <slrne9upmb.hf0.tadmc@magna.augustmail.com>
Jockser <qbert@comcast.net> wrote:
> Subject: Another newbie question
You will get more help if people can tell what you need help with.
Please put the subject of your article in the Subject of your article.
(You will also get more help if you don't put "newbie" in the Subject.)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 25 Jun 2006 21:45:28 -0700
From: xfx.publishing@gmail.com
Subject: Making the simple impossible and the impossible unthinkable...
Message-Id: <1151297128.066479.201740@b68g2000cwa.googlegroups.com>
Heya. I'm up against what is turning out to be a tough one...
I'm trying to get a Perl script with LWP to get information from AOL
profiles.
What I'm doing is I have a LWP useragent logging in with my AIM
screenname and password at
https://my.screenname.aol.com/_cqr/login/login.psp, grabbing the
cookies, and then requesting
http://memberdirectory.aol.com/aolus/profile?sn=$screenname
The login part is working, and I'm caching the cookies fine it looks
like, but the results I get back from
http://memberdirectory.aol.com/aolus/profile?sn=$screenname are not the
same thing I'm getting in my real browser (firefox) -- and not getting
the info I want out to parse.
>From what I can tell there's some weird and utterly pointless
Javascripting going on. I set up a logger on my XP box (first free HTTP
logger I could find, so XP it was -- but I'm doing the code under
Debian Linux just so you know) and I'm getting cookies being sent that
I don't have -- which is giving the strong impression that some
Javascript somewhere is making these cookies up on the fly. This gives
me the strong impression that AOL takes the opposite philosophy of
Perl, and possibly has occasional meetings where people get together
and decide 'We don't have enough code -- we need more code to do the
same thing. Let's try and complicate things more.' I bet they have
buzzwords like 'complexify'. It's asinine to do so much stupid crap
just to set up login validation.
But, rant aside, if someone can figure out what's going on with this...
Here's the intended subroutine -- you will notice commented bits of
hair-pulling in places and debuggy bits, no doubt
But in theory this should be able to set up a hashref in the
$obj->{profile} key that contains all their AOL user info. In theory.
And I just can't get back the right info (and yes I double checked my
AIM password and stuff, and got distinctly different results putting in
a nonsense password just to make sure there wasn't manglement going on
there).
Anyway, well... this definitely counts as a challenge, if nothing else.
I'd like to have this working, but for the tme being, I just can't get
the right page back.
sub SetInfo {
my $obj = shift;
my $user = shift;
my $aol_login = $obj->{aol_login};
my $aol_pass = $obj->{aol_pass};
unless ($aol_login and $aol_pass) {
$obj->{errstr} = 'AOL or AIM Screen Name and Password required
to '.
'access.';
return undef;
}
# We is a BIG LIAH saying we's Firefox. In British. On XP. Just
what
# they expect. But some of these sites act like assholes so screw
it
# better that than this potentially not working if they block us
my $web = LWP::UserAgent->new('Mozilla/5.0 (Windows; U; Windows NT
5.1;'.
' en-GB; rv:1.8.0.3) Gecko/20060426 '.
'Firefox/1.5.0.3');
$web->cookie_jar(HTTP::Cookies->new(file =>
"/usr/local/WPCookies.lwp",
autosave => 1,
ignore_discard => 1));
#$web->cookie_jar({});
my $login =
$web->post('https://my.screenname.aol.com/_cqr/login/login.psp',
[sitedomain =>
'memberdirectory-beta.estage.aol.com',
siteId => '',
lang => 'en',
locale => 'us',
authLev => '1',
siteState =>
"OrigUrl%3Dhttp%253A%252F%252Fmemberdirectory.aol.com%252Faolus%252Fprofile%253Fsn%253D$user",
isSiteStateEncoded => 'true',
mcState => 'initialized',
usrd => '1889976',
loginId => $aol_login,
password => $aol_pass,
rememberMe => 'off']);
unless ($login->is_success) {
$obj->{errstr} = 'AOL login failed:'. $login->status_line;
return undef;
}
$obj->{login_page} = $login->content;
$obj->{ua} = $web;
#=stop
$obj->{login_headers} = $login->as_string;
$obj->{login_headers} =~ s/\n\n.*//gsm;
$obj->{login_cookies} = [];
for my $h (split /[\r\n]+/, $obj->{login_headers}) {
my ($k, $v) = split /:\s+/, $h;
push @{$obj->{login_cookies}}, {$k => $v} if lc $k eq
'set-cookie';
}
#=cut
if ($obj->{login_page}
=~ /You have entered an invalid Screen Name or password/) {
$obj->{errstr} = 'AOL login failed: invalid login info.';
return undef;
}
$obj->{pull_success} = "Didn't try yet.";
my $url_base = 'http://memberdirectory.aol.com/aolus/profile?sn=';
my $req = HTTP::Request->new('GET',
"$url_base$user",
[@{$obj->{login_cookies}},
);
my $resp = $web->request($req);
if ($resp->is_success) {
my $prof;
$obj->{pull_success} = "Successful.";
$obj->{page} = $resp->content;
my $p = HTML::PullParser->new(doc => $resp->content,
start => 'tagname, event, attr',
end => 'tagname, event,
skipped_text',
ignore_elements => [qw(script style
applet embed
object)],
report_tags => ['script']);
while (my $token = $p->get_token) {
my $type = $token->[1];
next unless ($type eq 'end');
my $script = $token->[2];
if ($script =~ /var\s+nameString\s*=/) {
# this is the right script with the data in it
# that is easy to read
$script =~ /var\s+memMessage\s*=\s*"I am (\w+)\."/;
$prof->{online} = $1;
$script =~ /var\s+nameDetails\s*=\s*"([^"]*)"/;
$prof->{name} = $1;
$script =~ /var\s+locDetails\s*=\s*"([^"]*)"/;
$prof->{loc} = $1;
$script =~ /var\s+genderDetails\s*=\s*"([^"]*)"/;
$prof->{gender} = $1;
$script =~ /var\s+maritalDetails\s*=\s*"([^"]*)"/;
$prof->{marital} = $1;
$script =~ /var\s+hobbiesDetails\s*=\s*"([^"]*)"/;
$prof->{hobbies} = $1;
$script =~ /var\s+gadgetsDetails\s*=\s*"([^"]*)"/;
$prof->{gadgets} = $1;
$script =~ /var\s+occDetails\s*=\s*"([^"]*)"/;
$prof->{occ} = $1;
$script =~ /var\s+quoteDetails\s*=\s*"([^"]*)"/;
$prof->{quote} = $1;
$script =~ /var\s+linksDetails\s*=\s*"([^"]*)"/;
$prof->{links} = $1;
}
for my $k (keys %{$prof}) {
# Strip out annoying HTML tags in profiles
$prof->{$k} =~ s/<[^>]*>//gsm;
}
$obj->{profile} = $prof;
}
}
else {
$obj->{pull_success} = 'Failed';
$obj->{errstr} = "Can't retrieve AOL member page for
$obj->{user}.\n";
return undef;
}
}
------------------------------
Date: Sun, 25 Jun 2006 23:03:10 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Need Search::Binary examples
Message-Id: <slrne9un3u.hf0.tadmc@magna.augustmail.com>
Arvin Portlock <nomail@sorry.com> wrote:
> if (-e $textfile) {
> open (STATFILE, $textfile);
You should always, yes *always*, check the return value from open():
open(STATFILE, $textfile) or die "could not open '$textfile' $!";
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 26 Jun 2006 04:42:05 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Mon Jun 26 2006
Message-Id: <J1GAE5.1Go0@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Acme-l33t-0.01
http://search.cpan.org/~yanick/Acme-l33t-0.01/
a l33t interpreter
----
Algorithm-QuineMcCluskey-0.01
http://search.cpan.org/~kulp/Algorithm-QuineMcCluskey-0.01/
solve Quine-McCluskey set-cover problems
----
Alien-wxWidgets-0.14
http://search.cpan.org/~mbarbon/Alien-wxWidgets-0.14/
building, finding and using wxWidgets binaries
----
Catalyst-Devel-0.99_01
http://search.cpan.org/~mramberg/Catalyst-Devel-0.99_01/
Catalyst Development Tools
----
Catalyst-Model-DBI-0.14
http://search.cpan.org/~alexp/Catalyst-Model-DBI-0.14/
DBI Model Class
----
Catalyst-Runtime-5.70_01
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.70_01/
Catalyst Runtime version
----
Chemistry-File-InternalCoords-0.01
http://search.cpan.org/~davidrw/Chemistry-File-InternalCoords-0.01/
Internal coordinates (z-matrix) molecule format reader/writer
----
Class-Accessor-Named-0.001
http://search.cpan.org/~jesse/Class-Accessor-Named-0.001/
Better profiling output for Class::Accessor
----
DBIx-SimplePerl-1.40
http://search.cpan.org/~landman/DBIx-SimplePerl-1.40/
Perlish access to DBI
----
DBIx-YAWM-2.32
http://search.cpan.org/~ahicox/DBIx-YAWM-2.32/
(Yet Annother Wrapper Module) Provides a simplified interface to DBI
----
Deco-0.01
http://search.cpan.org/~narked/Deco-0.01/
----
Deco-0.02
http://search.cpan.org/~narked/Deco-0.02/
Module for simulating body tissue during a scuba dive
----
Devel-PPPort-3.08_06
http://search.cpan.org/~mhx/Devel-PPPort-3.08_06/
Perl/Pollution/Portability
----
FEAR-API-0.488
http://search.cpan.org/~xern/FEAR-API-0.488/
Web Scraping Zen
----
FEAR-API-0.488.1
http://search.cpan.org/~xern/FEAR-API-0.488.1/
Web Scraping Zen
----
Fax-Hylafax-Client-1.02
http://search.cpan.org/~arak/Fax-Hylafax-Client-1.02/
Simple HylaFAX client
----
Filesys-Df-0.92
http://search.cpan.org/~iguthrie/Filesys-Df-0.92/
Perl extension for filesystem disk space information.
----
Filesys-DfPortable-0.85
http://search.cpan.org/~iguthrie/Filesys-DfPortable-0.85/
Perl extension for filesystem disk space information.
----
Filesys-Statvfs-0.82
http://search.cpan.org/~iguthrie/Filesys-Statvfs-0.82/
Perl extension for statvfs() and fstatvfs()
----
Font-TTF-0.39a
http://search.cpan.org/~mhosken/Font-TTF-0.39a/
Perl module for TrueType Font hacking
----
Games-Maze-SVG-0.74
http://search.cpan.org/~gwadej/Games-Maze-SVG-0.74/
Build mazes in SVG.
----
IPC-Run-Simple-1.0
http://search.cpan.org/~sfink/IPC-Run-Simple-1.0/
Simple system() wrapper
----
IPC-Run-Simple-1.1
http://search.cpan.org/~sfink/IPC-Run-Simple-1.1/
Simple system() wrapper
----
Language-Prolog-Sugar-0.05
http://search.cpan.org/~salva/Language-Prolog-Sugar-0.05/
Syntactic sugar for Prolog term constructors
----
Language-Prolog-Yaswi-0.10
http://search.cpan.org/~salva/Language-Prolog-Yaswi-0.10/
Yet another interface to SWI-Prolog
----
Moose-Autobox-0.02
http://search.cpan.org/~stevan/Moose-Autobox-0.02/
Autoboxed for her pleasure
----
Nagios-Clientstatus-0.06
http://search.cpan.org/~horshack/Nagios-Clientstatus-0.06/
Framework for Nagios check-service programs
----
Net-MAC-Vendor-1.15
http://search.cpan.org/~bdfoy/Net-MAC-Vendor-1.15/
look up the vendor for a MAC
----
Net-TCP-PtyServer-1
http://search.cpan.org/~rjlee/Net-TCP-PtyServer-1/
Serves pseudo-terminals. Opens a listening connection on a port, waits for network connections on that port, and serves each one in a seperate PTY.
----
Net-VNC-0.33
http://search.cpan.org/~lbrocard/Net-VNC-0.33/
A simple VNC client
----
NetAddr-IP-Lite-0.12
http://search.cpan.org/~miker/NetAddr-IP-Lite-0.12/
Manages IPv4 and IPv6 addresses and subnets
----
SQL-Translator-Producer-DBIx-Class-File-Simple-0.1
http://search.cpan.org/~dongyi/SQL-Translator-Producer-DBIx-Class-File-Simple-0.1/
DBIx::Class file producer
----
Test-JavaScript-0.04
http://search.cpan.org/~kevinj/Test-JavaScript-0.04/
JavaScript Testing Module
----
URI-Fetch-0.071
http://search.cpan.org/~btrott/URI-Fetch-0.071/
Smart URI fetching/caching
----
Unicode-RecursiveDowngrade-0.03
http://search.cpan.org/~taniguchi/Unicode-RecursiveDowngrade-0.03/
Turn off the UTF-8 flags inside of complex variable
----
WWW-Arbeitsagentur-0.02
http://search.cpan.org/~iwiarda/WWW-Arbeitsagentur-0.02/
Search for jobs via arbeitsagentur.de
----
Win32-Fonts-Info-0.01
http://search.cpan.org/~rpagitsch/Win32-Fonts-Info-0.01/
Perl extension for get a list of installed fontfamilies on a Win32 Computer.
----
Win32-IPConfig-0.09
http://search.cpan.org/~jmacfarla/Win32-IPConfig-0.09/
IP Configuration Settings for Windows NT/2000/XP/2003
----
YAML-AppConfig-0.14
http://search.cpan.org/~moconnor/YAML-AppConfig-0.14/
Manage configuration files with YAML and variable reference.
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Mon, 26 Jun 2006 06:25:51 GMT
From: Mark Healey <dont@like.spammers>
Subject: Re: Regexp problem
Message-Id: <pan.2006.06.26.06.25.49.26409@like.spammers>
On Sun, 25 Jun 2006 09:11:15 -0500, Tad McClellan wrote:
> Mark Healey <dont@like.spammers> wrote:
>> On Sat, 24 Jun 2006 06:32:29 +0000, Jürgen Exner wrote:
>>
>>> Mark Healey wrote:
>>>> Here is the line that is giving me problems:
>>>>
>>>> $Falbum =~ s/$edir\/.\/$Fartist\///;
>>>>
>>>> The problem is that $Fartist sometimes has grouping characters "()[]"
>>>> which screws up the search.
>>>>
>>>> How do I get it to treat these characters as if they were "\(\)\[\]"?
>>>
>>> perldoc -f quotemeta
>>
>> This doesn't help when I'm using some meta characters in my search
>> strings.
>
>
> Yes it does.
>
>
>> I need something that only does it to the variables.
>
>
> quotemeta only does it where you ask it to do it, so ask it to
> do it "to the variables":
>
> $edir = quotemeta $edir;
> $Fartist = quotemeta $Fartist;
> $Falbum =~ s#$edir/./$Fartist/##; # Look Ma! No backslashes!
>
> or, lookup the \Q that the docs mention:
Like most open source perldoc sucks. By the time you know enough to pick
the right terms to look for you don't need it.
> $Falbum =~ s#\Q$edir\E/./\Q$Fartist/##;
That wasn't on my cheat sheet but I did eventually find it.
--
Mark Healey
marnkews ãt healeyonline döt com
------------------------------
Date: 25 Jun 2006 22:41:55 -0700
From: "jeremyje@gmail.com" <jeremyje@gmail.com>
Subject: Regular Expression Generator
Message-Id: <1151300515.365672.44050@m73g2000cwd.googlegroups.com>
Is there a library or a way to generate an appropriate regular
expression for any given input string?
(remove quotes for examples)
For example: "1234567890abcdef is in hex9"
Regex Generator returns: [0-9|A-F]{16} [a-z]{2} [a-z]{2} [0-9|a-z]{3}
Or anything that does some sort of similar processing?
------------------------------
Date: 25 Jun 2006 22:48:24 -0700
From: "janicehwang1325@yahoo.com" <janicehwang1325@yahoo.com>
Subject: Re: Running another program in daemon server
Message-Id: <1151300904.642313.147200@b68g2000cwa.googlegroups.com>
I will try based on your advice. thank you very much.
Ben Morrow wrote:
> Quoth tadmc@augustmail.com:
> > Ted Zlatanov <tzz@lifelogs.com> wrote:
> >
> > > Generally specify paths for system() with '/' instead of '\' and life
> > > will be easier and more portable.
> >
> > But only for the more-than-1-arg form of system().
> >
> > You cannot use forward slashes with 1-arg system() on
> > silly "operating systems". (I think.)
>
> ...unless you change your shell. :)
>
> Ben
>
> --
> 'Deserve [death]? I daresay he did. Many live that deserve death. And some die
> that deserve life. Can you give it to them? Then do not be too eager to deal
> out death in judgement. For even the very wise cannot see all ends.'
> benmorrow@tiscali.co.uk
------------------------------
Date: Mon, 26 Jun 2006 08:06:04 +0200
From: "John Thingstad" <john.thingstad@chello.no>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <op.tbqokem8pqzri1@pandora.upc.no>
On Sun, 25 Jun 2006 20:11:22 +0200, Anton van Straaten
<anton@appsolutions.com> wrote:
> rossberg@ps.uni-sb.de wrote:
>>>> In this context, the term "latently-typed language" refers to the
>>>> language that a programmer experiences, not to the subset of that
>>>> language which is all that we're typically able to formally define.
>> That language is not a subset, if at all, it's the other way round,
>> but
>> I'd say they are rather incomparable. That is, they are different
>> languages.
>
> The "subset" characterization is not important for what I'm saying. The
> fact that they are different languages is what's important. If you
> agree about that, then you can at least understand which language I'm
> referring to when I say "latently-typed language".
>
> Besides, many dynamically-typed languages have no formal models, in
> which case the untyped formal model I've referred to is just a
> speculative construct. The language I'm referring to with
> "latently-typed language" is the language that programmers are familiar
> with, and work with.
>
>>> That is starting to get a bit too mystical for my tastes.
>> I have to agree.
>> \sarcasm One step further, and somebody starts calling C a "latently
>> memory-safe language", because a real programmer "knows" that his code
>> is in a safe subset... And where he is wrong, dynamic memory page
>> protection checks will guide him.
>
> That's a pretty apt comparison, and it probably explains how it is that
> the software we all use, which relies so heavily on C, works as well as
> it does.
>
> But the comparison critiques the practice of operating without static
> guarantees, it's not a critique of the terminology.
>
> Anton
Actually I have never developed a C/C++ program
without a bounds checker the last 15 years.
It checks all memory references and on program shutdown
checks for memory leaks. What is it about you guys that make you blind
to these fact's. Allocation problem's haven't really bugged me at all
since forever. Now debugging fluky templates on the other hands..
But then debugging Lisp macro's isn't much better.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
------------------------------
Date: Mon, 26 Jun 2006 06:20:20 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <E0Lng.159802$F_3.7156@newssvr29.news.prodigy.net>
Chris Smith wrote:
> What makes static type systems interesting is not the fact that these
> logical processes of reasoning exist; it is the fact that they are
> formalized with definite axioms and rules of inference, performed
> entirely on the program before execution, and designed to be entirely
> evaluatable in finite time bounds according to some procedure or set of
> rules, so that a type system may be checked and the same conclusion
> reached regardless of who (or what) is doing the checking. All that,
> and they still reach interesting conclusions about programs.
There's only one issue mentioned there that needs to be negotiated
w.r.t. latent types: the requirement that they are "performed entirely
on the program before execution". More below.
> If
> informal reasoning about types doesn't meet these criteria (and it
> doesn't), then it simply doesn't make sense to call it a type system
> (I'm using the static terminology here). It may make sense to discuss
> some of the ways that programmer reasoning resembles types, if indeed
> there are resemblances beyond just that they use the same basic rules of
> logic. It may even make sense to try to identify a subset of programmer
> reasoning that even more resembles... or perhaps even is... a type
> system. It still doesn't make sense to call programmer reasoning in
> general a type system.
I'm not trying to call programmer reasoning in general a type system.
I'd certainly agree that a programmer muddling his way through the
development of a program, perhaps using a debugger to find all his
problems empirically, may not be reasoning about anything that's
sufficiently close to types to call them that. But "latent" means what
it implies: someone who is more aware of types can do better at
developing the latent types.
As a starting point, let's assume we're dealing with a disciplined
programmer who (following the instructions found in books such as the
one at htdp.org) reasons about types, writes them in his comments, and
perhaps includes assertions (or contracts in the sense of "Contracts for
Higher Order Functions[1]), to help check his types at runtime (and I'm
talking about real type-checking, not just tag checking).
When such a programmer writes a type signature as a comment associated
with a function definition, in many cases he's making a claim that's
provable in principle about the inputs and outputs of that function.
For example, if the type in question is "int -> int", then the provable
claim is that given an int, the function cannot return anything other
than an int. Voila, assuming we can actually prove our claim, then
we've satisfied the requirement in Pierce's definition of type system,
i.e. "proving the absence of certain program behaviors by classifying
phrases according to the kinds of values they compute."
The fact that the proof in question may not be automatically verified is
no more relevant than the fact that so many proofs in mathematics have
not been automatically verified. Besides, if the proof turns out to be
wrong, we at least have an automated mechanism for finding witnesses to
the error: runtime tag checks will generate an error. Such detection is
not guaranteed, but again, "proof" does not imply "automation".
What I've just described walks like a type and talks like a type, or at
least it appears to do so according to Pierce's definition. We can
classify many terms in a given dynamically-typed program on this basis
(although some languages may be better at supporting this than others).
So, on what grounds do you reject this as not being an example of a
type, or at the very least, something which has clear and obvious
connections to formal types, as opposed to simply being arbitrary
programmer reasoning?
Is it the lack of a formalized type system, perhaps? I assume you
recognize that it's not difficult to define such a system.
Regarding errors, we haven't proved that the function in question can
never be called with something other than an int, but we haven't claimed
to prove that, so there's no problem there. I've already described how
errors in our proofs can be detected.
Another possible objection is that I'm talking about local cases, and
not making any claims about extending it to an entire program (other
than to observe that it can be done). But let's take this a step at a
time: considered in isolation, if we can assign types to terms at the
local level in a program, do you agree that these are really types, in
the type theory sense?
If you were to agree, then we could move on to looking at what it means
to have many local situations in which we have fairly well-defined
types, which may all be defined within a common type system.
As an initial next step, we could simply rely on the good old universal
type everywhere else in the program - it ought to be possible to make
the program well-typed in that case, it would just mean that the
provable properties would be nowhere near as pervasive as with a
traditional statically-typed program. But the point is we would now
have put our types into a formal context.
> In the same post here, you simultaneously suppose that there's something
> inherently informal about the type reasoning in dynamic languages; and
> then talk about the type system "in the static sense" of a dynamic
> language. How is this possibly consistent?
The point about inherent informality is just that if you fully formalize
a static type system for a dynamic language, such that entire programs
can be statically typed, you're likely to end up with a static type
system with the same disadvantages that the dynamic language was trying
to avoid.
However, that doesn't preclude type system being defined which can be
used to reason locally about dynamic programs. Some people actually do
this, albeit informally.
>>So we actually have quite a bit of evidence about the presence of static
>>types in dynamically-typed programs.
>
>
> No. What we have is quite a bit of evidence about properties remaining
> true in dynamically typed programs, which could have been verified by
> static typing.
Using my example above, at least some of those properties would have
been verified by manual static typing. So those properties, at least,
seem to be types, at least w.r.t. the local fragment they're proved within.
>>We're currently discussing something that so far has only been captured
>>fairly informally. If we restrict ourselves to only what we can say
>>about it formally, then the conversation was over before it began.
>
>
> I agree with that statement. However, I think the conversation
> regarding static typing is also over when you decide that the answer is
> to weaken static typing until the word applies to informal reasoning.
> If the goal isn't to reach a formal understanding, then the word "static
> type" shouldn't be used
Well, I'm trying to use the term "latent type", as a way to avoid the
ambiguity of "type" alone, to distinguish it from "static type", and to
get away from the obvious problems with "dynamic type".
But I'm much less interested in the term itself than in the issues
surrounding dealing with "real" types in dynamically-checked programs -
if someone had a better term, I'd be all in favor of it.
> and when that is the goal, it still shouldn't
> be applied to process that aren't formalized until they manage to become
> formalized.
This comes back to the phrase I highlighted at the beginning of this
message: "performed entirely on the program before execution".
Formalizing local reasoning about types is pretty trivial, in many
cases. It's just that there are other cases where that's less
straightforward.
So when well-typed program fragments are considered as part of a larger
untyped program, you're suggesting that this so radically changes the
picture, that we can no longer distinguish the types we identified as
being anything beyond programmer reasoning in general? All the hard
work we did figuring out the types, writing them down, writing
assertions for them, and testing the program to look for violations
evaporates into the epistemological black hole that exists outside the
boundaries of formal type theory?
> Hopefully, this isn't perceived as too picky. I've already conceded
> that we can use "type" in a way that's incompatible with all existing
> research literature.
Not *all* research literature. There's literature on various notions of
dynamic type.
> I would, however, like to retain some word with
> actually has that meaning. Otherwise, we are just going to be
> linguistically prevented from discussing it.
For now, you're probably stuck with "static type". But I think it was
never likely to be the case that type theory would succeed in absconding
with the only technically valid use of the English word "type".
Although not for want of trying!
Besides, I think it's worth considering why Bertrand Russell used the
term "types" in the first place. His work had deliberate connections to
the real world. Type theory in computer science unavoidably has similar
connections. You could switch to calling it Zoltar Theory, and you'd
still have to deal with the fact that a zoltar would have numerous
connections to the English word "type". In CS, we don't have the luxury
of using the classic mathematician's excuse when confronted with
inconvenient philosophical issues, of claiming that type theory is just
a formal symbolic game, with no meaning outside the formalism.
Anton
[1]
http://people.cs.uchicago.edu/~robby/pubs/papers/ho-contracts-techreport.pdf
------------------------------
Date: Mon, 26 Jun 2006 06:34:15 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <HdLng.159803$F_3.28531@newssvr29.news.prodigy.net>
John Thingstad wrote:
> On Sun, 25 Jun 2006 20:11:22 +0200, Anton van Straaten
> <anton@appsolutions.com> wrote:
>
>> rossberg@ps.uni-sb.de wrote:
...
>>> \sarcasm One step further, and somebody starts calling C a "latently
>>> memory-safe language", because a real programmer "knows" that his code
>>> is in a safe subset... And where he is wrong, dynamic memory page
>>> protection checks will guide him.
>>
>>
>> That's a pretty apt comparison, and it probably explains how it is
>> that the software we all use, which relies so heavily on C, works as
>> well as it does.
>>
>> But the comparison critiques the practice of operating without static
>> guarantees, it's not a critique of the terminology.
>>
>> Anton
>
>
> Actually I have never developed a C/C++ program
> without a bounds checker the last 15 years.
> It checks all memory references and on program shutdown
> checks for memory leaks. What is it about you guys that make you blind
> to these fact's.
You misunderstand -- for the purposes of the above comparison, a bounds
checker serves essentially the same purpose as "dynamic memory page
protection checks". The point is that it happens dynamically, i.e. at
runtime, and that there's a lack of static guarantees about memory
safety in C or C++. That's why, as I said, the comparison to latent vs.
static typing is an apt one.
Anton
------------------------------
Date: Mon, 26 Jun 2006 07:03:24 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <0FLng.159806$F_3.1840@newssvr29.news.prodigy.net>
Joachim Durchholz wrote:
> Anton van Straaten schrieb:
>
>> Marshall wrote:
>>
>>> Can you be more explicit about what "latent types" means?
>>
>>
>> Sorry, that was a huge omission. (What I get for posting at 3:30am.)
>>
>> The short answer is that I'm most directly referring to "the types in
>> the programmer's head".
>
>
> Ah, finally that terminology starts to make sense to me. I have been
> wondering whether there's any useful difference between "latent" and
> "run-time" typing. (I tend to avoid the term "dynamic typing" because
> it's overloaded with too many vague ideas.)
Right, that's the reason for using a different term. Runtime and
dynamic types are both usually associated with the idea of tagged
values, and don't address the types of program phrases.
>> there are usually many possible static type schemes that can be
>> assigned to a given program.
>
>
> This seems to apply to latent types as well.
That's what I meant, yes.
> Actually the set of latent types seems to be the set of possible static
> type schemes.
> Um, well, a superset of these - static type schemes tend to be slightly
> less expressive than what the programmer in his head. (Most type schemes
> cannot really express things like "the range of this index variable is
> such-and-so", and the boundary to general assertions about the code is
> quite blurry anyway.)
Yes, although this raises the type theory objection of how you know
something is a type if you haven't formalized it. For the purposes of
comparison to static types, I'm inclined to be conservative and stick to
things that have close correlates in traditional static types.
>> There's a close connection between latent types in the sense I've
>> described, and the "tagged values" present at runtime. However, as
>> type theorists will tell you, the tags used to tag values at runtime,
>> as e.g. a number or a string or a FooBar object, are not the same
>> thing as the sort of types which statically-typed languages have.
>
>
> Would that be a profound difference, or is it just that annotating a
> value with a full type expression would cause just too much runtime
> overhead?
It's a profound difference. The issue is that it's not just the values
that need to be annotated with types, it's also other program terms. In
addition, during a single run of a program, all it can ever normally do
is record the types seen on the path followed during that run, which
doesn't get you to static types of terms. To figure out the static
types, you really need to do static analysis.
Of course, static types give an approximation of the actual types of
values that flow at runtime, and if you come at it from the other
direction, recording the types of values flowing through terms on
multiple runs, you can get an approximation to the static type. Some
systems use that kind of thing for method lookup optimization.
> In your terminology:
>
>> So, where do tagged values fit into this? Tags help to check types at
>> runtime, but that doesn't mean that there's a 1:1 correspondence
>> between tags and types.
>
>
> Would it be possible to establish such a correspondence, would it be
> common consensus that such a system should be called "tags" anymore, or
> are there other, even more profound differences?
There's a non 1:1 correspondence which I gave an example of in the
quoted message. For 1:1 correspondence, you'd need to associate types
with terms, which would need some static analysis. It might result in
an interesting program browsing and debugging tool...
Anton
------------------------------
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 9381
***************************************
