Re: DDT 0.5.0 (Creamfields) released
On Thu, 22 Sep 2011 06:47:18 +, Bernard Helyer wrote: I was wrong about the multiple editor thing, but you were spot on about the folding. Disabling it made all the hitches go away. Thanks. Spoke too soon. It seems to be related to errors parsing or something. I'll try and get you a test case.
Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff
Am 22.09.2011 02:38, schrieb Walter Bright: nsightly vector classes in C++, but fortunately using vendor specific compiler intrinsics usually leads to decent code generation. I can currently imagine an equally ugly (possibly worse) hardware vector library in D, if it's even possible. But perhaps I've missed something here? Your C++ vector code should be amenable to translation to D, so that effort of yours isn't lost, except that it'd have to be in inline asm rather than intrinsics. I recently tried that, and I couldn't do it because D has no way of aligning structs on the stack. Manually allocating the neccessary aligned memroy is also not always possible because it can not be done for compiler temporary variables: vec4 v1 = func1(); vec4 v2 = func2(); vec4 result = (v1 + v2) * 0.5f; Even if I manually allocate v1,v2 and result, the temporary variable that the compiler uses to compute the expression might be unaligned. That is a total killer for SSE optimizations because you can not hide them away. Does DMC++ have __declspec(align(16)) support? -- Kind Regards Benjamin Thaut
thoughts on immutability in D
The initial submission got junked so I resubmitted: http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/ Andrei
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On 22.09.2011 05:24, a wrote:
How would one do something like this without intrinsics (the code is c++ using
gcc vector extensions):
[snip]
At present, you can't do it without ultimately resorting to inline asm.
But, what we've done is to move SIMD into the machine model: the D
machine model assumes that float[4] + float[4] is a more efficient
operation than a loop.
Currently, only arithmetic operations are implemented, and on DMD at
least, they're still not proper intrinsics. So in the long term it'll be
possible to do it directly, but not yet.
At various times, several of us have implemented 'swizzle' using CTFE,
giving you a syntax like:
float[4] x, y;
x[] = y[].swizzle!cdcd();
// x[0]=y[2], x[1]=y[3], x[2]=y[2], x[3]=y[3]
which compiles to a single shufps instruction.
That cdcd string is really a tiny DSL: the language consists of four
characters, each of which is a, b, c, or d.
A couple of years ago I made a DSL compiler for BLAS1 operations. It was
capable of doing some pretty wild stuff, even then. (The DSL looked like
normal D code).
But the compiler has improved enormously since that time. It's now
perfectly feasible to make a DSL for the SIMD operations you need.
The really nice thing about this, compared to normal asm, is that you
have access to the compiler's symbol table. This lets you add
compile-time error messages, for example.
A funny thing about this, which I found after working on the DMD
back-end, is that is MUCH easier to write an optimizer/code generator in
a DSL in D, than in a compiler back-end.
templateclass V
struct Fft
{
typedef typename V::T T;
typedef typename V::vec vec;
static const int VecSize = V::Size;
...
templateint Interleaved
static NOINLINE void fft_pass_interleaved(
vec * __restrict pr,
vec *__restrict pi,
vec *__restrict pend,
T *__restrict table)
{
for(; pr pend; pr += 2, pi += 2, table += 2*Interleaved)
{
vec tmpr, ti, ur, ui, wr, wi;
V::template expandComplexArrayToRealImagVecInterleaved(table, wr, wi);
V::template deinterleaveInterleaved(pr[0],pr[1], ur, tmpr);
V::template deinterleaveInterleaved(pi[0],pi[1], ui, ti);
vec tr = tmpr*wr - ti*wi;
ti = tmpr*wi + ti*wr;
V::template interleaveInterleaved(ur + tr, ur - tr, pr[0], pr[1]);
V::template interleaveInterleaved(ui + ti, ui - ti, pi[0], pi[1]);
}
}
...
Here vector elements need to be shuffled around when they are loaded and stored.
This is platform dependent and cannot be expressed through vector operations
(or gcc vector extensions). Here I abstracted platform dependent functionality
in member functions of V, which are implemented using intrinsics. The assembly
generated for SSE single precision and Interleaved=4 is:
_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf:
0: 48 39 d7cmp%rdx,%rdi
3: 0f 83 9c 00 00 00 jae
a5_ZN3FftI6SSEVecIfEE20fft_pass_interleavedILi4EEEvPDv4_fS5_S5_Pf+0xa5
9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
10: 0f 28 19movaps (%rcx),%xmm3
13: 0f 28 41 10 movaps 0x10(%rcx),%xmm0
17: 48 83 c1 20 add$0x20,%rcx
1b: 0f 28 f3movaps %xmm3,%xmm6
1e: 0f 28 2fmovaps (%rdi),%xmm5
21: 0f c6 d8 dd shufps $0xdd,%xmm0,%xmm3
25: 0f c6 f0 88 shufps $0x88,%xmm0,%xmm6
29: 0f 28 e5movaps %xmm5,%xmm4
2c: 0f 28 47 10 movaps 0x10(%rdi),%xmm0
30: 0f 28 4e 10 movaps 0x10(%rsi),%xmm1
34: 0f c6 e0 88 shufps $0x88,%xmm0,%xmm4
38: 0f c6 e8 dd shufps $0xdd,%xmm0,%xmm5
3c: 0f 28 06movaps (%rsi),%xmm0
3f: 0f 28 d0movaps %xmm0,%xmm2
42: 0f c6 c1 dd shufps $0xdd,%xmm1,%xmm0
46: 0f c6 d1 88 shufps $0x88,%xmm1,%xmm2
4a: 0f 28 cdmovaps %xmm5,%xmm1
4d: 0f 28 f8movaps %xmm0,%xmm7
50: 0f 59 cemulps %xmm6,%xmm1
53: 0f 59 fbmulps %xmm3,%xmm7
56: 0f 59 c6mulps %xmm6,%xmm0
59: 0f 59 ddmulps %xmm5,%xmm3
5c: 0f 5c cfsubps %xmm7,%xmm1
5f: 0f 58 c3addps %xmm3,%xmm0
62: 0f 28 dcmovaps %xmm4,%xmm3
65: 0f 5c d9subps %xmm1,%xmm3
68: 0f 58 ccaddps %xmm4,%xmm1
6b: 0f 28 e1movaps %xmm1,%xmm4
6e: 0f 15 cbunpckhps %xmm3,%xmm1
71: 0f 14 e3unpcklps %xmm3,%xmm4
74: 0f 29 4f 10 movaps %xmm1,0x10(%rdi)
78: 0f 28 camovaps %xmm2,%xmm1
7b: 0f 29 27movaps %xmm4,(%rdi)
7e: 0f 5c c8subps %xmm0,%xmm1
81: 48 83 c7 20 add$0x20,%rdi
85: 0f 58 c2addps
Re: Anonymous function syntax
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered. It would be awesome if D
infered argument types for labdas too.
Also Java 8 adopted the same lambda syntax as Scala and C#.
To add a few things to your list:
Nemerle
fun (x, y) { x + y }
(x, y) = x + y
Scala and Nemerle supports placeholder lambda syntax
_ + _
Scheme
(lambda (x y) (+ x y))
Smalltalk
[ :x :y | x + y ]
ML/Ocaml/F#
fun x y - x + y
Ruby has a whole zoo of syntaxes
{|x, y| x + y }
-(x, y) { x + y }
do |x, y| x + y end
Groovy
{ x, y - x + y }
So (args) = body is the most common syntax now
Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff
Manu Wrote: I'd love to try out D on some console systems. Fortunately there are some great home-brew scenes available for a bunch of slightly older consoles; PSP/PS2 (MIPS), XBox1 (embedded x86), GameCube/Wii (PPC), Dreamcast (SH4). They all have GCC compilers maintained by the community. How difficult will it be to make GDC work with those toolchains? Sadly I know nothing about configuring GCC, so sadly I can't really help here. http://pspemu.soywiz.com/2011/07/fourth-release-d-pspemu-r301.html Maybe this man can be of some help for you.
Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff
On 9/21/2011 10:56 PM, Benjamin Thaut wrote: Even if I manually allocate v1,v2 and result, the temporary variable that the compiler uses to compute the expression might be unaligned. That is a total killer for SSE optimizations because you can not hide them away. Does DMC++ have __declspec(align(16)) support? No, but 64 bit DMD aligns the stack on 16 byte boundaries.
Re: Anonymous function syntax
On 9/21/2011 8:10 PM, Jesse Phillips wrote:
On Wed, 21 Sep 2011 18:29:34 -0400, bearophile wrote:
Walter Bright:
D
(a,b) { return a + b; }
In D to define a true lambda you need types too: auto f = (int a,int b){
return a + b; };
This is true of C# too and I think is appropriate to mention, though it
can take the destination type into account when doing inference.
As Andrei pointed out, it is not true of D, since D does not require the types
for the parameters.
Re: Anonymous function syntax
On 9/21/2011 11:47 PM, Max Klyga wrote: It would be awesome if D infered argument types for labdas too. It does, and it is awesome!
Re: Anonymous function syntax
Perhaps bearofile refers to this:
import std.stdio;
string getit(alias runme)() {
return runme(b,da);
}
string getit2(string delegate(string,string) dg) {
return dg(b, da);
}
void main() {
writefln(this is a %s, getit!((a,b){ return lam~a~b; })());
/+writefln(this is a %s too, getit2((a,b){ return lam~a~b; }));
/*lambdas.d(13): Error: undefined identifier a
lambdas.d(13): Error: undefined identifier b
lambdas.d(13): Error: function lambdas.getit2 (string
delegate(string, string) dg) is not callable using argument types (_error_
delegate(_error_, _error_))
lambdas.d(13): Error: cannot implicitly convert expression
(__dgliteral4) of type _error_ delegate(_error_, _error_) to string
delegate(string, string)
*/
+/
writefln(this is a %s too, getit2((string a, string b) { return
lam~a~b; }));
}
Cheers,
Rory
On Thu, Sep 22, 2011 at 12:50 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/21/11 5:29 PM, bearophile wrote:
Walter Bright:
D
(a,b) { return a + b; }
In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };
No.
Andrei
Re: thoughts on immutability in D
On 22/09/11 7:04 AM, Andrei Alexandrescu wrote: The initial submission got junked so I resubmitted: http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/ Andrei Thanks for the reddit'ing. I launched up google analytics this morning and noticed a sudden spike. That could only mean one thing :-) Out of interest, does anyone have any criticism of my post, esp. if there's any technical inaccuracies (or just disagreement?)
Re: Why do we have transitive const, again?
On Wednesday, September 21, 2011 10:15:31 Mehrdad wrote:
I can't find the thread, but I remember someone (bearophile?) mentioned
that the reason we have transitive const is to support purity.
I don't think I understand why this is necessary, though -- could
someone please explain why we have transitive const, and what problems
it fixes?
I believe that it comes down primarily to three things:
1. To provide strong compiler guarantees (unlike C++)
2. immutability
3. simplicity
Take this C++ code for example
class C
{
public:
vectorint* getter() const
{
return _var;
}
private:
vectorint* _var;
}
int func(const C c)
{
...
vectorint* v = c.getter();
*v[2] = 3;
...
}
c is const, and yet func changes its state. That makes it very difficult (if
not
impossible) for the compiler to give any guarantees about const beyond
complaining when you directly try and alter a const variable. So, the compiler
can't use const for optimizations or whatnot unless it's dealing with a
primitive type - even if there was no mutable and you couldn't cast away const
and alter variables.
Now, what if you add immutable into the mix? The compiler _must_ be able to
make guarantees about immutable. If the above were D code (with non-
transivitive const/immutable) with immutable, then the compiler couldn't
actually do anything useful with immutable, because it couldn't guarantee that
c was actually immutable. In order to do stuff like pass objects across threads
with send and receive, you must have compiler guarantees that the object is
actually immutable. And because anything which is const could actually be
immutable (aside from value types where there is no difference between const
and immutable), const must provide all of the guarantees that immutable does.
And so, they must both be transitive.
Now, on some level at least, we could avoid the need for fully transitive
const using some sort of tail and head const where we fully specified what was
and wasn't const or immutable. Stuff would still have to be fully immutable to
be passed along with functions like send and receive, and you'd lose some
optimizations when using head or tail const instead of fully transitive const,
but it could be done, and there are situations where it would be useful.
However, doing that gets far too complicated. It would make const too hard to
use. It was explored early in D2 and dropped precisely because of the
usability issues. Instead, we went with fully transitive const which could be
minimally restricted with parens.
- Jonathan M Davis
Re: Anonymous function syntax
Walter Bright , dans le message (digitalmars.D:144959), a écrit :
I've collected a few from various languages for comparison:
D
(a,b) { return a + b; }
Few ideas:
(a,b){ a + b }
Lambdas can avoid to type 'return'.
returning void would be harder, except if to return void, you can just
put the semicolon at the end (but it could be confusing).
a, b - a + b
Introduce a - operator to generate a delegate. Depending on the
precedence, (a,b) - (a + b) might be prefered. (a,b - a+b) will
be safer to use obviously. I prefer that instead of {a,b - a+b} because
the second adds a different meaning to {}, which is different from
statement grouping and function body.
The = symbol is fine too, but looks like a mistyped comparison
operator to me.
--
Christophe
Re: Anonymous function syntax
On 2011-09-22 00:50, Andrei Alexandrescu wrote:
On 9/21/11 5:29 PM, bearophile wrote:
Walter Bright:
D
(a,b) { return a + b; }
In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };
No.
Andrei
void foo (int delegate (int, int) a){}
void main ()
{
foo((a, b) { return a +b;});
}
Results in:
main.d(48): Error: undefined identifier a
main.d(48): Error: undefined identifier b
main.d(48): Error: function main.foo (int delegate(int, int) a) is not
callable using argument types (_error_ delegate(_error_, _error_))
main.d(48): Error: cannot implicitly convert expression (__dgliteral1)
of type _error_ delegate(_error_, _error_) to int delegate(int, int)
Failed: /Users/jacob/.dvm/bin/dvm-current-dc -v -o-
'/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d'
/Users/jacob/development/d/main.d.deps
--
/Jacob Carlborg
Re: Anonymous function syntax
On 2011-09-22 00:17, Walter Bright wrote:
I've collected a few from various languages for comparison:
D
(a,b) { return a + b; }
Ruby
-(a,b) { a + b }
C++0x
[](int a, int b) { return a + b; }
C#
(a,b) = a + b
Scala
(a:Int, b:Int) = a + b
Erlang
fun(a, b) - a + b end.
Haskell
\a b - a + b
Javascript
function(a,b) { return a + b; }
Clojure
# (+ % %2)
Lua
function(a,b) return a + b end
Python
lambda a,b: a + b
I vote for the Scala/C# syntax. It's worth noting there's a couple of
things going on except the syntax that I think is as equally important:
* Inferred parameter types
* Automatically return the last expression
* No need for ending with a semicolon
* One line lambdas can omit the braces
Note that Scala can infer the parameter types.
An additional question, do we want/need a new syntax for declaring
lambda/delegate types?
--
/Jacob Carlborg
Re: D's confusing strings (was Re: D on hackernews)
Jonathan M Davis , dans le message (digitalmars.D:144962), a écrit : - char[], etc. being real arrays. Which is actually arguably a _bad_ thing, since it doesn't generally make sense to operate on individual chars. What you really want 99.999% of the time is code points not code units. Well, char could also disapear in favor of ubyte, but that will confuse even more people. If we were to start over again, that may very well be the way that we'd go, but the added benefits just don't outweigh the immense amount of code breakage which would result. I 100% agree with that. -- Christophe
Re: C compatibility module for phobos.
On 2011-09-21 21:02, Gor F. Gyolchanyan wrote: I didn't know about core.stdc package because it doesn't show u on dpl.org. The difference is, that some compilers make long 64 bit for 64-bit systems, and some leave the long 32-bit no matter what. core.stdc.config handles that. -- /Jacob Carlborg
Re: The Strange Loop conference
On 2011-09-21 22:20, Andrei Alexandrescu wrote:
On 9/21/11 2:29 PM, Timon Gehr wrote:
On 09/21/2011 06:55 PM, Andrei Alexandrescu wrote:
I'm back from the Strange Loop conference. It's been an interesting
experience. The audience was very diverse, with interest in everything
functional (you'd only need to say Haskell or monad to get positive
aahs), Web/cloud/tablet stuff, concurrent and distributed systems.
Mentioning C++ non-mockingly was all but a faux pas; languages like
Scala, Haskell, Clojure, and Erlang got attention. The quality of talks
has been very variable, and unfortunately the
over-confident-but-clueless-speaker stereotype was well represented.
I gave a talk there
(https://thestrangeloop.com/sessions/generic-programming-galore-using-d)
which has enjoyed moderate audience and success. I uploaded the slides
at http://erdani.com/d/generic-programming-galore.pdf and the video may
be available soon.
I am looking forward to it!
There was a very strong interest in D's CTFE abilities, which we should
consider a strategic direction going forward.
One milestone would be to make DMD GC enabled. CTFE string manipulation
sucks up too much memory.
Also finalizing D's
concurrency language and library infrastructure is essential. These two
features are key differentiators. Also, capitalizing on D's functional
features (which are e.g. better than Scala's but less known) would add
good value.
Where D still loses when compared to Scala is functional code syntax:
val newcol = collection filter {x=x5} map {x=2*x}
Yoda this wrote.
or maybe
val newcol = for(x-collection if(x5)) yield 2*x
Too baroque.
vs
auto newrange = filter!((x){return x5;})(map!((x){return 2*x;})(range));
auto newrange = filter!a5(map!2*a(range));
At first some people get the heebiejeebies when seeing string-based
lambda and the implicit naming convention for unary and binary
functions. More importantly, there's the disadvantage you can't access
local functions inside a string lambda. We should probably add a
specialized lambda syntax.
I like this syntax:
auto newRange = range.map(a = 2 * a).filter(a = a 5);
--
/Jacob Carlborg
Re: Anonymous function syntax
On 2011-09-22 08:47, Max Klyga wrote:
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered. It would be awesome if D infered
argument types for labdas too.
Also Java 8 adopted the same lambda syntax as Scala and C#.
To add a few things to your list:
Nemerle
fun (x, y) { x + y }
(x, y) = x + y
Scala and Nemerle supports placeholder lambda syntax
_ + _
Scheme
(lambda (x y) (+ x y))
Smalltalk
[ :x :y | x + y ]
ML/Ocaml/F#
fun x y - x + y
Ruby has a whole zoo of syntaxes
{|x, y| x + y }
-(x, y) { x + y }
do |x, y| x + y end
Groovy
{ x, y - x + y }
So (args) = body is the most common syntax now
Scala also has this syntax that can be useful sometimes:
foo {
}
Where foo is a method taking a delegate as an argument. This allows to
create, what looks like, new statements. Which can be very handy for DSL's.
--
/Jacob Carlborg
Re: Paradox about D's popularity.
On Wed, 21 Sep 2011 22:33:06 +0100, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 22.09.2011 1:14, Gor F. Gyolchanyan wrote: I had an idea of a D library for including C headers for a while now. All i need is to make a compile-time C parser for that. This thing would literally remove any need for binding. Translating header file is a one-time job, as in sh-$: translate fancy.h fancy.di Why would you need to do it at compile time, except because it's fancy :), I don't quite get. And, as much as I'm sorry to bring bad news, you'd have to make a C preprocessor as well (or even in the first place). Then you'd have to struggle through vendor extensions but that's doable. At one time (2+ years back) I started writing a C lexer, and then C preprocessor in D. In part to learn about how compilers work and in part to convert C headers to D (there was no .di at that stage) so I could interface C. The lexer was no trouble, I even managed to make it flexible by having it read a C grammar file but when I got to the preprocessor I lost steam/momentum and it all fell by the way side. Something I discovered, which may help bootstrap your plans, is that most C compilers will preprocess source for you and give you the resulting stream of text, which you can then lex/parse/etc. However, this results in the C compiler processing macros and following includes, which you often don't actually want it to do - as you're likely trying to replicate the file tree (so want to see includes) and trying to replace macros with CTFE or similar. So, perhaps a combined approach, tame a compiler and have it preprocess a file at a time and then use that output, plus the original file to produce some D replacement code.. not sure if that would work but it might be worth investigating. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Paradox about D's popularity.
On Wed, 21 Sep 2011 22:01:04 +0100, Gor F. Gyolchanyan gor.f.gyolchan...@gmail.com wrote: You're right. I gotta apologize for my over-reaction to D's problems. It's just, that i want it to thrive. Maybe i care too much and i make too bit a deal out of this. :-) Never appologise for enthusiasm! :) I had the same enthusiasm when I first discovered D and I only wish I had more spare time to devote to it .. I have too many hobbies :p Bear in mind however, that 'we' (I am using 'we' despite only being a part-time participant of this group, and not one who has actually done a lot for D, so hopefully the core guys don't mind me including myself in the 'we') get a lot of people with ideas here, but those ideas don't always become concrete results. The reasons are varied, but usually boil down to time/enthusiasm. So if you get a mixed response to your ideas, it's only because some of them have come up before, and gone nowhere. That's not said to discourage you, just to let you know that some people here may appear a little 'jaded'. But! We all want the same things and we do have a small but very dedicated team of people achieving them, and of late with more momentum than ever before. If you have the time and energy to contribute you'll find your contributions well received, provided they gel with the overall scheme/plan Walter and Co have for D.. meaning that it's important to double-check and air your ideas here before spending too long on something, but don't let a few discouraging comments discourage you from your ideas, as results speak louder than proposals I have found. Best of luck! R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Paradox about D's popularity.
On Thursday, September 22, 2011 11:15:23 Regan Heath wrote: as results speak louder than proposals I have found. It's often easy to come up with ideas. The hard part is implementing them, and in many cases, they need to be implemented to be shown that they're viable and to iron them out. Also, there are only so many people working on implementing stuff for dmd, druntime, and Phobos, and they only have so much time - not to mention their own interests - so simply suggesting a good idea is often not enough to actually get it implemented, even if it _is_ a good idea. So, while good ideas are most certainly welcome, and discussing ideas is often quite advantageous, ideas will get a lot farther, faster if the folks suggesting them actually implement them. This is particularly true for compiler features. Walter doesn't spend a lot of time implementing enhancement requests at this point. He's working more on core implementation issues and bugs. So, even if a feature request is solid, backwards compatible, and generally considered to be desirable, it's a _lot_ more likely to make it into dmd if someone else takes the time to do it. Fortunately, the level of contributions to dmd has been quite good of late and the number of people who have some understanding of dmd's implementation is increasing, so dmd has been improved at a considerably increased pace. So, in any case, ideas are great and welcome, but it's often necessary to volunteer your own time and effort to actually get your ideas implemented. - Jonathan M Davis
Re: The Strange Loop conference
Peter Alexander peter.alexander...@gmail.com wrote in message
news:j5dhe0$2ln6$1...@digitalmars.com...
For example, in Haskell, map (correctly) has the signature:
map :: (a - b) - [a] - [b]
but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)
map :: (a - b) - [a] - Map!((a - b), [a])
That actually brings up something I've found kind of interesting about D's
map and other similar functions. They return a type that's specially-tasked
as the return type for function {whatever}. So, in a way, it seems almost
like saying:
ReturnTypeOf!(foo) foo()
{...}
Ie, The return type of this function is defined to be the type this
function returns.
Of course, I realize that's not actually what's going on.
Re: D features
Am 21.09.2011, 01:20 Uhr, schrieb Walter Bright
newshou...@digitalmars.com:
On 9/20/2011 2:28 PM, Jonathan M Davis wrote:
On Tue, 20 Sep 2011 15:58:06 -0400, Rishat Galiulin
2) Why D not using functions exceptions specification list like Java?
Checked exceptions have generally been determined to have been a bad
idea.
Bruce Eckel's article about it convinced me.
http://www.mindview.net/Etc/Discussions/CheckedExceptions
I don't find this article all that convincing. The symptom is that people
begin to write stub exception handlers and 'swallow' the exception. And
this is seen as proof of a failed concept. I wrote exception stubs myself
in the past. Mainly because I had to compile the program first to see the
error, then write the proper exception handler or write a throw clause.
That is cumbersome and you tend to just write a stub at the lowest level
in your code, because it is less typing.
Checked exceptions have the purpose to inform the program of invalid
conditions in areas outside the immediate control of the program. In a
released program you should take care of those one way or another, because
it is likely that a host name cannot be resolved, or a file cannot be read
(down to the fact that the disk has bad sectors). So you are made aware of
this and must solve the problem in one of three ways, depending on the
code structure:
- add a throws clause to let the next higher level handle it
- catch and handle it right there
- do both
- wrap the exception (if it happened in the subprocess of something bigger)
It is a bit of a motivation to write actual error handlers, that you can
easily forget otherwise.
One of the reasons Java is popular is because of the great tools support.
I am a big fan of Eclipse and if you have a look at the situation there
you notice
1. try {...} catch (SomeKindOfException e) {}
will mark the empty braces and print a warning about an undocumented
empty block
2. Uncaught checked exceptions will show up as an error while you are
typing
3. For these errors and many others there are 'quick-fixes'. You just
press Ctrl+1 and choose
a) add throws clause to method
b) surround by try-catch
3b will add a stub like this:
} catch (ExceptionType e) {
e.printStackTrace();
}
This means that no Exception actually goes unnoticed anymore as described
in the article! It is plain no point today in Java. :)
I guess one can say they hack around the flaws in the language, you need
an IDE to even use it properly or one can say they learned and found a
way to make a good idea just work. For D there is no such IDE and all
language features must promote good code when written in programming
editors, Java can excuse a lot in that aspect.
Re: Anonymous function syntax
On 09/22/2011 09:35 AM, Walter Bright wrote: On 9/21/2011 11:47 PM, Max Klyga wrote: It would be awesome if D infered argument types for labdas too. It does, and it is awesome! Indeed, but it currently only works if the delegate literal is a template parameter, in which case the literal is actually fully generic, right?
Re: thoughts on immutability in D
Andrei Alexandrescu: The initial submission got junked so I resubmitted: http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/ A logical const can coexist beside the other two (three) kinds of const of D. For simplicity I use the lconst keyword. lconst works similar to the C++ const, and it gives not troubles, because it is orthogonal to the other true consts. You are allowed to safely cast away lconst and then change the variable contents. But if you change it without casting away lconst, the compiler complains statically. Is it better to design lconst too transitive? Maybe lconst is also a head const just like C++. This is probably handy enough. So with a lconst array you are allowed to change its contents, but not reassign it or change its length. A lconst doesn't implicitly cast to immutable. So I think this is well doable. And probably it is useful too. But having four kinds of const in D is a lot of stuff. Maybe it is too much complex. An alternative solution to face some of the needs of lconst is to define a trusted pure that allows to create a pure memoization (a pure memoize). - Walter: You're right. Logical const is only a convention, since it cannot be enforced by the compiler. Even if it can't be enforced in 100% of the cases, I think it's still useful. So you need to look at the situation from a bit wider point of view. Bye, bearophile
Re: Paradox about D's popularity.
Le 22/09/2011 12:31, Jonathan M Davis a écrit : On Thursday, September 22, 2011 11:15:23 Regan Heath wrote: as results speak louder than proposals I have found. It's often easy to come up with ideas. The hard part is implementing them, and in many cases, they need to be implemented to be shown that they're viable and to iron them out. True, but the fact is that compiler technologies are very specifics. Even for people really exprienced in devellopement in general, and thus knowing what work/doesn't work in several languages, or what is needed to spread D over the IT place, only a reduced portion of them is able to implement something in a compiler frontend. Even if you know compilation algorithm and related stuff (that's my case) you have a tons of details that ends up not being details after all, that you learn by practice. And even if you are, then you have to be confident with DMD front end source code. This is a quite complicated requirement. Maybe advice could be given about where to start (which algorithm, which file(s) in the front end) should be given with comments about implementation.
Re: Paradox about D's popularity.
On 2011-09-22 11:47, Regan Heath wrote: At one time (2+ years back) I started writing a C lexer, and then C preprocessor in D. In part to learn about how compilers work and in part to convert C headers to D (there was no .di at that stage) so I could interface C. The lexer was no trouble, I even managed to make it flexible by having it read a C grammar file but when I got to the preprocessor I lost steam/momentum and it all fell by the way side. Something I discovered, which may help bootstrap your plans, is that most C compilers will preprocess source for you and give you the resulting stream of text, which you can then lex/parse/etc. However, this results in the C compiler processing macros and following includes, which you often don't actually want it to do - as you're likely trying to replicate the file tree (so want to see includes) and trying to replace macros with CTFE or similar. So, perhaps a combined approach, tame a compiler and have it preprocess a file at a time and then use that output, plus the original file to produce some D replacement code.. not sure if that would work but it might be worth investigating. R I've done something similar using Clang: https://github.com/jacob-carlborg/clang -- /Jacob Carlborg
Re: __restrict, architecture intrinsics vs asm, consoles, and other
which compiles to a single shufps instruction.
Doesn't it often require additional needless movaps instructions?
For example, the following:
asm
{
movaps XMM0, a;
movaps XMM1, b;
addps XMM0, XMM1;
movaps a, XMM0;
}
asm
{
movaps XMM0, a;
movaps XMM1, b;
addps XMM0, XMM1;
movaps a, XMM0;
}
compiles to
movaps -0x48(%rsp),%xmm0
movaps -0x38(%rsp),%xmm1
addps%xmm1,%xmm0
movaps %xmm0,-0x48(%rsp)
movaps -0x48(%rsp),%xmm0
movaps -0x38(%rsp),%xmm1
addps%xmm1,%xmm0
movaps %xmm0,-0x48(%rsp)
Is it possible to avoid needlless loading and storing of values when calling
multiple functions that use asm blocks? It also seems that the compiler doesn't
inline functions containing asm.
Re: The Strange Loop conference
Nick Sabalausky , dans le message (digitalmars.D:145002), a écrit :
For example, in Haskell, map (correctly) has the signature:
map :: (a - b) - [a] - [b]
but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)
map :: (a - b) - [a] - Map!((a - b), [a])
except that [a] should be a D Range, and that Map is a D Range too.
So I'd go for:
map :: (a - b) - Range!A - Range!B
oh, that's quite close to Haskell's map...
Let me try the other game: what is Haskell's signature ?
I need to introduce Haskell's type to D, so:
// all types are lazy pure:
template Haskell(T)
{
alias pure T function() Haskell;
}
// Haskell's list:
template HaskellR(T)
{
alias pure Tuple!(Haskell!A, HaskellR!T) function() HaskellR;
}
// Then the signature of map is:
HaskellR!B map(A,B)(Haskell!B function(Haskell!A), HaskellR!A);
Experienced Haskell's users may correct me.
All functions must be pure, and those pure function, and a lot of
optimization comes from the memoization of those functions.
Haskell!T could be rewritten to take into account this memoization.
I wonder what efficiency would we get compared to Haskell with a library
based on this kind of stuff in D. We would probably miss many
optimization opportunities that Haskell is tuned to find out, but it
must be fun to try that out.
--
Christophe
Re: thoughts on immutability in D
On Thu, 22 Sep 2011 11:02:27 +0300, Peter Alexander peter.alexander...@gmail.com wrote: Thanks for the reddit'ing. I launched up google analytics this morning and noticed a sudden spike. That could only mean one thing :-) I tried adding your blog to Planet D, but I can't figure out how to get an RSS feed of the D category on your blog. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff
== Auszug aus Walter Bright (newshou...@digitalmars.com)'s Artikel On 9/21/2011 10:56 PM, Benjamin Thaut wrote: Even if I manually allocate v1,v2 and result, the temporary variable that the compiler uses to compute the expression might be unaligned. That is a total killer for SSE optimizations because you can not hide them away. Does DMC++ have __declspec(align(16)) support? No, but 64 bit DMD aligns the stack on 16 byte boundaries. Unfortunaltey there is no 64 bit dmd on windows.
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On 9/22/11 1:39 AM, Don wrote: On 22.09.2011 05:24, a wrote: How would one do something like this without intrinsics (the code is c++ using gcc vector extensions): [snip] At present, you can't do it without ultimately resorting to inline asm. But, what we've done is to move SIMD into the machine model: the D machine model assumes that float[4] + float[4] is a more efficient operation than a loop. Currently, only arithmetic operations are implemented, and on DMD at least, they're still not proper intrinsics. So in the long term it'll be possible to do it directly, but not yet. At various times, several of us have implemented 'swizzle' using CTFE, giving you a syntax like: float[4] x, y; x[] = y[].swizzle!cdcd(); // x[0]=y[2], x[1]=y[3], x[2]=y[2], x[3]=y[3] which compiles to a single shufps instruction. That cdcd string is really a tiny DSL: the language consists of four characters, each of which is a, b, c, or d. I think we should put swizzle in std.numeric once and for all. Is anyone interested in taking up that task? A couple of years ago I made a DSL compiler for BLAS1 operations. It was capable of doing some pretty wild stuff, even then. (The DSL looked like normal D code). But the compiler has improved enormously since that time. It's now perfectly feasible to make a DSL for the SIMD operations you need. The really nice thing about this, compared to normal asm, is that you have access to the compiler's symbol table. This lets you add compile-time error messages, for example. A funny thing about this, which I found after working on the DMD back-end, is that is MUCH easier to write an optimizer/code generator in a DSL in D, than in a compiler back-end. A good argument for (a) moving stuff from the compiler into the library, (b) continuing Don's great work on making CTFE a solid proposition. Andrei
Re: Anonymous function syntax
On 9/22/11 2:35 AM, Walter Bright wrote: On 9/21/2011 11:47 PM, Max Klyga wrote: It would be awesome if D infered argument types for labdas too. It does, and it is awesome! C++'s lambdas require the types to be present, which some consider a large mistake. Andrei
Re: Anonymous function syntax
On 9/22/11 1:47 AM, Max Klyga wrote: Actually Scala doesn't need type declarations in labmda literals. Most of the time argument types are infered. Already does. We're looking for a briefer syntax. Andrei
Re: thoughts on immutability in D
On 9/22/11 3:02 AM, Peter Alexander wrote: On 22/09/11 7:04 AM, Andrei Alexandrescu wrote: The initial submission got junked so I resubmitted: http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/ Andrei Thanks for the reddit'ing. I launched up google analytics this morning and noticed a sudden spike. That could only mean one thing :-) Out of interest, does anyone have any criticism of my post, esp. if there's any technical inaccuracies (or just disagreement?) You could have specified that e.g. mutable state can be implemented safely with the help of a global hash table. Andrei
Re: Anonymous function syntax
On 9/22/11 3:49 AM, Jacob Carlborg wrote:
On 2011-09-22 00:50, Andrei Alexandrescu wrote:
On 9/21/11 5:29 PM, bearophile wrote:
Walter Bright:
D
(a,b) { return a + b; }
In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };
No.
Andrei
void foo (int delegate (int, int) a){}
void main ()
{
foo((a, b) { return a +b;});
}
Results in:
main.d(48): Error: undefined identifier a
main.d(48): Error: undefined identifier b
main.d(48): Error: function main.foo (int delegate(int, int) a) is not
callable using argument types (_error_ delegate(_error_, _error_))
main.d(48): Error: cannot implicitly convert expression (__dgliteral1)
of type _error_ delegate(_error_, _error_) to int delegate(int, int)
Failed: /Users/jacob/.dvm/bin/dvm-current-dc -v -o-
'/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d'
/Users/jacob/development/d/main.d.deps
That's a bug in the compiler.
Andrei
Re: Anonymous function syntax
On 2011-09-22 16:11, Andrei Alexandrescu wrote:
On 9/22/11 3:49 AM, Jacob Carlborg wrote:
On 2011-09-22 00:50, Andrei Alexandrescu wrote:
On 9/21/11 5:29 PM, bearophile wrote:
Walter Bright:
D
(a,b) { return a + b; }
In D to define a true lambda you need types too:
auto f = (int a,int b){ return a + b; };
No.
Andrei
void foo (int delegate (int, int) a){}
void main ()
{
foo((a, b) { return a +b;});
}
Results in:
main.d(48): Error: undefined identifier a
main.d(48): Error: undefined identifier b
main.d(48): Error: function main.foo (int delegate(int, int) a) is not
callable using argument types (_error_ delegate(_error_, _error_))
main.d(48): Error: cannot implicitly convert expression (__dgliteral1)
of type _error_ delegate(_error_, _error_) to int delegate(int, int)
Failed: /Users/jacob/.dvm/bin/dvm-current-dc -v -o-
'/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d'
/Users/jacob/development/d/main.d.deps
That's a bug in the compiler.
Andrei
Ok, has that been reported?
--
/Jacob Carlborg
Re: Anonymous function syntax
On 9/22/11 9:17 AM, Jacob Carlborg wrote:
void foo (int delegate (int, int) a){}
void main ()
{
foo((a, b) { return a +b;});
}
Results in:
main.d(48): Error: undefined identifier a
main.d(48): Error: undefined identifier b
main.d(48): Error: function main.foo (int delegate(int, int) a) is not
callable using argument types (_error_ delegate(_error_, _error_))
main.d(48): Error: cannot implicitly convert expression (__dgliteral1)
of type _error_ delegate(_error_, _error_) to int delegate(int, int)
Failed: /Users/jacob/.dvm/bin/dvm-current-dc -v -o-
'/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d'
/Users/jacob/development/d/main.d.deps
That's a bug in the compiler.
Andrei
Ok, has that been reported?
Yes :o). http://d.puremagic.com/issues/show_bug.cgi?id=6714
Andrei
Re: Go and generic programming on reddit, also touches on D
On Wed, 21 Sep 2011 16:02:53 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 9/21/11 1:49 PM, Don wrote: On 19.09.2011 18:12, Andrei Alexandrescu wrote: On 9/19/11 10:46 AM, Robert Jacques wrote: So, on balance, I'd say the two pointers representation is categorically worse than the fat pointer representation. Benchmark. A few of your assumptions don't hold. Andrei Note that high-performance libraries that use slices, like GMP and the many BLAS libraries, use the pointer+length representation, not pointer+pointer. They've done a lot of benchmarking on a huge range of architectures, with a large range of compilers. The underlying reason for this, is that almost all CISC instruction sets have built-in support for pointer+length. AFAIK nothing has builtin support for ptr+ptr. On x86, you have this wonderful [EAX+8*EBX] addressing mode, that can be used on almost every instruction, so that the calculation [addr + sz*index] takes ZERO clock cycles when sz is a power of 2. Generally, when you supply two pointers, the optimizer will try to convert it into ptr + offset (where offset isn't bytes, it corresponds to D's length). To all who replied and tested - color me convinced we should keep the current state of affairs. Thanks! Andrei No problem. Also, TDPL uses ptr+ptr for its representation. Having gone back and looked at the chapter on arrays, I think that it makes for great figures and aides the comprehension of ideas. On the other hand, a lot of programming books, e.g. Numeric Recipes in C, have done a lot of harm over the years through people copying their sub-optimal code samples/snippets. So you may want to add a sentence regarding D's actual implementation to the clause under figure 4.1 on page 98.
Re: __restrict, architecture intrinsics vs asm, consoles, and other
Am 22.09.2011, 08:39 Uhr, schrieb Don nos...@nospam.com: On 22.09.2011 05:24, a wrote: How would one do something like this without intrinsics (the code is c++ using gcc vector extensions): [snip] At present, you can't do it without ultimately resorting to inline asm. But, what we've done is to move SIMD into the machine model: the D machine model assumes that float[4] + float[4] is a more efficient operation than a loop. Currently, only arithmetic operations are implemented, and on DMD at least, they're still not proper intrinsics. So in the long term it'll be possible to do it directly, but not yet. At various times, several of us have implemented 'swizzle' using CTFE, giving you a syntax like: float[4] x, y; x[] = y[].swizzle!cdcd(); // x[0]=y[2], x[1]=y[3], x[2]=y[2], x[3]=y[3] which compiles to a single shufps instruction. That cdcd string is really a tiny DSL: the language consists of four characters, each of which is a, b, c, or d. A couple of years ago I made a DSL compiler for BLAS1 operations. It was capable of doing some pretty wild stuff, even then. (The DSL looked like normal D code). But the compiler has improved enormously since that time. It's now perfectly feasible to make a DSL for the SIMD operations you need. The really nice thing about this, compared to normal asm, is that you have access to the compiler's symbol table. This lets you add compile-time error messages, for example. A funny thing about this, which I found after working on the DMD back-end, is that is MUCH easier to write an optimizer/code generator in a DSL in D, than in a compiler back-end. That's a nice fresh approach to intrinsics. I bet if other languages had the CTFE capabilities, they'd probably do the same. Sure, it is ideal if the compiler works magic here, but it takes longer to implement the right code generation in the compiler, than to write an isolated piece of library code and extensions can be added by anyone, especially since there will already be some examples to look at. Thumbs up!
Re: Anonymous function syntax
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 9/22/11 1:47 AM, Max Klyga wrote:
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered.
Already does. We're looking for a briefer syntax.
What is the problem with just inferring the `return`, allowing you to replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
This seems competitive with the other syntaxes for brevity, but ISTR there was
some objection to doing things that
way.
Also would it make sense to have a template library along the lines of
boost::proto/boost::lambda to allow even
shorter, expression-based lambdas like
_1 + _2
I'm not exactly a D template metaprogramming pro, but I think this would work
for a lot of common cases.
Cheers, Pillsy
Re: Paradox about D's popularity.
Ideally, you also want to simply convert #ifdefs to static ifs as well. It's details like this that have convinced me I can manually convert headers in less time than it takes me to manually post-process the result of an automatic translator. Sad. Sent from my iPhone On Sep 21, 2011, at 2:33 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 22.09.2011 1:14, Gor F. Gyolchanyan wrote: I had an idea of a D library for including C headers for a while now. All i need is to make a compile-time C parser for that. This thing would literally remove any need for binding. Translating header file is a one-time job, as in sh-$: translate fancy.h fancy.di Why would you need to do it at compile time, except because it's fancy :), I don't quite get. And, as much as I'm sorry to bring bad news, you'd have to make a C preprocessor as well (or even in the first place). Then you'd have to struggle through vendor extensions but that's doable. -- Dmitry Olshansky
Re: Anonymous function syntax
On 9/22/11 10:42 AM, pillsy wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 9/22/11 1:47 AM, Max Klyga wrote:
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered.
Already does. We're looking for a briefer syntax.
What is the problem with just inferring the `return`, allowing you to replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
This seems competitive with the other syntaxes for brevity, but ISTR there was
some objection to doing things that
way.
The objection is that it introduces a number of questions:
1. How about using that syntax in regular functions?
2. What if the lambda wants to actually evaluate the expression but
return void?
3. How is the semicolon relevant? (If its presence is used as a
disambiguator for (2), it's poor design to predicate a large semantic
difference on such a distinction.)
Also would it make sense to have a template library along the lines of
boost::proto/boost::lambda to allow even
shorter, expression-based lambdas like
_1 + _2
I'm not exactly a D template metaprogramming pro, but I think this would work
for a lot of common cases.
Such an approach has caused more trouble than benefits in C++.
Andrei
Type tuple of all constructors?
Is there a way to get a type tuple of all aviable constructors in a class?
class Test {
public:
this(Foo foo){
m_foo = foo;
}
this(bool flop){
}
this(int x, int y){
}
}
For this class I would expect something like ((Foo),(bool),(int,int))
--
Kind Regards
Benjamin Thaut
Re: Paradox about D's popularity.
I'm thinking the best way to translate C headers is to run it through a string processor instead of a compiler. There's some places where I want the compiler - especially figuring out the values of some constants - but usually, when translating C headers, I just copy/paste and find/replace.
Re: thoughts on immutability in D
On 22/09/11 12:39 PM, bearophile wrote: Andrei Alexandrescu: The initial submission got junked so I resubmitted: http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/ A logical const can coexist beside the other two (three) kinds of const of D. For simplicity I use the lconst keyword. lconst works similar to the C++ const, and it gives not troubles, because it is orthogonal to the other true consts. You are allowed to safely cast away lconst and then change the variable contents. But if you change it without casting away lconst, the compiler complains statically. Is it better to design lconst too transitive? Maybe lconst is also a head const just like C++. This is probably handy enough. So with a lconst array you are allowed to change its contents, but not reassign it or change its length. A lconst doesn't implicitly cast to immutable. So I think this is well doable. And probably it is useful too. But having four kinds of const in D is a lot of stuff. Maybe it is too much complex. An alternative solution to face some of the needs of lconst is to define a trusted pure that allows to create a pure memoization (a pure memoize). As much as I would like logical const, I think adding it would be a mistake. Every feature, no matter how simple, adds complexity to the language: it has to be implemented, maintained, understood by tools, taught, documented... Also, if you keep adding more and more qualifiers and attributes then eventually you spend more time describing the characteristics of your program rather than the program itself. You're right. Logical const is only a convention, since it cannot be enforced by the compiler. Even if it can't be enforced in 100% of the cases, I think it's still useful. So you need to look at the situation from a bit wider point of view. Yes, it is still useful, even if not to the compiler. It's like documentation that the compiler can semi-enforce.
Re: Type tuple of all constructors?
On 2011/09/23 1:11, Benjamin Thaut wrote:
Is there a way to get a type tuple of all aviable constructors in a class?
class Test {
public:
this(Foo foo){
m_foo = foo;
}
this(bool flop){
}
this(int x, int y){
}
}
For this class I would expect something like ((Foo),(bool),(int,int))
$ cat test.d
struct Foo {}
class Test {
public:
this(Foo foo){
}
this(bool flop){
}
this(int x, int y){
}
}
import std.traits;
import std.stdio;
void main()
{
foreach(ctor; __traits(getOverloads, Test, __ctor))
{
alias ParameterTypeTuple!(typeof(ctor)) args;
writeln(args.stringof);
}
}
$ ./test
(Foo)
(bool)
(int, int)
Re: Anonymous function syntax
Andrei Alexandrescu: Yes :o). http://d.puremagic.com/issues/show_bug.cgi?id=6714 Thank you for adding it, and sorry for not filing it myself in past. Bye, bearophile
Re: thoughts on immutability in D
On 22/09/11 1:34 PM, Vladimir Panteleev wrote: On Thu, 22 Sep 2011 11:02:27 +0300, Peter Alexander peter.alexander...@gmail.com wrote: Thanks for the reddit'ing. I launched up google analytics this morning and noticed a sudden spike. That could only mean one thing :-) I tried adding your blog to Planet D, but I can't figure out how to get an RSS feed of the D category on your blog. I'll see what I can do about getting a D only RSS feed. In the meantime there is a all-inclusive RSS feed: http://poita.org/index.php?format=feedtype=rss
Re: Anonymous function syntax
Jacob Carlborg Wrote:
* Inferred parameter types
* Automatically return the last expression
* No need for ending with a semicolon
* One line lambdas can omit the braces
Note that Scala can infer the parameter types.
An additional question, do we want/need a new syntax for declaring
lambda/delegate types?
--
/Jacob Carlborg
The only issue I have with current syntax is return. The type inferring is a
bug so...
I've really enjoyed the current syntax options. I've used
auto var = { /// function thing
return asuth; }()
for a more complex ?:
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On 22/09/11 7:39 AM, Don wrote: On 22.09.2011 05:24, a wrote: How would one do something like this without intrinsics (the code is c++ using gcc vector extensions): [snip] At present, you can't do it without ultimately resorting to inline asm. But, what we've done is to move SIMD into the machine model: the D machine model assumes that float[4] + float[4] is a more efficient operation than a loop. Currently, only arithmetic operations are implemented, and on DMD at least, they're still not proper intrinsics. So in the long term it'll be possible to do it directly, but not yet. At various times, several of us have implemented 'swizzle' using CTFE, giving you a syntax like: float[4] x, y; x[] = y[].swizzle!cdcd(); // x[0]=y[2], x[1]=y[3], x[2]=y[2], x[3]=y[3] which compiles to a single shufps instruction. How can it compile into a single shufps? x and y would need to already be in vector registers, and unless I've missed something, they won't be. You'll need instructions for loading into registers (using the slow movups because 16-byte alignment isn't guaranteed) then do the shufps, then load back out again. This is too slow for performance critical code. Being stored in XMM registers from creation, passed and returned in XMM registers to/from functions is a key requirement for this sort of code. If you have to keep loading in and out of memory then you lose all performance.
Re: Why do we have transitive const, again?
On 21/09/11 6:15 PM, Mehrdad wrote:
I can't find the thread, but I remember someone (bearophile?) mentioned
that the reason we have transitive const is to support purity.
I don't think I understand why this is necessary, though -- could
someone please explain why we have transitive const, and what problems
it fixes?
Thanks!
It's mostly for concurrent programming.
If I pass an immutable(T) reference type to another thread then I need
to be guaranteed that the object is entirely immutable.
If it weren't for transitive const/immutable, this would be possible:
class Foo
{
Foo m_ref;
this() { m_ref = this; }
Foo get() immutable { return m_ref; }
}
immutable(Foo) foo = new Foo();
Foo surprise = foo.get(); // un-immutable-ified!
Re: __restrict, architecture intrinsics vs asm, consoles, and other stuff
On 22/09/11 1:38 AM, Walter Bright wrote: D doesn't have __restrict. I'm going to argue that it is unnecessary. AFAIK, __restrict is most used in writing vector operations. D, on the other hand, has a dedicated vector operation syntax: a[] += b[] * c; where a[] and b[] are required to not be overlapping, hence enabling parallelization of the operation. It's used for vector stuff, but I wouldn't say mostly. Just about any performance intensive piece of code involving pointers can benefit from __restrict. I use it in a VM for example. As an extension from that, why is there no hardware vector support in the language? Surely a primitive vector4 type would be a sensible thing to have? The language supports it now (see the aforementioned vector syntax), it's just that the vector code gen isn't done (currently it is just implemented using loops). I don't see how this would be possible without intrinsics, or at least some form of language extension. Would DMD just *always* put float[4] in XMM registers (assuming they are available)? That doesn't seem like a good idea if you don't want to use it as a vector. BTW, if you want to get a good idea of how game programmers use vector intrinsics on current hardware, there is a good blog post about it here: http://altdevblogaday.com/2011/01/31/vectiquette/
Re: Anonymous function syntax
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 9/22/11 10:42 AM, pillsy wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
[...]
Already does. We're looking for a briefer syntax.
What is the problem with just inferring the `return`, allowing you to
replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
This seems competitive with the other syntaxes for brevity, but ISTR there
was
some objection to doing things that way.
The objection is that it introduces a number of questions:
At the risk of relitigating a long-settled issue, I think there are good
answers to all these questions.
1. How about using that syntax in regular functions?
That sounds great! :)
2. What if the lambda wants to actually evaluate the expression but
return void?
Is this commonly important? If so, there are three possibilities:
a. Have an expression with type void, perhaps a `void` literal or empty
patens `()`, that can be used as the
ultimate expression when needed, as in
(i) { total += i; void; }
b. Require the use of a bare `return` in these cases.
c. Require the return type to be explicitly declared as void in those
cases. This seems like it's especially not a
problem for named functions, since `void` isn't any longer than `auto.
3. How is the semicolon relevant? (If its presence is used as a
disambiguator for (2), it's poor design to predicate a large semantic
difference on such a distinction.)
It's just part of the syntax. I agree that using it to disambiguate the
function's return type is horrible. Mathematica
does that, and I've torn out a fair amount of my hair because of it over the
years.
[...]
I'm not exactly a D template metaprogramming pro, but I think this would
work for a lot of common cases.
Such an approach has caused more trouble than benefits in C++.
Fair enough.
Cheers, Pillsy
Re: The Strange Loop conference
On 22.09.2011 1:53, Timon Gehr wrote: On 09/21/2011 11:11 PM, Andrei Alexandrescu wrote: On 9/21/11 3:34 PM, Peter Alexander wrote: What if foo is a virtual member function? Those can't be templates. Then it would need to take a dynamic Range as parameter, parameterized with the element type. Would it be a good idea to allow this? to!Interface(structInstance); This would work if Struct implicitly fulfills the interface and return a class instance that is constructed on the fly and implements the interface by forwarding to the struct instance. foo(to!IInputRange(map!(...)(...))); There is an adaptTo already in Phobos that does something like that. So all what's left is screwing some bolts in 'to'. -- Dmitry Olshansky
Re: __restrict, architecture intrinsics vs asm, consoles, and other
Am 22.09.2011, 19:26 Uhr, schrieb Peter Alexander peter.alexander...@gmail.com: On 22/09/11 7:39 AM, Don wrote: On 22.09.2011 05:24, a wrote: How would one do something like this without intrinsics (the code is c++ using gcc vector extensions): [snip] At present, you can't do it without ultimately resorting to inline asm. But, what we've done is to move SIMD into the machine model: the D machine model assumes that float[4] + float[4] is a more efficient operation than a loop. Currently, only arithmetic operations are implemented, and on DMD at least, they're still not proper intrinsics. So in the long term it'll be possible to do it directly, but not yet. At various times, several of us have implemented 'swizzle' using CTFE, giving you a syntax like: float[4] x, y; x[] = y[].swizzle!cdcd(); // x[0]=y[2], x[1]=y[3], x[2]=y[2], x[3]=y[3] which compiles to a single shufps instruction. How can it compile into a single shufps? x and y would need to already be in vector registers, and unless I've missed something, they won't be. You'll need instructions for loading into registers (using the slow movups because 16-byte alignment isn't guaranteed) then do the shufps, then load back out again. This is too slow for performance critical code. Being stored in XMM registers from creation, passed and returned in XMM registers to/from functions is a key requirement for this sort of code. If you have to keep loading in and out of memory then you lose all performance. I thought about this. Either write long functions, so you don't have to load and unload often or just make the functions assume that the parameters are in registers without explicit declaration.
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On 9/22/2011 5:11 AM, a wrote: It also seems that the compiler doesn't inline functions containing asm. That's correct, it currently does not.
Re: Anonymous function syntax
On 9/22/2011 4:36 AM, Timon Gehr wrote: Indeed, but it currently only works if the delegate literal is a template parameter, in which case the literal is actually fully generic, right? It gets internally rewritten into being a template function.
Re: Anonymous function syntax
On 9/22/2011 9:06 AM, Andrei Alexandrescu wrote: On 9/22/11 10:42 AM, pillsy wrote: _1 + _2 I'm not exactly a D template metaprogramming pro, but I think this would work for a lot of common cases. Such an approach has caused more trouble than benefits in C++. Besides just looking awfully hackish.
Re: Paradox about D's popularity.
On 21/09/11 6:41 PM, bearophile wrote: Gor Gyolchanyan: I'm ready to donate money to sponsor an ad campaign. Advertising has to be done at the right time and rhythm. Too little and no one knows you, too much and you risk wasting the single opportunity certain persons will give you. D doesn't need too much advertising now. There is not even a hash map in Phobos and there are some unfinished parts in the core language, like inout, const, modules, associative arrays, etc. Bye, bearophile I agree with this. There are large and important parts of the language that simply haven't been implemented or barely work. If everyone were to come and use D now, expecting a finished language, they would be disappointed. A single bad experience can put people off for years, or even a lifetime. Just look at how many people still complain about Tango vs. Phobos. It's not worth risking IMO.
64 bit version?
I just read that D fits nicely to the 64-bit architecture. Is there currently a D compiler that fully exploits the 64-bit hardware under Windows 7? I mean e.g. one can have operations in D on unsigned long int of 64 bits size that correspond directly to hardware operations so as to achieve high efficiency? (Sorry for my ignorant's question, I don't know yet the language.) Thanks in advance. M. K. Shen
Re: 64 bit version?
On Thursday, September 22, 2011 19:38:25 mok-kong shen wrote: I just read that D fits nicely to the 64-bit architecture. Is there currently a D compiler that fully exploits the 64-bit hardware under Windows 7? I mean e.g. one can have operations in D on unsigned long int of 64 bits size that correspond directly to hardware operations so as to achieve high efficiency? (Sorry for my ignorant's question, I don't know yet the language.) Thanks in advance. It's a toolchain issue. dmc, Digital Mars' C compiler, and optlink, its linker, are 32-bit only. On Linux, gcc is used as the linker, and gcc can be 64-bit, so it was fairly straightforward to port dmd to 64-bit on Windows as far as the toolchain goes, but since on Windows, the entire rest of the toolchain is still 32-bit only, we can't have a 64-bit dmd yet. It'll happen eventually, but I believe that the main focus at this point is on bug fixing and that fixing the Windows toolchain to be 64-bit capable is a lower priority for right now. - Jonathan M Davis
dmd - AST dump.
Is it posiible to dump AST for given D source file (like clang++ -cc1 -ast-dump myCoolSrc.cpp, for example)?
Re: 64 bit version?
Currently you have to use GDC.
Re: 64 bit version?
or ldc, I thought that could also compile d2 2011/9/22 Trass3r u...@known.com Currently you have to use GDC.
Re: Anonymous function syntax
Andrei Alexandrescu wrote:
On 9/22/11 10:42 AM, pillsy wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 9/22/11 1:47 AM, Max Klyga wrote:
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered.
Already does. We're looking for a briefer syntax.
What is the problem with just inferring the `return`, allowing you to
replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
This seems competitive with the other syntaxes for brevity, but ISTR
there was some objection to doing things that way.
The objection is that it introduces a number of questions:
1. How about using that syntax in regular functions?
2. What if the lambda wants to actually evaluate the expression but
return void?
As an alternative, a brief syntax could just be restricted to lambda
expressions because we already have complete function literals for
statements, unlike python for example. A void returning function is only
used for side-effects, I am not be bothered at all to have to use full
punctuation for that.
(a, b) { a + b } or (a, b) = a + b would be sweet :)
Re: 64 bit version?
or ldc, I thought that could also compile d2 LLVM still doesn't support SEH, though it's being worked on.
Re: Anonymous function syntax
On 2011-09-22 18:06, Andrei Alexandrescu wrote:
On 9/22/11 10:42 AM, pillsy wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 9/22/11 1:47 AM, Max Klyga wrote:
Actually Scala doesn't need type declarations in labmda literals. Most
of the time argument types are infered.
Already does. We're looking for a briefer syntax.
What is the problem with just inferring the `return`, allowing you to
replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
This seems competitive with the other syntaxes for brevity, but ISTR
there was some objection to doing things that
way.
The objection is that it introduces a number of questions:
1. How about using that syntax in regular functions?
2. What if the lambda wants to actually evaluate the expression but
return void?
I function/delegate that returns a value should be implicitly converted
to a function/delegate that returns void.
--
/Jacob Carlborg
Re: Anonymous function syntax
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token =
2. Add this rewrite to the grammar:
symbol = expression
translates to
(symbol) { return expression; }
3. Add this rewrite to the grammar:
symbol1 symbol2 = expression
translates to
(symbol1 symbol2) { return expression; }
4. Add this rewrite to the grammar:
(comma_separated_parms) = expression
translates to
(comma_separated_parms) = expression
Each item in comma_separated_parms may be 1 or 2 symbols separated by
whitespace. Example:
(int a, b) = a + b
is valid and translates to (int a, b) { return a + b; }
5. The expression cannot contain commas at top level; an unparenthesized
comma is considered to finish expression, just like in a function call's
argument list. For example:
fun(int a = a + 1, a + 2)
is interpreted as
fun((int a = a + 1), (a + 2))
To use comma inside expression, add parens around it.
5. Remove bugs and limitations. A function literal may specify none,
all, or some parameter types, and the compiler correctly figures out the
appropriate template and non-template parameters. The literal
subsequently converts to function pointer or delegate whenever there's a
match of parameter and result types.
Andrei
Re: Anonymous function syntax
On 9/22/11 3:54 PM, Andrei Alexandrescu wrote:
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
[snip]
I can't believe I forgot an all-important aspect.
A function literal should be comparable to another for equality. Two
function literals are equal if they have the same token type sequence
(up to alpha renaming) and use the same environment.
Example:
bool test(auto fun)()
{
return fun == (x, y = x + y);
}
unittest
{
assert(test!(a, b = a + b)());
}
This will not be easy to implement (especially when environment
dependencies come into play) but is necessary.
Andrei
Re: Anonymous function syntax
On Thu, 22 Sep 2011 16:54:55 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 4. Add this rewrite to the grammar: (comma_separated_parms) = expression translates to (comma_separated_parms) = expression Am I missing something here? -Steve
Re: Anonymous function syntax
Andrei Alexandrescu: A function literal should be comparable to another for equality. Are you willing to explain me why, and show an use case? Bye, bearophile
Re: The Strange Loop conference
Andrei Alexandrescu: I have missed to answer a small part: On 9/21/11 5:22 PM, bearophile wrote: This is why I have asked for functions like amap/afilter in Phobos, because in many situations in D you need an array instead of a lazy range. I don't think that was being asked. I don't understand what you are saying me here. This is what I was referring to: http://d.puremagic.com/issues/show_bug.cgi?id=5756 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=29516 Bye, bearophile
Re: Anonymous function syntax
I'd much rather see the bugs in the current lambda syntax get fixed (e.g.
http://d.puremagic.com/issues/show_bug.cgi?id=4724) rather than spend more time
bikeshedding.
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token =
2. Add this rewrite to the grammar:
symbol = expression
translates to
(symbol) { return expression; }
3. Add this rewrite to the grammar:
symbol1 symbol2 = expression
translates to
(symbol1 symbol2) { return expression; }
4. Add this rewrite to the grammar:
(comma_separated_parms) = expression
translates to
(comma_separated_parms) = expression
Each item in comma_separated_parms may be 1 or 2 symbols separated by
whitespace. Example:
(int a, b) = a + b
is valid and translates to (int a, b) { return a + b; }
5. The expression cannot contain commas at top level; an unparenthesized
comma is considered to finish expression, just like in a function call's
argument list. For example:
fun(int a = a + 1, a + 2)
is interpreted as
fun((int a = a + 1), (a + 2))
To use comma inside expression, add parens around it.
5. Remove bugs and limitations. A function literal may specify none,
all, or some parameter types, and the compiler correctly figures out the
appropriate template and non-template parameters. The literal
subsequently converts to function pointer or delegate whenever there's a
match of parameter and result types.
Andrei
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token =
2. Add this rewrite to the grammar:
symbol = expression
translates to
(symbol) { return expression; }
3. Add this rewrite to the grammar:
symbol1 symbol2 = expression
translates to
(symbol1 symbol2) { return expression; }
4. Add this rewrite to the grammar:
(comma_separated_parms) = expression
translates to
(comma_separated_parms) = expression
Each item in comma_separated_parms may be 1 or 2 symbols separated by
whitespace. Example:
(int a, b) = a + b
is valid and translates to (int a, b) { return a + b; }
5. The expression cannot contain commas at top level; an unparenthesized
comma is considered to finish expression, just like in a function call's
argument list. For example:
fun(int a = a + 1, a + 2)
is interpreted as
fun((int a = a + 1), (a + 2))
To use comma inside expression, add parens around it.
5. Remove bugs and limitations. A function literal may specify none,
all, or some parameter types, and the compiler correctly figures out the
appropriate template and non-template parameters. The literal
subsequently converts to function pointer or delegate whenever there's a
match of parameter and result types.
Andrei
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token =
2. Add this rewrite to the grammar:
symbol = expression
translates to
(symbol) { return expression; }
3. Add this rewrite to the grammar:
symbol1 symbol2 = expression
translates to
(symbol1 symbol2) { return expression; }
4. Add this rewrite to the grammar:
(comma_separated_parms) = expression
translates to
(comma_separated_parms) = expression
Each item in comma_separated_parms may be 1 or 2 symbols separated by
whitespace. Example:
(int a, b) = a + b
is valid and translates to (int a, b) { return a + b; }
5. The expression cannot contain commas at top level; an unparenthesized
comma is considered to finish expression, just like in a function call's
argument list. For example:
fun(int a = a + 1, a + 2)
is interpreted as
fun((int a = a + 1), (a + 2))
To use comma inside expression, add parens around it.
5. Remove bugs and limitations. A function literal may specify none,
all, or some parameter types, and the compiler correctly figures out the
appropriate template and non-template parameters. The literal
subsequently converts to function pointer or delegate whenever there's a
match of parameter and result types.
Andrei
Re: Fast 2D matrix of bits
Denis Shelomovskij: Is it? Every conditional branch can break CPU command queue and slow down execution. Anyway, I saw same problem not far-away (2^n sized OpenGL textures). Hours ago Don has written a comment in one of my enhancement requests that is related to this topic: http://d.puremagic.com/issues/show_bug.cgi?id=4046 I will do better benchmarks, and if necessary I'll update that helper function in the bit matrix code in Bugzilla (I have already fixed most of the other suggestions given by Timon Gehr). If Don is right, this asks for some deprecation in core.bitops. Bye, bearophile
Re: Anonymous function syntax
On 9/22/11 4:03 PM, Steven Schveighoffer wrote:
On Thu, 22 Sep 2011 16:54:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
4. Add this rewrite to the grammar:
(comma_separated_parms) = expression
translates to
(comma_separated_parms) = expression
Am I missing something here?
I am. The rewrite should be:
(comma_separated_parms) { return expression; }
Andrei
Re: Anonymous function syntax
---
Cristi Cobzarenco
BSc in Artificial Intelligence and Computer Science
University of Edinburgh
Profile: http://www.google.com/profiles/cristi.cobzarenco
On 22 September 2011 22:03, Steven Schveighoffer schvei...@yahoo.com wrote:
On Thu, 22 Sep 2011 16:54:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
4. Add this rewrite to the grammar:
(comma_separated_parms) = expression
translates to
(comma_separated_parms) = expression
Am I missing something here?
-Steve
Of course he meant (comma_separated_parms) { return expression; }
Re: Anonymous function syntax
On 9/22/11 4:13 PM, dsimcha wrote: I'd much rather see the bugs in the current lambda syntax get fixed (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=4724) rather than spend more time bikeshedding. That's not an either-or choice, and of course improving current lambdas (btw that's not a purely syntactic bug) would improve the rewrites as well. What I noticed lately is that people simply appreciate terse lambdas a whole lot. They hate C++ lambdas because you need to mention types, dislike Java's poor solution to lambdas to the extent the language had to add a feature just for them (which is subject to further controversy) and so on. I think current D is no slouch for lambda expressions, and function attribute deduction adds great power to lambdas, but further simplifying lambdas may mark a sensible improvement in their usability. Andrei
Re: Anonymous function syntax
On 9/22/2011 1:13 PM, Jacob Carlborg wrote: I function/delegate that returns a value should be implicitly converted to a function/delegate that returns void. That doesn't work in some cases - consider a function that returns an object that the caller must destruct. Or even just returns a struct - the caller passes in a hidden pointer to where the return type gets written. Implicit conversion of function pointers and delegates requires binary ABI compatibility.
Re: Anonymous function syntax
On 9/22/2011 2:03 PM, Steven Schveighoffer wrote: On Thu, 22 Sep 2011 16:54:55 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 4. Add this rewrite to the grammar: (comma_separated_parms) = expression translates to (comma_separated_parms) = expression Am I missing something here? I like easy rewrites!
Re: Anonymous function syntax
On Thursday, September 22, 2011 14:47 Andrei Alexandrescu wrote: On 9/22/11 4:13 PM, dsimcha wrote: I'd much rather see the bugs in the current lambda syntax get fixed (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=4724) rather than spend more time bikeshedding. That's not an either-or choice, and of course improving current lambdas (btw that's not a purely syntactic bug) would improve the rewrites as well. What I noticed lately is that people simply appreciate terse lambdas a whole lot. They hate C++ lambdas because you need to mention types, dislike Java's poor solution to lambdas to the extent the language had to add a feature just for them (which is subject to further controversy) and so on. I think current D is no slouch for lambda expressions, and function attribute deduction adds great power to lambdas, but further simplifying lambdas may mark a sensible improvement in their usability. It wouldn't hurt my feelings any if an abbreviated lambda syntax weren't added, but it _is_ a bit annoying that lambdas are as long as they are for simple stuff - especially when I'm forced to use the lambda syntax because the string syntax that I was trying to use wouldn't work for one reason or another. So, adding an abbreviated lambda syntax is likely a good idea. And your suggested syntax is probably the right way to go, since it's most similar to C# rather than one of the functional languages, and none of the other syntaxes are really objectively better anyway. But we will need someone to take the time to implement it (though fortunately, that's far easier now than it used to be given the increasing number of contributors to dmd). - Jonathan M Davis
Re: Anonymous function syntax
On 09/22/11 16:08, bearophile wrote: Andrei Alexandrescu: A function literal should be comparable to another for equality. Are you willing to explain me why, and show an use case? An important application is optimizing for specific lambdas (e.g. equality). For example, a substring search using equality for characters could use bitwise comparison. Andrei
Re: Anonymous function syntax
std.algorithm already introduces a sort of lambda syntax...
map!a+b(...) or map!q{a+b}(...)
If D is looking for its own style of short lambda, maybe implicit use of a and
b could be extended.
Candidates:
a+b
{a+b}
f{a+b}
auto{a+b}
auto a+b
Personally, I like the 2nd or 3rd one. The second is visually cleaner while the
3rd is easily parsed and feels very similar to q strings. I picked f because
that's frequently used to represent a function. x could work, but that's a
common variable name...
Walter Bright Wrote:
I've collected a few from various languages for comparison:
D
(a,b) { return a + b; }
Ruby
-(a,b) { a + b }
C++0x
[](int a, int b) { return a + b; }
C#
(a,b) = a + b
Scala
(a:Int, b:Int) = a + b
Erlang
fun(a, b) - a + b end.
Haskell
\a b - a + b
Javascript
function(a,b) { return a + b; }
Clojure
# (+ % %2)
Lua
function(a,b) return a + b end
Python
lambda a,b: a + b
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On Fri, 23 Sep 2011 02:00:50 +0300, so s...@so.so wrote: It refuses to except a few things which i think it should. accept...
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On Thu, 22 Sep 2011 17:07:25 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I think we should put swizzle in std.numeric once and for all. Is anyone
interested in taking up that task?
You mean some helper functions to be used in user structures? Because i
don't know of any structure in std.numerics that could use it.
We first need to improve opDispatch. Currently i think no one know how it
works or how it was intended to work.
It refuses to except a few things which i think it should.
For example:
A {
opDispatch(string)()
opDispatch(string)() const
}
A a, b;
a.fun = b.run; // This should be perfectly fine.
Re: The Strange Loop conference
On 09/22/2011 02:29 PM, Christophe wrote:
Nick Sabalausky , dans le message (digitalmars.D:145002), a écrit :
For example, in Haskell, map (correctly) has the signature:
map :: (a - b) - [a] - [b]
but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)
map :: (a - b) - [a] - Map!((a - b), [a])
except that [a] should be a D Range, and that Map is a D Range too.
So I'd go for:
map :: (a - b) - Range!A - Range!B
oh, that's quite close to Haskell's map...
Let me try the other game: what is Haskell's signature ?
I need to introduce Haskell's type to D, so:
// all types are lazy pure:
template Haskell(T)
{
alias pure T function() Haskell;
}
// Haskell's list:
template HaskellR(T)
{
alias pure Tuple!(Haskell!A, HaskellR!T) function() HaskellR;
}
// Then the signature of map is:
HaskellR!B map(A,B)(Haskell!B function(Haskell!A), HaskellR!A);
Experienced Haskell's users may correct me.
All functions must be pure, and those pure function, and a lot of
optimization comes from the memoization of those functions.
Haskell!T could be rewritten to take into account this memoization.
I wonder what efficiency would we get compared to Haskell with a library
based on this kind of stuff in D. We would probably miss many
optimization opportunities that Haskell is tuned to find out, but it
must be fun to try that out.
I did: http://pastebin.com/2rEdx0RD
port of some haskell code from RosettaCode (run it ~20 min to get
results, haskell runs in less than 2s)
http://pastebin.com/Vx4hXvaT
Output of the second example is screwed up with the latest release
though, I don't know why, but converting BigNums to string is a PITA
anyways... Has there been a regression in the std.bigint.BigInt.toString
code?
The main performance issue is the garbage collector. Turning it off will
help performance a lot if you have enough RAM. Furthermore, DMD does not
do any advanced optimizations
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On 9/22/11 6:00 PM, so wrote: On Thu, 22 Sep 2011 17:07:25 +0300, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I think we should put swizzle in std.numeric once and for all. Is anyone interested in taking up that task? You mean some helper functions to be used in user structures? I was thinking of a template that takes and return T[n]. Andrei
Re: Anonymous function syntax
On 09/22/2011 11:46 PM, Walter Bright wrote: On 9/22/2011 1:13 PM, Jacob Carlborg wrote: I function/delegate that returns a value should be implicitly converted to a function/delegate that returns void. That doesn't work in some cases - consider a function that returns an object that the caller must destruct. Or even just returns a struct - the caller passes in a hidden pointer to where the return type gets written. Implicit conversion of function pointers and delegates requires binary ABI compatibility. The compiler could insert a thunk that discards the result if the two delegate types are not ABI compatible.
Re: The Strange Loop conference
You might wan to play with GC.reserve.
Sent from my iPhone
On Sep 22, 2011, at 4:35 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 09/22/2011 02:29 PM, Christophe wrote:
Nick Sabalausky , dans le message (digitalmars.D:145002), a écrit :
For example, in Haskell, map (correctly) has the signature:
map :: (a - b) - [a] - [b]
but in D, std.map has the signature (expressed in some Haskell/D
pseudocode)
map :: (a - b) - [a] - Map!((a - b), [a])
except that [a] should be a D Range, and that Map is a D Range too.
So I'd go for:
map :: (a - b) - Range!A - Range!B
oh, that's quite close to Haskell's map...
Let me try the other game: what is Haskell's signature ?
I need to introduce Haskell's type to D, so:
// all types are lazy pure:
template Haskell(T)
{
alias pure T function() Haskell;
}
// Haskell's list:
template HaskellR(T)
{
alias pure Tuple!(Haskell!A, HaskellR!T) function() HaskellR;
}
// Then the signature of map is:
HaskellR!B map(A,B)(Haskell!B function(Haskell!A), HaskellR!A);
Experienced Haskell's users may correct me.
All functions must be pure, and those pure function, and a lot of
optimization comes from the memoization of those functions.
Haskell!T could be rewritten to take into account this memoization.
I wonder what efficiency would we get compared to Haskell with a library
based on this kind of stuff in D. We would probably miss many
optimization opportunities that Haskell is tuned to find out, but it
must be fun to try that out.
I did: http://pastebin.com/2rEdx0RD
port of some haskell code from RosettaCode (run it ~20 min to get results,
haskell runs in less than 2s)
http://pastebin.com/Vx4hXvaT
Output of the second example is screwed up with the latest release though, I
don't know why, but converting BigNums to string is a PITA anyways... Has
there been a regression in the std.bigint.BigInt.toString code?
The main performance issue is the garbage collector. Turning it off will help
performance a lot if you have enough RAM. Furthermore, DMD does not do any
advanced optimizations
Rewrite rules [Was: Re: The Strange Loop conference]
Timon Gehr: Furthermore, DMD does not do any advanced optimizations In Haskell there are ways to add library-defined optimizations, with rewrite rules: http://www.haskell.org/haskellwiki/Playing_by_the_rules http://www.haskell.org/haskellwiki/GHC/Using_rules There are also papers about this. Some people are discussing how add library-defined error messages in Haskell, to reduce the big problems caused by complex type error messages. Maybe similar solutions will be the way to solve similar optimization problems in future D. Bye, bearophile
Re: Anonymous function syntax
On 09/22/2011 01:17 AM, Walter Bright wrote:
I've collected a few from various languages for comparison:
D
(a,b) { return a + b; }
I prefer to make return optional as the argument type
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On Fri, 23 Sep 2011 02:40:11 +0300, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 9/22/11 6:00 PM, so wrote: On Thu, 22 Sep 2011 17:07:25 +0300, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I think we should put swizzle in std.numeric once and for all. Is anyone interested in taking up that task? You mean some helper functions to be used in user structures? I was thinking of a template that takes and return T[n]. Andrei Something like this? test.d Description: Binary data
Dangling Else, Yet Again
http://www.reddit.com/r/programming/comments/kooiy/dangling_else_yet_again/ Andrei
Re: __restrict, architecture intrinsics vs asm, consoles, and other
On 9/22/11 9:11 PM, so wrote: On Fri, 23 Sep 2011 02:40:11 +0300, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 9/22/11 6:00 PM, so wrote: On Thu, 22 Sep 2011 17:07:25 +0300, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I think we should put swizzle in std.numeric once and for all. Is anyone interested in taking up that task? You mean some helper functions to be used in user structures? I was thinking of a template that takes and return T[n]. Andrei Something like this? Looks promising, though I was hoping to not need an additional struct V. But I'm not an expert. Andrei
Re: Formal Review of region allocator begins
Okay. The review period for the region allocator is over (actually, it was over about 2 days ago, but I've been busy and forgot to post about it). So, the question is: Is it ready for a vote, or does it need further revision and review? Looking over the thread, it's not at all clear to me that we're ready for a vote - particularly since the most recent update was fairly recent and almost no one has commented on the changes. Also, I believe that the most recent revision is the first to include std.allocators.allocator, and it's particularly critical that that be solid before moving forward with custom allocators. So, I'm not at all convinced that this is ready for a vote, but I don't know. David, would you consider it to be ready for a vote? - Jonathan M Davis
Re: Anonymous function syntax
On Thu, 22 Sep 2011 18:59:31 -0400, Jason House jason.james.ho...@gmail.com
wrote:
std.algorithm already introduces a sort of lambda syntax...
map!a+b(...) or map!q{a+b}(...)
If D is looking for its own style of short lambda, maybe implicit use of a and
b could be extended.
Candidates:
a+b
{a+b}
f{a+b}
auto{a+b}
auto a+b
Personally, I like the 2nd or 3rd one. The second is visually cleaner while the
3rd is easily parsed and feels very similar to q strings. I picked f because
that's frequently used to represent a function. x could work, but that's a
common variable name...
I like the idea, although 1,2,3 and 5 are too close to valid D syntax for my
comfort. We could borrow from Haskell:
\{a+b}
But I'd prefer not to have special syntax rules inside lambda blocks. (It
increases the cognitive load of D) So why not make it a statement? i.e.
\a+b;
then {} would only be for multi-statement or void functions:
\{a+b; return;}
What I worry about though is variable hijacking rules. e.g.
auto b = 5;
reduce!\a+b(map!\a+b([1,2,3,4));
Re: Dangling Else, Yet Again
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:j5gv0j$825$1...@digitalmars.com...
http://www.reddit.com/r/programming/comments/kooiy/dangling_else_yet_again/
Andrei
It works by keeping track of any lexically enclosing statement that is
looking for an else clause, so if an else clause is found for the current
statement without a following { }, then it is marked as illegal.
Can someone explain that for me? (My brain is completely scrambled right now
from a nasty Flash/IE bug.)
Re: thoughts on immutability in D
On 9/22/2011 4:39 AM, bearophile wrote: Walter: You're right. Logical const is only a convention, since it cannot be enforced by the compiler. Even if it can't be enforced in 100% of the cases, I think it's still useful. So you need to look at the situation from a bit wider point of view. It's worse than a half-implemented C++ feature, because the other half cannot be implemented. Even worse, when the app gets migrated to multiple threads, one inexorably falls into the tarpit of the Double Checked Locking Bug. logical const in C++ is faith-based programming. You'd be better off providing it as a library type that only allows read access to its state.
Re: I can't build dsfml2 or derelict.sfml whit dsss
DSFML2 doesn't exist right now. So no doubt you'll have trouble to compile it. I don't know what you are try to achieve, but definitively not what you believe. Note that my answer in the mentionned link give you all you need to use SFML with D. SFML2 is currently on a devellopement stage, so is DSFML2. Considering the current stage of DSFML2, you don't want to use it right now. Le 22/09/2011 06:10, Cuauhtémoc Ledesma a écrit : First at all sorry for my english. I've tried to build any binding of sfml in a 32-bit machine with archlinux. My problem with dsfml2 is similar to this http://www.digitalmars.com/d/archives/digitalmars/D/learn/Buliding_DSFML2_64-bit_Linux_25694.html. After installing mingw32-pthreads (what i don't know if is the correct library) the problem persist and I don't know which library link. But this only happens when i try to compile an individual file with dmd, not with dsss build. After trying to build derelict (using the command dsss net install derelict) to get derelict.sfml, I figured that the problem maybe is dsss, becouse every time I invoke it the output is as if I hadn't written anything after the dsss command, what is not true. I know that there is a derelict2 packages in yaourt, but i get some errors when I try to install it. This is insane , I can't get any binding of this particular library becouse I can't even get that the tools work properly (I also tried in a mac but I get some different errors). So if any one can help me to solve any of this problems I will extremly grateful. Thanks.
