[27986] in Perl-Users-Digest
Perl-Users Digest, Issue: 9350 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 23 03:05:41 2006
Date: Fri, 23 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 Fri, 23 Jun 2006 Volume: 10 Number: 9350
Today's topics:
[ANNOUNCE] Emacs modules for Perl programming (Jari Aalto+mail.perl)
Re: Hash of Arrays <hoosier45678@hotmail.com>
Re: Hash of Arrays <hoosier45678@hotmail.com>
Re: Hash of Arrays <someone@example.com>
Re: Help with worthy project ? <hooper1@optonline.net>
Re: Help with worthy project ? krakle@visto.com
new CPAN modules on Fri Jun 23 2006 (Randal Schwartz)
Re: Online Graphing Calculator - Perl Backend <corff@zedat.fu-berlin.de>
Re: question on Net::LPR / Unix::Login <"v.niekerk at hccnet.nl">
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 23 Jun 2006 04:32:22 GMT
From: <jari.aalto@poboxes.com> (Jari Aalto+mail.perl)
Subject: [ANNOUNCE] Emacs modules for Perl programming
Message-Id: <perl-faq/emacs-lisp-modules_1151037091@rtfm.mit.edu>
Archive-name: perl-faq/emacs-lisp-modules
Posting-Frequency: 2 times a month
Maintainer: Jari Aalto A T cante net
Announcement: "What Emacs lisp modules can help with programming Perl"
Preface
Emacs is your friend if you have to do anything comcerning software
development: It offers plug-in modules, written in Emacs lisp
(elisp) language, that makes all your programmings wishes come
true. Please introduce yourself to Emacs and your programming era
will get a new light.
Where to find Emacs/XEmacs
o Unix:
http://www.gnu.org/software/emacs/emacs.html
http://www.xemacs.org/
o Unix Windows port (for Unix die-hards):
install http://www.cygwin.com/ which includes native Emacs 21.x.
and XEmacs port
o Pure Native Windows port
http://www.gnu.org/software/emacs/windows/ntemacs.html
ftp://ftp.xemacs.org/pub/xemacs/windows/setup.exe
o More Emacs resources at
http://tiny-tools.sourceforge.net/ => Emacs resource page
Emacs Perl Modules
Cperl -- Perl programming mode
http://math.berkeley.edu/~ilya/software/emacs/
by Ilya Zakharevich
CPerl is major mode for editing perl files. Also included in
latest Emacs, but newest version is at Ilya's site. Note that
the directrory at CPAN is out of date:
http://www.cpan.org/modules/by-authors/id/ILYAZ/cperl-mode/
Compared to default `perl-mode' that comes with Emacs, this
one has more features.
TinyPerl -- Perl related utilities
http://tiny-tools.sourceforge.net/
If you ever wonder how to deal with Perl POD pages or how to find
documentation from all perl manpages, this package is for you.
Couple of keystrokes and all the documentaion is in your hands.
o Instant function help: See documentation of `shift', `pop'...
o Show Perl manual pages in *pod* buffer
o Grep through all Perl manpages (.pod)
o Follow POD references e.g. [perlre] to next pod with RETURN
o Coloured pod pages with `font-lock'
o Separate `tiperl-pod-view-mode' for jumping topics and pages
forward and backward in *pod* buffer.
o Update `$VERSION' variable with YYYY.MMDD on save.
o Load source code into Emacs, like Devel::DProf.pm
o Prepare script (version numbering) and Upload it to PAUSE
o Generate autoload STUBS (Devel::SelfStubber) for you
Perl Module (.pm)
TinyIgrep -- Perl Code browsing and easy grepping
[TinyIgrep is included in Tiny Tools Kit]
To grep from all installed Perl modules, define database to
TinyIgrep. There is example file emacs-rc-tinyigrep.el that shows
how to set up dattabases for Perl5, Perl4 whatever you have
installed
TinyIgrep calls Igrep.el to to do the search, You can adjust
recursive grep options, set search case sensitivity, add user grep
options etc.
You can find latest `igrep.el' module at
<http://groups.google.com/groups?group=gnu.emacs.sources> The
maintainer is Jefin Rodgers <kevinr@ihs.com>.
TinyCompile -- To Browse grep results in Emacs *compile* buffer
TinyCompile is a minor mode for *compile* buffer from where
you can collapse unwanted lines or shorten file URLs:
/asd/asd/asd/asd/ads/as/da/sd/as/as/asd/file1:NNN: MATCHED TEXT
/asd/asd/asd/asd/ads/as/da/sd/as/as/asd/file2:NNN: MATCHED TEXT
-->
cd /asd/asd/asd/asd/ads/as/da/sd/as/as/asd/
file1:NNN: MATCHED TEXT
file1:NNN: MATCHED TEXT
End
------------------------------
Date: Thu, 22 Jun 2006 23:57:12 -0500
From: James <hoosier45678@hotmail.com>
Subject: Re: Hash of Arrays
Message-Id: <pan.2006.06.23.04.57.07.12836@hotmail.com>
On Thu, 22 Jun 2006 18:58:39 -0700, Deepu wrote:
> %hash = (
> FILE1 => ["STATEMAIN", "STATESUSPEND", "STATE1",
> "STATE2", "STATERESUME", "RESET"],
> FILE1 => ["STATEMAIN", "STATE9", "STATE10"], FILE2 => - -
> - - -
> );
Back up and perldoc perldata, then perldoc perlreftut. Your understanding
of hashes (aka associative arrays) is well off.
Here's something like what you asked for, untested... hope this wasn't a
homework assignment
################################################
use strict;
use Data::Dumper;
my @files = qw/FILE1 FILE2/;
my %transitions;
foreach my $filename (@files)
{
my $fh;
open $fh, $filename
or do {
warn "$filename missing";
next;
};
my $run_through = 0;
my $recording_enabled = 0;
while (<$fh>)
{
if (/^RESET\b/)
{
$recording_enabled = 0;
}
elsif (/^STATEMAIN\b/)
{
$run_through++;
$recording_enabled = 1;
push @{$transitions{$filename}[$run_through]}, $_;
}
elsif ($recording_enabled)
{
push @{$transitions{$filename}[$run_through]}, $_;
}
}
close $fh or die $!;
}
print Dumper \%transitions;
------------------------------
Date: Fri, 23 Jun 2006 00:28:55 -0500
From: James <hoosier45678@hotmail.com>
Subject: Re: Hash of Arrays
Message-Id: <pan.2006.06.23.05.28.51.75710@hotmail.com>
On Thu, 22 Jun 2006 23:57:12 -0500, James wrote:
Just looked over what I wrote and was critiquing myself...
> ################################################ use strict;
> use Data::Dumper;
>
> my @files = qw/FILE1 FILE2/;
>
> my %transitions;
>
> foreach my $filename (@files)
> {
> my $fh;
> open $fh, $filename
> or do {
> warn "$filename missing";
change to:
warn "$filename:$!";
> next;
> };
>
> my $run_through = 0;
> my $recording_enabled = 0;
> while (<$fh>)
> {
> if (/^RESET\b/)
> {
> $recording_enabled = 0;
> }
> elsif (/^STATEMAIN\b/)
> {
> $run_through++;
change to:
if (defined $transitions{$filename}[$run_through])
{
$run_through++;
}
> $recording_enabled = 1;
> push @{$transitions{$filename}[$run_through]}, $_;
> }
> elsif ($recording_enabled)
> {
> push @{$transitions{$filename}[$run_through]}, $_;
> }
> }
> close $fh or die $!;
> }
>
> print Dumper \%transitions;
------------------------------
Date: Fri, 23 Jun 2006 06:31:23 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Hash of Arrays
Message-Id: <%ULmg.75153$A8.63883@clgrps12>
Deepu wrote:
>
> I have a problem and i am not able to get what might be a better way of
> solving this. Can somebody please give me some ideas on solving this.
>
> I have a file which have transitions like:
>
> STATE1
> STATE3
> STATEMAIN ####
> STATESUSPEND
> STATE1
> STATE2
> STATERESUME
> RESET
> STATE6
> STATE8
> STATEMAIN ####
> STATE9
> STATE10
>
> This indicates a transition from STATE1 to STATE3, then STATE3 to
> STATEMAIN and so on. There are also 10 files which will have different
> combinations of these states.
>
> Here i need to go through the file and check for STATEMAIN and when i
> see STATEMAIN, then i need to put it in an array till i see RESET or
> end of file. After that again i need to proceed further to check
> whether there is any more STATEMAIN. If present again i need to put it
> in a different array till RESET or end of file.
>
> I need to store it in an hash:
>
> %hash = (
> FILE1 => ["STATEMAIN", "STATESUSPEND", "STATE1",
> "STATE2", "STATERESUME", "RESET"],
> FILE1 => ["STATEMAIN", "STATE9", "STATE10"],
In Perl a hash cannot have two different keys with the same name.
> FILE2 => - - - - -
> );
>
> and also if there is no STATEMAIN in any file there is no need of
> putting in the hash.
This will put your data into a HoAoA:
my %hash;
while ( <> ) {
push @{ $hash{ $ARGV } }, [] if /STATEMAIN/;
push @{ $hash{ $ARGV }[ -1 ] }, $_ if /STATEMAIN/ .. /RESET/ || eof;
}
use Data::Dumper;
print Dumper \%hash;
John
--
use Perl;
program
fulfillment
------------------------------
Date: 22 Jun 2006 21:08:36 -0700
From: "GHBoom" <hooper1@optonline.net>
Subject: Re: Help with worthy project ?
Message-Id: <1151035716.358450.60960@i40g2000cwc.googlegroups.com>
J=FCrgen Exner wrote:
> GHBoom wrote:
> > for example as the script evolved
> > I used at one point @here=3Dsort(@there)
> > looking at it many many changes later, Im left ondering why I just
> > didnt
> > sort(@there) and be done with it !
>
> Maybe because you wanted to _use_ the sorted result and not compute it and
> then ignore it?
>
> jue
Your probably right I may have had plans for it, but they have been
long forgoten !!!
So, that code made it through umpteen revisions :(
I need someone who,
knows perl more then I,
has a fresh set of eyes,
willing to help me add some functions that I would love to see,
basicly, help me take it from looked like a newb wrote it to
wow ! this newb and others did a fine job !
Its a project, no doubt about it. I can search and read
all day for info, but some of this is
needs a person with a good solid foundation...
GHBoom
------------------------------
Date: 22 Jun 2006 22:58:51 -0700
From: krakle@visto.com
Subject: Re: Help with worthy project ?
Message-Id: <1151042331.630342.6280@u72g2000cwu.googlegroups.com>
GHBoom wrote:
> I need someone who,
> knows perl more then I,
> has a fresh set of eyes,
> willing to help me add some functions that I would love to see,
> basicly, help me take it from looked like a newb wrote it to
> wow ! this newb and others did a fine job !
>
> Its a project, no doubt about it. I can search and read
> all day for info, but some of this is
> needs a person with a good solid foundation...
>
> GHBoom
Why would anyone want to do your project for you for free? You mention
it *may* take off... No it won't. It won't because it looks "like a
newb wrote it". If you don't know Perl well enough to write effecient
programs than your project isn't even sufficient. With that said, Learn
the language and do it yourself or pay someone... In any case, this
isn't the place for it...
------------------------------
Date: Fri, 23 Jun 2006 04:42:06 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Fri Jun 23 2006
Message-Id: <J1AqE6.CAL@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.
App-SimpleScan-1.09
http://search.cpan.org/~mcmahon/App-SimpleScan-1.09/
simple_scan's core code
----
Audio-M4P-0.32
http://search.cpan.org/~billh/Audio-M4P-0.32/
M4P/MP4/M4A QuickTime audio music format modules
----
Authen-PAAS-1.1.1
http://search.cpan.org/~danberr/Authen-PAAS-1.1.1/
Perl Authentication & Authorization Service
----
B-Deobfuscate-0.13
http://search.cpan.org/~jjore/B-Deobfuscate-0.13/
Extension to B::Deparse for use in de-obfuscating source code
----
Bundle-Combust-1.03
http://search.cpan.org/~abh/Bundle-Combust-1.03/
All the modules required to run Combust
----
Class-MOP-0.29_02
http://search.cpan.org/~stevan/Class-MOP-0.29_02/
A Meta Object Protocol for Perl 5
----
DBIx-Log4perl-0.05
http://search.cpan.org/~mjevans/DBIx-Log4perl-0.05/
Perl extension for DBI to selectively log SQL, parameters, result-sets, transactions etc to a Log::Log4perl handle.
----
File-Copy-Recursive-0.24
http://search.cpan.org/~dmuey/File-Copy-Recursive-0.24/
Perl extension for recursively copying files and directories
----
Formatter-HTML-MPS-0.2
http://search.cpan.org/~vetler/Formatter-HTML-MPS-0.2/
----
Froody-42.007
http://search.cpan.org/~fotango/Froody-42.007/
Yet another XML web API framework
----
Getopt-GUI-Long-0.61
http://search.cpan.org/~hardaker/Getopt-GUI-Long-0.61/
----
Getopt-GUI-Long-0.62
http://search.cpan.org/~hardaker/Getopt-GUI-Long-0.62/
----
Mac-Carbon-0.76
http://search.cpan.org/~cnandor/Mac-Carbon-0.76/
Access to Mac OS Carbon API
----
Module-ExtractUse-0.18
http://search.cpan.org/~domm/Module-ExtractUse-0.18/
Find out what modules are used
----
Net-Lite-FTP-0.45
http://search.cpan.org/~eyck/Net-Lite-FTP-0.45/
Perl FTP client with support for TLS
----
Parse-RecDescent-Topiary-0.02
http://search.cpan.org/~ivorw/Parse-RecDescent-Topiary-0.02/
tree surgery for Parse::RecDescent autotrees
----
Plagger-0.7.3
http://search.cpan.org/~miyagawa/Plagger-0.7.3/
Pluggable RSS/Atom Aggregator
----
QWizard-3.01
http://search.cpan.org/~hardaker/QWizard-3.01/
Display a series of questions, get the answers, and act on the answers.
----
QWizard-3.02
http://search.cpan.org/~hardaker/QWizard-3.02/
Display a series of questions, get the answers, and act on the answers.
----
QWizard-3.03
http://search.cpan.org/~hardaker/QWizard-3.03/
Display a series of questions, get the answers, and act on the answers.
----
Regexp-MultiLanguage-0.01
http://search.cpan.org/~robwalker/Regexp-MultiLanguage-0.01/
Convert common regular expressions checks in to Perl, PHP, and JavaScript code.
----
Sub-Uplevel-0.13
http://search.cpan.org/~dagolden/Sub-Uplevel-0.13/
apparently run a function in a higher stack frame
----
Sys-Virt-0.1.1
http://search.cpan.org/~danberr/Sys-Virt-0.1.1/
Represent and manage a libvirt hypervisor connection
----
Template-Provider-Markdown-0.01
http://search.cpan.org/~gugod/Template-Provider-Markdown-0.01/
Markdown as template body, no HTML.
----
Term-Menus-1.13
http://search.cpan.org/~reedfish/Term-Menus-1.13/
Create Powerful Terminal, Console and CMD Enviroment Menus
----
Test-WWW-Selenium-1.01
http://search.cpan.org/~lukec/Test-WWW-Selenium-1.01/
Test applications using Selenium Remote Control
----
WWW-Search-Odeo-0.1
http://search.cpan.org/~sock/WWW-Search-Odeo-0.1/
Find cool stuff in Odeo
----
YAML-AppConfig-0.10
http://search.cpan.org/~moconnor/YAML-AppConfig-0.10/
Manage configuration files with YAML and variable reference.
----
YAML-AppConfig-0.12
http://search.cpan.org/~moconnor/YAML-AppConfig-0.12/
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: 23 Jun 2006 04:51:51 GMT
From: <corff@zedat.fu-berlin.de>
Subject: Re: Online Graphing Calculator - Perl Backend
Message-Id: <4g1ab7F1k2937U2@uni-berlin.de>
robby.walker@gmail.com wrote:
: I've just released a full-featured online graphing calculator at
: http://www.e-tutor.com/et2/graphing/ - the back end is built with
: (mod_)Perl and GD.
Beautiful.
: points on the curve, graph multiple functions, and more. I'm also
: interested in hearing people's feature requests.
I noticed some small parsing problem in the function field:
You can have a function "x", but you can't say "-x", you have to say
"-1*x" instead. Likewise, "x/2" works, but "-x/2" has to be expressed
as "-1*x/2".
I did not try other things yet.
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: Fri, 23 Jun 2006 06:38:09 +0200
From: Huub <"v.niekerk at hccnet.nl">
Subject: Re: question on Net::LPR / Unix::Login
Message-Id: <449b7045$0$27495$e4fe514c@dreader26.news.xs4all.nl>
>> 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.
>
> 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.
------------------------------
Date: Fri, 23 Jun 2006 06:32:49 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <lWLmg.102756$H71.27944@newssvr13.news.prodigy.com>
Chris Smith wrote:
> I don't recall who said what at this
> point, but earlier today someone else posted -- in this same thread --
> the idea that static type "advocates" want to classify some languages as
> untyped in order to put them in the same category as assembly language
> programming. That's something I've never seen, and I think it's far
> from the goal of pretty much anyone; but clearly, *someone* was
> concerned about it. I don't know if much can be done to clarify this
> rhetorical problem, but it does exist.
For the record, I'm not concerned about that problem as such. However,
I do think that characterizations of dynamically typed languages from a
static type perspective tend to oversimplify, usually because they
ignore the informal aspects which static type systems don't capture.
Terminology is a big part of this, so there are valid reasons to be
careful about how static type terminology and concepts are applied to
languages which lack formally defined static type systems.
> The *other* bit that's been brought up in this thread is that the word
> "type" is just familiar and comfortable for programmers working in
> dynamically typed languages, and that they don't want to change their
> vocabulary.
What I'm suggesting is actually a kind of bridge between the two
positions. The dynamically typed programmer tends to think in terms of
values having types, rather than variables. What I'm pointing out is
that even those programmers reason about something much more like static
types than they might realize; and that there's a connection between
that reasoning and static types, and also a connection to the tags
associated with values.
If you wanted to take the word "type" and have it mean something
reasonably consistent between the static and dynamic camps, what I'm
suggesting at least points in that direction. Obviously, nothing in the
dynamic camp is perfectly isomorphic to a real static type, which is why
I'm qualifying the term as "latent type", and attempting to connect it
to both static types and to tags.
> The *third* thing that's brought up is that there is a (to me, somewhat
> vague) conception going around that the two really ARE varieties of the
> same thing. I'd like to pin this down more, and I hope we get there,
> but for the time being I believe that this impression is incorrect. At
> the very least, I haven't seen a good way to state any kind of common
> definition that withstands scrutiny. There is always an intuitive word
> involved somewhere which serves as an escape hatch for the author to
> retain some ability to make a judgement call, and that of course
> sabotages the definition. So far, that word has varied through all of
> "type", "type error", "verify", and perhaps others... but I've never
> seen anything that allows someone to identify some universal concept of
> typing (or even the phrase "dynamic typing" in the first place) in a way
> that doesn't appeal to intuition.
It's obviously going to be difficult to formally pin down something that
is fundamentally informal. It's fundamentally informal because if
reasoning about the static properties of terms in DT languages were
formalized, it would essentially be something like a formal type system.
However, there are some pretty concrete things we can look at. One of
them, which as I've mentioned elsewhere is part of what led me to my
position, is to look at what a soft type inferencer does. It takes a
program in a dynamically typed language, and infers a static type scheme
for it (obviously, it also defines an appropriate type system for the
language.) This has been done in both Scheme and Erlang, for example.
How do you account for such a feat in the absence of something like
latent types? If there's no static type-like information already
present in the program, how is it possible to assign a static type
scheme to a program without dramatically modifying its source?
I think it's reasonable to look at a situation like that and conclude
that even DT programs contain information that corresponds to types.
Sure, it's informal, and sure, it's usually messy compared to an
explicitly defined equivalent. But the point is that there is
"something" there that looks so much like static types that it can be
identified and formalized.
> Undoubtedly, some programmers sometimes perform reasoning about their
> programs which could also be performed by a static type system.
I think that's a severe understatement. Programmers always reason about
things like the types of arguments, the types of variables, the return
types of functions, and the types of expressions. They may not do
whole-program inference and proof in the way that a static type system
does, but they do it locally, all the time, every time.
BTW, I notice you didn't answer any of the significant questions which I
posed to Vesa. So let me pose one directly to you: how should I rewrite
the first sentence in the preceding paragraph to avoid appealing to an
admittedly informal notion of type? Note, also, that I'm using the word
in the sense of static properties, not in the sense of tagged values.
>>There are reasons to connect
>>it to type theory, and if you can't see those reasons, you need to be
>>more explicit about why.
>
>
> Let me pipe up, then, as saying that I can't see those reasons; or at
> least, if I am indeed seeing the same reasons that everyone else is,
> then I am unconvinced by them that there's any kind of rigorous
> connection at all.
For now, I'll stand on what I've written above. When I see if or how
that doesn't convince you, I can go further.
> It is, nevertheless, quite appropriate to call the language "untyped" if
> I am considering static type systems.
I agree that in the narrow context of considering to what extent a
dynamically typed language has a formal static type system, you can call
it untyped. However, what that essentially says is that formal type
theory doesn't have the tools to deal with that language, and you can't
go much further than that. As long as that's what you mean by untyped,
I'm OK with it.
> I seriously doubt that this usage
> in any way misleads anyone into assuming the absence of any mental
> processes on the part of the programmer. I hope you agree.
I didn't suggest otherwise (or didn't mean to). However, the term
"untyped" does tend to lead to confusion, to a lack of recognition of
the significance of all the static information in a DT program that is
outside the bounds of a formal type system, and the way that runtime tag
checks relate to that static information.
One misconception that occurs is the assumption that all or most of the
static type information in a statically-typed program is essentially
nonexistent in a dynamically-typed program, or at least is no longer
statically present. That can easily be demonstrated to be false, of
course, and I'm not arguing that experts usually make this mistake.
> If not,
> then I think you significantly underestimate a large category of people.
If you think there's no issue here, I think you significantly
overestimate a large category of people. Let's declare that line of
argument a draw.
>>The first point I was making is that *automated* checking has very
>>little to do with anything, and conflating static types with automated
>>checking tends to lead to a lot of confusion on both sides of the
>>static/dynamic fence.
>
>
> I couldn't disagree more. Rather, when you're talking about static
> types (or just "types" in most research literature that I've seen), then
> the realm of discussion is specifically defined to be the very set of
> errors that are automatically caught and flagged by the language
> translator. I suppose that it is possible to have an unimplemented type
> system, but it would be unimplemented only because someone hasn't felt
> the need nor gotten around to it. Being implementABLE is a crucial part
> of the definition of a static type system.
I agree with the latter sentence. However, it's nevertheless the case
that it's common to confuse "type system" with "compile-time checking".
This doesn't help reasoning in debates like this, where the existence
of type systems in languages that don't have automated static checking
is being examined.
> I am beginning to suspect that you're make the converse of the error I
> made earlier in the thread. That is, you may be saying things regarding
> the psychological processes of programmers and such that make sense when
> discussing dynamic types, and in any case I haven't seen any kind of
> definition of dynamic types that is more acceptable yet; but it's
> completely irrelevant to static types. Static types are not fuzzy -- if
> they were fuzzy, they would cease to be static types -- and they are not
> a phenomenon of psychology. To try to redefine static types in this way
> not only ignores the very widely accepted basis of entire field of
> existing literature, but also leads to false ideas such as that there is
> some specific definable set of problems that type systems are meant to
> solve.
I'm not trying to redefine static types. I'm observing that there's a
connection between the static properties of untyped programs, and static
types; and attempting to characterize that connection.
You need to be careful about being overly formalist, considering that in
real programming languages, the type system does have a purpose which
has a connection to informal, fuzzy things in the real world. If you
were a pure mathematician, you might get away with claiming that type
systems are just a self-contained symbolic game which doesn't need any
connections beyond its formal ruleset.
Think of it like this: the more ambitious a language's type system is,
the fewer uncaptured static properties remain in the code of programs in
that language. However, there are plenty of languages with rather weak
static type systems. In those cases, code has more static properties
that aren't captured by the type system. I'm pointing out that in many
of these cases, those properties resemble types, to the point that it
can make sense to think of them and reason about them as such, applying
the same sort of reasoning that an automated type inferencer applies.
If you disagree, then I'd be interested to hear your answers to the two
questions I posed to Vesa, and the related one I posed to you above,
about what else to call these things.
>>I agree, to make the comparison perfect, you'd need to define a type
>>system. But that's been done in various cases.
>
>
> I don't think that has been done, in the case of dynamic types.
I was thinking of the type systems designed for soft type inferencers;
as well as those cases where e.g. a statically-typed subset of an
untyped language is defined, as in the case of PreScheme.
But in such cases, you end up where a program in these systems, while in
some sense statically typed, is also a valid untyped program. There's
also nothing to stop someone familiar with such things programming in a
type-aware style - in fact, books like Felleisen et al's "How to Design
Programs" encourage that, recommending that functions be annotated with
comments expressing their type. Examples:
;; product : (listof number) -> number
;; copy : N X -> (listof X)
You also see something similar in e.g. many Erlang programs. In these
cases, reasoning about types is done explicitly by the programmer, and
documented.
What would you call the descriptions in those comments? Once you tell
me what I should call them other than "type" (or some qualified variant
such as "latent type"), then we can compare terminology and decide which
is more appropriate.
> It has
> been done for static types, but much of what you're saying here is in
> contradiction to the definition of a type system in that sense of the
> word.
Which is why I'm using a qualified version of the term.
>>The problem we're dealing with in this case is that anything that's not
>>formally defined is essentially claimed to not exist.
>
>
> I see it as quite reasonable when there's an effort by several
> participants in this thread to either imply or say outright that static
> type systems and dynamic type systems are variations of something
> generally called a "type system", and given that static type systems are
> quite formally defined, that we'd want to see a formal definition for a
> dynamic type system before accepting the proposition that they are of a
> kind with each other.
A complete formal definition of what I'm talking about may be impossible
in principle, because if you could completely formally define it, you'd
have a static type system.
If that makes you throw up your hands, then all you're saying is that
you're unwilling to deal with a very real phenomenon that has obvious
connections to type theory, examples of which I've given above. That's
your choice, but at the same time, you have to give up exclusive claim
to any variation of the word "type".
Terms are used in a context, and it's perfectly reasonable to call
something a "latent type" or even a "dynamic type" in a certain context
and point out connections between those terms and their cousins (or if
you insist, their completely unrelated namesakes) static types.
> So far, all the attempts I've seen to define a
> dynamic type system seem to reduce to just saying that there is a well-
> defined semantics for the language.
That's a pretty strong claim, considering you have so far ducked the
most important questions I raised in the post you replied to.
> I believe that's unacceptable for several reasons, but the most
> significant of them is this. It's not reasonable to ask anyone to
> accept that static type systems gain their essential "type system-ness"
> from the idea of having well-defined semantics.
The definition of static type system is not in question. However,
realistically, as I pointed out above, you have to acknowledge that type
systems exist in, and are inextricably connected to, a larger, less
formal context. (At least, you have to acknowledge that if you're
interested in programs that do anything related to the real world.) And
outside the formally defined borders of static type systems, there are
static properties that bear a pretty clear relationship to types.
Closing your eyes to this and refusing to acknowledge any connection
doesn't achieve anything. In the absence of some other account of the
phenomena in question, (an informal version of) types turn out to be a
pretty convenient way to deal with the situation.
> From the perspective of
> a statically typed language, this looks like a group of people getting
> together and deciding that the real "essence" of what it means to be a
> type system is...
There's a sense in which one can say that yes, the informal types I'm
referring to have an interesting degree of overlap with static types;
and also that static types do, loosely speaking, have the "purpose" of
formalizing the informal properties I'm talking about.
But I hardly see why such an informal characterization should bother
you. It doesn't affect the definition of static type. It's not being
held up as a foundation for type theory. It's simply a way of dealing
with the realities of programming in a dynamically-checked language.
There are some interesting philophical issues there, to be sure
(although only if you're willing to stray outside the formal), but you
don't have to worry about those unless you want to.
> and then naming something that's so completely non-
> essential that we don't generally even mention it in lists of the
> benefits of static types, because we have already assumed that it's true
> of all languages except C, C++, and assembly language.
This is based on the assumption that all we're talking about is
"well-defined semantics". However, there's much more to it than that.
I need to hear your characterization of the properties I've described
before I can respond.
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 9350
***************************************
