On Tuesday, 26 January 2016 at 01:34:09 UTC, Manu wrote:
Possible to std.regex in ctfe?
(...)
I have a string import destined for a mixin, and I want to
parse it with regex, but I haven't been able to make it work.
The docs mention nothing about this possibility.
Hi Manu,
a possible solutio
> Anyway, thank you very much for the code. The weekend is coming -> I'll play
> with your implementation and see if there any improvements possible.
Be sure to keep me informed of any enormous mistake I made. I tried
Appender and other concatenation means, without big success.
Btw, I saw on the
> Thanks a lot, by the way!
>
> I've just skimmed through the code and the README... You did not use the
> packed forest representation, did you..?
Sorry for the microscopic documentation (Pegged is more documented
than that...), it was a 'for me only' project.
The forest is packed, in the sense
On Thu, Oct 2, 2014 at 11:19 PM, Vladimir Kazanov via Digitalmars-d
wrote:
> Check the mailbox,
>
> Thank you
I sent it to you. I was asleep, sorry :-)
> I have a huge collection of projects I never published :-) We all do, I
> guess.
Oh, the ratio is more and 100 projects for one published...
> No, this is not exactly what I mean. Multithreading can be perfectly fine in
> some cases, very fruitful sometimes. Say, in NLP, when one has to proces
e now, it seems I'm still using Pegged to parse the
initial grammar. Bootstrapping did not go well.
Send me an email at firstname . lastname @gmail.com
(philippe sigaud)
>> Halas, even with some shortcuts on Kleene stars it was quite slow. I
>> tried to use threads (spawni
> Chances are that I will be able to get the original GLL parser generator
> from one of algorithm authors (Adrian Johnstone). He's really helpful here.
> From that point, I will only have to add a frontend for generating a
> concrete parser, starting with Python - it already has a fully working
>
On Wed, Sep 3, 2014 at 7:59 PM, Ali Çehreli wrote:
> Also, I've just noticed that "Questions about learning D" sounds a little
> off because it sounds as if the questions should be like "how can I learn
> D". :) How about something like "Questions when learning D".
Or even: "Learning D"
> What is D's attitude toward this concept?
Hickey's original announcement is also interesting to read. Elegant, as always.
It seems to me that ranges and range algorithms in D already permit
this composition of actions, without the creation of intermediate
structures:
import std.algorithm;
impo
On Friday, 29 August 2014 at 17:29:34 UTC, H. S. Teoh via
Digitalmars-d wrote:
A lot of Adam's stuff are in that category.
(...)
I highly recommending studying how Adam's code achieves this.
:-)
It's also a bit hypnotic. I wanted to do a quick test of his
simpledisplay.d module, after read
On Fri, Aug 29, 2014 at 7:12 PM, H. S. Teoh via Digitalmars-d
wrote:
> The mixin("import "...) line was mind-blowingly ingenious, I have to
> say.
I remember using the same 'module' trick a few years ago (that is,
getting a name with __traits and testing whether it begins with
"module " or not) a
> http://stackoverflow.com/questions/2329/d-finding-all-functions-with-certain-attribute
That's what a good part of his book is about, also. A nice read, one
of my favorite chapters of the "D Cookbook".
Ideally, Adam should do a PR for Phobos to add some code-walking
ability like this.
I'm in
On Wed, Aug 20, 2014 at 11:49 PM, Jakob Ovrum via Digitalmars-d
wrote:
> Certainly the easiest, but I don't think it's always the best. If
> light-weightedness is desired, make the struct contain the reference,
> effectively making the struct a reference type
Well, yes. But the OP explicitly aske
> After initialization there is no need to modify the data anymore.
> My first question is: can the data be changed to "const" once
> initialized?
You can have const or immutable data, that can be initialized once.
I tend to use pure functions to do that:
struct Node {
Node[] block;
>> I won't look at it again for a different reason. They're the types that
>> say "A monad is just a monoid in the category of endofunctors, what's
>> the problem?"
>
>
> Sure, so one should point out that problem may be made out to be that the
> monoidal product [1][2] is underspecified for someon
On Tuesday, 19 August 2014 at 11:14:17 UTC, Vladimir Panteleev
wrote:
You realize you're replying to a decade-old post, right?
What about storing D files on BETAMAX tapes? Oh, wait.
On Fri, Aug 15, 2014 at 9:13 PM, artemav via Digitalmars-d
wrote:
> :) Wow, thanks for all replies. I realized too late that should write
> "that's it".
> Hmm, It's also a good sign that D community is active.
Can I add something? ;)
You can also use a class, as they are reference types:
class
Kenji Hara:
> I implemented partial type deduction in AA keys.
> https://github.com/D-Programming-Language/dmd/pull/3615
>
> For example:
> auto[auto[$]] aa5 = [[1,2]:1, [3,4]:2];
> static assert(is(typeof(aa5) == int[int[2]]));
>
> int[int[][$]] aa15 = [[[1],[2]]:1, [[3],[4]]:2];
>
I'm catching up on some Dconf 2014 videos (great job, guys!) and
wondering whether the associated slides will be put on the
website somewhere. There are some where I'd like to ponder the
code and ideas. It's not easy to do that on a stopped Youtube
stream :)
I know some links have been provid
I see, thanks.
> struct / class Element(T) {
> T name;
> T[T] attributes;
> // ...
> string toString() {
> return ...;
> }
> }
Why did you chose the same type for keys and values? And shouldn't
'name' always be a string?
Yes indeed, you can provide a range interface on a tree. That's a good idea!
But I suppose Chuck wants to teach his students generic notions such as
mapping or folding. Ranges are more a D-specific thing.
Also, what's interesting is that when mapping a tree, you can keep its
'shape', whereas pro
On Sat, Jun 7, 2014 at 5:00 PM, MattCoder via Digitalmars-d
wrote:
> Yes this is interesting idead. -But If I remember well, he said to send him
> an e-mail with ideas. So I think you should point him (through e-mail) about
> this topic!
I will. I just wanted to see what other ideas people here
I was watching Chuck Allison talk yesterday, and wondered what
could be a possible homework in D. Maybe other people here have
some ideas, maybe Bearophile will point to RosettaCode, I don't
know. But here is a possible idea:
Trees.
Since you taught them about ranges/lists and functional
map
> Also true, though as a side note, I think a library solution for this could
> be quite nice:
>
> enum newton = 1.as!"kg*m/s^2"; // One possibility.
> enum newton = 1*kg*m/square(s); // Another.
Sorry to intrude, but you can also get:
enum newton = 1.kg/m/s^^2;
Which is quite readable. In
At the very least, it's contradicted by the website:
http://dlang.org/expression#CastExpression
"Casting a value v to a struct S, when value is not a struct of the
same type, is equivalent to: S(v)"
In your case, you have no 'this' in Decimal to accept a Decimal with
other arguments. This should
Linux 64bits here also.
In fact, contrary to the OP belief, it's mainly a Linux crowd here.
People using Windows regularly complain about it, saying we don't see
the way some tools are missing or not working as well on Windows.
> For those who don't know Kenji because he rarely posts on the forums, Brad
> put up a slide at Dconf yesterday showing the top committers by pull
> requests over the last three years and Kenji was at the top for '12 and '13.
> He was second so far this year, after Andrej.
>
> I don't know if he w
> No, I think I mentioned that string mixins can't get the context they are
> inserted in. Why would I simply wrap a string mixin around a template mixin
> if there wasn't some purpose that string mixins couldn't use in the first
> place?
OK. I just preferred to ask, to be sure.
> Hence you can't
That's probably not the solution you want, but could you use direct
string mixins?
import std.stdio;
string B() { return `void foo(double d) { writeln("foo(double)"); }`; }
class C
{
void foo(int x) { writeln("x"); }
mixin(B());
}
void main() {
auto c = new C();
c.foo(1.3);
}
On Sun, Mar 23, 2014 at 7:10 PM, "Nordlöw" wrote:
> e2ir.c
Probably this one:
https://d.puremagic.com/issues/show_bug.cgi?id=12179
>> And I realized I meant symmetrical. IIRC reflexive means you're your own
>> friend.
>> That would be a very sad message from osrc: the coder you're the most
close
>> is... yourself. Go hide under a rock!
>
>
> http://osrc.dfm.io/MartinNowak
>
>> Martin's developer personality is very similar to
>
>> Friendship is neither reflexive, nor transitive :-)
>
>
> Not even friendship in D :)
And I realized I meant symmetrical. IIRC reflexive means you're your own
friend.
That would be a very sad message from osrc: the coder you're the most close
is... yourself. Go hide under a rock!
Anyway... T
Le 22 févr. 2014 16:10, "Jacob Carlborg" a écrit :
>
> On 2014-02-22 04:07, Orvid King wrote:
>
>> Apparently I am a C# coder (have been for the last 3 years, only came
>> into real D dev within the last year or so), and yet "It seems like
>> Orvid is—or should be—friends with jacob-carlborg."
>
>
>> And it creates new compliments every time you refresh. Mirror mirror
>> on the wall..
>
>
> LOL! Simply genious :)
> I'm going to refresh until I have all of them, and I'll print them on my
CV. "The internet says so, so it must be true!"
>
The Internet says I'm an exceptional coder *and* a soci
On Wed, Feb 19, 2014 at 2:18 PM, Bienlein wrote:
> I see. Unhappily, I don't have a D compiler handy. Would this compile:
>
> immutable s = ["red", "blue"].sum
>
> If not, it would be interesting to understand how that works :-)
It won't work, since binary + is not defined for strings. I don't
un
On Wed, Feb 19, 2014 at 1:29 PM, Bienlein wrote:
> There is the nice old Smalltalk-80 inject:into: method in the Collection
> class:
> A little more general ;-). The Scala guys have also cloned it where it is
> called foldLeft.
Oh, but D has `reduce`, for years now. It was maybe one of the very
> BTW, the differences in results is not due to optimization, but to dmd
> keeping intermediate results to 80 bits of precision, while other compilers
> are doing 64 bit precision on intermediate results.
OK, well noted. It also seems many languages silently use the same C
library to power their m
> Floating point sucks like that.
Looks like a mail signature :-)
> LDC2 optimizes this code even worse than DMD.
I naively thought that optimizations did not change computation results.
I guess it's no different from C: same ocode, same computer, but
different compiler => different results.
Oh well...
I was reading this thread on the Clojure Google group:
https://groups.google.com/forum/#!topic/clojure/kFNxGrRPf2k
Where the guy is mostly computing (converting from the C++ code):
import std.math;
import std.stdio;
double g(double x) {
return sin(2.3*x) + cos(3.7*x);
}
void main() {
On Wed, Dec 25, 2013 at 5:47 PM, Andrei Alexandrescu
wrote:
> On 12/25/13 8:29 AM, Gordon wrote:
>> For completeness (since we're dealing with timing):
>>
>> 1. Running the above code with Garbage-collection enabled, takes 1m45s.
>>
>> 2. Running it with GC disabled takes 50s .
>>
>> 3. Running wi
Out of curiosity, do you know which one of his 3 suggestions brought you
the highest speed boost? What happens if you do not disable the GC, for
example?
On Mon, Dec 23, 2013 at 7:34 PM, Andrej Mitrovic
wrote:
> I'm waiting to see what others who use TypeTuples think of the DIP.
> E.g. Philippe Sigaud, David Nadlinger, Hara Kenji, Martin Nowak, Don
> Clugston, David Simcha, Steven Schveighoffer, etc. I'm pretty sure
> (m
> Is there a way to get cpu usage to dynamically set the parallel options ?
> Conclusion :
> So it would be useful to have a "std" way to set the nice of the pid, and
> get the cpu usage and eventually deciding on which core -obviously the least
> busy- the parallel will start on and then, eventua
>> After reviewing the API and comparing it to the C API, I think
>> you did a fine job accomplishing this.
I concur. zmqd user code looks much cleaner than the original C code.
Kudos to you!
I also like the docs. I see you used your own ddoc file
(https://github.com/kyllingstad/ltkdoc). Clean an
On Sun, Dec 15, 2013 at 8:59 AM, Joseph Rushton Wakeling
wrote:
> On Sunday, 15 December 2013 at 07:26:30 UTC, logicchains wrote:
>>
>> What about using a preprocessor? Wouldn't be hard to have it turn all ¡
>> into !.
>
>
> That's my Spanish program buggered, then.
In Spanish D, we put ¡ *around
On Tue, Dec 10, 2013 at 12:02 AM, Ali Çehreli wrote:
> On 12/09/2013 10:02 AM, Philippe Sigaud wrote:
>> What issues and limitations?
>>
>
> Nothing major and nothing more than you and I have already discussed: ;)
>
> http://forum.dlang.org/post/l579tu$2vta$1...@digit
On Mon, Dec 9, 2013 at 1:42 AM, Ali Çehreli wrote:
>>> What format used Ali? HTML?
>>
>> DDoc ;-)
>
> I wanted to use what D offered partly to also learn DDoc. DDoc has some
> issues and apparently some limitations but it worked for me.
What issues and limitations?
On Sun, Dec 8, 2013 at 10:29 PM, Andrei Alexandrescu
wrote:
> On 12/8/13 1:22 PM, Raphaël Jakse wrote:
>>
>> To be fair, I used Whata! mainly because I am the author of this syntax
>> and I'm used to it.
>
>
> I'd say that's a perfectly reasonable answer.
Well, using Ddoc would be a good demonstr
First, kudos for translating all this! I'm sure that'll be a good
reference and maybe pave the way for other translations (Spanish,
German & Japanese come to mind).
I have a few questions:
- why did you use this whata! language instead of a standard format,
like markdown or even ddoc? At least th
On Wed, Dec 4, 2013 at 6:13 AM, Meta wrote:
> On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
>>
>> Pull request please. Also does everybody like the graphics at the top of
>> http://dconf.org/2014/index.html?
>>
>> Andrei
>
>
> The space between the 0, 1 and 4 in 2014 is m
No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
Works with 5 or 6 case's also.
On Mon, Nov 25, 2013 at 7:10 PM, Philippe Sigaud
wrote:
> Good idea, it's something I tend to forget. I always create associated
> functions when an anony...
Arg, damn gmail. ... when an anonymous one would be enough (and would
not clutter the namespace)
Good idea, it's something I tend to forget. I always create associated
functions when an anony...
On Sun, Nov 24, 2013 at 9:54 PM, Shammah Chancellor
wrote:
> On 2013-11-24 19:42:11 +0000, Philippe Sigaud said:
>
>> The consensus might well be 'use recursion' :) That's what I'd do in
>> your case. CT computation on types is a lot like functional
>
> But I can't undersatnd how to make some kind of compile-time
> variable. If we have advanced metaprogramming features I think possibility
> of defining compile-time variables is needed. Am I right or not?
That's what we all want, but it's more or less impossible. If your
variable do not change t
On Sun, Nov 24, 2013 at 8:09 PM, Uranuz wrote:
> As far as I understand I can't use immutable values as template arguments.
Indeed not. They are not defined at compile-time.
> //Some template method
> void foo(string arg)()
> { //Some actions here
>
> }
>
> void main()
> {
> foreach( nam
On Sun, Nov 24, 2013 at 9:06 PM, John Colvin
wrote:
>> You can have a look there:
>>
>> https://github.com/PhilippeSigaud/dranges/blob/master/tuple.d
>>
>> and
>>
>> https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d
>>
>> (this one was fun: regex on type tuples!)
>> https://github
On Sun, Nov 24, 2013 at 8:46 PM, John Colvin
wrote:
> However, the current set of tools is a bit lacking in that department.
> Hopefully I'll be able to rectify this with my attempt at a proper std.meta
> package :) Unfortunately, it's proving to a bit of a stress-test on some
> dustier parts o
On Sun, Nov 24, 2013 at 6:40 PM, Shammah Chancellor
wrote:
> However, for non-string templates. They have to be written in a recursive
> form, which can be particularly difficult in some cases.
>
> template FooTemplate() //This code is totally made up and not meant
> to do anything us
On Sun, Nov 24, 2013 at 5:19 PM, monarch_dodra wrote:
> This is cleaner, IMO.
Well, in an ideal world, we wouldn't have to fall back to these contortions.
On Sun, Nov 24, 2013 at 5:14 PM, Uranuz wrote:
> Thanks! I'll try it. Another question is can I use immutable variables in
> compile time or they are just runtime variables that are once initialized
> and can't be modified? Is it only way to use manifest constants (enum). And
> what is semantics o
Geez, I just spent 15' trying to make this work! AA + Compile-time are
like oil and water.
You can use CTFE and an initializing function. It's a bit cumbersome,
but it works.
module main;
import std.stdio;
string[int][string] initializePohod()
{
string[int][string] result;
result["vid"]
On Tue, Nov 19, 2013 at 11:31 PM, Timon Gehr wrote:
>
> In essence, the following is easily possible in theory:
>
> mixin ADT!q{
> List(T):
> | Nil
> | Cons T List!T
> };
>
> auto list(R)(R r) if(isInputRange!R){
> if(r.empty) return Nil!(ElementType!R);
> auto f = r.front;
> r.pop
On Sun, Nov 17, 2013 at 8:41 PM, Simen Kjærås wrote:
> Source is attached. I hope God forgives me.
Nice ideas. I particularly like this one:
final abstract class Args {
@property
static auto opDispatch(string name, Arg)(Arg arg) {
return NamedArg!(name, Arg)(arg);
}
}
Which
On Tue, Nov 12, 2013 at 9:55 PM, Dmitry Olshansky wrote:
> If we just had:
>
> //this would invoke compiler's parser at CTFE
> auto ast = "x = y;".astof
>
> and have it work at CTFE to return sensible AST (a big if btw).
>
> And then (after some manipulations):
> ast.toString() //get back a strin
On Sat, Nov 9, 2013 at 11:42 AM, Paulo Pinto wrote:
>
> For example, in Portugal and African Portuguese speaking countries, we
> rather mix English technical terms with Portuguese even when a translation
> does exist, whereas in Brazil they tend to choose other words.
>
> My experience leaving in
On Sat, Nov 9, 2013 at 11:31 AM, matovitch wrote:
>
>>
> Thanks. I forked the D template tutorial of Philipp Sigaud to start a
> french translation : https://github.com/matovitch/D-templates-tutorial.
> Feel free to clone ! :-)
>
> Templates are a strong features of D and I think they deserve to b
On Sat, Nov 9, 2013 at 8:43 AM, Raphaël Jakse wrote:
> Le 09/11/2013 08:21, John J a écrit :
>
> On 11/09/2013 01:40 AM, Philippe Sigaud wrote:
>>
>>> I don't even know how to say 'template' in French.
>>>
>>>
>> Do they really need
On Sat, Nov 9, 2013 at 8:21 AM, John J wrote:
> On 11/09/2013 01:40 AM, Philippe Sigaud wrote:
>
>> I don't even know how to say 'template' in French.
>>
>>
> Do they really need to translate keywords like 'template' into French, for
> t
On Friday, November 08, 2013 20:16:44 Timothee Cour wrote:
> > french as well (although living in US).
> > A great start would be lobbying so that they teach D in French
> Engineering
> > schools ... instead of ocaml.
>
Did they teach you ocaml? I had C, with maybe a dash of C++.
> > I'll probab
French here also. I'll have a look at this forum!
As for Ali's book in French, I didn't know there was any translating being
done. Can we help? Are there any similar processes for other languages?
I now realize that I've never even *thought* about D in French, and I've
been using D since 2008. I
On Tue, Nov 5, 2013 at 6:45 PM, Martin Nowak wrote:
> On 11/03/2013 02:45 AM, Timothee Cour wrote:
>
>> 1)
>> The main issue I see with pegged is PEG grammars don't support left
>> recursion, so for example will fail on foo[1].bar(2).fun().
>> Unless there's a plan to accomodate those, I sense a
On Tue, Nov 5, 2013 at 6:39 PM, Martin Nowak wrote:
>
>> Like many others I'm hoping for a nice general parser generator for quite
> some time.
> So I'm also asking specifically about your insights on PEGs.
> From what I know they do have some memory issues due to the backtrace
> memoization (onl
On Wed, Nov 6, 2013 at 9:34 AM, Chad Joan wrote:
> On Wednesday, 6 November 2013 at 08:19:13 UTC, Jacob Carlborg wrote:
>
>> On 2013-11-05 17:55, Philippe Sigaud wrote:
>>
>> Walter is far from convinced that AST manipulation is a good thing. You
>>> would hav
On Wed, Nov 6, 2013 at 9:19 AM, Jacob Carlborg wrote:
>
> You know, Walter did a talk about AST macros at the first D conference.
> The idea back then was to add AST macros, hence the "macro" keyword.
I know. But since then, I guess he changed his mind, or thought about it a
bit more :-)
On Tue, Nov 5, 2013 at 8:27 AM, Brian Schott wrote:
> But we should take a step back first. Before we try to implement a parser
> for D's grammar, we need to figure out what exactly D's grammar is.
>
> Seriously. We don't have a real grammar for D. We have the language spec
> on dlang.org, but it
On Tue, Nov 5, 2013 at 3:54 PM, Dmitry Olshansky wrote:
>
>
>
> I was also toying with the idea of exposing Builder interface for
> std.regex. But push/pop IMHO are better be implicitly designed-out:
>
> auto re = atom('x').star(charClass(unicode.Letter),atom('y')).build();
>
> ... and letting the
On Tue, Nov 5, 2013 at 5:45 AM, Chad Joan wrote:
> Use the repetition operator(s) and turn the resulting array into
>> whatever tree you like. In practice, I have never had a problem with this.
>>
>> I have used both Pegged and have written an SQL parser at work (not
>> exhaustive, just what's
On Mon, Nov 4, 2013 at 1:55 AM, Timothee Cour wrote:
>
> I guess I'll have to write a CT-compatible LALR(1) engine...
>>
>>
>> D does not fit into LALR(1), you need glr.
>>
>
Well, too bad. GLR is also on my plate, but I fear its cubic behavior
(IIRC, it degrades gracefully, though).
Do you know w
I *used* the grammar, obviously. Suing could be an option to disallow
left-recursion, but let's explore other ways for now.
On Mon, Nov 4, 2013 at 6:46 AM, Philippe Sigaud
wrote:
> On Mon, Nov 4, 2013 at 1:58 AM, Timothee Cour wrote:
>
>>
>> On Sat, Nov 2, 2013 at 1
On Sun, Nov 3, 2013 at 7:08 PM, Timothee Cour wrote:
>
> On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud > wrote:
>
>>
>> My current plan is to write different engines, and letting either the
>> user select them at compile-time, or to have the parser decide which o
On Mon, Nov 4, 2013 at 1:58 AM, Timothee Cour wrote:
>
> On Sat, Nov 2, 2013 at 1:19 AM, Philippe Sigaud > wrote:
>
>>
>> Note that Pegged has no problem with the official C grammar or the
>> officiel XML specification...
>>
>
> how do you handle le
On Sun, Nov 3, 2013 at 2:45 AM, Timothee Cour wrote:
> 1)
> The main issue I see with pegged is PEG grammars don't support left
> recursion, so for example will fail on foo[1].bar(2).fun().
> Unless there's a plan to accomodate those, I sense a dead end.
> One can eliminate left recursion but this
Manfred:
>One prerequisite for every PEG-Parser is, that
>the language has to be designed to be without any ambiguity.
>
>This is not the case for D, because of its evolution
> based on recursive descent parsing including tricks.
>
>It is therefore not sufficient to eliminate bugs in Pegged.
That'
The examples directory shows different grammars, from JSON to XML to C to D.
I used it with the D grammar, but the one on the website is woefully
inadequate (some mistakes, out of date compared to the compiler and written
in a somewhat convoluted style full of left-recursion). The shortcomings
are
Do you want to evaluate an expression at CT or to parse an expression?
D has a powerful constant-folding step during compilation, where whole
functions can be evaluated, provided they contain only a subset of D
(almost all of D, except taking adresses/pointers and generating classes,
IIRC).
http:
> However in an old discussion someone said that the D grammar isn't LALR(1)
> or LR(1), so I don't think that is possible with current D parser
> generators. Do we have a pegged grammar for D?
>
Yes, it comes with the project. But, it's still buggy (sometimes due to my
own mistakes, sometimes due
On Sun, Mar 24, 2013 at 11:15 AM, Jacob Carlborg wrote:
>> auto result = nfoo(q{z = "Title", x = 1, y = 100}); // nfoo will parse
>> the input string
>>
>> I rather like this one. Why did you ditch it?
>
> That would requires compile time values, i.e. no variables.
You're right.
> It's now looking pretty close to the ideal D syntax:
> auto a=fun(z:3,x:4);
The last time I tried this (maybe 2 years ago, so before
std.traits.ParameterNameTuple?), I used associative arrays:
alias nfoo = named!foo; // nfoo is now a function admitting AA as arguments
auto result = nfoo(["z":"
On Sat, Mar 23, 2013 at 12:57 PM, Martin wrote:
> On Saturday, 23 March 2013 at 11:55:37 UTC, Andrej Mitrovic wrote:
>>
>> On Saturday, 23 March 2013 at 10:46:11 UTC, Martin wrote:
>>>
>>>enum allMembers = __traits(allMembers, T);
>>
>>
>> Try:
>> enum allMembers = [__traits(allMembers, T
>> - Upon instantiating a new random access range, 'r.front == r[0]', and
>> then after 'r.popFront()', 'r.front == r[1]', etc.
>
> This should be relatively easy to check.
Is that really the behaviour for RA ranges? I'd say that after calling
r.popFront(), then r.front == r[0].
The test could b
>> (* Knowing the guts of a front end means you can decide to add type
>> system and syntax extensions for private use. :P)
>
> Ah, I see where the wind blows ;)
Or, even better, an extensible FE with commonly distributed extensions
like the Haskell compiler. And, of course, an AST macro system an
>
>> Use an alias:
>>
>> string GetMembers(alias T)() {
>
>
> Excellent. An alias parameter is just what I was looking for. Thanks,
> everyone!
Ben,
I present some ideas on this problem in a template tutorial you can find here:
https://github.com/PhilippeSigaud/D-templates-tutorial
In the pdf,
>> This link does not work for me :(
>
>
>
> Yeah sorry, I found a bug in it, so I took it off and fixed it (... or so I
> think).
> I wouldn't be surprised if it's still buggy.
>
> It's more of a proof of concept than anything... it definitely has room for
> improvement, but the speed is still dec
On Mon, Jan 28, 2013 at 12:43 PM, Mehrdad wrote:
> https://gist.github.com/b10ae22ab822c87467a3
This link does not work for me :(
> The hint is that your question is a bit faulty: by calling it "the D
> grammar" do you mean the exact one listed on the website or any equivalent
> that parses the same language (including the ones obtained by simple
> transformations)?
The latter. The one I use for Pegged to generate (what is h
>> ... which is exactly what parsing expression grammars (and other
>> scannerless parsers) do.
>>
>
> That is only a happenstance and is highly overrated. What does it buy you is
> the right question to ask. After all every LL-parser can be written avoiding
> notion of lexer and strangely I see no
> I concur. One of the biggest reason* there is a separate lexer step is
> because it could be made to do this stage very-very fast. Then the rest of
> the parser will greatly benefit from this underlying speed.
>
> *Otherwise we could have just as well add the lexer stage as simple rules to
> the
1 - 100 of 534 matches
Mail list logo
