On Monday, 17 December 2012 at 01:14:37 UTC, Walter Bright wrote:
On 12/16/2012 3:24 PM, SomeDude wrote:
Proof is, it seems to me that you (Isaac Gouy) often come
around here. We can
magically invoke you every time one talks about the shootout.
Which is pretty
astonishing for a language you ar
On 12/16/2012 3:24 PM, SomeDude wrote:
Proof is, it seems to me that you (Isaac Gouy) often come around here. We can
magically invoke you every time one talks about the shootout. Which is pretty
astonishing for a language you aren't interested in.
Not really. You can set Google to email you whe
On Sun, Dec 16, 2012 at 04:45:31PM +0100, jerro wrote:
> >if, say, GDC was granted to come back in the shootout. Given it's
> >now widely acknowledged (at least in the programming communities)
> >to be one of the most promising languages around...
>
> And especially if you also consider the fact t
On Sunday, 16 December 2012 at 19:59:31 UTC, Isaac Gouy wrote:
On Sunday, 16 December 2012 at 15:45:32 UTC, jerro wrote:
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the programming
communities) to be one of the most promising languages
On Sunday, 16 December 2012 at 23:21:15 UTC, SomeDude wrote:
On Sunday, 16 December 2012 at 19:59:31 UTC, Isaac Gouy wrote:
On Sunday, 16 December 2012 at 15:45:32 UTC, jerro wrote:
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the progra
On Sunday, 16 December 2012 at 13:05:50 UTC, SomeDude wrote:
-snip-
Was it something the compiler writers told you?
Probably bearophile meant that...
I can make my own guesses, but I wanted to know what bearophile
meant so I asked him ;-)
On Sunday, 16 December 2012 at 15:45:32 UTC, jerro wrote:
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the programming
communities) to be one of the most promising languages
around...
And especially if you also consider the fact that t
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the programming
communities) to be one of the most promising languages around...
And especially if you also consider the fact that there Clean and
ATS are in the shootout and I'm guessing tha
On Saturday, 15 December 2012 at 17:11:01 UTC, Isaac Gouy wrote:
On Tuesday, 11 December 2012 at 23:59:29 UTC, bearophile wrote:
-snip-
But as usual you have to take such comparisons cum grano
salis, because there are a lot more people working on the GHC
compiler and because the Shootout Hask
On Tuesday, 11 December 2012 at 23:59:29 UTC, bearophile wrote:
-snip-
But as usual you have to take such comparisons cum grano salis,
because there are a lot more people working on the GHC compiler
and because the Shootout Haskell solutions are quite
un-idiomatic (you can see it also from th
On 12/13/2012 10:28 PM, SomeDude wrote:
On Thursday, 13 December 2012 at 01:51:27 UTC, Timon Gehr wrote:
Certainly, you can argue that the faster version should be in a
prominent place in the standard library, but the fact that it is not
does not indicate a fundamental performance problem in th
On 12/13/2012 09:09 PM, SomeDude wrote:
On Wednesday, 12 December 2012 at 20:01:43 UTC, Timon Gehr wrote:
On 12/12/2012 03:45 AM, Walter Bright wrote:
On 12/11/2012 5:05 PM, bearophile wrote:
Walter Bright:
ML has been around for 30-40 years, and has failed to catch on.
OcaML, Haskell, F#,
nevermind, i've lost the whole idea...
On Friday, 14 December 2012 at 08:04:55 UTC, Han wrote:
Then put up a real-time tracking chart of that on the D
website: "The
popularity of D vs. the popularity of The Beatles". I think
what you
answered goes to show the level of dissillusionment of (or
shamefully
insulting level of propagand
xenon325 wrote:
> On Wednesday, 12 December 2012 at 08:25:04 UTC, Han wrote:
>> Walter Bright wrote:
>>> Overlooked is the previous 10 years the band struggled in
>>> obscurity.
>>
>> You KNOW that D has not been "overlooked". Developers and users
>> with
>> applications give it a look (the former
On Thursday, 13 December 2012 at 21:28:52 UTC, SomeDude wrote:
On Thursday, 13 December 2012 at 01:51:27 UTC, Timon Gehr wrote:
And
if the standard library is twice as slow in implementation A
than in implemention B, then most programs will feel *at least*
twice as slow, and usually more, beca
On 12/13/2012 4:46 AM, Timon Gehr wrote:
Now they certainly are.
http://d.puremagic.com/issues/show_bug.cgi?id=9148
The following you can close if you think 'const' should not guarantee no
mutation. It does not break other parts of the type system:
http://d.puremagic.com/issues/show_bug.cgi?id=
On Thursday, 13 December 2012 at 01:51:27 UTC, Timon Gehr wrote:
Certainly, you can argue that the faster version should be in a
prominent place in the standard library, but the fact that it
is not does not indicate a fundamental performance problem in
the Haskell language. Also, note that I
On Thursday, 13 December 2012 at 01:32:23 UTC, bearophile wrote:
Walter Bright:
Java makes no attempt to detect integer overflows.
There are various kinds of code. In some kinds of programs you
want to be more sure that the result is correct, while other
kinds of programs this need is less
On Wednesday, 12 December 2012 at 20:01:43 UTC, Timon Gehr wrote:
On 12/12/2012 03:45 AM, Walter Bright wrote:
On 12/11/2012 5:05 PM, bearophile wrote:
Walter Bright:
ML has been around for 30-40 years, and has failed to catch
on.
OcaML, Haskell, F#, and so on are all languages derived more
On 12/13/2012 04:54 AM, Walter Bright wrote:
On 12/12/2012 5:16 PM, Timon Gehr wrote:
On 12/13/2012 12:43 AM, Walter Bright wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
It is somewhat similar to (the still quite broken) 'pure' in D,
Broken how?
- There is no way to specify that a deleg
On Wednesday, 12 December 2012 at 08:25:04 UTC, Han wrote:
Walter Bright wrote:
Overlooked is the previous 10 years the band struggled in
obscurity.
You KNOW that D has not been "overlooked". Developers and users
with
applications give it a look (the former mostly) and then choose
something
SomeDude wrote:
> On Wednesday, 12 December 2012 at 08:04:07 UTC, Han wrote:
>> Walter Bright wrote:
>>> On 12/11/2012 10:35 PM, Han wrote:
Walter Bright wrote:
> I'm interested in crafting D to be a language that people
> will like
> and use.
Does that statement, th
On Wednesday, 12 December 2012 at 21:05:05 UTC, Walter Bright
wrote:
On 12/12/2012 2:53 AM, foobar wrote:
One example that comes to mind is the
future version of JavaScript is implemented in ML.
Um, there are many implementations of Javascript. In fact, I
have implemented it in both C++ and D
it's both very fast (C++-class fast, faster than Java on
certain kinds of code, if well used) and apparently quite safer
Last I tried OCaml, "well used" in context of performance would
mean avoiding many useful abstractions. One thing I remember is
that using functors always has run time cost
SomeDude wrote:
> On Wednesday, 12 December 2012 at 08:04:07 UTC, Han wrote:
>> Walter Bright wrote:
>>> On 12/11/2012 10:35 PM, Han wrote:
Walter Bright wrote:
> I'm interested in crafting D to be a language that people
> will like
> and use.
Does that statement, th
On Wednesday, 12 December 2012 at 08:04:07 UTC, Han wrote:
Walter Bright wrote:
On 12/11/2012 10:35 PM, Han wrote:
Walter Bright wrote:
I'm interested in crafting D to be a language that people
will like
and use.
Does that statement, then, represent a change in direction
for the D
project
On 12/12/2012 5:16 PM, Timon Gehr wrote:
On 12/13/2012 12:43 AM, Walter Bright wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
It is somewhat similar to (the still quite broken) 'pure' in D,
Broken how?
- There is no way to specify that a delegate is strongly pure without resorting
to type
On 12/12/2012 5:32 PM, bearophile wrote:
One "important" firm uses OcaML for high speed trading because it's both very
fast (C++-class fast, faster than Java on certain kinds of code, if well used)
and apparently quite safer to use than C/C++. And it's harder to find OcaML
programmers than C++ on
On 12/12/2012 5:51 PM, Timon Gehr wrote:
A significant part of the D code is spent arranging data into the right layout,
while the Haskell code does nothing like that.
So, please take the bait :-) and write a Haskell version that runs faster than
the D one.
On 12/13/2012 12:47 AM, Walter Bright wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
On 12/12/2012 10:35 PM, Walter Bright wrote:
some algorithms are doomed to be slower.
Here's a (real) quicksort:
http://stackoverflow.com/questions/5268156/how-do-you-do-an-in-place-quicksort-in-haskell
O
Walter Bright:
Java makes no attempt to detect integer overflows.
There are various kinds of code. In some kinds of programs you
want to be more sure that the result is correct, while other
kinds of programs this need is less strong.
I personally know people who write high speed trading s
On 12/13/2012 12:43 AM, Walter Bright wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
It is somewhat similar to (the still quite broken) 'pure' in D,
Broken how?
- There is no way to specify that a delegate is strongly pure without
resorting to type deduction, because
- Member functions
On Wednesday, 12 December 2012 at 06:19:14 UTC, Walter Bright
wrote:
You're not going to get performance with overflow checking even
with the best compiler support. For example, much arithmetic
code is generated for the x86 using addressing mode
instructions, like:
LEA EAX,16[8*EBX][ECX]
On Wednesday, 12 December 2012 at 23:47:26 UTC, Walter Bright
wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
On 12/12/2012 10:35 PM, Walter Bright wrote:
some algorithms are doomed to be slower.
Here's a (real) quicksort:
http://stackoverflow.com/questions/5268156/how-do-you-do-an-in-place-q
On 12/12/2012 3:29 PM, Timon Gehr wrote:
On 12/12/2012 10:25 PM, Walter Bright wrote:
On 12/12/2012 4:51 AM, Araq wrote:
...
So how does D improve on C's model? If signed integers are required to
wrap
around in D (no undefined behaviour), you also prevent some otherwise
possible
optimizations (
On 12/12/2012 3:23 PM, Timon Gehr wrote:
On 12/12/2012 10:35 PM, Walter Bright wrote:
some algorithms are doomed to be slower.
Here's a (real) quicksort:
http://stackoverflow.com/questions/5268156/how-do-you-do-an-in-place-quicksort-in-haskell
Ok, I'll bite.
Here's a program in Haskell and
On 12/12/2012 3:23 PM, Timon Gehr wrote:
It is somewhat similar to (the still quite broken) 'pure' in D,
Broken how?
Provided the code is correct.
No language or compiler can prove code correct.
On 12/12/2012 10:25 PM, Walter Bright wrote:
On 12/12/2012 4:51 AM, Araq wrote:
...
So how does D improve on C's model? If signed integers are required to
wrap
around in D (no undefined behaviour), you also prevent some otherwise
possible
optimizations (there is a reason it's still undefined beh
On 12/12/2012 10:35 PM, Walter Bright wrote:
On 12/12/2012 12:01 PM, Timon Gehr wrote:
That is certainly fixable. It is a mere QOI issue.
When you have a language that fundamentally disallows mutation,
It does not.
some algorithms are doomed to be slower.
Here's a (real) quicksort:
http:
On 12/12/2012 2:17 PM, bearophile wrote:
Two comments:
- I've seen Facebook start from PHP, go to PHP compiled in some ways, and lately
start to switch to faster languages, so when you have tons of servers space and
electricity used by CPUs becomes important for the bottom line. On the other
hand
On Wednesday, 12 December 2012 at 22:36:35 UTC, ixid wrote:
On Wednesday, 12 December 2012 at 21:27:35 UTC, Walter Bright
wrote:
On 12/12/2012 3:12 AM, foobar wrote:
Regarding performance and overflow checking, the example you
give is x86
specific. What about other platforms? For example ARM is
On Wednesday, 12 December 2012 at 21:27:35 UTC, Walter Bright
wrote:
On 12/12/2012 3:12 AM, foobar wrote:
Regarding performance and overflow checking, the example you
give is x86
specific. What about other platforms? For example ARM is very
popular nowadays
in the mobile world and there are man
Walter Bright:
Consider running a server farm. If you can make your code 5%
faster, you need 5% fewer servers. That translates into
millions of dollars.
Two comments:
- I've seen Facebook start from PHP, go to PHP compiled in some
ways, and lately start to switch to faster languages, so when
Even OOP possible in asm.
It's completely OT ;)
On Wednesday, 12 December 2012 at 21:51:00 UTC, Michael wrote:
Thread (and etc) is a high level abstraction that requires a
support by hardware/software/instruction set.
And you can do happily multi-threading on a single processor,
with no parallelization and so on. It is just time-slicing. Th
Thread (and etc) is a high level abstraction that requires a
support by hardware/software/instruction set.
Not only. First of all, it requires that the compiler *knows* and
*understands* the concept of thread. This is why C mimicking C++
will *never* get as fast as a true C++ compiler, for the
Thread (and etc) is a high level abstraction that requires a
support by hardware/software/instruction set. If it necessary,
library can be integrated to language. And it's another one
question about design.
On 12/12/2012 12:01 PM, Timon Gehr wrote:
That is certainly fixable. It is a mere QOI issue.
When you have a language that fundamentally disallows mutation, some algorithms
are doomed to be slower. I asked Erik Maijer, one of the developers of Haskell,
if the implementation does mutation "unde
On 12/12/2012 3:12 AM, foobar wrote:
Regarding performance and overflow checking, the example you give is x86
specific. What about other platforms? For example ARM is very popular nowadays
in the mobile world and there are many more smart-phones out there than there
are PCs. Is the same issue exi
On 12/12/2012 4:51 AM, Araq wrote:
From http://embed.cs.utah.edu/ioc/
" Examples of undefined integer overflows we have reported:
An SQLite bug
Some problems in SafeInt
GNU MPC
PHP
Firefox
GCC
PostgreSQL
LLVM
Python
We also reported bugs to BIND an
For each platform developer have solution as library. Right way
is creating something new instead cutting something that exist.
Moving some of the things to from the library to the language is
hard and limitating, but sometimes it worths the effort.
An example: threads. C/C++ have those as ex
On 12/12/2012 2:53 AM, foobar wrote:
One example that comes to mind is the
future version of JavaScript is implemented in ML.
Um, there are many implementations of Javascript. In fact, I have implemented it
in both C++ and D.
I read all thread and conclude that developers want a one button
- 'do all what I need'.
As mentioned above, for example, python have a arbitrary int
(that implemented as C library ;)).
C can be used on many platforms. For each platform developer have
solution as library. Right way is creati
On 12/12/2012 03:45 AM, Walter Bright wrote:
On 12/11/2012 5:05 PM, bearophile wrote:
Walter Bright:
ML has been around for 30-40 years, and has failed to catch on.
OcaML, Haskell, F#, and so on are all languages derived more or less
directly
from ML, that share many of its ideas. Has Haskel
OTOH, I *never* asked for compulsory promotion, just mimicking
it. (in fact, I was not asking for anything, just addressed a
question) The idea is to guarantee, by the compiler, that the
final result of an integral arithmetic expression is AS IF all
integrals there are promoted to some widest
On Wednesday, 12 December 2012 at 14:39:40 UTC, Michael wrote:
Machine/hardware have a explicitly defined register size and
does know nothing about sign and data type. fastest operation
is unsigned and fits to register size.
Frankly, the hardware knows nothing about classes and about
virtual
On Wednesday, 12 December 2012 at 08:00:09 UTC, Walter Bright
wrote:
On 12/11/2012 11:53 PM, Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch
on.
Isn't D on that same historical path?
Many languages wa
On Wednesday, 12 December 2012 at 02:44:42 UTC, Walter Bright
wrote:
UDAs are a primo example of this.
OT: Why those are not allowed on module decls and local decls? We
can't use UDAs on decls in unittest blocks. We can't use a UDA to
mark a module reflectable, can't put an attribute on a
"v
And about C# checked:
http://msdn.microsoft.com/ru-ru/library/74b4xzyw.aspx
By default it is only for constants. For expressions in runtime
it must be explicitly enabled.
en link: http://msdn.microsoft.com/en-us/library/74b4xzyw.aspx
Machine/hardware have a explicitly defined register size and does
know nothing about sign and data type. fastest operation is
unsigned and fits to register size.
For example in your case, some algorithm that coded with
chained-if-checks may come unusable because it will slow.
And about C# ch
Araq:
So how does D improve on C's model?
There is some range analysis on shorter integral values. But
overall it shares the same troubles.
If signed integers are required to wrap around in D (no
undefined behaviour),
I think in D specs signed integers don't require the wrap-around
(so
foobar:
So basically you're suggesting to implement Integer and Word
library types using compiler intrinsics as a way to migrate to
better ML compatible semantics.
I think there were no references to ML in that part of Walter
answer.
Regarding performance and overflow checking, the exampl
Arithmetic in computers is different from the math you learned
in school. It's 2's complement, and it's best to always keep
that in mind when writing programs.
From http://embed.cs.utah.edu/ioc/
" Examples of undefined integer overflows we have reported:
An SQLite bug
Some problems in
On Wednesday, 12 December 2012 at 10:35:26 UTC, Walter Bright
wrote:
On 12/12/2012 2:33 AM, foobar wrote:
This isn't a perfect solutions
since the compiler has builtin knowledge about int and does
optimizations that
will be lost with a library type.
See my reply to bearophile about that.
Y
On Wednesday, 12 December 2012 at 00:51:19 UTC, Walter Bright
wrote:
On 12/11/2012 3:44 PM, foobar wrote:
Thanks for proving my point. after all , you are a C++
developer, aren't you? :)
No, I'm an assembler programmer. I know how the machine works,
and C, C++, and D map onto that, quite deli
On 12/12/2012 2:33 AM, foobar wrote:
This isn't a perfect solutions
since the compiler has builtin knowledge about int and does optimizations that
will be lost with a library type.
See my reply to bearophile about that.
On Wednesday, 12 December 2012 at 00:43:39 UTC, H. S. Teoh wrote:
On Wed, Dec 12, 2012 at 01:26:08AM +0100, foobar wrote:
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile
wrote:
>foobar:
>
>>I would enforce overflow and underflow checking semantics.<
>
>Plus one or two switches to dis
I implement, say, a Matrix class, then I should be able to tell
the
compiler that certain Matrix expressions, say A*B+A*C, can be
factored
into A*(B+C), and have the optimizer automatically do this for
me based
on what is defined in the type. Or specify that
write("a");writeln("b");
can be repl
Hai :D I have seen your D program language on Google, it looks
cool! how much different is it to the C program language?
Han wrote:
> Walter Bright wrote:
>> On 12/11/2012 11:53 PM, Walter Bright wrote:
>>> On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
> ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
>>>
>>> Many languages wander
On 12/12/2012 12:27 AM, Han wrote:
You KNOW that D has not been "overlooked".
No, I don't know that. I just returned from a conference where few knew anything
at all about D, and were quite impressed by what I had to show.
> Do you really think that D will ever have popularity to the level o
On 12/12/2012 12:07 AM, Han wrote:
So you are skirting the issue then, or going to come back and post a real
answer after you think about it some more?
Or are you just trolling and baiting?
Walter Bright wrote:
> On 12/11/2012 11:53 PM, Walter Bright wrote:
>> On 12/11/2012 11:47 PM, Han wrote:
>>> Walter Bright wrote:
>>>
ML has been around for 30-40 years, and has failed to catch on.
>>>
>>> Isn't D on that same historical path?
>>
>> Many languages wander in the wilderness for
Walter Bright wrote:
> On 12/11/2012 11:47 PM, Han wrote:
>> Walter Bright wrote:
>>
>>> ML has been around for 30-40 years, and has failed to catch on.
>>
>> Isn't D on that same historical path?
>
> Many languages wander in the wilderness for years before they catch
> on.
Wow (Wow!), it's like y
On 12/11/2012 11:53 PM, Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
Many languages wander in the wilderness for years before they catch on.
BTW, many ro
Walter Bright wrote:
> On 12/11/2012 10:35 PM, Han wrote:
>> Walter Bright wrote:
>>
>>> I'm interested in crafting D to be a language that people will like
>>> and use.
>>
>> Does that statement, then, represent a change in direction for the D
>> project? How long will this "crafting" take? Has th
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
Many languages wander in the wilderness for years before they catch on.
Walter Bright wrote:
> ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path? One-third to one-fourth of the way...
to, um, where exactly? Follow the yellow brick road? All roads lead to The
Land of Oz? (I couldn't resist the analogy!). Seriously t
On 12/11/2012 10:35 PM, Han wrote:
Walter Bright wrote:
I'm interested in crafting D to be a language that people will like
and use.
Does that statement, then, represent a change in direction for the D
project? How long will this "crafting" take? Has this "crafting" been
already going on now
Walter Bright wrote:
> I'm interested in crafting D to be a language that people will like
> and use.
Does that statement, then, represent a change in direction for the D
project? How long will this "crafting" take? Has this "crafting" been
already going on now for a decade? More than a decade?
On 12/11/2012 9:51 PM, David Piepgrass wrote:
The problem, as I see it, is nobody actually cares about this. Why would I say
something so provocative? Because I've seen D programmers go to herculean
lengths to get around problems they are having in the language. These efforts
make a strong case t
David Piepgrass:
I do want overflow detection, yet I would not use a CheckedInt
in D for the same reason I do not usually use one in C++:
without compiler support, it is too expensive to detect
overflow.
Here I have listed several problems in a library-defined SafeInt,
but Walter has expres
The problem, as I see it, is nobody actually cares about this.
Why would I say something so provocative? Because I've seen D
programmers go to herculean lengths to get around problems they
are having in the language. These efforts make a strong case
that they need better language support (UDAs
On 12/11/2012 8:42 PM, d coder wrote:
Where can I learn more about this library Manu is developing?
Manu posts here, reply to him!
On Wednesday, 12 December 2012 at 04:42:57 UTC, d coder wrote:
On Wed, Dec 12, 2012 at 8:14 AM, Walter Bright
wrote:
(This is how the high level vector library Manu is
implementing is done.)
Greetings
Where can I learn more about this library Manu is developing?
regards
- Puneet
The cod
On Wed, Dec 12, 2012 at 8:14 AM, Walter Bright
wrote:
> (This is how the high level vector library Manu is implementing is done.)
>
Greetings
Where can I learn more about this library Manu is developing?
regards
- Puneet
Walter Bright:
The way to deal with this is to examine the implementation of
CheckedInt, and design a couple of compiler intrinsics to use
in its implementation that will eliminate the asm code.
OK, good. I didn't think of this option.
Using intrinsics deals with this issue nicely, as the o
On 12/11/2012 5:05 PM, bearophile wrote:
Walter Bright:
ML has been around for 30-40 years, and has failed to catch on.
OcaML, Haskell, F#, and so on are all languages derived more or less directly
from ML, that share many of its ideas. Has Haskell caught on? :-)
Haskell is the language tha
On 12/11/2012 5:15 PM, bearophile wrote:
Regarding safeInt I think today there is no way to write it efficiently in D,
because the overflow flags are not accessible from D, and if you use inlined
asm, you lose inlining in DMD. This is just one of the problems.
The way to deal with this is to ex
On Wed, Dec 12, 2012 at 02:15:24AM +0100, bearophile wrote:
> H. S. Teoh:
>
> >Just because you specify a certain compiler switch, it can cause
> >unrelated breakage in some obscure library somewhere, that assumes
> >modular arithmetic with C/C++ semantics.
>
> The idea was about two switches, on
H. S. Teoh:
Just because you specify a certain compiler switch, it can cause
unrelated breakage in some obscure library somewhere, that
assumes modular arithmetic with C/C++ semantics.
The idea was about two switches, one for signed integrals, and
the other for both signed and unsigned. But
Walter Bright:
ML has been around for 30-40 years, and has failed to catch on.
OcaML, Haskell, F#, and so on are all languages derived more or
less directly from ML, that share many of its ideas. Has Haskell
caught on? :-)
Bye,
bearophile
On 12/11/2012 4:06 PM, bearophile wrote:
Plus one or two switches to disable such checking, if/when someone wants it, to
regain the C performance. (Plus some syntax way to disable/enable such checking
in a small piece of code).
I.e. the C# "solution".
1. The global switch "solution": What I ha
On 12/11/2012 3:44 PM, foobar wrote:
Thanks for proving my point. after all , you are a C++ developer, aren't you? :)
No, I'm an assembler programmer. I know how the machine works, and C, C++, and D
map onto that, quite deliberately. It's one reason why D supports the vector
types directly.
On Wed, Dec 12, 2012 at 01:26:08AM +0100, foobar wrote:
> On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile wrote:
> >foobar:
> >
> >>I would enforce overflow and underflow checking semantics.<
> >
> >Plus one or two switches to disable such checking, if/when someone
> >wants it, to regain
On 12/11/2012 3:15 PM, deadalnix wrote:
That's irrelevant to this discussion. It is not a problem with the language.
Anyone can improve the library one if they desire, or do their own.
The library is part of the language. What is a language with no vocabulary ?
I think it is useful to draw a d
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile wrote:
foobar:
I would enforce overflow and underflow checking semantics.<
Plus one or two switches to disable such checking, if/when
someone wants it, to regain the C performance. (Plus some
syntax way to disable/enable such checki
foobar:
I would enforce overflow and underflow checking semantics.<
Plus one or two switches to disable such checking, if/when
someone wants it, to regain the C performance. (Plus some syntax
way to disable/enable such checking in a small piece of code).
Maybe someday Walter will change hi
Walter Bright:
I don't notice anyone reaching for Lisp or Ocaml for high
performance applications.
Nowadays CommonLisp is not used much for anything (people at ITA
use it to plan flights, their code is efficient, algorithmically
complex, and used for heavy loads).
OCaML on the other hand i
1 - 100 of 121 matches
Mail list logo
