Re: Google Tech Talk: lisp at JPL
In article <6a4a234d-db48-4659-8714-098d79fb9...@l30g2000yqb.googlegroups.com>, ccc31807 wrote: > On Apr 3, 1:53ﾊam, Xah Lee wrote: > > 〈The Remote Agent Experiment: Debugging Code from 60 Million Miles > > Away〉 > > Google Tech Talk, (2012-02-14) Presented by Ron Garret. > > @http://www.youtube.com/watch?v=_gZK0tW8EhQ > > RG mentions giving a more technical version to a Lisp User Group. Any > chance that this talk is publicly available? Nope. It wasn't recorded. Sorry. > Thanks for the talk, Ron, I really enjoyed it, and wish you (and NASA) > all the best. I haven't worked at NASA for nearly ten years now, but thanks for the kinds words nonetheless. rg -- http://mail.python.org/mailman/listinfo/python-list
Line-by-line processing when stdin is not a tty
When stdin is not a tty, Python seems to buffer all the input through EOF before processing any of it: [...@mickey:~]$ cat | python print 123 print 456 123 456 Is there a way to get Python to process input line-by-line the way it does when stdin is a TTY even when stdin is not a TTY? Thanks, rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Line-by-line processing when stdin is not a tty
In article , Cameron Simpson wrote: > On 11Aug2010 00:11, RG wrote: > | When stdin is not a tty, Python seems to buffer all the input through > | EOF before processing any of it: > | > | [...@mickey:~]$ cat | python > | print 123 > | print 456 > | 123 > | 456 > | > | Is there a way to get Python to process input line-by-line the way it > | does when stdin is a TTY even when stdin is not a TTY? > > What you're seeing here is not python's behaviour but cat's behaviour. > > Almost all programs do line buffering (flush buffer at newline) when the > file is a terminal (character device) and block buffering (flush when a > fixed size buffer, typically 8192 bytes or some larger power of 2) when > the file is not a terminal. This is default behaviour for the stdio > package. > > So "cat" is simply not feeding any data to python until it has a lot of > it; I don't think that's right: [...@mickey:~]$ cat | cat 123 123 321 321 Cat seems to flush its buffer after every newline. Also: [...@mickey:~]$ cat -u | python print 123 print 456 123 456 > We would need to know > more about your specific task to suggest workarounds. I'm writing a system in a different language but want to use a Python library. I know of lots of ways to do this (embed a Python interpreter, fire up a python server) but by far the easiest to implement is to have the main program spawn a Python interpreter and interact with it through its stdin/stdout. In my code I explicitly force the output stream that is being piped to Python's stdin to be flushed so I know it's not a buffering problem on the input side. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Line-by-line processing when stdin is not a tty
In article , Peter Otten <__pete...@web.de> wrote: > Grant Edwards wrote: > > > On 2010-08-11, Tim Harig wrote: > >> On 2010-08-11, RG wrote: > >>> When stdin is not a tty, Python seems to buffer all the input through > >>> EOF before processing any of it: > >>> > >>> [...@mickey:~]$ cat | python > >>> print 123 > >>> print 456 > >>> 123 > >>> 456 > >>> > >>> Is there a way to get Python to process input line-by-line the way it > >>> does when stdin is a TTY even when stdin is not a TTY? > >> > >> It would be much better to know the overall purpose of what you are > >> trying > >> to achieve. There are may be better ways (ie, sockets) depending what > >> you > >> are trying to do. Knowing your target platform would also be helpful. > >> > >> For the python interpeter itself, you can can get interactive behavior by > >> invoking it with the -i option. > > > > If you're talking about unbuffered stdin/stdout, the option is -u. > > > > I don't really see how the -i option is relevent -- it causes the > > interpreter to go into interactive mode after running the script. > > I'd say the following looks like what the OP was asking for: > > $ cat | python -i -c'import sys; sys.ps1=""' > print sys.stdin.isatty() > False > print 1 > 1 > print 2 > 2 That is indeed the behavior I'm looking for. > (Whether it's useful is yet another question) It's useful to me :-) I'm trying to access a python library from a program written in another language for which an equivalent library is not available. The easiest way to do that is to spawn a Python interpreter and interact with it through stdin/stdout. Thanks! rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Line-by-line processing when stdin is not a tty
In article , Tim Harig wrote: > On 2010-08-11, RG wrote: > > I'm writing a system in a different language but want to use a Python > > library. I know of lots of ways to do this (embed a Python interpreter, > > fire up a python server) but by far the easiest to implement is to have > > the main program spawn a Python interpreter and interact with it through > > its stdin/stdout. > > Or, open python using a socket. You mean a TCP/IP socket? Or a unix domain socket? The former has security issues, and the latter seems like a lot of work. Or is there an easy way to do it that I don't know about? rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Line-by-line processing when stdin is not a tty
In article , Tim Harig wrote: > On 2010-08-11, RG wrote: > > In article , > > Tim Harig wrote: > > > >> On 2010-08-11, RG wrote: > >> > I'm writing a system in a different language but want to use a Python > >> > library. I know of lots of ways to do this (embed a Python interpreter, > >> > fire up a python server) but by far the easiest to implement is to have > >> > the main program spawn a Python interpreter and interact with it through > >> > its stdin/stdout. > >> > >> Or, open python using a socket. > > > > You mean a TCP/IP socket? Or a unix domain socket? The former has > > security issues, and the latter seems like a lot of work. Or is there > > an easy way to do it that I don't know about? > > I was referring to unix domain sockets or more specifically stream > pipes. I guess it depends what language you are using and what libraries > you have access to. Under C, working with stream pipes is no more trivial > then using pipe(). You can simply create the socket descriptors using > socketpair(). Keep one of the descriptors for your process and pass the > other to the python child process as both stdin and stdout. Ah. That is in fact exactly what I am doing, and that is how I first encountered this problem. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Line-by-line processing when stdin is not a tty
In article , RG wrote: > In article , > Tim Harig wrote: > > > On 2010-08-11, RG wrote: > > > In article , > > > Tim Harig wrote: > > > > > >> On 2010-08-11, RG wrote: > > >> > I'm writing a system in a different language but want to use a Python > > >> > library. I know of lots of ways to do this (embed a Python > > >> > interpreter, > > >> > fire up a python server) but by far the easiest to implement is to > > >> > have > > >> > the main program spawn a Python interpreter and interact with it > > >> > through > > >> > its stdin/stdout. > > >> > > >> Or, open python using a socket. > > > > > > You mean a TCP/IP socket? Or a unix domain socket? The former has > > > security issues, and the latter seems like a lot of work. Or is there > > > an easy way to do it that I don't know about? > > > > I was referring to unix domain sockets or more specifically stream > > pipes. I guess it depends what language you are using and what libraries > > you have access to. Under C, working with stream pipes is no more trivial > > then using pipe(). You can simply create the socket descriptors using > > socketpair(). Keep one of the descriptors for your process and pass the > > other to the python child process as both stdin and stdout. > > Ah. That is in fact exactly what I am doing, and that is how I first > encountered this problem. > > rg And now I have encountered another problem: -> print sys.stdin.encoding <- None But when I run from a terminal: [...@mickey:~]$ python Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.stdout.encoding 'UTF-8' I thought the value of sys.stdin.encoding was hard-coded into the Python executable at compile time, but that's obviously wrong. So how does Python get the value of sys.stdin.encoding? rg -- http://mail.python.org/mailman/listinfo/python-list
How does Python get the value for sys.stdin.encoding?
I thought it was hard-coded into the Python executable at compile time, but that is apparently not the case: [...@mickey:~]$ python Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys;print sys.stdin.encoding UTF-8 >>> ^D [...@mickey:~]$ echo 'import sys;print sys.stdin.encoding' | python None [...@mickey:~]$ And indeed, trying to pipe unicode into Python doesn't work, even though it works fine when Python runs interactively. So how can I make this work? Thanks, rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Line-by-line processing when stdin is not a tty
In article , Nobody wrote: > On Wed, 11 Aug 2010 10:32:41 +, Tim Harig wrote: > > >>> Usually you either > >>> need an option on the upstream program to tell it to line > >>> buffer explicitly > >> > >> once cat had an option -u doing exactly that but nowadays > >> -u seems to be ignored > >> > >> http://www.opengroup.org/onlinepubs/009695399/utilities/cat.html > > > > I have to wonder why cat knows or cares. > > The issue relates to the standard C library. By convention[1], stdin and > stdout are line-buffered if the descriptor refers to a tty, and are > block-buffered otherwise. stderr is always unbuffered. > > Any program which uses stdin and stdout without explicitly setting the > buffering or using fflush() will exhibit this behaviour. > > [1] ANSI/ISO C is less specific; C99, 7.19.3p7: > > As initially opened, the standard error stream is not fully > buffered; the standard input and standard output streams are > fully buffered if and only if the stream can be determined not > to refer to an interactive device. > > POSIX says essentially the same thing: > > <http://www.opengroup.org/onlinepubs/9699919799/functions/stdin.html> This doesn't explain why "cat | cat" when run interactively outputs line-by-line (which it does). STDIN to the first cat is a TTY, but the second one isn't. For that matter, you can also do this: nc -l 1234 | cat and then telnet localhost 1234 and type at it, and it still works line-by-line. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: How does Python get the value for sys.stdin.encoding?
In article , Benjamin Kaplan wrote: > On Wed, Aug 11, 2010 at 6:21 PM, RG wrote: > > I thought it was hard-coded into the Python executable at compile time, > > but that is apparently not the case: > > > > [...@mickey:~]$ python > > Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) > > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > >>>> import sys;print sys.stdin.encoding > > UTF-8 > >>>> ^D > > [...@mickey:~]$ echo 'import sys;print sys.stdin.encoding' | python > > None > > [...@mickey:~]$ > > > > And indeed, trying to pipe unicode into Python doesn't work, even though > > it works fine when Python runs interactively. So how can I make this > > work? > > > > Sys.stdin and stdout are files, just like any other. There's nothing > special about them at compile time. When the interpreter starts, it > checks to see if they are ttys. If they are, then it tries to figure > out the terminal's encoding based on the environment. The code for > this is in pythonrun.c if you want to see exactly what it's doing. Thanks. Looks like the magic incantation is: export PYTHONIOENCODING='utf-8' > By the way, there is no such thing as piping Unicode into Python. Yeah, I know. I should have said "piping UTF-8 encoded unicode" or something like that. > You really have to watch your encodings > when you pass data around between programs. There's no way to avoid > it. Yeah, I keep re-learning that lesson again and again. rg -- http://mail.python.org/mailman/listinfo/python-list
Why can't I set sys.ps1 to a unicode string?
More precisely, why does sys.ps1 not appear if I set it to a unicode string? This problem is hard for me to describe here because my newsreader is not properly unicode enabled, but here's the gist of it: Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> First, let's make sure our encodings are set properly: >>> import sys >>> sys.stdin.encoding 'utf-8' >>> sys.stdout.encoding 'utf-8' Looks good. Now, let's make two unicode strings, identical except for one character: >>> s1 = u'%%% %%% ' >>> s2 = u'%%% ' + u'\u262f' + '%%% ' >>> print s1 %%% %%% >>> print s2 %%% /&%%% If this were a properly unicode-enabled newsreader you would see a yin-yang symbol in the middle of s2. Now the weird part: >>> sys.ps1 = s1 %%% %%% sys.ps1 = s2 # This is as expected print s1 # But this isn't. There's no prompt! %%% %%%# Everything still works print s2 %%% /&%%% sys.ps1 = s1 # If we reset sys.ps1 we get our prompt back %%% %%% sys.ps1 = '>>> ' >>> sys.ps1 = u'>>> ' >>> So... why does having a non-ascii character in sys.ps1 make the prompt vanish? (If you're wondering why I care, I want to connect to an interactive python interpreter from another program, and I want a non-ascii delimiter to unambiguously mark the end of the interpreter's output on every interaction.) Thanks, rg -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can't I set sys.ps1 to a unicode string?
In article , "Martin v. Loewis" wrote: > > So... why does having a non-ascii character in sys.ps1 make the prompt > > vanish? > > I can't pinpoint it to a specific line of code. Most likely, it tries > to encode the prompt as ASCII before writing it to stdout. That fails, > and it silently ignores the error. > > FWIW, this is fixed in Python 3. Guess it's time to upgrade. :-) Thanks! rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>, Squeamizh wrote: > On Sep 27, 10:46 am, namekuseijin wrote: > > On 27 set, 05:46, TheFlyingDutchman wrote: > > > > > > > > > > > > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon) > > > wrote: > > > > RG writes: > > > > > In article > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com>, > > > > > TheFlyingDutchman wrote: > > > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson" wrote: > > > > >> > This might have been mentioned here before, but I just came across > > > > >> > it: a > > > > >> > 2003 essay by Bruce Eckel on how reliable systems can get built in > > > > >> > dynamically-typed languages. It echoes things we've all said > > > > >> > here, but > > > > >> > I think it's interesting because it describes a conversion > > > > >> > experience: > > > > >> > Eckel started out in the strong-typing camp and was won over. > > > > > > >> > https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk > > > > > > >> > -- Scott > > > > > > >> If you are writing a function to determine the maximum of two > > > > >> numbers > > > > >> passed as arguents in a dynamic typed language, what is the normal > > > > >> procedure used by Eckel and others to handle someone passing in > > > > >> invalid values - such as a file handle for one varible and an array > > > > >> for the other? > > > > > > > The normal procedure is to hit such a person over the head with a > > > > > stick > > > > > and shout "FOO". > > > > > > Moreover, the functions returning the maximum may be able to work on > > > > non-numbers, as long as they're comparable. What's more, there are > > > > numbers that are NOT comparable by the operator you're thinking about!. > > > > > > So to implement your specifications, that function would have to be > > > > implemented for example as: > > > > > > (defmethod lessp ((x real) (y real)) (< x y)) > > > > (defmethod lessp ((x complex) (y complex)) > > > > (or (< (real-part x) (real-part y)) > > > > (and (= (real-part x) (real-part y)) > > > > (< (imag-part x) (imag-part y) > > > > > > (defun maximum (a b) > > > > (if (lessp a b) b a)) > > > > > > And then the client of that function could very well add methods: > > > > > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y)) > > > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y))) > > > > (defmethod lessp ((x string) (y string)) (string< x y)) > > > > > > and call: > > > > > > (maximum 'hello "WORLD") --> "WORLD" > > > > > > and who are you to forbid it!? > > > > > > -- > > > > __Pascal Bourguignon__ > > > > http://www.informatimago.com/-Hidequoted text - > > > > > > - Show quoted text - > > > > > in C I can have a function maximum(int a, int b) that will always > > > work. Never blow up, and never give an invalid answer. If someone > > > tries to call it incorrectly it is a compile error. > > > In a dynamic typed language maximum(a, b) can be called with incorrect > > > datatypes. Even if I make it so it can handle many types as you did > > > above, it could still be inadvertantly called with a file handle for a > > > parameter or some other type not provided for. So does Eckel and > > > others, when they are writing their dynamically typed code advocate > > > just letting the function blow up or give a bogus answer, or do they > > > check for valid types passed? If they are checking for valid types it > > > would seem that any benefits gained by not specifying type are lost by > > > checking for type. And if they don't check for type it would seem that > > > their code's error handling is poor. > > > > that is a lie. > > > > Compilation only makes sure that values provided at compilation-time > > are of the right datatype. > > > > What happens th
Re: "Strong typing vs. strong testing"
In article <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>, Squeamizh wrote: > On Sep 29, 3:02 pm, RG wrote: > > In article > > <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>, > > > > > > > > > > > > Squeamizh wrote: > > > On Sep 27, 10:46 am, namekuseijin wrote: > > > > On 27 set, 05:46, TheFlyingDutchman wrote: > > > > > > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon) > > > > > wrote: > > > > > > RG writes: > > > > > > > In article > > > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com > > > > > > > >, > > > > > > > TheFlyingDutchman wrote: > > > > > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson" wrote: > > > > > > >> > This might have been mentioned here before, but I just came > > > > > > >> > across > > > > > > >> > it: a > > > > > > >> > 2003 essay by Bruce Eckel on how reliable systems can get > > > > > > >> > built in > > > > > > >> > dynamically-typed languages. It echoes things we've all said > > > > > > >> > here, but > > > > > > >> > I think it's interesting because it describes a conversion > > > > > > >> > experience: > > > > > > >> > Eckel started out in the strong-typing camp and was won over. > > > > > > > > >> > https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk > > > > > > > > >> > -- Scott > > > > > > > > >> If you are writing a function to determine the maximum of two > > > > > > >> numbers > > > > > > >> passed as arguents in a dynamic typed language, what is the > > > > > > >> normal > > > > > > >> procedure used by Eckel and others to handle someone passing in > > > > > > >> invalid values - such as a file handle for one varible and an > > > > > > >> array > > > > > > >> for the other? > > > > > > > > > The normal procedure is to hit such a person over the head with a > > > > > > > stick > > > > > > > and shout "FOO". > > > > > > > > Moreover, the functions returning the maximum may be able to work > > > > > > on > > > > > > non-numbers, as long as they're comparable. What's more, there are > > > > > > numbers that are NOT comparable by the operator you're thinking > > > > > > about!. > > > > > > > > So to implement your specifications, that function would have to be > > > > > > implemented for example as: > > > > > > > > (defmethod lessp ((x real) (y real)) (< x y)) > > > > > > (defmethod lessp ((x complex) (y complex)) > > > > > > (or (< (real-part x) (real-part y)) > > > > > > (and (= (real-part x) (real-part y)) > > > > > > (< (imag-part x) (imag-part y) > > > > > > > > (defun maximum (a b) > > > > > > (if (lessp a b) b a)) > > > > > > > > And then the client of that function could very well add methods: > > > > > > > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y)) > > > > > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y))) > > > > > > (defmethod lessp ((x string) (y string)) (string< x y)) > > > > > > > > and call: > > > > > > > > (maximum 'hello "WORLD") --> "WORLD" > > > > > > > > and who are you to forbid it!? > > > > > > > > -- > > > > > > __Pascal Bourguignon__ > > > > > > http://www.informatimago.com/-Hidequotedtext - > > > > > > > > - Show quoted text - > > > > > > > in C I can have a function maximum(int a, int b) that will always > > > > > work. Never blow up, and never give an invalid answer. If someone > > > > > tries to call it incorrectly it is a compile error. > > > > > In a dynamic
Re: "Strong typing vs. strong testing"
In article ,
Keith Thompson wrote:
> RG writes:
> > In article
> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> > Squeamizh wrote:
> >> On Sep 29, 3:02 pm, RG wrote:
> [...]
> >> > This is a red herring. You don't have to invoke run-time input to
> >> > demonstrate bugs in a statically typed language that are not caught by
> >> > the compiler. For example:
> >> >
> >> > [...@mighty:~]$ cat foo.c
> >> > #include
> >> >
> >> > int maximum(int a, int b) {
> >> > return (a > b ? a : b);
> >> >
> >> > }
> >> >
> >> > int foo(int x) { return 9223372036854775807+x; }
> >> >
> >> > int main () {
> >> > printf("%d\n", maximum(foo(1), 1));
> >> > return 0;}
> >> >
> >> > [...@mighty:~]$ gcc -Wall foo.c
> >> > [...@mighty:~]$ ./a.out
> >> > 1
> >> >
> >> > Even simple arithmetic is Turing-complete, so catching all type-related
> >> > errors at compile time would entail solving the halting problem.
> >> >
> >> > rg
> >>
> >> In short, static typing doesn't solve all conceivable problems.
> >
> > More specifically, the claim made above:
> >
> >> in C I can have a function maximum(int a, int b) that will always
> >> work. Never blow up, and never give an invalid answer.
> >
> > is false. And it is not necessary to invoke the vagaries of run-time
> > input to demonstrate that it is false.
>
> But the above maximum() function does exactly that. The program's
> behavior happens to be undefined or implementation-defined for reasons
> unrelated to the maximum() function.
>
> Depending on the range of type int on the given system, either the
> behavior of the addition in foo() is undefined (because it overflows),
> or the implicit conversion of the result to int either yields an
> implementation-defined result or (in C99) raises an
> implementation-defined signal; the latter can lead to undefined
> behavior.
>
> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> the addition yields the value 0, but the C language doesn't require that
> particular result. You then call maximum with arguments 0 and 1, and
> it quite correctly returns 1.
This all hinges on what you consider to be "a function maximum(int a,
int b) that ... always work[s] ... [and] never give[s] an invalid
answer." But if you don't consider an incorrect answer (according to
the rules of arithmetic) to be an invalid answer then the claim becomes
vacuous. You could simply ignore the arguments and return 0, and that
would meet the criteria.
If you try to refine this claim so that it is both correct and
non-vacuous you will find that static typing does not do nearly as much
for you as most of its adherents think it does.
> >> We are all aware that there is no perfect software development process
> >> or tool set. I'm interested in minimizing the number of problems I
> >> run into during development, and the number of bugs that are in the
> >> finished product. My opinion is that static typed languages are
> >> better at this for large projects, for the reasons I stated in my
> >> previous post.
> >
> > More power to you. What are you doing here on cll then?
>
> This thread is cross-posted to several newsgroups, including
> comp.lang.c.
Ah, so it is. My bad.
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article ,
Keith Thompson wrote:
> RG writes:
> > In article ,
> > Keith Thompson wrote:
> >
> >> RG writes:
> >> > In article
> >> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> >> > Squeamizh wrote:
> >> >> On Sep 29, 3:02 pm, RG wrote:
> >> [...]
> >> >> > This is a red herring. You don't have to invoke run-time input to
> >> >> > demonstrate bugs in a statically typed language that are not caught
> >> >> > by
> >> >> > the compiler. For example:
> >> >> >
> >> >> > [...@mighty:~]$ cat foo.c
> >> >> > #include
> >> >> >
> >> >> > int maximum(int a, int b) {
> >> >> > return (a > b ? a : b);
> >> >> >
> >> >> > }
> >> >> >
> >> >> > int foo(int x) { return 9223372036854775807+x; }
> >> >> >
> >> >> > int main () {
> >> >> > printf("%d\n", maximum(foo(1), 1));
> >> >> > return 0;}
> >> >> >
> >> >> > [...@mighty:~]$ gcc -Wall foo.c
> >> >> > [...@mighty:~]$ ./a.out
> >> >> > 1
> >> >> >
> >> >> > Even simple arithmetic is Turing-complete, so catching all
> >> >> > type-related
> >> >> > errors at compile time would entail solving the halting problem.
> >> >> >
> >> >> > rg
> >> >>
> >> >> In short, static typing doesn't solve all conceivable problems.
> >> >
> >> > More specifically, the claim made above:
> >> >
> >> >> in C I can have a function maximum(int a, int b) that will always
> >> >> work. Never blow up, and never give an invalid answer.
> >> >
> >> > is false. And it is not necessary to invoke the vagaries of run-time
> >> > input to demonstrate that it is false.
> >>
> >> But the above maximum() function does exactly that. The program's
> >> behavior happens to be undefined or implementation-defined for reasons
> >> unrelated to the maximum() function.
> >>
> >> Depending on the range of type int on the given system, either the
> >> behavior of the addition in foo() is undefined (because it overflows),
> >> or the implicit conversion of the result to int either yields an
> >> implementation-defined result or (in C99) raises an
> >> implementation-defined signal; the latter can lead to undefined
> >> behavior.
> >>
> >> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> >> the addition yields the value 0, but the C language doesn't require that
> >> particular result. You then call maximum with arguments 0 and 1, and
> >> it quite correctly returns 1.
> >
> > This all hinges on what you consider to be "a function maximum(int a,
> > int b) that ... always work[s] ... [and] never give[s] an invalid
> > answer."
>
> int maximum(int a, int b) { return a > b ? a : b; }
>
> > But if you don't consider an incorrect answer (according to
> > the rules of arithmetic) to be an invalid answer then the claim becomes
> > vacuous. You could simply ignore the arguments and return 0, and that
> > would meet the criteria.
>
> I don't believe it's possible in any language to write a maximum()
> function that returns a correct result *when given incorrect argument
> values*.
>
> The program (assuming a typical implementation) calls maximum() with
> arguments 0 and 1. maximum() returns 1. It works. The problem
> is elsewhere in the program.
That the problem is "elsewhere in the program" ought to be small
comfort. But very well, try this instead:
[...@mighty:~]$ cat foo.c
#include
int maximum(int a, int b) { return a > b ? a : b; }
int main() {
long x = 8589934592;
printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
return 0;
}
[...@mighty:~]$ gcc -Wall foo.c
[...@mighty:~]$ ./a.out
Max of 8589934592 and 1 is 1
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article ,
Keith Thompson wrote:
> RG writes:
> [...]
> > That the problem is "elsewhere in the program" ought to be small
> > comfort.
>
> I don't claim that it's comforting, merely that it's true.
>
> > But very well, try this instead:
> >
> > [...@mighty:~]$ cat foo.c
> > #include
> >
> > int maximum(int a, int b) { return a > b ? a : b; }
> >
> > int main() {
> > long x = 8589934592;
> > printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> > return 0;
> > }
> > [...@mighty:~]$ gcc -Wall foo.c
> > [...@mighty:~]$ ./a.out
> > Max of 8589934592 and 1 is 1
>
> That exhibits a very similar problem.
>
> 8589934592 is 2**33.
>
> Given the output you got, I presume your system has 32-bit int and
> 64-bit long. The call maximum(x, 1) implicitly converts the long
> value 8589934592 to int. The result is implementation-defined,
> but typically 0. So maximum() is called with arguments of 0 and 1,
> as you could see by adding a printf call to maximum().
>
> Even here, maximum() did exactly what was asked of it.
Of course. Computers always do only exactly what you ask of them. On
this view there is, by definition, no such thing as a bug, only
specifications that don't correspond to one's intentions.
Unfortunately, correspondence to intentions is the thing that actually
matters when writing code.
> I'll grant you that having a conversion from a larger type to a smaller
> type quietly discard high-order bits is unfriendly.
"Unfriendly" is not the adjective that I would choose to describe this
behavior.
There is a whole hierarchy of this sort of "unfriendly" behavior, some
of which can be caught at compile time using a corresponding hierarchy
of ever more sophisticated tools. But sooner or later if you are using
Turing-complete operations you will encounter the halting problem, at
which point your compile-time tools will fail. (c.f. the Collatz
problem)
I'm not saying one should not use compile-time tools, only that one
should not rely on them. "Compiling without errors" is not -- and
cannot ever be -- be a synonym for "bug-free."
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Keith Thompson wrote: > > I'm not saying one should not use compile-time tools, only that one > > should not rely on them. "Compiling without errors" is not -- and > > cannot ever be -- be a synonym for "bug-free." > > Agreed. (Though C does make it notoriously easy to sneak buggy code > past the compiler.) Let's just leave it at that then. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Seebs wrote: > On 2010-09-30, RG wrote: > > Of course. Computers always do only exactly what you ask of them. On > > this view there is, by definition, no such thing as a bug, only > > specifications that don't correspond to one's intentions. > > f00f. > > That said... I think you're missing Keith's point. > > > Unfortunately, correspondence to intentions is the thing that actually > > matters when writing code. > > Yes. Nonetheless, the maximum() function does exactly what it is intended > to do *with the inputs it receives*. The failure is outside the function; > it did the right thing with the data actually passed to it, the problem > was a user misunderstanding as to what data were being passed to it. > > So there's a bug -- there's code which does not do what it was intended > to do. However, that bug is in the caller, not in the maximum() > function. > > This is an important distinction -- it means we can write a function > which performs that function reliably. Now we just need to figure out > how to call it with valid data... :) We lost some important context somewhere along the line: > > > in C I can have a function maximum(int a, int b) that will always > > > work. Never blow up, and never give an invalid answer. If someone > > > tries to call it incorrectly it is a compile error. Please take note of the second sentence. One way or another, this claim is plainly false. The point I was trying to make is not so much that the claim is false (someone else was already doing that), but that it can be demonstrated to be false without having to rely on any run-time input. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <5bf24e59-1be0-4d31-9fa7-c03a8bf9b...@y12g2000prb.googlegroups.com>, TheFlyingDutchman wrote: > > > Yes. Nonetheless, the maximum() function does exactly what it is intended > > > to do *with the inputs it receives*. The failure is outside the function; > > > it did the right thing with the data actually passed to it, the problem > > > was a user misunderstanding as to what data were being passed to it. > > > > > So there's a bug -- there's code which does not do what it was intended > > > to do. However, that bug is in the caller, not in the maximum() > > > function. > > > > > This is an important distinction -- it means we can write a function > > > which performs that function reliably. Now we just need to figure out > > > how to call it with valid data... :) > > > > We lost some important context somewhere along the line: > > > > > > > in C I can have a function maximum(int a, int b) that will always > > > > > work. Never blow up, and never give an invalid answer. If someone > > > > > tries to call it incorrectly it is a compile error. > > > > Please take note of the second sentence. > > > > One way or another, this claim is plainly false. The point I was trying > > to make is not so much that the claim is false (someone else was already > > doing that), but that it can be demonstrated to be false without having > > to rely on any run-time input. > > > > The second sentence is not disproved by a cast from one datatype to > another (which changes the value) that happens before maximum() is > called. You can't have it both ways. Either I am calling it incorrectly, in which case I should get a compiler error, or I am calling it correctly, and I should get the right answer. That I got neither does in fact falsify the claim. The only way out of this is to say that maximum(8589934592, 1) returning 1 is in fact "correct", in which case we'll just have to agree to disagree. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article ,
Keith Thompson wrote:
> RG writes:
> [...]
> > You can't have it both ways. Either I am calling it incorrectly, in
> > which case I should get a compiler error, or I am calling it correctly,
> > and I should get the right answer. That I got neither does in fact
> > falsify the claim. The only way out of this is to say that
> > maximum(8589934592, 1) returning 1 is in fact "correct", in which case
> > we'll just have to agree to disagree.
>
> You are calling maximum() incorrectly, but you are doing so in a way
> that the compiler is not required to diagnose.
Yes. I know. That was my whole point. There are ways to call a
function incorrectly (more broadly, there are errors in code) that a C
compiler is not required to diagnose.
> If you want to say that the fact that the compiler is not required
> to diagnose the error is a flaw in the C language, I won't
> argue with you.
I'm not even saying it's a flaw in the language. All I'm saying is that
the original claim -- that any error in a C program will be caught by
the compiler -- is false, and more specifically, that it can be
demonstrated to be false without appeal to unknown run-time input.
As an aside, this particular error *could* be caught (and in fact would
be caught by other tools like lint), but there are errors that can not
be caught by any static analysis, and that therefore one should not be
lulled into a false sense of security by the fact that your code is
written in a statically typed language and compiled without errors or
warnings. That's all.
> If I write:
>
> const double pi = 22.0/7.0;
> printf("pi = %f\n", pi);
>
> then I suppose I'm calling printf() incorrectly, but I wouldn't
> expect my compiler to warn me about it.
>
> If you're arguing that
>
> int maximum(int a, int b) { return a > b ? a : b; }
>
> is flawed because it's too easy to call it incorrectly, you're
> effectively arguing that it's not possible to write correct
> code in C at all.
I would say that it is very, very hard to write correct code in C for
any non-vacuous definition of "correct". That is the reason that core
dumps and buffer overflows are so ubiquitous. I prefer Lisp or Python,
where core dumps and buffer overflows are virtually nonexistent. One
does get the occasional run-time error that might have been caught at
compile time, but I much prefer that to a core dump or a security hole.
One might hypothesize that the best of both worlds would be a dynamic
language with a static analyzer layered on top. Such a thing does not
exist. It makes an instructive exercise to try to figure out why. (For
the record, I don't know the answer, but I've learned a lot through the
process of pondering this conundrum.)
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Seebs wrote: > On 2010-09-30, RG wrote: > > You can't have it both ways. Either I am calling it incorrectly, in > > which case I should get a compiler error, > > You get a warning if you ask for it. If you choose to run without all > the type checking on, that's your problem. My example compiles with no warnings under gcc -Wall. Yes, I know I could have used lint. But that misses the point. For any static analyzer, because of the halting problem, I can construct a program that either contains an error that the analyzer will not catch, or for which the analyzer will produce a false positive. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Seebs wrote: > On 2010-09-30, Lie Ryan wrote: > > On 09/30/10 16:09, TheFlyingDutchman wrote: > >> Dynamic typed languages like Python fail in this case on "Never blows > >> up". > > > How do you define "Never blows up"? > > I would say "blow up" would be "raise an exception". > > > Personally, I'd consider maximum(8589934592, 1) returning 1 as a blow > > up, and of the worst kind since it passes silently. > > So run your compiler with a decent set of warning levels, and watch as > you are magically warned that you're passing an object of the wrong type. My code compiles with no warnings under gcc -Wall. > On any given system, one or the other is true: > > 1. The constant 8589934592 is of type int, and the function will > "work" -- will give that result. > 2. The constant is not of type int, and the compiler will warn you about > this if you ask. It would be nice if this were true, but my example clearly demonstrates that it is not. And if your response is to say that I should have used lint, then my response to that will be that because of the halting problem, for any static analyzer that you present, I can construct a program that either contains an error that either your analyzer will not catch, or for which it will generate a false positive. It just so happens that constructing such examples for standard C is very easy. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Seebs wrote: > And that's the magic of static typing: It is not a false positive to > warn you that "2L" is not of type int. We'll have to agree to disagree about that. The numerical value 2 can safely be represented as an int, so I would consider this a false positive. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <7xr5gbxfry@ruckus.brouhaha.com>, Paul Rubin wrote: > RG writes: > > Yes, I know I could have used lint. But that misses the point. For any > > static analyzer, because of the halting problem, I can construct a > > program that either contains an error that the analyzer will not catch, > > or for which the analyzer will produce a false positive. > > Can you describe any plausible real-world programs where the effort of > complicated static is justified, and for which the halting problem gets > in the way of analysis? By "real world", I meanI wouldn't consider > searching for counterexamples to the Collatz conjecture to qualify as > sufficiently real-world and sufficiently complex for fancy static > analysis. And even if it did, the static analyzer could deliver a > partial result, like "this function either returns a counterexample to > the Collatz conjecture or else it doesn't return". > > D. Turner wrote a famous paper arguing something like the above, saying > basically that Turing completeness of programming languages is > overrated: > > http://www.jucs.org/jucs_10_7/total_functional_programming > > The main example of a sensible program that can't be written in a > non-complete language is an interpreter for a Turing-complete language. > But presumably a high-assurance application should never contain such a > thing, since the interpreted programs themselves then wouldn't have > static assurance. There are only two possibilities: either you have a finite-state machine, or you have a Turning machine. (Well, OK, you could have a pushdown automaton, but there are no programming languages that model a PDA. Well, OK, there's Forth, but AFAIK there are no static type checkers for Forth. Besides, who uses Forth? ;-) If you have a finite state machine everything is trivial. If you have a Turing machine everything is generally impossible. This is an oversimplification but not far from the fundamental underlying truth. My favorite practical example is the square root function. The standard C library defines a square root function on floats (actually on doubles), which is to say, over a finite-state model with 2^64 states. The model is not well defined over half of that range (negative numbers), which the static type checker cannot catch because there is no such thing as an unsigned double. But the fun doesn't stop there. Doubles >= 0.0 are not the only thing one might reasonably want to take a square root of, and indeed C++ overloads sqrt to work on complex and valarray types in addition to floats of various lengths (though you still have to manually keep track of whether or not the argument to sqrt might be a negative real). But what if I want an exact integer square root? Or a square root of a data type that represents irrational numbers not as floating point approximations but as exact symbolic representations? I haven't worked out the details, but I'd be surprised if none of these variations turned out to be Turing complete. The Turner paper is right on point: there's a fundamental distinction between the (known) finite and the (potentially) infinite. In my experience most of the cool interesting stuff has been found in the latter domain, and trying to shoehorn the latter into the former is more trouble then it's worth. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article
<0390e2b4-fa28-49b3-a867-39be6d668...@w19g2000yqb.googlegroups.com>,
ImpalerCore wrote:
> On Sep 29, 9:01 pm, RG wrote:
>
>
>
> > [...@mighty:~]$ cat foo.c
> > #include
> >
> > int maximum(int a, int b) { return a > b ? a : b; }
> >
> > int main() {
> > long x = 8589934592;
> > printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> > return 0;}
> >
> > [...@mighty:~]$ gcc -Wall foo.c
> > [...@mighty:~]$ ./a.out
> > Max of 8589934592 and 1 is 1
>
> In the context of procedural programming, there is always an implicit
> contract between the function and its client. If you're going to fool
> around sending cleverly crafted garbage into the input of 'maximum'
> due to C conversion rules, why do you expect the 'maximum' function to
> be responsible for producing the correct response to an ill-formed
> question? What alternative behavior of 'maximum' would you prefer to
> see, that the C language auto-promote the function arguments and
> return type to type long based on the type of arguments provided to
> the 'maximum' function?
>
> You either learn to play in the sandbox that C provides, splinters and
> all, or you find another sandbox.
>
> Best regards,
> John D.
You're missing a lot of context. I'm not trying to criticize C, just to
refute a false claim that was made about it.
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article ,
Seebs wrote:
> On 2010-09-30, RG wrote:
> > In article ,
> > Seebs wrote:
> >> And that's the magic of static typing: It is not a false positive to
> >> warn you that "2L" is not of type int.
>
> > We'll have to agree to disagree about that.
>
> No, we won't. It's the *definition* of static typing. Static typing
> is there to give you some guarantees at the expense of not being able
> to express some things without special extra effort. That's why it's
> static.
I don't want to quibble over terminology. Whatever label you choose to
put on it ("false positive", "not being able to express some things
without special extra effort") I consider it a deficiency. The costs
are greater than the benefits. Reasonable people can (and obviously do)
disagree.
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article ,
Keith Thompson wrote:
> RG writes:
> > In article ,
> > Seebs wrote:
> >
> >> On 2010-09-30, Lie Ryan wrote:
> >> > On 09/30/10 16:09, TheFlyingDutchman wrote:
> >> >> Dynamic typed languages like Python fail in this case on "Never blows
> >> >> up".
> >>
> >> > How do you define "Never blows up"?
> >>
> >> I would say "blow up" would be "raise an exception".
> >>
> >> > Personally, I'd consider maximum(8589934592, 1) returning 1 as a blow
> >> > up, and of the worst kind since it passes silently.
> >>
> >> So run your compiler with a decent set of warning levels, and watch as
> >> you are magically warned that you're passing an object of the wrong type.
> >
> > My code compiles with no warnings under gcc -Wall.
>
> Conclusion: "-Wall" is not "a decent set of warning levels" in this
> context, in spite of the name. (If you want to complain that the
> name "-Wall" is misleading, I won't disagree, but it's a gcc issue,
> not a C issue.)
>
> With "-Wconversion", I get:
>
> c.c: In function 'main':
> c.c:7: warning: passing argument 1 of 'maximum' with different width due to
> prototype
>
> [...]
That gives (what I would consider to be) false positives, e.g.:
[...@mighty:~]$ cat foo.c
void foo(long x) {}
int main() { foo(1); }
[...@mighty:~]$ gcc -Wconversion foo.c
foo.c: In function ‘main’:
foo.c:4: warning: passing argument 1 of ‘foo’ with different width due
to prototype
> >> On any given system, one or the other is true:
> >>
> >> 1. The constant 8589934592 is of type int, and the function will
> >> "work" -- will give that result.
> >> 2. The constant is not of type int, and the compiler will warn you about
> >> this if you ask.
> >
> > It would be nice if this were true, but my example clearly demonstrates
> > that it is not. And if your response is to say that I should have used
> > lint, then my response to that will be that because of the halting
> > problem, for any static analyzer that you present, I can construct a
> > program that either contains an error that either your analyzer will not
> > catch, or for which it will generate a false positive. It just so
> > happens that constructing such examples for standard C is very easy.
>
> And yet you have not managed to do it.
Actually I have. Twice now. Remember, the claim is not that the
compiler will fail to warn. It's trivial to never fail to warn simply
by always warning. The claim is that the compiler with *either* fail to
warn *or* generate false positives. So you have to choose your compiler
(and flags) first, and then I get to construct my example. If my
example has *either* an error that the compiler doesn't catch *or* a
non-error that it does catch then I win.
Want to try another round?
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <87tyl63cag@mail.geddis.org>, Don Geddis wrote: > Keith Thompson wrote on Thu, 30 Sep 2010: > > RG writes: > >> You're missing a lot of context. I'm not trying to criticize C, just to > >> refute a false claim that was made about it. > > Can you cite the article that made this false claim, and exactly what > > the false claim was? > > http://groups.google.com/group/comp.lang.lisp/msg/431925448da59481 > > Message-ID: > <0497e39d-6bd1-429d-a86f-f4c89babe...@u31g2000pru.googlegroups.com> > From: TheFlyingDutchman > Newsgroups: comp.lang.lisp > > [...] > in C I can have a function maximum(int a, int b) that will always > work. Never blow up, and never give an invalid answer. If someone > tries to call it incorrectly it is a compile error. > [...] > > __ > _ > Don Geddis http://don.geddis.org/ > d...@geddis.org Thanks, Don. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article ,
Seebs wrote:
> On 2010-09-30, RG wrote:
> > That gives (what I would consider to be) false positives, e.g.:
>
> > [...@mighty:~]$ cat foo.c
>
> > void foo(long x) {}
>
> > int main() { foo(1); }
> > [...@mighty:~]$ gcc -Wconversion foo.c
> > foo.c: In function ???main???:
> > foo.c:4: warning: passing argument 1 of ???foo??? with different width due
> > to prototype
>
> But it's *not* a false positive. The compiler is not claiming that the
> conversion couldn't be done -- it's just telling you that there is a
> change of type going on.
Again, you can't have it both ways. Either a warning is a "compiler
error" according to the claim at issue (see below) or it is not. If it
is, then this is a false positive. If it is not, then my previous
example refutes the claim.
> If you don't want that message, it is certainly possible to write code
> which won't get it, and which will reliably work everywhere.
Of course it's possible. It's *possible*, with enough effort, to write
correct code in any programming language. What does that have to do
with anything?
> > So you have to choose your compiler
> > (and flags) first, and then I get to construct my example. If my
> > example has *either* an error that the compiler doesn't catch *or* a
> > non-error that it does catch then I win.
>
> Those goal posts are sorta red shifted at this point.
At this point I would like to quote a wise man who once said:
> May I suggest that, if you don't want to use words and terminology
> precisely, perhaps computer programming is not for you?
Red shifted?
> You're redefining "error" and "non-error" so as to demand that a statically
> typed language offer you the same semantics of errors and non-errors that
> dynamically typed languages have. That's cheating, though. The claim
> is about C, not about what people who are expecting a dynamically typed
> language would like C to be like.
The claim is:
http://groups.google.com/group/comp.lang.lisp/msg/431925448da59481
Message-ID:
<0497e39d-6bd1-429d-a86f-f4c89babe...@u31g2000pru.googlegroups.com>
From: TheFlyingDutchman
Newsgroups: comp.lang.lisp
[...]
in C I can have a function maximum(int a, int b) that will always
work. Never blow up, and never give an invalid answer. If someone
tries to call it incorrectly it is a compile error.
[...]
The truth of this claim hinges on the definitions of "work", "never blow
up", "invalid", "call incorrectly" and "compile error." Define these
however you like, the result will be that the claim is either false or
vacuous.
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Seebs wrote: > On 2010-10-01, RG wrote: > > Again, you can't have it both ways. Either a warning is a "compiler > > error" according to the claim at issue (see below) or it is not. If it > > is, then this is a false positive. > > No, it isn't. It's a correctly identified type mismatch. > > You keep moving the goal posts from the actual standard of a false positive > (the compiler warns that something is of the wrong type when it's not of > the wrong type) to a made-up standard (the compiler warns that something is > of the wrong type when it is indeed of the wrong type, but could be safely > converted to the right type). > > It doesn't matter whether, in a given case, you *could* safely perform > the conversion. If you don't perform the conversion, and the compiler points > this out, that's not a false positive. > > >> Those goal posts are sorta red shifted at this point. > > > At this point I would like to quote a wise man who once said: > > >> May I suggest that, if you don't want to use words and terminology > >> precisely, perhaps computer programming is not for you? > > > Red shifted? > > Moving away fast enough that their color has visibly changed. > > > The truth of this claim hinges on the definitions of "work", "never blow > > up", "invalid", "call incorrectly" and "compile error." Define these > > however you like, the result will be that the claim is either false or > > vacuous. > > Not really. If you use the most obvious and natural meanings *for a > statically typed language*, it is obvious that it is true. > > And indeed, significantly so. In the real world, programs written in > scripting languages with runtime typing are fairly likely to throw occasional > exceptions because something is of the wrong type. In a statically typed > language, the of-the-wrong-type is something which can, by definition, be > caught at compile time. > > The fundamental thing you seem to be getting stuck on is that you're assuming > that if a conversion could be made, that it should be and it should be > automatic and silent. That, however, is at odds with discussion of a > statically typed language. There's a reason we have the option of converting > things from one type to another. No, this is not what I'm getting stuck on. I understand the technical theory behind statically typed languages. What I'm getting "stuck" on is this: > In a statically typed language, the of-the-wrong-type is something which > can, by definition, be caught at compile time. Any time something is true "by definition" that is an indication that it's not a particularly useful fact. The whole concept of "type" is a red herring. It's like this: there are some properties of programs that can be determined statically, and others that can't. Some of the properties that can't be determined statically matter in practice. But all of the properties that can be determined statically can also be determined dynamically. The *only* advantage that static analysis has is that *sometimes* it can determine *some* properties of a program faster or with less effort than a dynamic approach would. What I take issue with is the implication made by advocates of static analysis that static analysis is somehow *inherently* superior to dynamic analysis, that static analysis can provide some sort of "guarantee" of reliability that actually has some sort of practical meaning in the real world. It doesn't. The net effect of static analysis in the real world is to make programmers complacent about properties of programs that can only be determined at run time, to make them think that compiling without errors means something, and that if a program compiles without errors then there is no need for run-time checking of any sort. *You* may not believe these things, but the vast majority of programmers who use statically typed languages do believe these things, even if only tacitly. The result is a world where software by and large is a horrific mess of stack overflows, null pointer exceptions, core dumps, and security holes. I'm not saying that static analysis is not useful. It is. What I'm saying is that static analysis is nowhere near as useful as its advocates like to imply that it is. And it's better to forego static analysis and *know* that you're flying without a net at run-time than to use it and think that you're safe when you're really not. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article
<1a172248-8aab-42f0-a8a2-3f00168f9...@u13g2000vbo.googlegroups.com>,
Keith H Duggar wrote:
> On Sep 29, 9:01 pm, RG wrote:
> > That the problem is "elsewhere in the program" ought to be small
> > comfort. But very well, try this instead:
> >
> > [...@mighty:~]$ cat foo.c
> > #include
> >
> > int maximum(int a, int b) { return a > b ? a : b; }
> >
> > int main() {
> > long x = 8589934592;
> > printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> > return 0;}
> >
> > [...@mighty:~]$ gcc -Wall foo.c
> > [...@mighty:~]$ ./a.out
> > Max of 8589934592 and 1 is 1
>
> $ gcc -Wconversion -Werror foo.c
> cc1: warnings being treated as errors
> foo.c: In function 'main':
> foo.c:5: warning: passing argument 1 of 'maximum' with different width
> due to prototype
>
> It's called "learning to compile".
It's called "being late for the game." This has already been raised and
addressed. Read the rest of the thread.
rg
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , "BartC" wrote: > "Thomas A. Russ" wrote in message > news:ymi1v7vgyp8@blackcat.isi.edu... > > torb...@diku.dk (Torben ZÆgidius Mogensen) writes: > > > >> Trigonometric functions do take arguments of particular units: radians > >> or (less often) degrees, with conversion needed if you use the "wrong" > >> unit. > > > > But radians are dimensionless. > > But they are still units No, they aren't. > so that you can choose to use radians, degrees or gradians Those aren't units either, any more than a percentage is a unit. They are just different ways of writing numbers. All of the following are the same number written in different notations: 0.5 1/2 50% Likewise, all of the following are the same number written in different notations: pi/2 pi/2 radians 90 degrees 100 gradians 1/4 circle 0.25 circle 25% of a circle 25% of 2pi See? rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , "BartC" wrote: > "RG" wrote in message > news:rnospamon-20651e.17410012102...@news.albasani.net... > > In article , > > "BartC" wrote: > > > >> "Thomas A. Russ" wrote in message > > >> > But radians are dimensionless. > >> > >> But they are still units > > > > No, they aren't. > > > >> so that you can choose to use radians, degrees or gradians > > > > Those aren't units either, any more than a percentage is a unit. They > > are just different ways of writing numbers. > > > > All of the following are the same number written in different notations: > > > > 0.5 > > 1/2 > > 50% > > > > Likewise, all of the following are the same number written in different > > notations: > > > > pi/2 > > pi/2 radians > > 90 degrees > > 100 gradians > > 1/4 circle > > 0.25 circle > > 25% of a circle > > 25% of 2pi > > > > See? > > But what exactly *is* this number? Is it 0.25, 1.57 or 90? It's an irrational number, so it cannot be written out exactly. But it's approximately 1.57. > I can also write 12 inches, 1 foot, 1/3 yards, 1/5280 miles, 304.8 mm and so > on. They are all the same number, roughly 1/13100 of the polar > circumference of the Earth. These aren't numbers, these are lengths. They correspond to a physical thing out there in the real world. Numbers don't. > This does depend on the actual size of an arbitrary circle, but that seems > little different from the choice of 0.25, 1.57 or 90 for your quarter > circle. Why does it seem "little different"? That is exactly the difference. What you're doing in your "1/13100 of the polar circumference of the Earth" is taking the number 1/13100 and using it to describe a length. But what is 1/13100? Well, it's the ratio of one foot to the polar circumference of the earth. It's also the ratio of one apple to 13100 apples, or one sheep to 13100 sheep, or one second to 13100 seconds. It's the ratio of *anything* to 13100 of the same thing. (And, in case you're wondering, 13100 is the 13100th successor of zero.) rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , Keith Thompson wrote: > "BartC" writes: > > "RG" wrote in message > > news:rnospamon-20651e.17410012102...@news.albasani.net... > [...] > >> Likewise, all of the following are the same number written in different > >> notations: > >> > >> pi/2 > >> pi/2 radians > >> 90 degrees > >> 100 gradians > >> 1/4 circle > >> 0.25 circle > >> 25% of a circle > >> 25% of 2pi > >> > >> See? > > > > But what exactly *is* this number? Is it 0.25, 1.57 or 90? > > It's approximately 1.57. > > > I can also write 12 inches, 1 foot, 1/3 yards, 1/5280 miles, 304.8 mm and > > so > > on. They are all the same number, roughly 1/13100 of the polar > > circumference of the Earth. > > They aren't bare numbers, they're lengths (actually the same length). > > > This does depend on the actual size of an arbitrary circle, but that seems > > little different from the choice of 0.25, 1.57 or 90 for your quarter > > circle. > > The radian is defined as a ratio of lengths. That ratio is the same > regardless of the size of the circle. The choice of 1/(2*pi) of the > circumference isn't arbitrary at all; there are sound mathematical > reasons for it. Mathematicians could have chosen to set the full > circumference to 1, for example, but then a lot of computations > would contain additional multiplications and/or divisions by 2*pi. http://www.math.utah.edu/%7Epalais/pi.pdf rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <87mxqin49o@kuiper.lan.informatimago.com>, p...@informatimago.com (Pascal J. Bourguignon) wrote: > There's a notion of > angle that is different from the notion of interest rate. Only because of how they are conventionally used. There's no difference between sin(0.1) and sin(10%). Likewise there is no difference between an interest rate of 10% and an interest rate of 0.1. Even an interest rate of 0.1 radians makes sense if for some unfathomable reason you want to visualize your interest payment as the relative length of a line segment and an arc. > (I have also > vague memories of a mathematical presentation of angles that clearly > distinguished angles from numbers used to represent them). That would be interesting. If you find a pointer please pass it along. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing" [OT]
In article , Peter Nilsson wrote: > Keith Thompson wrote: > > The radian is defined as a ratio of lengths. That ratio > > is the same regardless of the size of the circle. The > > choice of 1/(2*pi) of the circumference isn't arbitrary > > at all; there are sound mathematical reasons for it. > > Yes, but what is pi then? > > > Mathematicians could have chosen to set the full > > circumference to 1, for example, but then a lot of > > computations would contain additional multiplications > > and/or divisions by 2*pi. > > The formula: circumference = 2 x pi x radius is taught > in primary schools, yet it's actually a very difficult > formula to prove! What's to prove? That's the definition of pi. rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <8hl3grfh2...@mid.individual.net>, Gregory Ewing wrote: > RG wrote: > > Even an interest > > rate of 0.1 radians makes sense if for some unfathomable reason you want > > to visualize your interest payment as the relative length of a line > > segment and an arc. > > It could even be quite reasonable if you're presenting it > as a segment of a pie graph. Good point. > For what it's worth, the GST rate here recently increased > from 0.7853 to 0.9425 radians. :-) :-) rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article <8hl2ucfdv...@mid.individual.net>, Gregory Ewing wrote: > Tim Bradshaw wrote: > > In general any function > > which raises its argument to more than one power ... doesn't make > > much sense if its argument has units. > > That's not true. Consider the distance travelled by a > falling object: y(t) = y0 + v0*t + 0.5*a*t**2. Here t has > dimensions of time, and it's being raised to different > powers in different terms. It works because the > coefficents have dimensions too, and all the terms end up > having the same dimensions. This reminds me of back when I was a kid and my dad was trying to teach me basic physics. He kept saying that the acceleration of gravity was 9.8 meters per second squared and I just couldn't wrap my brain around what it meant to square a second. Now that I think about it, I still can't. :-) rg -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
In article , r...@rpw3.org (Rob Warnock) wrote: > RG wrote: > +--- > | This reminds me of back when I was a kid and my dad was trying to teach > | me basic physics. He kept saying that the acceleration of gravity was > | 9.8 meters per second squared and I just couldn't wrap my brain around > | what it meant to square a second. > | > | Now that I think about it, I still can't. :-) > +--- > > Write it our longhand and it's easier to grok: > > 9.8 m/s^2 ==> 9.8 m/(s*s) ==> 9.8 m/(s*s) ==> > (9.8 meters per second) per second. > \ / > \__ speed added __/ per second Oh, that part I get. It's the abstract squared second that's still a deep mystery to me. A squared length is easily visualized. But according to relativity space and time are just two aspects of the same thing, so a squared second should make some kind of physical sense. rg -- http://mail.python.org/mailman/listinfo/python-list
