Walter Bright wrote:
But you can do that with the 'with' statement!
The with goes at the use end, not the object declaration end. Or I read
the spec wrong.
So does the scope guard. I think scope guard solves the same problem as
the with-statement, only it does it in a more flexible and arguab
Wed, 02 Dec 2009 08:38:29 +0100, Pelle Månsson wrote:
> retard wrote:
>> Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:
>>
>>> Rainer Deyke:
"open" by itself is ambiguous. What are you opening? A window? A
network port? I think the word "file" needs to be in there somewhere
On 28/11/2009 00:30, Walter Bright wrote:
One thing Java and Python, Ruby, etc., still hold over D is dynamic
classes, i.e. classes that are only known at runtime, not compile time.
In D, this:
s.foo(3);
Should opDispatch also enable dynamic property injection ?
I just thought that it would b
retard wrote:
Tue, 01 Dec 2009 14:22:10 -0800, Walter Bright wrote:
bearophile wrote:
Right. But what people care in the end is programs that get the work
done. If a mix of Python plus C/C++ libs are good enough and handy
enough then they get used. For example I am able to use the PIL Python
l
Rainer Deyke wrote:
Pelle Månsson wrote:
File looks like a constructor. You are not constructing a file you open
for reading.
"open" by itself is ambiguous. What are you opening? A window? A
network port? I think the word "file" needs to be in there somewhere to
disambiguate.
Something l
retard wrote:
Namespaces in general seem rather useful. I hate the php like 'there's a
flat global scope and everything is a free function approach'. It's
annoying me each time I use phobos.
If you have the same name declared in multiple imports, you cannot refer
to it without qualification (
retard wrote:
Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:
Rainer Deyke:
"open" by itself is ambiguous. What are you opening? A window? A
network port? I think the word "file" needs to be in there somewhere
to disambiguate.
When you program in Python you remember that open is a buil
Tue, 01 Dec 2009 12:40:21 -0500, Steven Schveighoffer wrote:
> On Tue, 01 Dec 2009 11:58:43 -0500, Denis Koroskin <2kor...@gmail.com>
> wrote:
>
>> On Tue, 01 Dec 2009 19:41:46 +0300, Steven Schveighoffer
>> wrote:
>>
>>> On Tue, 01 Dec 2009 11:20:06 -0500, Denis Koroskin <2kor...@gmail.com>
>>>
Tue, 01 Dec 2009 14:24:01 -0800, Walter Bright wrote:
> dsimcha wrote:
>> My biggest gripe about static verification is that it can't help you at
>> all with high-level logic/algorithmic errors, only lower level coding
>> errors. Good unit tests (and good asserts), on the other hand, are
>> inval
Tue, 01 Dec 2009 16:58:32 -0500, Adam D. Ruppe wrote:
> On Tue, Dec 01, 2009 at 09:17:44PM +, retard wrote:
>> The lack of type annotations at least removes all typing bugs.
>
> Quite the contrary, leaving off the type annotation spawns bugs.
It spawns new bugs, for sure, but it removes all
Tue, 01 Dec 2009 14:22:10 -0800, Walter Bright wrote:
> bearophile wrote:
>> Right. But what people care in the end is programs that get the work
>> done. If a mix of Python plus C/C++ libs are good enough and handy
>> enough then they get used. For example I am able to use the PIL Python
>> lib w
Tue, 01 Dec 2009 16:48:34 -0500, Steven Schveighoffer wrote:
> On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha wrote:
>
>> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
>>> If the compiler could somehow
>>> optimize out all instances of the template function to reduce bloat, I
>
Tue, 01 Dec 2009 13:15:53 -0800, Walter Bright wrote:
> grauzone wrote:
>> Walter Bright wrote:
>>> dsimcha wrote:
In Java, by going overboard on making the core language simple, you
end up pushing all the complexity into the APIs.
>>>
>>> Yup, and that's the underlying problem with "sim
Tue, 01 Dec 2009 18:58:25 -0500, bearophile wrote:
> Rainer Deyke:
>> "open" by itself is ambiguous. What are you opening? A window? A
>> network port? I think the word "file" needs to be in there somewhere
>> to disambiguate.
>
> When you program in Python you remember that open is a built-i
Andrei Alexandrescu wrote:
Hello,
I'll be in Quebec City on 10-13 December. I understand a couple of you
are from there. If you want to have a beer on Saturday night, please let
me know!
Andrei
I'll try to hitchhike my way there!
Jeremie
Bill Baxter wrote:
On Tue, Dec 1, 2009 at 5:08 PM, Bill Baxter wrote:
On Tue, Dec 1, 2009 at 4:37 PM, Andrei Alexandrescu
wrote:
Leandro Lucarella wrote:
Walter Bright, el 1 de diciembre a las 13:45 me escribiste:
Leandro Lucarella wrote:
I develop twice as fast in Python than in D. Of co
Bill Baxter wrote:
On Tue, Dec 1, 2009 at 4:37 PM, Andrei Alexandrescu
wrote:
Leandro Lucarella wrote:
Walter Bright, el 1 de diciembre a las 13:45 me escribiste:
Leandro Lucarella wrote:
I develop twice as fast in Python than in D. Of course this is only me,
but that's where I think Python
Leandro Lucarella wrote:
I think code translation from other languages is not a good reason for
adding complexity...
I think it is. We wouldn't have DWT otherwise, for example. Inner
classes were added specifically in order to speed up the translation
process.
The code complexity is suppo
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
D has three: RAII, scope guard, and try-catch-finally. As far as I'm
concerned, the only reason t-c-f isn't taken out to the woodshed and
shot is to make it easy to translate code from other languages to D.
I've
Bill Baxter Wrote:
> On Tue, Dec 1, 2009 at 4:22 PM, Steven Schveighoffer
> wrote:
> > Bill Baxter Wrote:
> >
> >> Good counterpoints to my argument. So I give up on that line.
> >>
> >> Here's another, how do you implement the opBinary_r operators with
> >> opDispatch?
> >
> > Kinda cooky, but
Walter Bright, el 1 de diciembre a las 17:31 me escribiste:
> Leandro Lucarella wrote:
> >It looks like you can (not as easily) according to bearophile example, but
> >this is besides the point, you only want to use malloc() for performance
> >reasons, and I already said that D is better than Pyth
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> D has three: RAII, scope guard, and try-catch-finally. As far as I'm
> concerned, the only reason t-c-f isn't taken out to the woodshed and
> shot is to make it easy to translate code from other languages to D.
I've literally nev
On Tue, Dec 1, 2009 at 5:08 PM, Bill Baxter wrote:
> On Tue, Dec 1, 2009 at 4:37 PM, Andrei Alexandrescu
> wrote:
>> Leandro Lucarella wrote:
>>>
>>> Walter Bright, el 1 de diciembre a las 13:45 me escribiste:
Leandro Lucarella wrote:
>
> I develop twice as fast in Python than
Leandro Lucarella wrote:
It looks like you can (not as easily) according to bearophile example, but
this is besides the point, you only want to use malloc() for performance
reasons, and I already said that D is better than Python on that.
I mentioned ctypes just for the point of easy C-interopera
Leandro Lucarella wrote:
I guess D can greatly benefit from a compiler that can compile and run
a multiple-files program with one command
dmd a b c -run args...
Steven Schveighoffer wrote:
On Tue, 01 Dec 2009 13:53:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright
wrote:
Making them not virtual would also make them not overridable, they'd
all be implicitly final.
Is there any com
bearophile wrote:
Walter Bright:
Ok, does this work:
p = libc.malloc(100); *p = 3;
? Or this:
struct S { int a; char b; }; S s; libc.fillInS(&s);
The purpose of ctypes is to interface Python with C libs, it's a
quite well designed piece of software engineering. This is how you
can do what
On Tue, Dec 1, 2009 at 4:37 PM, Andrei Alexandrescu
wrote:
> Leandro Lucarella wrote:
>>
>> Walter Bright, el 1 de diciembre a las 13:45 me escribiste:
>>>
>>> Leandro Lucarella wrote:
I develop twice as fast in Python than in D. Of course this is only me,
but that's where I think
Leandro Lucarella wrote:
Walter Bright, el 1 de diciembre a las 13:45 me escribiste:
Leandro Lucarella wrote:
I develop twice as fast in Python than in D. Of course this is only me,
but that's where I think Python is better than D :)
If that is not just because you know the Python system far
On Tue, Dec 1, 2009 at 4:22 PM, Steven Schveighoffer
wrote:
> Bill Baxter Wrote:
>
>> Good counterpoints to my argument. So I give up on that line.
>>
>> Here's another, how do you implement the opBinary_r operators with
>> opDispatch?
>
> Kinda cooky, but what about this:
>
> a + b -> b.opDispa
Bill Baxter Wrote:
> Good counterpoints to my argument. So I give up on that line.
>
> Here's another, how do you implement the opBinary_r operators with opDispatch?
Kinda cooky, but what about this:
a + b -> b.opDispatch!("r+" )(a)
-Steve
On 01.12.2009 6:33, Bill Baxter wrote:
Perhaps Walter just doesn't really know what tags are or what they are good for.
I've always had the feeling that Walter doesn't actually use svn as a
tool for his work. He just checks in stuff when he's done. That would
explain why he doesn't add tags
Walter Bright, el 1 de diciembre a las 13:45 me escribiste:
> Leandro Lucarella wrote:
> >I develop twice as fast in Python than in D. Of course this is only me,
> >but that's where I think Python is better than D :)
>
> If that is not just because you know the Python system far better
> than the
Steven Schveighoffer Wrote:
> > The danger is that it's easy to miss accidental sharing and it's very
> > hard to test for it.
>
> I think this danger is rare, and it's easy to search for (just search for
> ~= in your code, I did it with Tango). I think it can be very well
> defined in a t
Walter Bright, el 1 de diciembre a las 13:43 me escribiste:
> Leandro Lucarella wrote:
> >5. simple interfacing to C
> In case you mean no unnecessary wrappers etc., this has more to
> do with the execution model than language features. Most
> scripting languages are interpreted, a
On 30.11.2009 7:02, retard wrote:
foreach (line; new Lines!(char) (new File ("foobar.txt")))
Cout (line).newline;
}
To be fair, it's a bit simpler than that in Tango:
foreach (line; new TextFileInput("foobar.txt"))
Cout (line).newline;
}
2. Read a whole file into an array of bytes.
Rainer Deyke:
> "open" by itself is ambiguous. What are you opening? A window? A
> network port? I think the word "file" needs to be in there somewhere to
> disambiguate.
When you program in Python you remember that open is a built-in function to
open files :-)
When you want to open other thi
Walter Bright:
> Ok, does this work:
>
> p = libc.malloc(100);
> *p = 3;
>
> ? Or this:
>
> struct S { int a; char b; };
> S s;
> libc.fillInS(&s);
The purpose of ctypes is to interface Python with C libs, it's a quite well
designed piece of software engineering. This
Pelle Månsson wrote:
> File looks like a constructor. You are not constructing a file you open
> for reading.
"open" by itself is ambiguous. What are you opening? A window? A
network port? I think the word "file" needs to be in there somewhere to
disambiguate.
--
Rainer Deyke - rain...@eldw
On Tue, Dec 1, 2009 at 3:01 PM, Steven Schveighoffer
wrote:
>> How about this: given only a catch-all opDispatch which implements
>> dynamic dispatch, the compiler cannot statically determine if
>> operators are really implemented or not.
>
> Why does it have to?
> proposed implementation:
>
> com
On Tue, 01 Dec 2009 17:24:30 -0500, Bill Baxter wrote:
On Tue, Dec 1, 2009 at 1:10 PM, Steven Schveighoffer
wrote:
On Tue, 01 Dec 2009 16:01:41 -0500, Bill Baxter
wrote:
On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
wrote:
On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
wro
Andrei Alexandrescu wrote:
Parameters to dynDispatch (the user-defined forwarding function), NOT
opDispatch. opDispatch can take _anything_.
Sorry if I'm repeating what you know already, but I am obsessing over a
small misunderstanding could end up hamstringing this very powerful
feature.
S
Adam D. Ruppe wrote:
You might say that I should have been more disciplined about [...]
That's the usual excuse for poor language design . What I've been
trying to do with D is enable more static verification, so that the
project team can rely on enforced guarantees rather than discipline,
e
On Tue, Dec 1, 2009 at 1:35 PM, Joel C. Salomon wrote:
> On 12/1/2009 3:21 PM, Andrei Alexandrescu wrote:
>>
>> I think the dynamic bit that D lacks and many interpreters have is
>> eval(someString).
>
> I wonder if ddmd can be shoehorned into that…
Only if you make the whole compiler part of the
dsimcha wrote:
My biggest gripe about static verification is that it can't help you at all with
high-level logic/algorithmic errors, only lower level coding errors. Good unit
tests (and good asserts), on the other hand, are invaluable for finding and
debugging high-level logic and algorithmic er
bearophile wrote:
Right. But what people care in the end is programs that get the work
done. If a mix of Python plus C/C++ libs are good enough and handy
enough then they get used. For example I am able to use the PIL
Python lib with Python to load, save and process jpeg images at
high-speed with
On Tue, Dec 1, 2009 at 1:10 PM, Steven Schveighoffer
wrote:
> On Tue, 01 Dec 2009 16:01:41 -0500, Bill Baxter wrote:
>
>> On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
>> wrote:
>>>
>>> On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
>>>
>>> wrote:
>>>
Steven Schveighoffer wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha wrote:
> > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> >> If the compiler could somehow
> >> optimize out all instances of the template function to reduce bloat
Adam D. Ruppe wrote:
On Tue, Dec 01, 2009 at 09:17:44PM +, retard wrote:
The lack of type annotations at least removes all typing bugs.
Quite the contrary, leaving off the type annotation spawns bugs.
Yah, I was wondering about that! The hypothesis is there, but the
conclusion was the n
Walter Bright:
> I meant it in the form of the simpler being better hypothesis.
I see, I have missed that purpose of the discussion... I am sorry.
> The very existence of those shows that Python itself is not powerful enough.
Right. But what people care in the end is programs that get the work
On 2009-12-01 14:01:26 -0500, Andrei Alexandrescu
said:
KennyTM~ wrote:
Alternative suggestion:
Make "x in y" returns a bool and works for arrays. Then you can write
int opBinary(string s)(int rhs) if (s in ["+", "-", "*", "/", "^", "|",
"&"]) { ... }
It's a bit difficult to see a very t
On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
If the compiler could somehow
optimize out all instances of the template function to reduce bloat, I
think that would make it a little less annoying.
What is the sudden obses
Don wrote:
Bill Baxter wrote:
And once again we see Clugston's Law at work. As soon as you figure
out how to do one thing in D, a new compiler feature comes along that
makes it a one-liner. :-)
I love it!
Part of that is just that Don is very good at figuring out what needs to
be supporte
Leandro Lucarella wrote:
I develop twice as fast in Python than in D. Of course this is only me,
but that's where I think Python is better than D :)
If that is not just because you know the Python system far better than
the D one, then yes indeed it is a win.
I think only not having a compi
On Tue, Dec 01, 2009 at 09:17:44PM +, retard wrote:
> The lack of type annotations at least removes all typing bugs.
Quite the contrary, leaving off the type annotation spawns bugs. I had to
write a web app in Ruby last year, and well remember the little things that
slipped past tests, pissin
Leandro Lucarella wrote:
5. simple interfacing to C
In case you mean no unnecessary wrappers etc., this has more to
do with the execution model than language features. Most
scripting languages are interpreted, and require some sort of
assistance from the runtime system. If the language was compi
On 12/1/2009 3:21 PM, Andrei Alexandrescu wrote:
I think the dynamic bit that D lacks and many interpreters have is
eval(someString).
I wonder if ddmd can be shoehorned into that…
—Joel Salomon
dsimcha:
> Good unit
> tests (and good asserts), on the other hand, are invaluable for finding and
> debugging high-level logic and algorithmic errors.
Contract programming too can help. For example in a precondition of a binary
search function you can test that the items are sorted. If you don't
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> If the compiler could somehow
> optimize out all instances of the template function to reduce bloat, I
> think that would make it a little less annoying.
What is the sudden obsession with code bloat here lately? Check out this
S
bearophile wrote:
I suggest Walter to don't try to say that D2 is "better" than Python,
it's a waste of time and it means nothing.
I meant it in the form of the simpler being better hypothesis. I am
arguing that a simpler language often leads to complex code.
CorePy, PyCuda, PyOpenCL, etc. a
== Quote from retard (r...@tard.com.invalid)'s article
> Tue, 01 Dec 2009 10:46:11 -0800, Walter Bright wrote:
> > Leandro Lucarella wrote:
> >> I really think the *only* *major* advantage of D over Python is speed.
> >> That's it.
> >
> > I probably place a lot more importance on static verificati
Bill Baxter wrote:
On Tue, Dec 1, 2009 at 12:23 PM, Bill Baxter wrote:
On Tue, Dec 1, 2009 at 12:15 PM, Pelle M�nsson wrote:
It's a bit difficult to see a very thin operator mask a linear operation,
but I'm thinking maybe "x in y" could be defined if y is a compile-time
array. In that case, t
grauzone wrote:
Walter Bright wrote:
dsimcha wrote:
In Java, by going overboard on making the core language simple,
you end up pushing all the complexity into the APIs.
Yup, and that's the underlying problem with "simple" languages.
Complicated code.
I think users of scripting languages wo
On Tue, 01 Dec 2009 13:53:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright
wrote:
Making them not virtual would also make them not overridable, they'd
all be implicitly final.
Is there any compelling use case for virtu
Tue, 01 Dec 2009 17:11:26 -0300, Leandro Lucarella wrote:
> And again, judging from experience, I don't know why, but I really have
> a very small bug count when using Python. I don't work with huge teams
> of crappy programmers (which I think is the scenario that D tries to
> cover), that can be
Andrei Alexandrescu wrote:
Yah, point taken :o). I probably haven't clarified enough that I'm
talking about a mere belief. Arguments have been discussed here in the
past (e.g. scalability of the language construct with multiple
transactions). Time will tell, but one indicating factor is that
p
Tue, 01 Dec 2009 10:46:11 -0800, Walter Bright wrote:
> Leandro Lucarella wrote:
>> I really think the *only* *major* advantage of D over Python is speed.
>> That's it.
>
> I probably place a lot more importance on static verification rather
> than relying on convention and tons of unit tests.
Tue, 01 Dec 2009 10:39:44 -0800, Andrei Alexandrescu wrote:
> retard wrote:
>> Tue, 01 Dec 2009 03:16:47 -0800, Walter Bright wrote:
>>
>>> Ary Borenszweig wrote:
Can you show examples of points 2, 3 and 4?
>>> Have opDispatch look up the string in an associative array that
>>> returns an as
On Tue, 01 Dec 2009 16:01:41 -0500, Bill Baxter wrote:
On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
wrote:
On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
wrote:
Steven Schveighoffer wrote:
Isn't opBinary almost identical to opDispatch? The only difference I
see is that o
On Tue, Dec 1, 2009 at 1:01 PM, Bill Baxter wrote:
> On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
> wrote:
>> On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
>> wrote:
>>
>>> Steven Schveighoffer wrote:
>>
Isn't opBinary almost identical to opDispatch? The only difference I
>>>
On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
wrote:
> On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
> wrote:
>
>> Steven Schveighoffer wrote:
>
>>> Isn't opBinary almost identical to opDispatch? The only difference I
>>> see is that opBinary works with operators as the 'symbol' and
On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
wrote:
Steven Schveighoffer wrote:
Isn't opBinary almost identical to opDispatch? The only difference I
see is that opBinary works with operators as the 'symbol' and dispatch
works with valid symbols. Is it important to distinguish be
Walter Bright, el 1 de diciembre a las 11:17 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
> >>retard wrote:
> >>>Is this again one of those features that is supposed to hide the
> >>>fact that dmd & optlink toolchain sucks? At least gcc
Leandro Lucarella wrote:
Andrei Alexandrescu, el 1 de diciembre a las 11:07 me escribiste:
Walter Bright wrote:
Leandro Lucarella wrote:
with file(fname) as f:
x = f.read(10)
f.write(x)
Looks like you're right, and it's a recently added new feature. I
suggest it proves my point - Pytho
BCS wrote:
Hello Denis,
On Tue, 01 Dec 2009 17:02:40 +0300, Nick Sabalausky wrote:
"Gzp" wrote in message
news:hf2k9a$2l5...@digitalmars.com...
The compiler also should provide readably output of the generated
code.
I'm not sure if this is what you mean, but I definitely want a
compiler
Andrei Alexandrescu, el 1 de diciembre a las 10:58 me escribiste:
> >I really think the *only* *major* advantage of D over Python is speed.
> >That's it.
>
> In wake of the above, it's actually huge. If you can provide
> comparable power for better speed, that's a very big deal. (Usually
> dynami
On Tue, Dec 1, 2009 at 12:23 PM, Bill Baxter wrote:
> On Tue, Dec 1, 2009 at 12:15 PM, Pelle Månsson
> wrote:
>>> It's a bit difficult to see a very thin operator mask a linear operation,
>>> but I'm thinking maybe "x in y" could be defined if y is a compile-time
>>> array. In that case, the com
On Tue, Dec 1, 2009 at 12:15 PM, Pelle Månsson wrote:
>> It's a bit difficult to see a very thin operator mask a linear operation,
>> but I'm thinking maybe "x in y" could be defined if y is a compile-time
>> array. In that case, the compiler knows the operation and the operand so it
>> may decide
Andrei Alexandrescu, el 1 de diciembre a las 11:07 me escribiste:
> Walter Bright wrote:
> >Leandro Lucarella wrote:
> >>with file(fname) as f:
> >>x = f.read(10)
> >>f.write(x)
> >
> >Looks like you're right, and it's a recently added new feature. I
> >suggest it proves my point - Python
bearophile wrote:
KennyTM~:
Make "x in y" returns a bool and works for arrays.
That's something more useful than the sum of usefulness of opDispatch, opPow
and opLength. You use it all the time in code, and in D it's even more useful
than in Python because in D a small linear scan can be ver
Walter Bright, el 1 de diciembre a las 10:46 me escribiste:
> >And BTW, Python *have* some built-in immutable types (strings, tuples,
> >integers, floats, frozensets, and I don't remember if there is anything
> >else). Python uses convention over hard-discipline (no public/private for
> >example),
Andrei Alexandrescu wrote:
KennyTM~ wrote:
On Dec 1, 09 22:30, Steven Schveighoffer wrote:
An idea I just had when thinking about how ugly opDispatch and opBinary
operators will be if we get those was, wouldn't it be cool if the
compiler could translate:
myTemplateMethod("abc" || "def")() if(c
Steven Schveighoffer wrote:
On Tue, 01 Dec 2009 13:50:38 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Sat, 28 Nov 2009 18:36:07 -0500, Walter Bright
wrote:
And here it is (called opDispatch, Michel Fortin's suggestion):
http://www.dsource.org/projects/dmd/changeset?n
Hello Denis,
On Tue, 01 Dec 2009 17:02:40 +0300, Nick Sabalausky wrote:
"Gzp" wrote in message
news:hf2k9a$2l5...@digitalmars.com...
The compiler also should provide readably output of the generated
code.
I'm not sure if this is what you mean, but I definitely want a
compiler
switch that
On Tue, Dec 1, 2009 at 11:43 AM, Don wrote:
> Bill Baxter wrote:
>>
>> On Tue, Dec 1, 2009 at 5:18 AM, Lutger
>> wrote:
>>>
>>> Ary Borenszweig wrote:
>
The feature isn't very dynamic since the dispatch rules are defined
statically. The only thing you can do is rewire the associ
Bill Baxter wrote:
On Tue, Dec 1, 2009 at 5:18 AM, Lutger wrote:
Ary Borenszweig wrote:
The feature isn't very dynamic since the dispatch rules are defined
statically. The only thing you can do is rewire the associative
I don't get it, what if WhatTypeToPutHere does a dynamic lookup, then
I suggest Walter to don't try to say that D2 is "better" than Python, it's a
waste of time and it means nothing.
Walter Bright:
>can you do Bill Baxter's swizzler? Can you do Don Clugston's FPU code
>generator?<
Python is more more flexible. See the __getattr__ standard method:
class Reg4(obj
Steven Schveighoffer Wrote:
> On Tue, 01 Dec 2009 11:52:32 -0500, Sean Kelly
> wrote:
>
> > Leandro Lucarella Wrote:
> >
> >> Speaking of improving the VCS usage, how about tagging?
> >
> > An easy intermediate step would be to include the SVN revision numbers
> > of Phobos ad Druntime when
Leandro Lucarella Wrote:
> Sean Kelly, el 1 de diciembre a las 11:52 me escribiste:
> > Leandro Lucarella Wrote:
> >
> > > Speaking of improving the VCS usage, how about tagging?
> >
> > An easy intermediate step would be to include the SVN revision numbers
> > of Phobos ad Druntime when a rele
On Tue, Dec 1, 2009 at 10:47 AM, Walter Bright
wrote:
> Bill Baxter wrote:
>>
>> "bugzilla 3558 Optimizer bug results in false if condition being taken"
>> Excellent. That's a much more useful commit message.
>
> Yah, the only problem is that's the wrong message. I meant bugzilla 3521.
> 3558 rem
Leandro Lucarella wrote:
Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
retard wrote:
Is this again one of those features that is supposed to hide the
fact that dmd & optlink toolchain sucks? At least gcc can optimize
the calls in most cases where the operator is defined to be
vir
Andrei Alexandrescu wrote:
I don't think that's any difference at all. Javascript does use a sort
of Variant for all of its values.
So if you want dynamic:
a) have opDispatch forward the string to dynDispatch as a regular
(runtime) value, pack all parameters into Variants (or an array thereof
Walter Bright wrote:
Andrei Alexandrescu wrote:
I don't think that's any difference at all. Javascript does use a sort
of Variant for all of its values.
So if you want dynamic:
a) have opDispatch forward the string to dynDispatch as a regular
(runtime) value, pack all parameters into Variant
On Tue, Dec 01, 2009 at 11:07:15AM -0800, Walter Bright wrote:
> std.variant needs to be extended with opDispatch so it can execute a
> call operation on a Variant, then it will be very very similar to
> Javascript.
I looked into this for a few minutes this morning. Variant already stores
delega
Walter Bright wrote:
Leandro Lucarella wrote:
with file(fname) as f:
x = f.read(10)
f.write(x)
Looks like you're right, and it's a recently added new feature. I
suggest it proves my point - Python had to add complexity to support
another paradigm. Python's "with" doesn't look any sim
On Tue, 01 Dec 2009 13:50:38 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Sat, 28 Nov 2009 18:36:07 -0500, Walter Bright
wrote:
And here it is (called opDispatch, Michel Fortin's suggestion):
http://www.dsource.org/projects/dmd/changeset?new=trunk%2f...@268&old=trun
Bill Baxter wrote:
I forgot a biggie: with opDispatch you must know the return type at
compile time.
You could make the return type be Variant or something, but then that
makes it quite different from a "regular" function.
Whereas in a dynamic language like Javascript a dynamic method looks
just
Lutger wrote:
In javascript I understand it is like this:
void yourMagicJavascriptFunction(T d)
{
d.foo(); // rewritten as d["foo"]
}
d.foo is rewritten as d["foo"],
d.foo() is rewritten as d["foo"]()
Steven Schveighoffer wrote:
On Tue, 01 Dec 2009 11:20:06 -0500, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 01 Dec 2009 19:02:27 +0300, Steven Schveighoffer
wrote:
You are missing the point of opDispatch. It is not runtime defined,
because the compiler statically decides to call o
KennyTM~ wrote:
On Dec 1, 09 22:30, Steven Schveighoffer wrote:
An idea I just had when thinking about how ugly opDispatch and opBinary
operators will be if we get those was, wouldn't it be cool if the
compiler could translate:
myTemplateMethod("abc" || "def")() if(condition) {}
to
myTemplate
1 - 100 of 194 matches
Mail list logo
