On 2013-01-24 03:35, deadalnix wrote:
SDC does something similar with LLVM JIT capabilities.
That's the correct approach.
--
/Jacob Carlborg
On 2013-01-23 22:50, Andrei Alexandrescu wrote:
It's a subset. That's a better thing than _another_ language.
Of course. But then the CTFE and regular code is handled differently by
the compiler it will start to become a different language, although very
similar. I'm wondering if that is
On Thursday, 24 January 2013 at 07:55:37 UTC, Jacob Carlborg
wrote:
On 2013-01-24 03:35, deadalnix wrote:
SDC does something similar with LLVM JIT capabilities.
That's the correct approach.
The question is not so much about correctness, but about
performance.
Building an LLVM function
On Thursday, 24 January 2013 at 13:59:43 UTC, David Nadlinger
wrote:
On Thursday, 24 January 2013 at 07:55:37 UTC, Jacob Carlborg
wrote:
On 2013-01-24 03:35, deadalnix wrote:
SDC does something similar with LLVM JIT capabilities.
That's the correct approach.
The question is not so much
On 1/23/13 2:28 AM, Jacob Carlborg wrote:
On 2013-01-22 20:51, Andrei Alexandrescu wrote:
Not at all, I'd say. CTFE has a much lower cost of learning - you only
need to know which subset of D is allowed. Maybe you meant code mixins?
To be able to use AST macros one needs CTFE. One needs
On Wednesday, 23 January 2013 at 07:57:10 UTC, Andrei
Alexandrescu wrote:
Martin Odersky confessed to me being quite worried about the
possible community reaction to the introduction of AST macros.
I haven't kept close tabs to see how it's turning out.
Can he or you explain why ?
I
On Wed, Jan 23, 2013 at 09:38:01AM +0100, deadalnix wrote:
[...]
Anyway, I do strongly feel like we should stop adding more stuff
now. Too much stuff is here already, some already start to misbehave
together. It is probably time to consolidate the language, and keep
that kind of stuff for a
On Wednesday, 23 January 2013 at 15:36:16 UTC, H. S. Teoh wrote:
On Wed, Jan 23, 2013 at 09:38:01AM +0100, deadalnix wrote:
[...]
Anyway, I do strongly feel like we should stop adding more
stuff
now. Too much stuff is here already, some already start to
misbehave
together. It is probably time
On Wed, 2013-01-23 at 02:57 -0500, Andrei Alexandrescu wrote:
[…]
Martin Odersky confessed to me being quite worried about the possible
community reaction to the introduction of AST macros. I haven't kept
close tabs to see how it's turning out.
AST transforms are working wonderfully well in
On 1/23/13 2:08 PM, Russel Winder wrote:
There is no doubt that AST transforms in Groovy is not something the
application programmer would spend time on unless they knew what they
were doing. It isn't a trivial API. However it is straightforward once
you know ASTs.
Given the richness of
On 2013-01-23 08:57, Andrei Alexandrescu wrote:
I completely disagree. (Sorry to foul you twice.) All AST macro systems
I've studied are considerably difficult to understand and use
effectively. By comparison, string macros are brutal and unstructured
but the kind of thing all programmer worth
On Wed, 2013-01-23 at 15:15 -0500, Andrei Alexandrescu wrote:
[…]
Given the richness of today's D, I'd say AST macros are not part of the
mythical plan.
Works for me.
The issue is only whether there is an idiomatic expression for a given
style. For me currently D has everything I need that
On 1/23/13 3:29 PM, Jacob Carlborg wrote:
On 2013-01-23 08:57, Andrei Alexandrescu wrote:
I completely disagree. (Sorry to foul you twice.) All AST macro systems
I've studied are considerably difficult to understand and use
effectively. By comparison, string macros are brutal and unstructured
The difficult tension for me is JVM vs. native. On the JVM I
have
Groovy, Scala, (Ceylon, Kotlin, JRuby, Jython, Clojure), even
Java,
which is an interesting milieu. Natively there is C, C++, D,
Clay,
Rust, Haskell which makes for fun tensions.
There is also Nimrod which has 'yield' and
On Wednesday, 23 January 2013 at 21:50:39 UTC, Andrei
Alexandrescu wrote:
In Scala it _is_ the regular compiler that handles both the
CTFE and the
regular code. A bug in the regular compiler will show up
during CTFE as
well.
Agreed this is a good thing for Scala, it takes advantage of
the
On Wednesday, 23 January 2013 at 21:13:12 UTC, Russel Winder
wrote:
[...]
The core problem is how to make D appealing to C and C++
programmers.
One possibility is that once we have 100% shared library support,
C/C++ programmers can start making use out of a growing base of
very nice
On 2013-01-24 01:30, Araq wrote:
There is also Nimrod which has 'yield' and AST macros ...
And Nemerle (on .Net), which both has AST macros and allows the
programmer to add new syntax for these macros.
--
/Jacob Carlborg
On 01/21/2013 08:00 PM, Nick Sabalausky wrote:
On Mon, 21 Jan 2013 11:48:58 +0100
deadalnix deadal...@gmail.com wrote:
...
Why can't this be done in D ? What are the major problems ?
I don't know whether or not it can be done in D. ...
Why not? I have essentially done it and posted it here.
Jacob Carlborg d...@me.com wrote in message
news:kdlfhr$1676$1...@digitalmars.com...
Would that be so bad idea, to have a fixed AST representation? The AST
presented for the user doesn't need to be the same as the compiler uses
internally.
It's the same as any library function. You can
On 2013-01-22 12:00, Daniel Murphy wrote:
It depends how much information is in the AST you give the user. Just
syntax? Types? Full semantic information?
Of course you can transform the internal AST to the user AST, but the more
information the closer this gets to forcing the compiler to
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud
wrote:
On Tue, Jan 22, 2013 at 2:55 AM, deadalnix
deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg
wrote:
I know people don't like it but I have to say, this seems it
could be a
job for AST
On Tuesday, 22 January 2013 at 12:14:26 UTC, Max Samukha wrote:
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud
wrote:
On Tue, Jan 22, 2013 at 2:55 AM, deadalnix
deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg
wrote:
I know people don't like
On 1/22/13 7:14 AM, Max Samukha wrote:
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote:
On Tue, Jan 22, 2013 at 2:55 AM, deadalnix deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
I know people don't like it but I have to say,
On 2013-01-22 20:51, Andrei Alexandrescu wrote:
Not at all, I'd say. CTFE has a much lower cost of learning - you only
need to know which subset of D is allowed. Maybe you meant code mixins?
To be able to use AST macros one needs CTFE. One needs functions to
manipulate the AST during compile
On Mon, 21 Jan 2013 03:27:49 +0100
deadalnix deadal...@gmail.com wrote:
On Sunday, 20 January 2013 at 20:19:56 UTC, Nick Sabalausky wrote:
If we need to resort to using D-as-a-DSL-inside-D to get decent
coroutines, then that just further proves the need for a real
coroutine
support in
On Mon, 21 Jan 2013 01:18:48 +0100
Rob T al...@ucora.com wrote:
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky wrote:
Fibers: Too much performance overhead to be a general solution.
Only
good for, as an example, heavily I/O-bound stuff.
Where does the overhead come from?
On Monday, 21 January 2013 at 08:27:28 UTC, Nick Sabalausky wrote:
Stackless fibers: Requires gross syntactical contortions much
like
opApply does.
Can you explain more what a stackless fiber is ? From the linked
posted above I did really understood, as the example code clearly
call
On 01/21/2013 10:08 AM, deadalnix wrote:
On Monday, 21 January 2013 at 08:27:28 UTC, Nick Sabalausky wrote:
Stackless fibers: Requires gross syntactical contortions much like
opApply does.
Can you explain more what a stackless fiber is ? From the linked posted
above I did really understood,
On Monday, 21 January 2013 at 09:18:34 UTC, Timon Gehr wrote:
On 01/21/2013 10:08 AM, deadalnix wrote:
On Monday, 21 January 2013 at 08:27:28 UTC, Nick Sabalausky
wrote:
Stackless fibers: Requires gross syntactical contortions
much like
opApply does.
Can you explain more what a stackless
On Mon, 21 Jan 2013 11:48:58 +0100
deadalnix deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 09:18:34 UTC, Timon Gehr wrote:
On 01/21/2013 10:08 AM, deadalnix wrote:
On Monday, 21 January 2013 at 08:27:28 UTC, Nick Sabalausky
wrote:
Stackless fibers: Requires gross syntactical
On 2013-01-21 20:00, Nick Sabalausky wrote:
I don't know whether or not it can be done in D. But, if it can be
done, it would definitely require awkward syntax. Probably more awkward
than the preprocessor-based syntax of the C/C++ version. (Not that I
want a preprocessor in D.)
Maybe you could
On Monday, 21 January 2013 at 08:44:10 UTC, Nick Sabalausky wrote:
I ask, because if except for the overhead, fibers are a good
general solution, then it makes sense to determine if anything
can be done to lessen the overhead before trying to implement
yet another solution.
Yea, they
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
I know people don't like it but I have to say, this seems it
could be a job for AST macros.
It would be just as ugly as C macros. Well maybe not as ugly, but
D should have direct support for co-routines, it's an important
On Mon, 21 Jan 2013 21:15:48 +0100
Rob T al...@ucora.com wrote:
On Monday, 21 January 2013 at 08:44:10 UTC, Nick Sabalausky wrote:
I ask, because if except for the overhead, fibers are a good
general solution, then it makes sense to determine if anything
can be done to lessen the
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
On 2013-01-21 20:00, Nick Sabalausky wrote:
I don't know whether or not it can be done in D. But, if it
can be
done, it would definitely require awkward syntax. Probably
more awkward
than the preprocessor-based syntax of the
On Monday, 21 January 2013 at 20:15:49 UTC, Rob T wrote:
On Monday, 21 January 2013 at 08:44:10 UTC, Nick Sabalausky
wrote:
I ask, because if except for the overhead, fibers are a good
general solution, then it makes sense to determine if
anything can be done to lessen the overhead before
deadalnix deadal...@gmail.com wrote in message
news:zrmlbyboedaswcllz...@forum.dlang.org...
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
On 2013-01-21 20:00, Nick Sabalausky wrote:
I know people don't like it but I have to say, this seems it could be a
job for AST
deadalnix deadal...@gmail.com wrote in message
news:zrmlbyboedaswcllz...@forum.dlang.org...
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
On 2013-01-21 20:00, Nick Sabalausky wrote:
I know people don't like it but I have to say, this seems it could be a
job for AST
On Tue, Jan 22, 2013 at 2:55 AM, deadalnix deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
I know people don't like it but I have to say, this seems it could be a
job for AST macros.
I was thinking the same thing, but don't wanted to bug people.
On Tue, Jan 22, 2013 at 06:51:07AM +0100, Philippe Sigaud wrote:
On Tue, Jan 22, 2013 at 2:55 AM, deadalnix deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote:
I know people don't like it but I have to say, this seems it could
be a job for AST
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud
wrote:
On Tue, Jan 22, 2013 at 2:55 AM, deadalnix
deadal...@gmail.com wrote:
On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg
wrote:
I know people don't like it but I have to say, this seems it
could be a
job for AST
On 2013-01-22 04:43, Daniel Murphy wrote:
AST macros are just compiler support pushed into user code/libraries.
Exposing the AST to the user is a huge task and forces any supporting
compiler to use a fixed AST representation.
Would that be so bad idea, to have a fixed AST representation? The
On Sun, Jan 20, 2013 at 3:45 AM, Timon Gehr timon.g...@gmx.ch wrote:
But I think we should first build a general-purpose DSEL library.
Almost there. I almost have macros, even. But the generated parser is
still quite slow...
On Sunday, 20 January 2013 at 02:45:01 UTC, Timon Gehr wrote:
On 01/19/2013 10:46 PM, Nick Sabalausky wrote:
On Sat, 19 Jan 2013 09:45:25 +0100
qznc q...@go.to wrote:
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky
wrote:
Then there's C/C++ which has libs that offer what are known
On 01/19/13 03:14, Timon Gehr wrote:
On 01/18/2013 06:59 PM, Nick Sabalausky wrote:
tl;dr: D's input ranges are much more awkward to create than they
actually NEED to be, but the existing workarounds all have big problems.
...
My shot at it: http://dpaste.dzfl.pl/baa538af
(Does not
On Sun, Jan 20, 2013 at 5:27 PM, deadalnix deadal...@gmail.com wrote:
This can be implemented a lot better looking in D. (My quick hack already
looks better.) But I think we should first build a general-purpose DSEL
library.
DSEL ?
Domain-Specific Embedded Language, I guess.
Timon is just
On Sun, 20 Jan 2013 03:45:00 +0100
Timon Gehr timon.g...@gmx.ch wrote:
On 01/19/2013 10:46 PM, Nick Sabalausky wrote:
On Sat, 19 Jan 2013 09:45:25 +0100
qznc q...@go.to wrote:
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky wrote:
Then there's C/C++ which has libs that
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky wrote:
Fibers: Too much performance overhead to be a general solution.
Only
good for, as an example, heavily I/O-bound stuff.
Where does the overhead come from? Is the overhead from using
fibers the only problem for implementing
On Sunday, 20 January 2013 at 20:19:56 UTC, Nick Sabalausky wrote:
If we need to resort to using D-as-a-DSL-inside-D to get decent
coroutines, then that just further proves the need for a real
coroutine
support in the language.
A good part of the job is done with Fibers. The biggest problem
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky wrote:
Then there's C/C++ which has libs that offer what are known as
stackless fibers. These utilize the preprocessor, along with
switch
and goto, to accomplish the same thing that (AIUI) C# does for
its
coroutines: It lets the user
On Sat, 19 Jan 2013 09:45:25 +0100
qznc q...@go.to wrote:
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky wrote:
Then there's C/C++ which has libs that offer what are known as
stackless fibers. These utilize the preprocessor, along with
switch
and goto, to accomplish the
On 01/19/2013 10:46 PM, Nick Sabalausky wrote:
On Sat, 19 Jan 2013 09:45:25 +0100
qznc q...@go.to wrote:
On Friday, 18 January 2013 at 17:59:36 UTC, Nick Sabalausky wrote:
Then there's C/C++ which has libs that offer what are known as
stackless fibers. These utilize the preprocessor, along
On Tue, 15 Jan 2013 13:52:10 +0100
bearophile bearophileh...@lycos.com wrote:
In D the Range static protocol of iteration is external and
opApply is internal. Some persons have suggested to use fibers in
D to introduce a very handy yield syntax for internal iteration.
D has problems in
On 01/18/2013 06:59 PM, Nick Sabalausky wrote:
tl;dr: D's input ranges are much more awkward to create than they
actually NEED to be, but the existing workarounds all have big problems.
...
My shot at it: http://dpaste.dzfl.pl/baa538af
(Does not work with 2.061)
The author of the experimental language Magpie is very
intelligent (in past I have read a very nice blog post about the
unusual bootstrapped type system of Magpie). Here he nicely
discusses well known things:
http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/
Reddit
On Jan 15, 2013, at 4:52 AM, bearophile bearophileh...@lycos.com wrote:
The author of the experimental language Magpie is very intelligent (in past I
have read a very nice blog post about the unusual bootstrapped type system of
Magpie). Here he nicely discusses well known things:
56 matches
Mail list logo
