[28081] in Perl-Users-Digest
Perl-Users Digest, Issue: 9445 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 10 18:06:03 2006
Date: Mon, 10 Jul 2006 15: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, 10 Jul 2006 Volume: 10 Number: 9445
Today's topics:
=?ISO-8859-1?Q?Re:_Re:_Encoding_of_the_perl_output_=28= <benkasminbullock@gmail.com>
ANN: CamelBones 1.0.0 <sherm@dot-app.org>
ANN: CamelBones 1.0.0 <sherm@dot-app.org>
Get <no@spam.co.name>
Re: Get <mritty@gmail.com>
Re: Get <sherm@Sherm-Pendleys-Computer.local>
Re: Hangman <David.Squire@no.spam.from.here.au>
Re: Hangman <tadmc@augustmail.com>
Re: How to make env-vars effective on return from perl <sgt19@tid.es>
Re: Inline missing with ActiveState? <sigzero@gmail.com>
Re: Problem with Multi- threaded Server <tzz@lifelogs.com>
Re: Problem with Multi- threaded Server xhoster@gmail.com
processing large numbers/values/figures <ruf@rawip.org>
Re: processing large numbers/values/figures <sherm@Sherm-Pendleys-Computer.local>
Re: processing large numbers/values/figures <1usa@llenroc.ude.invalid>
Re: processing large numbers/values/figures <ruf@rawip.org>
Re: processing large numbers/values/figures <ruf@rawip.org>
Re: processing large numbers/values/figures xhoster@gmail.com
Re: Spreadsheet::[Parse|Write]Excel - accessing the con <jgibson@mail.arc.nasa.gov>
Re: What is a type error? <jo@durchholz.org>
Re: What is a type error? <dnew@san.rr.com>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <dnew@san.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 11 Jul 2006 00:13:26 +0900
From: "Ben Bullock" <benkasminbullock@gmail.com>
Subject: =?ISO-8859-1?Q?Re:_Re:_Encoding_of_the_perl_output_=28=E1_=E9_=ED_=F3=29?=
Message-Id: <e8tqqi$jko$1@ml.accsnet.ne.jp>
"Alan J. Flavell" <flavell@physics.gla.ac.uk> wrote in message
news:Pine.LNX.4.64.0607100921480.31746@ppepc87.ph.gla.ac.uk...
> On Mon, 10 Jul 2006, Ben Bullock wrote:
>> and the problem is not Perl but that the
>> browser encoding is not set properly.
>
> Well, the proper place to set the character encoding for a browser is
> from the document source - rather than being set in the browser by the
> recipient, which is at best a workaround or repair technique.
Some other people (I see the names Sherm Pendley and Reto) already made
extensive posts about how to fix the encoding, but no-one seemed to have
mentioned that the supposedly incorrect output from Perl was actually
correct utf8.
------------------------------
Date: Mon, 10 Jul 2006 14:40:39 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: ANN: CamelBones 1.0.0
Message-Id: <m2ejwtjobc.fsf@Sherm-Pendleys-Computer.local>
CamelBones is a bridge framework for integrating Cocoa and Perl. It
allows Cocoa applications can be written entirely in Perl, or in a
combination of Objective-C and Perl.
The 1.0 release is the result of over three years of development, and
is now considered stable enough for production use. Future "point"
releases will leave the framework essentially unchanged, focusing
instead on adding additional utility applications and developer tools
to the overall package.
More information can be found at http://camelbones.sourceforge.net
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Mon, 10 Jul 2006 18:39:53 GMT
From: Sherm Pendley <sherm@dot-app.org>
Subject: ANN: CamelBones 1.0.0
Message-Id: <J27BMu.LI0@zorch.sf-bay.org>
CamelBones is a bridge framework for integrating Cocoa and Perl. It
allows Cocoa applications can be written entirely in Perl, or in a
combination of Objective-C and Perl.
The 1.0 release is the result of over three years of development, and
is now considered stable enough for production use. Future "point"
releases will leave the framework essentially unchanged, focusing
instead on adding additional utility applications and developer tools
to the overall package.
More information can be found at http://camelbones.sourceforge.net
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Mon, 10 Jul 2006 11:00:50 -0500
From: "M" <no@spam.co.name>
Subject: Get
Message-Id: <12b4uhgqacjihcf@corp.supernews.com>
I have this:
@content = split(/\n/, get "http://my.domain.com/acc/ip.cgi");
Which pulls data from cgi script once every few minutes. Is there an easy
way to convert to pulling data from a local file in the same directory?
M
------------------------------
Date: 10 Jul 2006 09:07:48 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Get
Message-Id: <1152547668.031689.34650@m73g2000cwd.googlegroups.com>
M wrote:
> I have this:
>
> @content = split(/\n/, get "http://my.domain.com/acc/ip.cgi");
>
> Which pulls data from cgi script once every few minutes. Is there an easy
> way to convert to pulling data from a local file in the same directory?
Just open the file for reading, and read it in. See:
perldoc -f open
perldoc -f readline
perldoc perlop (and search for the <> operator).
open my $fh, '<', 'localfile.txt' or die "Cannot open file: $!";
my @content = <$fh>;
close $fh;
Paul Lalli
------------------------------
Date: Mon, 10 Jul 2006 12:47:09 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: Get
Message-Id: <m2y7v1jtki.fsf@Sherm-Pendleys-Computer.local>
"M" <no@spam.co.name> writes:
> I have this:
>
> @content = split(/\n/, get "http://my.domain.com/acc/ip.cgi");
>
> Which pulls data from cgi script once every few minutes. Is there an easy
> way to convert to pulling data from a local file in the same directory?
By "easy", do you mean that you want to continue using LWP, while giving
users the option to work with both remote and local files?
If so, you could supply a file:// URI, like this:
@content = split(/\n/, get "file:///path/to/the/file.txt");
Note that this isn't as efficient as open()ing the file and reading it dir-
ectly. You'd only want to do it this way if you want to allow the user to
supply any one of a variety of URI schemes supported by LWP.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Mon, 10 Jul 2006 16:08:57 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: Hangman
Message-Id: <e8tqia$akl$1@gemini.csx.cam.ac.uk>
weberw@adelphia.net wrote:
> Thanks for answering my quesiton. The correct syntax to populate
> %guesses would be what?
Time to RTM. Try "perldoc perldata", or you can see it online at
http://search.cpan.org/dist/perl/pod/perldata.pod
DS
------------------------------
Date: Mon, 10 Jul 2006 11:35:35 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Hangman
Message-Id: <slrneb50en.42p.tadmc@magna.augustmail.com>
weberw@adelphia.net <weberw@adelphia.net> wrote:
> The correct syntax to populate
> %guesses would be what?
$guesses{somekey} = $somevalue;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 10 Jul 2006 16:46:55 +0200
From: Stephan Titard <sgt19@tid.es>
Subject: Re: How to make env-vars effective on return from perl module subrtn ?
Message-Id: <e8tp8m$i7e11@news.hi.inet>
Owen_Townsend escribió:
> Thanks to all above (Sinan Unar, kenslate,& anno4) for good advice.
> I should have explained what I amn trying to do here.
> I am converting mainframe JCL to perl scripts to run on unix/linux.
> My objective was to define files for COBOL using just 1 line per file,
> since there could be many files prior to each COBOL program execution.
> I think now I need 2 lines per file as follows:
>
> 1. exportfile("SORTIN","ar/sales.items"); # subrtn adds SORTIN to env
> #===================================== # via: $ENV{$_[0]} =
> "$_[1]";
> 2a. use Env ("SORTIN"); # suggested by kenslate & anno4 <-- IT
> WORKS
> #==================
> 2b. $SORTIN = $ENV{SORTIN}; # OR I could use this (less overhead ?)
> #======================
>
> I think I should probably use '2b.' above as the 2nd line,
> since I assume there would be less overhead.
> I am fairly new to perl & I got something useful from all who replied.
> I was converting JCL to Korn shell scripts & am now changing over to
> perl.
> If interested please see www.uvsoftware.ca/mvsjcl.htm
> and I will soon have a new doc called mvsjclperl.htm.
> Thanks again to all the respondents above.
>
> Owen
>
hi, maybe a better approach which is not confined to perl, is to dump
all the env-vars to a file, and use that file as a config file for the
*other* tool (perl in this case...)
env-vars are often over-used, and kind of dangerous if you do not use a
startup script which takes care of initializing your program whith the
only required env-vars: don't rely on profiles and such
hth
--stephan
------------------------------
Date: 10 Jul 2006 08:14:57 -0700
From: "Robert Hicks" <sigzero@gmail.com>
Subject: Re: Inline missing with ActiveState?
Message-Id: <1152544497.114193.191490@m79g2000cwm.googlegroups.com>
Ferry Bolhar wrote:
> Hi,
>
> while playing with ActiveState Perl 5.8.8, I couldn't found the Inline
> Module and
> its childs (Inline::C, Inline::Foo).
>
Add the repository for Randy Kobes:
http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?url:/PPMServer58
HTH
:Robert
------------------------------
Date: Mon, 10 Jul 2006 15:20:31 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Problem with Multi- threaded Server
Message-Id: <g6964i51d34.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 30 Jun 2006, xhoster@gmail.com wrote:
> Or just fork instead of threads. Ask your boss "How much are you willing
> to spend to accomplish your stupid and arbitrary requirements?"
I don't think that's a good question.
Here's a list of places where threads are usually better than fork():
- limited memory
- threads need to collaborate, especially with semaphores and timing
- programmers are familiar with threads
- performance
- lots of separate threads are expected
...plus many others I can't think of immediately. The requirement is
difficult for Perl, but may be very sensible for the particular situation.
Ted
------------------------------
Date: 10 Jul 2006 19:56:03 GMT
From: xhoster@gmail.com
Subject: Re: Problem with Multi- threaded Server
Message-Id: <20060710155936.099$1s@newsreader.com>
Ted Zlatanov <tzz@lifelogs.com> wrote:
> On 30 Jun 2006, xhoster@gmail.com wrote:
>
> > Or just fork instead of threads. Ask your boss "How much are you
> > willing to spend to accomplish your stupid and arbitrary requirements?"
>
> I don't think that's a good question.
I don't think it is universally, but in this case it seems like it.
> Here's a list of places where threads are usually better than fork():
>
> - limited memory
How does that work out in threads favor over fork? Perl's threads suck at
memory, and on most systems forks use COW, which makes static structures
quite compact.
> - threads need to collaborate, especially with semaphores and timing
Sure, but I don't see any indication that that is the case here.
> - programmers are familiar with threads
Then probably they are familiar with a language in which threads are
a strength rather than a weakness. Mabye they should use that language :)
> - performance
I'm unconvinced that Perl's threads have anything special to offer in that
regard. Sure, if you have well-implemented code using threads vs. poorly
implemented code using forks you might see a big difference. But that can
go the other way around, too.
> - lots of separate threads are expected
I don't see a benefit of Perl's threads over forks in this respect, either.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 10 Jul 2006 20:02:19 +0100
From: Lukas Ruf <ruf@rawip.org>
Subject: processing large numbers/values/figures
Message-Id: <slrneb55hc.kbb.ruf@pc-4082.ethz.ch>
Dear all,
for a large number of files, I must accumulate numbers found
therein. For this accumulation, I have been running into
number-overruns.
As a beginner with Perl, I have been able to 'split()' lines
into arrays of numeric-strings. However, when adding fields
together, number-overruns do happen.
After searching the web for a while (maybe with the wrong
keywords) without success, I kindly ask this mailing list
for help:
How can I deal with large numbers in Perl?
- adding
- subtracting
- multiplying
- dividing
- printing
+ large in the range up to 10*2^^40 (10 Tera).
+ most important: adding and printing to ASCII
Thanks in advance for any help!
wbr,
Lukas
--
Lukas Ruf <http://www.lpr.ch> | Ad Personam
rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
Raw IP <http://www.rawip.org> | Low Level Network Programming
<http://lists.lpr.ch/muttprint> | muttprint mailing list
------------------------------
Date: Mon, 10 Jul 2006 14:09:10 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: processing large numbers/values/figures
Message-Id: <m2mzbhjprt.fsf@Sherm-Pendleys-Computer.local>
Lukas Ruf <ruf@rawip.org> writes:
> How can I deal with large numbers in Perl?
Have a look at the Math::BigInt, Math::BigFloat, and Math::BigRat modules,
depending on the kind of numbers you're working with. All three are core.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Mon, 10 Jul 2006 18:30:19 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: processing large numbers/values/figures
Message-Id: <Xns97FC93A71FD70asu1cornelledu@127.0.0.1>
Lukas Ruf <ruf@rawip.org> wrote in news:slrneb55hc.kbb.ruf@pc-
4082.ethz.ch:
> How can I deal with large numbers in Perl?
>
> - adding
> - subtracting
> - multiplying
> - dividing
> - printing
>
> + large in the range up to 10*2^^40 (10 Tera).
> + most important: adding and printing to ASCII
#!/usr/bin/perl
use strict;
use warnings;
use bignum;
my $x = 10*(2**40);
print 123.55 * $x, "\n";
D:\UseNet\clpmisc> bignum.pl
1358446616117248
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: 10 Jul 2006 21:34:01 +0100
From: Lukas Ruf <ruf@rawip.org>
Subject: Re: processing large numbers/values/figures
Message-Id: <slrneb5at9.n05.ruf@pc-4082.ethz.ch>
> A. Sinan Unur [Mon, 10 Jul 2006 18:30:19 GMT]:
>
> Lukas Ruf <ruf@rawip.org> wrote in news:slrneb55hc.kbb.ruf@pc-
> 4082.ethz.ch:
>
> > How can I deal with large numbers in Perl?
> >
> > - adding
> > - subtracting
> > - multiplying
> > - dividing
> > - printing
> >
> > + large in the range up to 10*2^^40 (10 Tera).
> > + most important: adding and printing to ASCII
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use bignum;
>
> my $x = 10*(2**40);
> print 123.55 * $x, "\n";
>
thanks very much!
wbr,
Lukas
--
Lukas Ruf <http://www.lpr.ch> | Ad Personam
rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
Raw IP <http://www.rawip.org> | Low Level Network Programming
<http://lists.lpr.ch/muttprint> | muttprint mailing list
------------------------------
Date: 10 Jul 2006 21:37:27 +0100
From: Lukas Ruf <ruf@rawip.org>
Subject: Re: processing large numbers/values/figures
Message-Id: <slrneb5b3n.n05.ruf@pc-4082.ethz.ch>
> Sherm Pendley [Mon, 10 Jul 2006 14:09:10 -0400]:
>
> Lukas Ruf <ruf@rawip.org> writes:
>
> > How can I deal with large numbers in Perl?
>
> Have a look at the Math::BigInt, Math::BigFloat, and Math::BigRat
> modules, depending on the kind of numbers you're working with. All
> three are core.
>
thank you very much!
wbr,
Lukas
--
Lukas Ruf <http://www.lpr.ch> | Ad Personam
rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
Raw IP <http://www.rawip.org> | Low Level Network Programming
<http://lists.lpr.ch/muttprint> | muttprint mailing list
------------------------------
Date: 10 Jul 2006 20:21:24 GMT
From: xhoster@gmail.com
Subject: Re: processing large numbers/values/figures
Message-Id: <20060710162457.909$eo@newsreader.com>
Lukas Ruf <ruf@rawip.org> wrote:
> Dear all,
>
> for a large number of files, I must accumulate numbers found
> therein. For this accumulation, I have been running into
> number-overruns.
I don't get overruns until 10**307. Are you sure it is an overrun
rather than just a loss of precision?
>
> As a beginner with Perl, I have been able to 'split()' lines
> into arrays of numeric-strings. However, when adding fields
> together, number-overruns do happen.
>
> After searching the web for a while (maybe with the wrong
> keywords) without success, I kindly ask this mailing list
> for help:
>
> How can I deal with large numbers in Perl?
>
> - adding
> - subtracting
> - multiplying
> - dividing
> - printing
>
> + large in the range up to 10*2^^40 (10 Tera).
On my 32 bit machine, I get unit-level precision up to over 1000*2**40.
> + most important: adding and printing to ASCII
Aside from the bignum and other modules previously mentioned, have you
looked at using printf with a higher precision format? Maybe you are
losing precision at the print stage rather than the internal
representation.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 10 Jul 2006 09:46:58 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Spreadsheet::[Parse|Write]Excel - accessing the contents of a cell
Message-Id: <100720060946585726%jgibson@mail.arc.nasa.gov>
In article <slrneb30i9.814.justin.0607@moonlight.purestblue.com>,
Justin C <justin.0607@purestblue.com> wrote:
> On 2006-07-07, Jim Gibson <jgibson@mail.arc.nasa.gov> wrote:
> > In article <slrneaqtt1.3cm.justin.0607@moonlight.purestblue.com>,
> > Justin C <justin.0607@purestblue.com> wrote:
> >
> > [start of program snipped]
> >
> >> while ( $r <= $lastrow ) {
> >> my $c = 0 ;
> >> while ( $c < 10 ) {
> >
> > Perl has 'for' loops, you know.
>
> Yes, should I have used a for loop instead? Why is it better?
Fewer lines and therefore fewer chances for error and more readable
code. Also a smaller scope for loop variables resulting in a more
robust program.
>
>
> >> my $nsr = $r - $srow ; # new sheet row number
> >> my $cell = $oldsheet->{Cells}[$r][$c] ;
> >> $newsheet->write($nsr , $c , $cell->Value) if ( $cell->Value ) ;
> >
> > I would delete the if part of this statement. You don't know if
(Sorry, forgot to finish my sentence here.)
>
> My concern was, if the cell contained nothing then, $cell->Value would be
> undef and I'd either get something unwanted in the new worksheet or the
> program wouldn't run.
You are right. My test spreadsheet conveniently contained no empty
cells. You should test the return value return of the
$oldsheet->Cell($row,$column) method to see if the cell has contents.
However, don't test the return value of $cell->Value(), because the
cell might contain a 0 that you want to copy. At least test (defined
$cell->Value()).
>
> OK, let me try it and see what happens.
>
> Parse: 0.2603
> Write: 2.17
> Can't call method "Value" on an undefined value at bin/web_new/a2z2.pl line
> 22.
Testing the return value of $oldsheet->Cell($row,$column) fixes this.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Mon, 10 Jul 2006 17:17:05 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is a type error?
Message-Id: <e8traj$p57$1@online.de>
Marshall schrieb:
> Joachim Durchholz wrote:
>> Chris Smith schrieb:
>>> For example, I wrote that example using variables of type int. If we
>>> were to suppose that we were actually working with variables of type
>>> Person, then things get a little more complicated. We would need a few
>>> (infinite classes of) derived subtypes of Person that further constrain
>>> the possible values for state. For example, we'd need types like:
>>>
>>> Person{age:{18..29}}
>>>
>>> But this starts to look bad, because we used to have this nice
>>> property called encapsulation. To work around that, we'd need to
>>> make one of a few choices: [...] (c) invent some kind of generic
>>> constraint language so that constraints like this could be expressed
>>> without exposing field names. [...] Choice (c), though, looks a
>>> little daunting.
>> That's not too difficult.
>> Start with boolean expressions.
>> If you need to check everything statically, add enough constraints that
>> they become decidable.
>
> I'm not sure I understand. Could you elaborate?
Preconditions/postconditions can express anything you want, and they are
an absolutely natural extensions of what's commonly called a type
(actually the more powerful type systems have quite a broad overlap with
assertions).
I'd essentially want to have an assertion language, with primitives for
type expressions.
>> For the type language, you also need to add primitives for type
>> checking, and if the language is stateful, you'll also want primitives
>> for accessing earlier states (most notably at function entry).
>
> Again I'm not entirely clear what this means. Are you talking
> about pre/post conditions,
Yes.
Regards,
Jo
------------------------------
Date: Mon, 10 Jul 2006 16:28:31 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is a type error?
Message-Id: <Pevsg.26648$uy3.13388@tornado.socal.rr.com>
Chris Smith wrote:
> // Inside this block, a has type int{17..21} and b has type
> // int{18..22}
No what happens if right here you code
b := 16;
Does that again change the type of "b"? Or is that an illegal
instruction, because "b" has the "local type" of (18..22)?
> signContract(a); // error, because a might be 17
> signContract(b); // no error, because even though the declared
> // type of b is int{14..22}, it has a local
> // type of int{18..22}.
If the former (i.e., if reassigning to "b" changes the "static type" of
b, then the term you're looking for is not type, but "typestate".
In other words, this is the same sort of test that disallows using an
unassigned variable in a value-returning expression. When
{ int a; int b; b := a; }
returns a compile-time error because "a" is uninitialized at the
assignment, that's not the "type" of a, but the typestate. Just FYI.
> Incidentally, I'm not saying that such a feature would be a good idea.
It actually works quite well if the language takes advantage of it
consistantly and allows you to designate your expected typestates and such.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
------------------------------
Date: Mon, 10 Jul 2006 10:35:38 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f1c2fbdc841bd58989774@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> It's never been a strong point. Made worse now that my daughter
> is one of those up-at-the-crack-of-dawn types, and not old enough
> to understand why it's not nice to jump on mommy and daddy's
> bed while they're still asleep. But aren't you actually a time zone
> or two east of me?
Yes, I confess I'm one time zone to your east, and I was posting later
than you. So perhaps it wasn't really past your bedtime.
> The fields of an object/struct/what have you are often hidden behind
> a method-based interface (sometimes callled "encapsulated") only
> because we can't control their values otherwise.
I believe there are actually two kinds of encapsulation. The kind of
encapsulation that best fits your statement there is the getter/setter
sort, which says: "logically, I want an object with some set of fields,
but I can't make them fields because I lose control over their values".
That part can definitely be replaced, in a suitably powerful language,
with static constraints.
The other half of encapsulation, though, is of the sort that I mentioned
in my post. I am intentionally choosing to encapsulate something
because I don't actually know how it should end up being implemented
yet, or because it changes often, or something like that. I may
encapsulate the implementation of current tax code specifically because
I know that tax code changes on a year-to-year basis, and I want to
ensure that the rest of my program works no matter how the tax code is
modified. There may be huge structural changes in the tax code, and I
only want to commit to leaving a minimal interface.
In practice, the two purposes are not cleanly separated from each other.
Most people, if asked why they write getters and setters, would respond
not only that they want to validate against assignments to the field,
but also that it helps isolate changes should they change the internal
representation of the class. A publicly visible static constraint
language that allows the programmer to change the internal
representation of a class obviously can't make reference to any field,
since it may cease to exist with a change in representation.
> However for a function, the "fields" are the in and out parameters.
> The specific values in the relation that the function is aren't known
> until runtime either, (and then only the subset for which we actually
> perform computation.)
>
> Did that make sense?
I didn't understand that last bit.
> There are certainly syntactic issues, but I believe these are amenable
> to the usual approaches. The runtime/compile time question, and
> decidability seem bigger issues to me.
Well, the point of static typing is to do what's possible without
reaching the point of undecidability. Runtime support for checking the
correctness of type ascriptions certainly comes in handy when you run
into those limits.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Mon, 10 Jul 2006 10:50:29 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f1c334429ce4ae989775@news.altopia.net>
Darren New <dnew@san.rr.com> wrote:
> Chris Smith wrote:
> > // Inside this block, a has type int{17..21} and b has type
> > // int{18..22}
>
> No what happens if right here you code
> b := 16;
>
> Does that again change the type of "b"? Or is that an illegal
> instruction, because "b" has the "local type" of (18..22)?
It arranges that the expression "b" after that line (barring further
changes) has type int{16..16}, which would make the later call to
signContract illegal.
> If the former (i.e., if reassigning to "b" changes the "static type" of
> b, then the term you're looking for is not type, but "typestate".
We're back into discussion terminology, then. How fun. Yes, the word
"typestate" is used to describe this in a good bit of literature.
Nevertheless, a good number of authors -- including all of them that I'm
aware of in programming language type theory -- would agree that "type"
is a perfectly fine word.
When I said b has a type of int{18..22}, I meant that the type that will
be inferred for the expression "b" when it occurs inside this block as
an rvalue will be int{18..22}. The type of the variable didn't change,
because variables don't *have* types. Expressions (or, depending on
your terminology preference, terms) have types. An expression "b" that
occurs after your assignment is a different expression from the one that
occurs before your assignment, so it's entirely expected that in the
general case, it may have a different type.
It's also the case (and I didn't really acknowledge this before) that
the expression "b" when used as an lvalue has a different type, which is
determined according to different rules. As such, the assignment to b
was not at all influenced by the new type that was arranged for the
expression "b" as an rvalue.
(I'm using lvalue and rvalue intuitively; in practice, these would be
assigned on a case-by-case basis along the lines of actual operators or
language syntax.)
> In other words, this is the same sort of test that disallows using an
> unassigned variable in a value-returning expression.
Yes, it is.
> When
> { int a; int b; b := a; }
> returns a compile-time error because "a" is uninitialized at the
> assignment, that's not the "type" of a, but the typestate. Just FYI.
If you wish to say "typestate" to mean this, be my guest. It is also
correct to say "type".
> It actually works quite well if the language takes advantage of it
> consistantly and allows you to designate your expected typestates and such.
I'm not aware of a widely used language that implements stuff like this.
Are you?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Mon, 10 Jul 2006 17:01:07 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is a type error?
Message-Id: <nJvsg.22632$Z67.16855@tornado.socal.rr.com>
Chris Smith wrote:
> If you wish to say "typestate" to mean this, be my guest. It is also
> correct to say "type".
Sure. I just wasn't sure everyone here was aware of the term, is all. It
makes it easier to google if you have a more specific term.
> I'm not aware of a widely used language that implements stuff like this.
I've only used Hermes with extensive support for this sort of thing.
Hermes is process-oriented, rather than object-oriented, so it's a
little easier to deal with the "encapsulation" part of the equation
there. Sadly, Hermes went the way of the dodo.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
------------------------------
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 9445
***************************************
