[27996] in Perl-Users-Digest
Perl-Users Digest, Issue: 9360 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 23 18:05:52 2006
Date: Fri, 23 Jun 2006 15:05:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 23 Jun 2006 Volume: 10 Number: 9360
Today's topics:
Re: DESTROY isn't called <mumia.w.18.spam+nospam.usenet@earthlink.net>
Re: Help - Inline::C arrayref deref? xhoster@gmail.com
Re: Help - Inline::C arrayref deref? xhoster@gmail.com
Re: Help Required !!!! krakle@visto.com
LWP::MediaTypes <sonalibhave@gmail.com>
Re: LWP::MediaTypes <David.Squire@no.spam.from.here.au>
Re: LWP::MediaTypes <sonalibhave@gmail.com>
Re: LWP::MediaTypes <David.Squire@no.spam.from.here.au>
Re: Native language versions <corff@zedat.fu-berlin.de>
passing an array to another program guser@packetstorm.org
Re: passing an array to another program <noreply@gunnar.cc>
Re: passing an array to another program <mritty@gmail.com>
Re: Saying "latently-typed language" is making a catego <pc@p-cos.net>
Re: Saying "latently-typed language" is making a catego <pats@acm.org>
Re: Saying "latently-typed language" is making a catego <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: Saying "latently-typed language" is making a catego <marshall.spight@gmail.com>
Re: service name package <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 Jun 2006 20:52:38 GMT
From: "Mumia W." <mumia.w.18.spam+nospam.usenet@earthlink.net>
Subject: Re: DESTROY isn't called
Message-Id: <qwYmg.1351$ii.1077@newsread3.news.pas.earthlink.net>
Ferry Bolhar wrote:
> 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
>
>
It seems that perl doesn't like to call destructors on objects which are
based upon code refs. Just use an array ref like so:
sub later (&) {
bless [ shift ], 'Later';
}
sub Later::DESTROY {
$_[0]->[0]->();
}
Or you could use a scalar reference:
sub later ($) {
my $code = $_[0];
bless (\$code, 'Later');
}
sub Later::DESTROY {
${$_[0]}->();
}
If this restriction is not a bug in perl, perhaps someone should drop a
note to the editor of that book.
------------------------------
Date: 23 Jun 2006 18:47:59 GMT
From: xhoster@gmail.com
Subject: Re: Help - Inline::C arrayref deref?
Message-Id: <20060623144804.628$Pr@newsreader.com>
"Sisyphus" <sisyphus1@nomail.afraid.org> wrote:
> It seems to depend upon the placement of the sv_2mortal call. In the
> below script, the foo2 function will try to "free unreferenced scalar",
> but with foo1 there's no such problem (and neither foo1 nor foo2 leak
> memory afaict):
In foo2, the initial value of av_ret (the one from newAV()) never gets
freed at all, well the 2nd value of av_ret gets freed twice. If that
doesn't leak (and it appears not to) then apparently sometimes two wrongs
can indeed make a right!
>
> AV * foo2(SV * x) {
> AV * av_ret = newAV();
> av_ret = (AV*)SvRV(x);
> sv_2mortal(av_ret);
> return av_ret;
> }
>
...
>
> I really don't know whether it's correct to be providing an AV* as the
> argument to sv_2mortal(). There's no denying that it fixes the memory
> leak problem, but it also produces the following warnings during the
> compilation phase:
If you cast the AV* to an SV* first, the warning goes away.
sv_2mortal((SV*) av_ret);
Of course, the lack of warning still doesn't prove that it is proper. I
haven't found any examples of this in the docs, but there are plenty of
analogs to it:
SV* newRV_inc((SV*) thing);
SV* newRV_noinc((SV*) thing);
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 23 Jun 2006 21:05:02 GMT
From: xhoster@gmail.com
Subject: Re: Help - Inline::C arrayref deref?
Message-Id: <20060623170507.826$qp@newsreader.com>
"Lee" <leegee@gmail.com> wrote:
> xhoster@gmail.com wrote:
> > "Lee" <leegee@gmail.com> wrote:
> > > xhoster@gmail.com wrote:
> > > > "Sisyphus" <sisyphus1@nomail.afraid.org> wrote:
> > > > > Also, I was puzzled by the SvREFCNT_inc() call in the original
> > > > > code.
> > > >
> > > > You are right, that also shouldn't be there. I had cleaned it up
> > > > but forgot to mention doing so. That one is particularly
> > > > pernicious, because it causes the leak to occur in the regular Perl
> > > > code.
> > >
> > > Could you please explain? I'm confused because my XS and perlguts is
> > > minimal. If I replace this:
> > >
> > > AV* av_pcm = newAV();
> > > if (SvROK(rpcm) && (SvTYPE(SvRV(rpcm)) == SVt_PVAV))
> > > av_pcm = (AV*)SvREFCNT_inc(SvRV(rpcm));
> > >
> > > with this:
> > >
> > > AV* av_pcm = newAV();
> > > av_pcm = (AV*)(SvRV(rpcm));
> > >
> > > I get told, "Attempt to free unreferenced scalar: SV 0xb79d7540"
> >
> > I don't get that if I make that change on the code you originally
> > posted in the first post of this thread. Are you sure you don't make
> > some other change too? Can you show the complete code for the new C
> > sub?
>
> Here it is - my first C in years, my first every C/Perl integration:
>
> __C__
>
> AV* get_y (
> int samples_per_pixel,
> int height,
> float v_scale,
> SV* rpcm
> ){
> int i,j,fin;
> AV* av_ret = newAV();
> AV* av_pcm = newAV();
The new thingy that av_pcm points to needs to be cleaned up eventually.
The best way to make sure that happens is to call sv_2mortal now.
(Although I still question the need for the newAV at all, since in
non-error conditions it will immediately get thrown away.
> if (SvROK(rpcm) && (SvTYPE(SvRV(rpcm)) == SVt_PVAV))
> av_pcm = (AV*)SvREFCNT_inc(SvRV(rpcm));
Here (assuming the if statement works out, which it will if you actually
passed an arrayref), you overwrite the value of av_pcm, permanently loosing
it's old value. Now it is impossible for it to get cleaned up, since
no one any longer has track of it.
> sv_2mortal(av_pcm); // Thx perl.misc xho
Here you tell it to mortalize the new value of av_pcm (again, assuming the
if statement was satisfied). Because of the SvREFCNT_inc, the new value
actually does need to be mortalized. If you don't do the SvREFCNT_inc,
then this doesn't need to be (and in fact needs not to be) mortalized.
So get rid of the SvREFCNT_inc, then move the sv_2mortal to before rather
than after the if statement.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 23 Jun 2006 11:06:50 -0700
From: krakle@visto.com
Subject: Re: Help Required !!!!
Message-Id: <1151086010.277102.247910@y41g2000cwy.googlegroups.com>
vandana wrote:
> Subject: Help Required !!!!!
Help is required... It's optional...
------------------------------
Date: 23 Jun 2006 11:44:35 -0700
From: "spp" <sonalibhave@gmail.com>
Subject: LWP::MediaTypes
Message-Id: <1151088275.728765.101800@c74g2000cwc.googlegroups.com>
hello ,
I am using LWP::MeidaTypes package to get the mediatype. If it doesnt
recognize the type it returns media type as: application/octet-stream.
I am using its add_type function to add some extentions like bmp, php
etc. but its add_type doesnt seem to be working.
or may be I am doing something wrong.
My code :
use LWP::MediaTypes qw(add_type guess_media_type);
add_type("text/special")=>qw(shtml php htm);
add_type("image/special")=>qw(bmp png jpeg);
my $type = guess_media_type("http://www.cnn.com/abc.php" );
print "media type is". $type;
#
if i run this it prints media type is application/octet-stream
can anyone please tell me what am I doing wrong?
Thanks in advance,
SP
------------------------------
Date: Fri, 23 Jun 2006 19:55:58 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: LWP::MediaTypes
Message-Id: <e7hdfv$1m1$1@news.ox.ac.uk>
spp wrote:
> hello ,
>
> I am using LWP::MeidaTypes package to get the mediatype. If it doesnt
> recognize the type it returns media type as: application/octet-stream.
> I am using its add_type function to add some extentions like bmp, php
> etc. but its add_type doesnt seem to be working.
> or may be I am doing something wrong.
>
> My code :
>
> use LWP::MediaTypes qw(add_type guess_media_type);
>
> add_type("text/special")=>qw(shtml php htm);
>
> add_type("image/special")=>qw(bmp png jpeg);
>
>
> my $type = guess_media_type("http://www.cnn.com/abc.php" );
> print "media type is". $type;
>
> #
> if i run this it prints media type is application/octet-stream
>
Could you please give us a *real example*, as a *small but complete*
script? For a start, "http://www.cnn.com/abc.php" does not exist, and
the 404 page that the CNN site generates begins:
HTTP/1.1 404 Not Found
Date: Fri, 23 Jun 2006 18:51:32 GMT
Server: Apache
Vary: Accept-Encoding,User-Agent
Cache-Control: private
Content-Type: text/html
Content-Length: 23584
Connection: close
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
...
DS
------------------------------
Date: 23 Jun 2006 12:11:26 -0700
From: "spp" <sonalibhave@gmail.com>
Subject: Re: LWP::MediaTypes
Message-Id: <1151089886.116517.280810@b68g2000cwa.googlegroups.com>
ok , real example:
http://www.uccs.edu/%7Ewebdept/az/AZdir.php
thanks,
SP
David Squire wrote:
> spp wrote:
> > hello ,
> >
> > I am using LWP::MeidaTypes package to get the mediatype. If it doesnt
> > recognize the type it returns media type as: application/octet-stream.
> > I am using its add_type function to add some extentions like bmp, php
> > etc. but its add_type doesnt seem to be working.
> > or may be I am doing something wrong.
> >
> > My code :
> >
> > use LWP::MediaTypes qw(add_type guess_media_type);
> >
> > add_type("text/special")=>qw(shtml php htm);
> >
> > add_type("image/special")=>qw(bmp png jpeg);
> >
> >
> > my $type = guess_media_type("http://www.cnn.com/abc.php" );
> > print "media type is". $type;
> >
> > #
> > if i run this it prints media type is application/octet-stream
> >
>
> Could you please give us a *real example*, as a *small but complete*
> script? For a start, "http://www.cnn.com/abc.php" does not exist, and
> the 404 page that the CNN site generates begins:
>
> HTTP/1.1 404 Not Found
> Date: Fri, 23 Jun 2006 18:51:32 GMT
> Server: Apache
> Vary: Accept-Encoding,User-Agent
> Cache-Control: private
> Content-Type: text/html
> Content-Length: 23584
> Connection: close
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> ...
>
> DS
------------------------------
Date: Fri, 23 Jun 2006 20:26:04 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: LWP::MediaTypes
Message-Id: <e7hf8c$27c$1@news.ox.ac.uk>
spp wrote:
> ok , real example:
>
> http://www.uccs.edu/%7Ewebdept/az/AZdir.php
>
No. Real example of your small but complete script.
For what it's worth, the header for that one is:
HTTP/1.1 302 Found
Date: Fri, 23 Jun 2006 19:23:54 GMT
Server: Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7e PHP/4.4.1 DAV/2
X-Powered-By: PHP/4.4.1
location: http://www.uccs.edu/%7Ewebdept/az/azstatic/A.html
Content-Length: 7694
Content-Type: text/html; charset=ISO-8859-1
It correctly reports its content-type as text/html. Why would you want
to change that?
DS
------------------------------
Date: 23 Jun 2006 20:06:11 GMT
From: <corff@zedat.fu-berlin.de>
Subject: Re: Native language versions
Message-Id: <4g2vtjF1k2m2dU1@uni-berlin.de>
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
: 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 sure this will happen. Even though this is not Perl, but TeX, I know
of one case in Mongolia where a Mongolian computer scientist implemented
a package with Mongolian commands, instead of the English commands (TeX
is macro-based, and it is not a big problem to compile a huge list of
aliases to the existing macros).
: > Is it still Perl?
: No. Definitely not. It is a different language which can be translated
: into perl and can use Perl modules.
Well, I am not at all against writing modules which can replace (or enrich)
"native" Perl commands, statements and structures with English names by
any other given language. A bit further into the still dawning age of Unicode,
and everything can be expressed with non-ASCII characters. Not that Perl
is the restricting factor, but the constraints are usually in the users'
platforms.
I still have my doubts that it will help to lead people back to the joy
of programming even a simple script. You cited the age of CLIs and built-
in Basic, command shells etc. This age will not really return to the average
computer user any more. Computers tend to become more and more taken for
granted, omnipresent and powerful, to a degree that they start vanishing
from public perception, just like electry which is delivered from wall
outlets, not power plants, etc. Who still realizes that a digital camera,
a mobile phone, the cash register at the local market or the ignition control
system of your car happen to be powerful computers with specialized purposes
and interfaces?
That leads me back to Perl. The true hurdle lies not in the choice of
English of French or Japanese words for things like "print" or "while".
These can be replaced easily. Judging by an overwhelming number of postings,
we see fundamental conceptual errors as the source of various posters'
problems. Take anything like
$line_1="first line";
$line_2="second line";
$line_3=...
combined with the question "How can I construct a variable name from a
variable?"
where everybody can see that the answer would be an array. Or someone
puts $element=@elements and wonders why @elements=('a','b','c')
always becomes "3" in $element, instead of "abc".
This newsgroup is full of initial postings based on conceptual errors, and
astonishingly enough, these conceptual errors can occur even in the code
of contributors who otherwise seem to be quite fluent in fairly idiomatic
Perl. I do not think that the ratio of conceptual misunderstandings will
really decrease with localized programming code wordings.
This is why I question the practicality of just translating the keywords
of a language like Perl. First of all, the documentation needs a good,
thorough and complete translation, then you still can translate keywords,
but when you come to concepts, structures and symbols, there is not much
to translate. You have to learn them. Is the average native English (be she
British, American or Asian-Pacific (Australia and Hong Kong come to my mind))
programmer statistically less error-prone and more successful as a programmer
just because she seemingly doesn't have to learn the keywords?
The module providing English names to Perl's built-in variables ($_, $/,
$., etc.) can be complemented by a module providing German, Japanese, Chinese
and other names. This is helpful indeed, but users still have to read and
understand from documentation and general computer science knowledge how
to manipulate these symbols, and how to manipulate their data by them.
It doesn't really help if a German user has difficulties applying a $/
if the concept of an $INPUT_RECORD_SEPARATOR is not well understood, notably
if the first occurrence in perlvar.pod says "# enable localized slurp mode".
It doesn't even use concepts like EOL, record separators etc. Just imagine
a young Chinese, Japanese or even German computer science student trying
to understand what "slurp" means in the context of reading from a file handle,
while the first reference in the Oxford English dictionary is:
eat or drink (something) with a loud sloppy sucking noise:
she slurped her coffee | [ intrans. ] he slurped noisily
from a wine cup.
The first thing the definition mentions is the noise of the action, not the
"whole cup of coffee in one scoop" concept.
Perl is not Java! And here, English-speaking computer scientists and Perl
programmers do have an unfair advantage over speakers of different tongues,
all the more in cultural backgrounds which allow the peaceful coexistence
of humour, wit and irony with absolutely serious business. Not all
cultures do appreciate this ambiguity which may be highly irritating in
Japan, Egypt, India or many other places.
To make a long story short: Language is more than lexicon and grammar.
Replacing the lexicon by close approximates of the lexicon is only partially
helpful. It is the documentation which needs a careful translation first.
Perhaps after porting Perl to so many platforms, we should start porting
the Perl documentation to more languages besides English. CPAN would gain
a huge advantage from such an effort, as would the global Perl community.
If a good framework is established, then any hint to e.g. perlreftut will
still point to the intended information, regardless of the language in which
the documentation is perused.
Sorry for the lack of conciseness.
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
Date: 23 Jun 2006 12:05:32 -0700
From: guser@packetstorm.org
Subject: passing an array to another program
Message-Id: <1151089532.177317.218910@i40g2000cwc.googlegroups.com>
I have a scheduler program that hands off tasks to a tasking program
like this
my $retval = `tasker.pl @tasks`;
where the tasks are built like this
push (@tasks,"/program.pl --var=$val");
the tasker program gets the data but ARGV breaks up the task strings
into pieces
(@ARGV)
/program.pl [0]
--var=var1 [1]
/program.pl [2]
--var=var2 [3]
Where I need the data to be recieved like I passed it
(@ARGV)
/program.pl --var=var1 [0]
/program.pl --var=var2 [1]
Is there a way to force sending a series of strings (with spaces in in
the string) in array format to another program so that the destination
program can recieve each string intact without being split when
accessing ARGV?
thanks
------------------------------
Date: Fri, 23 Jun 2006 22:00:49 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: passing an array to another program
Message-Id: <4g2vnfF1for9lU1@individual.net>
guser@packetstorm.org wrote:
> I have a scheduler program that hands off tasks to a tasking program
> like this
>
> my $retval = `tasker.pl @tasks`;
>
> where the tasks are built like this
>
> push (@tasks,"/program.pl --var=$val");
>
> the tasker program gets the data but ARGV breaks up the task strings
> into pieces
> (@ARGV)
> /program.pl [0]
> --var=var1 [1]
> /program.pl [2]
> --var=var2 [3]
>
> Where I need the data to be recieved like I passed it
> (@ARGV)
> /program.pl --var=var1 [0]
> /program.pl --var=var2 [1]
>
> Is there a way to force sending a series of strings (with spaces in in
> the string) in array format to another program so that the destination
> program can recieve each string intact without being split when
> accessing ARGV?
If tasker.pl is a Perl program:
@ARGV = @tasks;
my $retval = do 'tasker.pl';
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 23 Jun 2006 13:03:29 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: passing an array to another program
Message-Id: <1151093009.865089.120520@m73g2000cwd.googlegroups.com>
guser@packetstorm.org wrote:
> I have a scheduler program that hands off tasks to a tasking program
> like this
>
> my $retval = `tasker.pl @tasks`;
>
> where the tasks are built like this
>
> push (@tasks,"/program.pl --var=$val");
>
> the tasker program gets the data but ARGV breaks up the task strings
> into pieces
> (@ARGV)
> /program.pl [0]
> --var=var1 [1]
> /program.pl [2]
> --var=var2 [3]
>
> Where I need the data to be recieved like I passed it
> (@ARGV)
> /program.pl --var=var1 [0]
> /program.pl --var=var2 [1]
>
> Is there a way to force sending a series of strings (with spaces in in
> the string) in array format to another program so that the destination
> program can recieve each string intact without being split when
> accessing ARGV?
The exact same way you would do it if you were not using perl, but
using the shell directly: enclose each entire argument in single
quotes:
push (@tasks,qq{'/program.pl --var=$val'});
Note that you could keep the "" rather than qq{}, but I prefer not to
use " and ' right next to each other in any piece of code.
Paul Lalli
------------------------------
Date: Fri, 23 Jun 2006 22:23:44 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <4g30ugF1l571tU1@individual.net>
Chris Uppal wrote:
> 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.
I don't know your definition of "real problem" ;), but ACL2 is
definitely used in industrial settings.
See
http://www.cs.utexas.edu/users/moore/publications/how-to-prove-thms/intro-to-acl2.pdf
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Fri, 23 Jun 2006 21:08:39 GMT
From: Patricia Shanahan <pats@acm.org>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <rLYmg.191$NP4.106@newsread1.news.pas.earthlink.net>
Chris Smith wrote:
> 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.
>
Of course, we can, and should, prefer programs we can prove terminate.
Languages can make it easier or harder to write provably terminating
programs.
Patricia
------------------------------
Date: Fri, 23 Jun 2006 22:23:33 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <449c5b85$0$656$bed64819@news.gradwell.net>
Chris Smith wrote:
> 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.
There may be more flexibility in this area than you'd think. I get the
impression that (after only a few years hard work) the terms "weak typing" and
"strong typing", used as synonyms for what we are here calling "dynamic typing"
and "static typing", are starting to die out.
So be of good hope !
I may yet be persuaded to talk of "static type checks" vs "dynamc checks" (with
a slight, veilled, sneer on the word "type" -- oh, so very limiting ;-)
> 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,
Not "arbitrary" -- there is only a specific class of statements that any given
type system can address. And, even if a given statement can be proved, then it
might not be something that most people would want to call a statement of type
(e.g. x > y).
It seems to me that most (all ? by definition ??) kinds of reasoning where we
want to invoke the word "type" tend to have a form where we reduce values (and
other things we want to reason about) to equivalence classes[*] w.r.t the
judgements we wish to make, and (usually) enrich that structure with
more-or-less stereotypical rules about which classes are substitutable for
which other ones. So that once we know what "type" something is, we can
short-circuit a load of reasoning based on the language semantics, by
translating into type-land where we already have a much simpler calculus to
guide us to the same answer.
(Or representative symbols, or... The point is just that we throw away the
details which don't affect the judgements.)
> a
> corresponding "informal type theory" would just be the entire set of
> informal reasoning by programmers about their programs.
I think that, just as for static theorem proving, there is informal reasoning
that fits the "type" label, and informal reasoning that doesn't.
I would say that if informal reasoning (or explanations) takes a form
more-or-less like "X can [not] do Y because it is [not] a Z", then that's
taking advantage of exactly the short-cuts mentioned above, and I would want to
call that informal type-based reasoning. But I certainly wouldn't call most of
the reasoning I do type-based.
-- chris
------------------------------
Date: 23 Jun 2006 14:49:44 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <1151099384.490397.22510@i40g2000cwc.googlegroups.com>
Chris Uppal wrote:
> 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.
An example of a non-Turing-complete language (at least the core
language; the standard is getting huge) with guaranteed termination,
that is used everywhere and quite useful, is SQL.
I wouldn't want to write an accounting package in it; its abstraction
facilities are too weak. But the language is much more powerful
than it is usually given credit for.
Marshall
------------------------------
Date: Fri, 23 Jun 2006 15:25:08 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: service name package
Message-Id: <g694pyboesr.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 23 Jun 2006, thepoet_nospam@arcor.de wrote:
Me wrote:
>> How can I get a service name using IANA assigned port numbers?
>> I want pass a port number and possibly the protocol (tcp,udp,etc)
>> and have the name returned.
>>
>> One package that does this but I can't get to install via CPAN
>> is Net::IANA::PortNumbers.
>
> Have look at "perldoc -f getservbyport".
>
> my @data = getservbyport( 21, 'tcp' );
> print "Service is: " . $data[0] if( @data );
Great answer, only one thing: this uses the machine's local
definitions of services (usually from /etc/services in a Unix
environment AFAIK). So if the OP wants the real IANA numbers, not the
ones defined by this particular system (and yes, they should be the
same) then they have to use the CPAN module mentioned above.
Ted
------------------------------
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 9360
***************************************
