On 27/03/2016 22:55, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote:
On 27/03/2016 18:19, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
There would be a list of expression terms that can also form independent
statements.
On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote:
> On 27/03/2016 18:19, Ned Batchelder wrote:
> > On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
>
> >> There would be a list of expression terms that can also form independent
> >> statements. Not knowing Python, the list wo
On 27 Mar 2016 23:11, "Ben Bacarisse" wrote:
>
> Steven D'Aprano writes:
>
> > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> >
> >> Steven D'Aprano writes:
> >>> For example, would you consider that this isolated C code is
> >>> "meaningless"?
> >>> int i = n + 1;
> >>
> >> It's meaningful a
On 27/03/2016 18:19, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
There would be a list of expression terms that can also form independent
statements. Not knowing Python, the list would comprise function calls
(ie. the function call is top node in the AST
Steven D'Aprano writes:
> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
>
>> Steven D'Aprano writes:
>>> For example, would you consider that this isolated C code is
>>> "meaningless"?
>>> int i = n + 1;
>>
>> It's meaningful as long as n is in a certain range of values so there's
>> no overf
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
> On 27/03/2016 16:48, Ned Batchelder wrote:
> > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> >> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
>
> >> Well, that could be done in Python (not so usefully because you can't
On 27/03/2016 16:48, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
On 27/03/2016 14:47, Dennis Lee Bieber wrote:
Well, that could be done in Python (not so usefully because you can't
take account of such info until a call is attempted), but that's not
what
On 3/27/2016 11:48 AM, Ned Batchelder wrote:
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
whether fn has an explicit return or not, and not allowing:
fn # and other kinds of expression
unless some keyword is used.
Python *could* have made it an error to have a u
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
> > On Sun, 27 Mar 2016 12:31:26 +0100, BartC declaimed the
> > following:
> >
> >> On 27/03/2016 07:34, Paul Rubin wrote:
> >>> BartC writes:
> But my suggestion was to have requi
On 27/03/2016 14:47, Dennis Lee Bieber wrote:
On Sun, 27 Mar 2016 12:31:26 +0100, BartC declaimed the
following:
On 27/03/2016 07:34, Paul Rubin wrote:
BartC writes:
But my suggestion was to have required a keyword in front of
such expressions.
Should there be a keyword in front of a l
On 27/03/2016 07:34, Paul Rubin wrote:
BartC writes:
But my suggestion was to have required a keyword in front of
such expressions.
Should there be a keyword in front of a line containing "sqrt(x)" ?
What about "launch(missiles)" ?
They both look like function calls. Function calls are *v
On 27 Mar 2016 10:56, "Steven D'Aprano" wrote:
>
>
> My C is a bit rusty, so excuse me if I get the syntax wrong. I have a
> function:
>
> void foo(int n) {
> int i = n + 1;
> bar(i);
> }
>
> There's a possible overflow of a signed int in there. This is undefined
> behaviour. Now, you migh
On Sunday, March 27, 2016 at 1:10:51 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
>
> > No it's not meaningless if it "might" overflow, it's meaningless if it
> > -does- overflow,
>
> No! That's exactly wrong!
>
> Paul, thank you for inadvertently provin
On Sun, 27 Mar 2016 01:30 am, Chris Angelico wrote:
> On Sun, Mar 27, 2016 at 1:09 AM, BartC wrote:
>> I'm surprised that both C and Python allow statements that apparently do
>> nothing. In both, an example is:
>>
>> x
>>
>> on a line by itself. This expression is evaluated, but then any resul
On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> For example, would you consider that this isolated C code is
>> "meaningless"?
>> int i = n + 1;
>
> It's meaningful as long as n is in a certain range of values so there's
> no overflow.
>
>> But according to the stan
On Sat, 26 Mar 2016 08:23 am, Chris Angelico wrote:
> On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano
> wrote:
>> Undefined behaviour does not mean "implementation specific behaviour".
>> Nor does it mean "something sensible will happen but we don't promise
>> what it will be". It means "the co
On Sunday, March 27, 2016 at 12:05:01 PM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > eg haskell (ghc) is written in ghc
> > Where did the first bootstrap start from?
>
> The very earliest Haskell implementation was written in Lisp.
Ummm So you found a little chink in my argument -- Ok :
Rustom Mody writes:
> eg haskell (ghc) is written in ghc
> Where did the first bootstrap start from?
The very earliest Haskell implementation was written in Lisp.
--
https://mail.python.org/mailman/listinfo/python-list
BartC writes:
> But my suggestion was to have required a keyword in front of
> such expressions.
Should there be a keyword in front of a line containing "sqrt(x)" ?
What about "launch(missiles)" ?
The compiler can't tell which of those expressions has a side effect.
The first might be buggy cod
Steven D'Aprano writes:
> For example, would you consider that this isolated C code is
> "meaningless"?
> int i = n + 1;
It's meaningful as long as n is in a certain range of values so there's
no overflow.
> But according to the standard, it's "meaningless", since it might
> overflow, and signed
On Sunday, March 27, 2016 at 10:32:34 AM UTC+5:30, Rustom Mody wrote:
> I had an impression of seeing some discussion on this and resolved not
> to incorporate.
Meaning: I think I remember something about a resolution -- after some debate
-- not to OO-ify the C/Unix errno system
--
https://mail.p
On Sunday, March 27, 2016 at 2:15:22 AM UTC+5:30, Terry Reedy wrote:
> On 3/26/2016 1:43 PM, Rustom Mody wrote:
>
> > There is this nice piece of OO called the exception hierarchy:
>
> > https://docs.python.org/2/library/exceptions.html#exception-hierarchy
>
> https://docs.python.org/3/library/
On Sun, Mar 27, 2016 at 1:44 PM, Steven D'Aprano wrote:
> If [anyone] takes over the world and bans C, insisting that it be
> replaced with a new language of his own design called "T", the
> *implementation* of CPython would have to change, but the *interface*, the
> language itself, won't have to
On Sun, 27 Mar 2016 04:43 am, Rustom Mody wrote:
> On Saturday, March 26, 2016 at 4:09:41 PM UTC+5:30, Steven D'Aprano wrote:
>> On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
>>
>> > For one thing its good to remember that we wouldn't be here without
>> > python Python wouldn't be what it is w
On Sun, Mar 27, 2016 at 4:43 AM, Rustom Mody wrote:
> On Saturday, March 26, 2016 at 4:09:41 PM UTC+5:30, Steven D'Aprano wrote:
>> On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
>>
>> > For one thing its good to remember that we wouldn't be here without python
>> > Python wouldn't be what it is
On 3/26/2016 1:43 PM, Rustom Mody wrote:
There is this nice piece of OO called the exception hierarchy:
> https://docs.python.org/2/library/exceptions.html#exception-hierarchy
https://docs.python.org/3/library/exceptions.html#exception-hierarchy
BaseException ⊇ Exception ⊇ EnvironmentError
On Saturday, March 26, 2016 at 4:09:41 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
>
> > For one thing its good to remember that we wouldn't be here without python
> > Python wouldn't be what it is without CPython
>
> There is nothing about Python that r
On 26/03/2016 14:30, Chris Angelico wrote:
On Sun, Mar 27, 2016 at 1:09 AM, BartC wrote:
I'm surprised that both C and Python allow statements that apparently do
nothing. In both, an example is:
x
on a line by itself. This expression is evaluated, but then any result
discarded. If there wa
On Sun, Mar 27, 2016 at 1:09 AM, BartC wrote:
> I'm surprised that both C and Python allow statements that apparently do
> nothing. In both, an example is:
>
> x
>
> on a line by itself. This expression is evaluated, but then any result
> discarded. If there was a genuine use for this (for examp
On 26/03/2016 13:22, Chris Angelico wrote:
On Sat, Mar 26, 2016 at 11:21 PM, Steven D'Aprano wrote:
In plain English, if the programmer had an intention for the code, and it
was valid C syntax, it's not hard to conclude that the code has some
meaning. Even if that meaning isn't quite what the p
On Sat, Mar 26, 2016 at 11:21 PM, Steven D'Aprano wrote:
> In plain English, if the programmer had an intention for the code, and it
> was valid C syntax, it's not hard to conclude that the code has some
> meaning. Even if that meaning isn't quite what the programmer expected.
> Compilers are well
On Sat, 26 Mar 2016 01:59 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
>> Culturally, C compiler writers have a preference for using undefined
>> behaviour to allow optimizations, even if it means changing the semantics
>> of your code.
>
> If your code has UB then by definition it has no sem
On Sat, Mar 26, 2016 at 9:39 PM, Steven D'Aprano wrote:
> It is an accident of history that Python's first and major implementation
> happens to be written in C. (Although its use as a glue language, allowing
> people to safely use libraries written in C, probably played a role in
> ensuring Pytho
On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote:
> For one thing its good to remember that we wouldn't be here without python
> Python wouldn't be what it is without CPython
There is nothing about Python that relies on the C standard being as it is.
There are Python implementations that are not w
Steven D'Aprano :
> On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:
>> Yes, although the same could be true for Python as well.
>
> Is this a philosophical question? Yes, it *could* be true, in some
> alternate universe, but it isn't actually true.
>
> Python does not have undefined behaviour
On Friday, March 25, 2016 at 9:20:23 PM UTC+5:30, Steven D'Aprano wrote:
>
> Undefined behaviour in C is a minefield waiting to blow your program's legs
> off, because the designers of the language made the explicit choice that
> they wanted the language to be as fast and efficient as possible, ev
Steven D'Aprano writes:
> Culturally, C compiler writers have a preference for using undefined
> behaviour to allow optimizations, even if it means changing the semantics
> of your code.
If your code has UB then by definition it has no semantics to change.
Code with UB has no meaning.
--
https:
On Fri, Mar 25, 2016, at 22:46, Steven D'Aprano wrote:
> Culturally, C compiler writers have a preference for using undefined
> behaviour to allow optimizations, even if it means changing the semantics
> of your code. The C compiler is allowed to ignore your code, move it
> around
> so that things
On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Undefined behaviour in C is a minefield waiting to blow your program's
>> legs off, because the designers of the language made the explicit
>> choice that they wanted the language to be as fast and efficient as
>> possib
On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano wrote:
> On Fri, 25 Mar 2016 06:54 am, BartC wrote:
>
>>> In the case of C, the line is limited to working with some specific type
>>> (say, an int32). Even there, if the addition might overflow, the
>>> behaviour is undefined and the compiler can d
Steven D'Aprano :
> Undefined behaviour in C is a minefield waiting to blow your program's
> legs off, because the designers of the language made the explicit
> choice that they wanted the language to be as fast and efficient as
> possible, even at the cost of safe, reproducible behaviour.
Yes, a
41 matches
Mail list logo
