On Mon, Feb 26, 2018 at 8:55 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 8:09 PM, Steven D'Aprano
> wrote:
>> Yes you did: "the last second of every year" is always 23:59:59 of 31st
>> December, and it is always the same time and
On Tue, Feb 27, 2018 at 2:55 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 8:09 PM, Steven D'Aprano
> wrote:
>> Yes you did: "the last second of every year" is always 23:59:59 of 31st
>> December, and it is always the same time and
On Tue, Feb 27, 2018 at 12:18 PM, Rick Johnson
wrote:
> On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano wrote:
>> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
>>
>> > For instance, if the age is queried many times a second,
>> > it would
On Mon, Feb 26, 2018 at 8:09 PM, Steven D'Aprano
wrote:
> Yes you did: "the last second of every year" is always 23:59:59 of 31st
> December, and it is always the same time and date "every year".
Except when it's 23:59:60 or 23:59:61 (which hasn't yet
On Mon, 26 Feb 2018 17:18:38 -0800, Rick Johnson wrote:
[...]
> So, for instance: if your birthday is January 25th 1969, the last second
> of the last day of your _first_ year is January 24th 1970 @ 11:59:59PM.
> And the last second of the last day of your _second_ year is January
> 24th 1971 @
On Mon, 26 Feb 2018 17:18:38 -0800, Rick Johnson wrote:
> On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano
> wrote:
>> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
>>
>> > For instance, if the age is queried many times a second, it would be
>> > a much wiser design to
On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
>
> > For instance, if the age is queried many times a second,
> > it would be a much wiser design to set-up an event that
> > will advance the age at the end of the
On Tue, Feb 20, 2018 at 10:09 PM, Chris Angelico wrote:
> On Wed, Feb 21, 2018 at 6:39 AM, Geldenhuys, J, Prof
> wrote:
>> I think your case illustrates the Python/Mathematica issue well: you found
>> a job for which Mathematica was not the
On 2018-02-18 22:55, Paul Rubin wrote:
Steven D'Aprano writes:
"positive odd integers greater than 10 but less than 15003 divisible by
17 except for 850, 867 and 1394; or primes that aren't Mersenne
primes"
It *could* be a type, if your type system
On 2018-02-18 22:55, Paul Rubin wrote:
Steven D'Aprano writes:
"positive odd integers greater than 10 but less than 15003 divisible by
17 except for 850, 867 and 1394; or primes that aren't Mersenne
primes"
It *could* be a type, if your type system
On 2/20/18 3:51 PM, Chris Angelico wrote:
On Wed, Feb 21, 2018 at 7:42 AM, Rick Johnson
wrote:
On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
The point he was making is that if you store a person's age, you'd have
to update it every year. It's
On 21-02-18 11:31, Terry Reedy wrote:
> On 2/21/2018 3:15 AM, Antoon Pardon wrote:
>> On 21-02-18 06:18, Terry Reedy wrote:
>>> On 2/20/2018 8:38 AM, Antoon Pardon wrote:
>>>
People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a
On Saturday, February 17, 2018 at 12:28:29 PM UTC+1, Ben Bacarisse wrote:
> Marko Rauhamaa writes:
>
> > Many people think static typing is key to high quality. I tend to think
> > the reverse is true: the boilerplate of static typing hampers
> > expressivity so much that, on
On 2/21/2018 3:15 AM, Antoon Pardon wrote:
On 21-02-18 06:18, Terry Reedy wrote:
On 2/20/2018 8:38 AM, Antoon Pardon wrote:
People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.
...
When
On 21-02-18 06:18, Terry Reedy wrote:
> On 2/20/2018 8:38 AM, Antoon Pardon wrote:
>
>> People praise the dynamic nature of Python here on this list and then
>> often enough seem to recoil when they see a piece of code really using
>> that dynamism.
>
> ...
>
> When makes people recoil is abusing
On 21-02-18 05:13, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 10:17:12 -0700, Ian Kelly wrote:
>
>> On Tue, Feb 20, 2018 at 8:38 AM, Steven D'Aprano
>> wrote:
>>> On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>>>
> Okay. Now create a
On 20-02-18 16:38, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>
>>> Okay. Now create a constraint on a name in C++ such that it can only
>>> accept integers representing A.D. years which, on the Gregorian
>>> calendar, are leap years. (Using a dedicated
On 2/20/2018 8:38 AM, Antoon Pardon wrote:
People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.
Dynamic typing is the addition of run-time type information (RTTI) to
data values. This
On Wed, Feb 21, 2018 at 6:39 AM, Geldenhuys, J, Prof
wrote:
> I think your case illustrates the Python/Mathematica issue well: you found a
> job for which Mathematica was not the perfect tool and you used Python. At
> the end of the day, both M & P have their
Hi Marcel,
I have read through the article and it seems to me that all of the problems
described boil down to one important point: use the right tool for the right
job. Python is probably not the best language for developing large, complex
systems (although there are such systems). Most (or
On Wed, Feb 21, 2018 at 9:01 AM, Rick Johnson
wrote:
> On Tuesday, February 20, 2018 at 2:51:56 PM UTC-6, Chris Angelico wrote:
> [...]
>> Nope. Even if you need the age many times per second, it's still
>> better to store the date of birth, because you eliminate
On Tue, 20 Feb 2018 10:17:12 -0700, Ian Kelly wrote:
> On Tue, Feb 20, 2018 at 8:38 AM, Steven D'Aprano
> wrote:
>> On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>>
Okay. Now create a constraint on a name in C++ such that it can only
On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote:
> For instance, if the age is queried many times a second, it would be a
> much wiser design to set-up an event that will advance the age at the
> end of the last second of every year
Do you really mean to say that everybody in the world
On Tue, 20 Feb 2018 22:19:13 +0100, Christian Gollwitzer wrote:
[...]
> LeapYearCheck could be implemented using template metaprogramming
> (quite horrible) or the new funky constexpr feature in C++11/C++14 (less
> horrible).
Thanks Christian. That's certainly interesting, I don't know much
On Tue, 20 Feb 2018 17:11:05 +, Wild, Marcel, Prof
wrote:
> I scarcely know Python, and I have no intention delving into it further.
> I was forced to use Python because it features binary decision
> diagrams, which MATHEMATICA doesn't. Coming from Mathematica the
>
On Tuesday, February 20, 2018 at 2:51:56 PM UTC-6, Chris Angelico wrote:
[...]
> Nope. Even if you need the age many times per second, it's still
> better to store the date of birth, because you eliminate boundary
> conditions and duplicated data.
You failed to provide any examples proving this
Am 20.02.18 um 14:58 schrieb Chris Angelico:
Okay. Now create a constraint on a name in C++ such that it can only
accept integers representing A.D. years which, on the Gregorian
calendar, are leap years. (Using a dedicated integer-like type is
permitted.) It must accept all multiples of four,
On Wed, Feb 21, 2018 at 7:42 AM, Rick Johnson
wrote:
> On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
>
>> The point he was making is that if you store a person's age, you'd have
>> to update it every year. It's far better to store the date of birth
On 20/02/2018 20:17, MRAB wrote:
On 2018-02-20 19:17, bartc wrote:
On 20/02/2018 19:04, Dennis Lee Bieber wrote:
On Tue, 20 Feb 2018 17:11:05 +, "Wild, Marcel, Prof
"
declaimed the following:
So the special type of the values 65..90 might not allow
On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
> The point he was making is that if you store a person's age, you'd have
> to update it every year. It's far better to store the date of birth and
> calculate the age on demand.
*AHEM*
At the risk of being labeled a "quibbler"
On 2018-02-20 19:17, bartc wrote:
On 20/02/2018 19:04, Dennis Lee Bieber wrote:
On Tue, 20 Feb 2018 17:11:05 +, "Wild, Marcel, Prof "
declaimed the following:
So the special type of the values 65..90 might not allow the type be multiplied
or divided,
On 20/02/2018 19:35, Lawrence D’Oliveiro wrote:
On Wednesday, February 21, 2018 at 1:43:41 AM UTC+13, bartc wrote:
In Pascal (and presumably Ada) then all the
gubbins need to make this work properly:
var x: 1..10;
x = 10;
x = x + 1; { error? }
Error on both statements. Pascal
On 2018-02-20, Rhodri James wrote:
> The schism is not as wide as you are implying. Aside from "print"
> becoming a function, which is blindingly obvious whenever you trip over
> it, there is relatively little reason why an ordinary Pythonista would
> care whether he or
On 20/02/2018 19:04, Dennis Lee Bieber wrote:
On Tue, 20 Feb 2018 17:11:05 +, "Wild, Marcel, Prof "
declaimed the following:
So the special type of the values 65..90 might not allow the type be multiplied
or divided, or added to itself. Because they
"Wild, Marcel, Prof " writes:
> I scarcely know Python, and I have no intention delving into it
> further.
That's fine. This is a forum for those who do have an ongoing interest
in Python. I think your needs would be better served elsewhere.
--
\
On 20/02/18 17:11, Wild, Marcel, Prof wrote:
I scarcely know Python, and I have no intention delving into it further.
I was forced to use Python because it features binary decision diagrams,
which MATHEMATICA doesn't. Coming from Mathematica the account of Nathan Murphy
> On Feb 20, 2018, at 8:58 AM, Chris Angelico wrote:
>
>> On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon wrote:
>> In C++ I can do something like:
>>
>> SomeClass MyVar;
>>
>> And after that the kind of possible assignments to MyVar are constraint.
On Tuesday, February 20, 2018 at 9:40:37 AM UTC-6, Steven D'Aprano wrote:
[...]
> Yes you did: you refused to meet the challenge, stating (and I quote):
I'm always entertained by Steven's so-called "challenges". You see, Steven is
addicted to winning, and he'll do anything to win a debate, even
I scarcely know Python, and I have no intention delving into it further.
I was forced to use Python because it features binary decision diagrams, which
MATHEMATICA doesn't. Coming from Mathematica the account of Nathan Murphy reads
like a nightmare.
The one point that stroke me the most was
On Tue, Feb 20, 2018 at 8:38 AM, Steven D'Aprano
wrote:
> On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>
>>> Okay. Now create a constraint on a name in C++ such that it can only
>>> accept integers representing A.D. years which, on the Gregorian
On Tue, 20 Feb 2018 14:12:08 +0100, Anders Wegge Keller wrote:
> På Tue, 20 Feb 2018 12:28:25 + (UTC) Steven D'Aprano
> skrev:
>> On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
>>
>> > På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven
On Tue, 20 Feb 2018 15:23:44 +0100, Antoon Pardon wrote:
>> Okay. Now create a constraint on a name in C++ such that it can only
>> accept integers representing A.D. years which, on the Gregorian
>> calendar, are leap years. (Using a dedicated integer-like type is
>> permitted.) It must accept
On 20-02-18 14:58, Chris Angelico wrote:
> On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon wrote:
>> In C++ I can do something like:
>>
>> SomeClass MyVar;
>>
>> And after that the kind of possible assignments to MyVar are constraint. It
>> makes the runtime throw an error
On 20-02-18 15:04, Paul Moore wrote:
> On 20 February 2018 at 13:53, Antoon Pardon wrote:
>
>> You can't put such constraints on names in Python.
> I know. That's what *I* said some time ago.
So why did you bother complaining to me when I wrote it?
--
On 20-02-18 14:55, Chris Angelico wrote:
> On Wed, Feb 21, 2018 at 12:38 AM, Antoon Pardon wrote:
>> Why should this be done at compile time? I say a static language can do
>> the same as a dynamic language and your counter point is to ask for how
>> that static language can
On 20/02/2018 13:38, Antoon Pardon wrote:
People praise the dynamic nature of Python here on this list and then
often enough seem to recoil when they see a piece of code really using
that dynamism.
Maybe everyone has their own ideas of how dynamic a language should be.
(I use another
On 20 February 2018 at 13:53, Antoon Pardon wrote:
> You can't put such constraints on names in Python.
I know. That's what *I* said some time ago.
>> Sigh. Languages are different. That's my point.
>
> So, if languages are different, why the difficulty in accepting one
On Wed, Feb 21, 2018 at 12:53 AM, Antoon Pardon wrote:
> In C++ I can do something like:
>
> SomeClass MyVar;
>
> And after that the kind of possible assignments to MyVar are constraint. It
> makes the runtime throw an error when somewhere the program tries to assign
>
On Wed, Feb 21, 2018 at 12:38 AM, Antoon Pardon wrote:
> Why should this be done at compile time? I say a static language can do
> the same as a dynamic language and your counter point is to ask for how
> that static language can do something extra.
>
> The point I am making
I'm not proficient with C++, but IIUC, you could make a class in C++ and
have the constructor and
copy operator check for these kind of things. True it would be run-time
checks but that would
already be more than Python can give.
>>> That (run-time checks) is exactly the
On 20-02-18 13:24, Steven D'Aprano wrote:
> On Tue, 20 Feb 2018 12:18:47 +0100, Antoon Pardon wrote:
>
>> On 19-02-18 15:25, Steven D'Aprano wrote:
Ones like C++ has already tied itself itself up in knots just doing
the basics; I'm not sure how it would handle even my 1,3,5,7,9 type.
On 20 February 2018 at 13:04, Antoon Pardon wrote:
> On 20-02-18 13:11, Paul Moore wrote:
>> On 20 February 2018 at 11:18, Antoon Pardon wrote:
>>> Personnally I would prefer the type system of Pascal and Modula2 with
>>> their interval type
>>> above
På Tue, 20 Feb 2018 12:28:25 + (UTC)
Steven D'Aprano skrev:
> On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
>
> > På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
> > skrev:
> >> On Mon,
On 20-02-18 13:11, Paul Moore wrote:
> On 20 February 2018 at 11:18, Antoon Pardon wrote:
>> Personnally I would prefer the type system of Pascal and Modula2 with
>> their interval type
>> above a Digit class in python. For the simple reason that once you had
>> declared a
On 20/02/2018 12:11, Paul Moore wrote:
On 20 February 2018 at 11:18, Antoon Pardon wrote:
There is no such possibility in Python. You can off course start with x
= Digit(5), but the language
won't stop you from doing x = 11 later.
I'm not proficient with C++, but
On Mon, 19 Feb 2018 16:34:29 +0100, Anders Wegge Keller wrote:
> På Mon, 19 Feb 2018 15:15:19 + (UTC) Steven D'Aprano
> skrev:
>> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
>>
>> > Array is not even close to providing a strongly
On Tue, 20 Feb 2018 12:18:47 +0100, Antoon Pardon wrote:
> On 19-02-18 15:25, Steven D'Aprano wrote:
>>
>>> Ones like C++ has already tied itself itself up in knots just doing
>>> the basics; I'm not sure how it would handle even my 1,3,5,7,9 type.
>>>
>>> But Python has classes and can do some
On 20 February 2018 at 11:18, Antoon Pardon wrote:
> Personnally I would prefer the type system of Pascal and Modula2 with
> their interval type
> above a Digit class in python. For the simple reason that once you had
> declared a variable
> like this:
> x: 1 .. 10;
>
>
On 19-02-18 15:25, Steven D'Aprano wrote:
>
>> Ones like C++ has already tied itself itself up in knots just doing the
>> basics; I'm not sure how it would handle even my 1,3,5,7,9 type.
>>
>> But Python has classes and can do some of this stuff; how would it
>> handle a numeric type that is
On 2/20/18 5:47 AM, Antoon Pardon wrote:
On 19-02-18 16:18, Ned Batchelder wrote:
On 2/19/18 9:54 AM, Steven D'Aprano wrote:
On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
[1] The most basic question, which people making such claims often
can't
answer, is "Do you mean that values are
On 19-02-18 16:18, Ned Batchelder wrote:
> On 2/19/18 9:54 AM, Steven D'Aprano wrote:
>> On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
>>
>>> [1] The most basic question, which people making such claims often
>>> can't
>>> answer, is "Do you mean that values are strongly typed, or that
On Tue, 20 Feb 2018 02:35:37 +1100, Chris Angelico wrote:
> But C is a language saddled with so much history and backward
> compatibility constraints that there are some things you just CAN'T make
> into errors
Indeed. C is not even close to a safe language, hence the move to create
(and more
On Monday, February 19, 2018 at 1:07:02 PM UTC, Anders Wegge Keller wrote:
> På Mon, 19 Feb 2018 04:39:31 + (UTC)
> Steven D'Aprano skrev:
> > On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote:
> >
> > > På Mon, 19 Feb 2018 08:47:14 +1100
> > > Tim Delaney skrev:
> > >> On 18
On Saturday, February 17, 2018 at 12:58:49 AM UTC-6, Paul Rubin wrote:
[...]
> Beyond that, the Python community (with some exceptions) seems to have a
> widespread hatred of threads. It instead prefers to handle concurrent
> i/o with in-thread async schemes that the rest of the world left behind
On Friday, February 16, 2018 at 10:25:32 PM UTC-6, Chris Angelico wrote:
[...]
> This is often touted as a necessity for industrial-grade
> software. It isn't. There are many things that a type
> system, no matter how sophisticated, cannot catch; for some
> reason, though, we don't hear people
On 2/19/18 10:35 AM, Chris Angelico wrote:
On Tue, Feb 20, 2018 at 12:34 AM, Steven D'Aprano
wrote:
On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote:
As an integer, 3.141590 is 107853 $
Looks to me like C is perfectly happy to interpret a
On 2/19/18 1:01 PM, Paul Moore wrote:
On 19 February 2018 at 17:11, Ned Batchelder wrote:
On 2/19/18 10:39 AM, Paul Moore wrote:
I'm curious - How would you explain Python's "variables" to someone
who knows how C variables work, in a way that ensures they don't carry
On 19 February 2018 at 17:11, Ned Batchelder wrote:
> On 2/19/18 10:39 AM, Paul Moore wrote:
>>
>> I'm curious - How would you explain Python's "variables" to someone
>> who knows how C variables work, in a way that ensures they don't carry
>> across any unfortunate
On 2/19/18 10:39 AM, Paul Moore wrote:
On 19 February 2018 at 15:18, Ned Batchelder wrote:
On 2/19/18 9:54 AM, Steven D'Aprano wrote:
On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
[1] The most basic question, which people making such claims often can't
Paul Moore :
> I'm curious - How would you explain Python's "variables" to someone
> who knows how C variables work, in a way that ensures they don't carry
> across any unfortunate misconceptions based on how C works?
Just say that
1. Every Python variable is of the type
On Mon, Feb 19, 2018 at 11:35 PM, bartc wrote:
> Sometimes, the reason for creating a special numerical type is precisely so
> you can't do arithmetic on them, if it's not meaningful for the type.
>
> So the special type of the values 65..90 might not allow the type be
>
On 19 February 2018 at 15:18, Ned Batchelder wrote:
> On 2/19/18 9:54 AM, Steven D'Aprano wrote:
>>
>> On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
>>
>>> [1] The most basic question, which people making such claims often can't
>>> answer, is "Do you mean that
On Tue, Feb 20, 2018 at 12:34 AM, Steven D'Aprano
wrote:
> On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote:
>
>> As an integer, 3.141590 is 107853 $
>>
>> Looks to me like C is perfectly happy to interpret a float as an int.
>
> Yes, but that's
På Mon, 19 Feb 2018 15:15:19 + (UTC)
Steven D'Aprano skrev:
> On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
>
> > Array is not even close to providing a strongly typed container.
>
> That's a mighty powerful claim that goes against
Ned Batchelder :
> I guess I'll have to continue to grit my teeth as people say, "Python
> doesn't have variables." Why can't we say, "Python's variables work
> differently than other languages"?
Because they don't?
Marko
--
On 2/19/18 9:54 AM, Steven D'Aprano wrote:
On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
[1] The most basic question, which people making such claims often can't
answer, is "Do you mean that values are strongly typed, or that names
are? Or did you mean that variables are, because if so
On Mon, 19 Feb 2018 14:06:36 +0100, Anders Wegge Keller wrote:
> Array is not even close to providing a strongly typed container.
That's a mighty powerful claim that goes against the documentation for
the array module. Can you back your claims up?
Here's an array and a list:
import array
arr
On Mon, 19 Feb 2018 13:28:26 +, Paul Moore wrote:
> [1] The most basic question, which people making such claims often can't
> answer, is "Do you mean that values are strongly typed, or that names
> are? Or did you mean that variables are, because if so Python doesn't
> even have variables in
On Mon, 19 Feb 2018 12:35:19 +, bartc wrote:
> Type systems get rapidly very complicated when you have to deal with
> arbitrary sets of values and with arbitrary rules of interaction.
> Someone has to devise a programming language to allow all that without
> tying itself up in knots. Someone
On Mon, 19 Feb 2018 12:19:14 +0100, Alain Ketterlin wrote:
> Steven D'Aprano writes:
>
>> On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
>>
>>> Tim Delaney writes:
>>>
>>> [...]
As others have said, typing is
On Mon, 19 Feb 2018 20:14:32 +1100, Chris Angelico wrote:
> As an integer, 3.141590 is 107853 $
>
> Looks to me like C is perfectly happy to interpret a float as an int.
Yes, but that's not an *automatic* coercion. To count as weakly typed,
the compiler has to do it automatically, without
On 19 February 2018 at 13:06, Anders Wegge Keller wrote:
> Python isn't particular strong typed. In fact, apart from asking an object
> what type it is, types are not that important. It's the interface that
> matters. I wonder why this is a sore point for Python developers?
På Mon, 19 Feb 2018 04:39:31 + (UTC)
Steven D'Aprano skrev:
> On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote:
>
> > På Mon, 19 Feb 2018 08:47:14 +1100
> > Tim Delaney skrev:
> >> On 18 February 2018 at
On 19/02/2018 02:59, Chris Angelico wrote:
On Mon, Feb 19, 2018 at 1:14 PM, bartc wrote:
How would even a type for the odd numbers from 1 to 10 inclusive work?
(That, a type consisting of one of the values in {1,3,5,7,9}.) Would they be
ordered or unordered? Can I do
Alain Ketterlin :
> Your claim essentially is: since we cannot prove everything, let's not
> even try to prove anything. Go on if you think this is the right way to
> think about typing.
This discussion is far too metaphysical.
Static type declarations
Adriaan Renting| Email: rent...@astron.nl
Software Engineer Radio Observatory
ASTRON | Phone: +31 521 595 100 (797 direct)
P.O. Box 2 | GSM: +31 6 24 25 17 28
NL-7990 AA Dwingeloo | FAX: +31 521 595 101
The Netherlands| Web:
On Mon, Feb 19, 2018 at 10:39 PM, Adriaan Renting wrote:
> I remember running 2 Mendocino 300 MHz Celerons on a Pentium II Xeon
> motherboard to get a
> multi-cpu machine for running multiple virtual machines for testing
> purposes around 1998.
> This was not as Intel intended,
Steven D'Aprano writes:
> On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
>
>> Tim Delaney writes:
>>
>> [...]
>>> As others have said, typing is about how the underlying memory is
>>> treated.
>>
>> No. It is much
On Mon, Feb 19, 2018 at 9:24 PM, Steven D'Aprano
wrote:
> On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
>
>> Tim Delaney writes:
>>
>> [...]
>>> As others have said, typing is about how the underlying memory is
>>>
Chris Angelico writes:
> On Mon, Feb 19, 2018 at 9:04 PM, Alain Ketterlin
> wrote:
>> Look at the C11 standard, section 6.3.2.3 ("Pointers"), 6.5.§6-7
>> ("effective types"), and 6.5.3.2 ("Address and indirection operators").
>> It
On Mon, 19 Feb 2018 09:40:09 +0100, Alain Ketterlin wrote:
> Tim Delaney writes:
>
> [...]
>> As others have said, typing is about how the underlying memory is
>> treated.
>
> No. It is much more than that. Typing is about everything you can say
> about a given
On Mon, Feb 19, 2018 at 9:04 PM, Alain Ketterlin
wrote:
> Chris Angelico writes:
>
>> On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
>> wrote:
>
>>> No. C has much stronger rules, not on
On Mon, Feb 19, 2018 at 8:36 PM, Antoon Pardon wrote:
> On 17-02-18 21:11, Chris Angelico wrote:
>> On Sun, Feb 18, 2018 at 1:47 AM, Ian Kelly wrote:
>>> On Fri, Feb 16, 2018 at 9:32 PM, Chris Angelico wrote:
You'd be surprised
Chris Angelico writes:
> On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
> wrote:
>> No. C has much stronger rules, not on casting, but on accessing the
>> pointees, which basically invalidates your argument. Refer to the C
>>
On 2/19/2018 4:14 AM, Chris Angelico wrote:
On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
wrote:
Tim Delaney writes:
C is statically and weakly typed. Variables know their types at compile
time (static typing). It is
On 17-02-18 21:11, Chris Angelico wrote:
> On Sun, Feb 18, 2018 at 1:47 AM, Ian Kelly wrote:
>> On Fri, Feb 16, 2018 at 9:32 PM, Chris Angelico wrote:
>>> You'd be surprised how rarely that kind of performance even matters.
>>> The author of that article
On Mon, Feb 19, 2018 at 7:40 PM, Alain Ketterlin
wrote:
> Tim Delaney writes:
>> C is statically and weakly typed. Variables know their types at compile
>> time (static typing). It is a feature of the language that you can
Tim Delaney writes:
[...]
> As others have said, typing is about how the underlying memory is treated.
No. It is much more than that. Typing is about everything you can say
about a given statement. Some type systems are focusing on type labels
only (like most
On Mon, 19 Feb 2018 04:26:32 +0100, Anders Wegge Keller wrote:
> På Mon, 19 Feb 2018 08:47:14 +1100
> Tim Delaney skrev:
>> On 18 February 2018 at 22:55, Anders Wegge Keller
>> wrote:
>
>
>> > That list is not only weakly typed, but rather
On Mon, 19 Feb 2018 02:14:26 +, bartc wrote:
> On 19/02/2018 00:09, Steven D'Aprano wrote:
>
>> Sure, but only the most boring, uninteresting kinds of types can be so
>> named. The point is that "sufficiently fine-grained types" can be
>> arbitrarily complex.
>
> I don't think so.
That's
1 - 100 of 155 matches
Mail list logo