Don has recently said that adding dynamic arrays at compile-time looks easy.
I'd also like to have compile-time associative arrays. So you can fill them
inside a CT function (the compiler may try to do the same for AAs created
inside a static this(){}), and save some run time.
Even if such compi
language_fan wrote:
> The members of the last group have studied computer science and
> languages, in particular. They have found a pet academic language,
> typically a pure one, but paradigms may differ. In fact this is the group
> which uses something other than the hybrid object-oriented/proc
Don wrote:
> Rainer Deyke wrote:
>> Don't forget that "uses floating point" is a transitive property. Any
>> pure function that calls a pure-but-unmemoisable function is itself
>> pure-but-unmemoisable.
>
> This is incorrect.
Then I must have misunderstood your proposal. Either you did a poor j
On Mon, 14 Sep 2009 18:53:51 -0400, Fawzi Mohamed wrote:
On 2009-09-14 17:07:00 +0200, "Robert Jacques" said:
On Mon, 14 Sep 2009 09:39:51 -0400, Leandro Lucarella
wrote:
Jeremie Pelletier, el 13 de septiembre a las 22:58 me escribiste:
[snip]
I understand your points for using a separ
pc wrote:
[snip]
This looks great, but for inclusion in Phobos I'd love to do two things
about it:
1. Make it work with any ranges of characters, not only strings.
2. Make it lazy, i.e. output a range.
Andrei
Hi Nick,
Thanks. The grammar is already spec'ed for LL ans so looking for the course of
least resistance.
I've used GOLD and spoken with its author, Devin Cook, in the past though.
It's rather cool in a way.
Still it's great to see GOLD coming to a screen in the D village.
> If you can't find
"Justin Johansson" wrote in message
news:h8m6qs$300...@digitalmars.com...
> Can D people please recommend suitable tools for generating a parser (in
> D) for an LL(1) grammar. There's bound to be much better parser generator
> tools available nowadays, since my last foray into this area 10+ ye
language_fan wrote:
In fact this is the group
which uses something other than the hybrid object-oriented/procedural
model.
Damn straight! They use a hybrid OO/procedural/functional model. Like D.
Or C#.
"Oh, but Prolog," you may say. And I admit, I've seen it used a couple
times by academi
On 2009-09-14 17:07:00 +0200, "Robert Jacques" said:
On Mon, 14 Sep 2009 09:39:51 -0400, Leandro Lucarella
wrote:
Jeremie Pelletier, el 13 de septiembre a las 22:58 me escribiste:
[snip]
I understand your points for using a separate memory manager, and
I agree with you that having less act
Lutger Wrote:
> language_fan wrote:
>
> > Mon, 14 Sep 2009 07:33:59 -0400, bearophile thusly wrote:
> >
> >> But lot of people will judge D against more modern languages like C#,
> >> Scala or Java) and not against C.
> >
> > Programmers often belong to three kinds of groups. First come the fan
> I've ported boost::spirit to d. No idea if it does what you want,
> but I've written some fairly complicated grammars with it.
>
> It's not a tool though, you just define your grammar directly in code.
> Which is either a plus or a minus depending on your point of view.
Thanks for all replies,
Justin Johansson wrote:
> Can D people please recommend suitable tools for generating a parser (in D)
> for an LL(1) grammar. There's bound to be much better parser generator tools
> available nowadays, since my last foray into this area 10+ years ago with
> YACC. I've heard of tools like biso
language_fan wrote:
> Mon, 14 Sep 2009 07:33:59 -0400, bearophile thusly wrote:
>
>> But lot of people will judge D against more modern languages like C#,
>> Scala or Java) and not against C.
>
> Programmers often belong to three kinds of groups. First come the fans of
> traditionally weakly typ
On Mon, Sep 14, 2009 at 2:46 PM, div0 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Justin Johansson wrote:
>> Can D people please recommend suitable tools for generating a parser (in D)
>> for an LL(1) grammar. There's bound to be much better parser generator
>> tools available
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Johansson wrote:
> Can D people please recommend suitable tools for generating a parser (in D)
> for an LL(1) grammar. There's bound to be much better parser generator tools
> available nowadays, since my last foray into this area 10+ years a
Can D people please recommend suitable tools for generating a parser (in D) for
an LL(1) grammar. There's bound to be much better parser generator tools
available nowadays, since my last foray into this area 10+ years ago with YACC.
I've heard of tools like bison, SableCC etc but apart from th
Brad Roberts wrote:
Walter Bright wrote:
strlen() is safe, while strcpy() and printf() are not.
You sure? Does running beyond the bounds of the array if there's no null
termination count as safe some how? :)
Yes. Memory safety is defined as being free of memory corruption errors.
Simply re
Walter Bright wrote:
> Don wrote:
>> We could get close, I think. We could catch all violations in SafeD.
>> Disallow calling core.stdc.fenv functions from inside SafeD modules,
>> and provide an RAII object in std.math for changing the rounding mode.
>>
>> Actually there's probably a few other C f
Mon, 14 Sep 2009 07:33:59 -0400, bearophile thusly wrote:
> But lot of people will judge D against more modern languages like C#,
> Scala or Java) and not against C.
Programmers often belong to three kinds of groups. First come the fans of
traditionally weakly typed compiled languages (basic, c,
Hello Lutger,
That's cool, but scrapple is exactly that: an assortment of small(ish)
projects / pieces of code that otherwise don't warrant a full project.
If you feel like putting it online, just ping BCS and I'm sure he'll
give you access right away.
All I need is your dsource user name.
On Mon, 14 Sep 2009 07:44:44 -0400, Jason House
wrote:
Robert Jacques Wrote:
On Sun, 13 Sep 2009 18:08:57 -0400, Jeremie Pelletier
wrote:
.
Bartosz took the concept one step further: when declared as shared, all
methods are implicitly wrapped in synchronize blocks. He then added a
keywo
On Mon, 14 Sep 2009 09:39:51 -0400, Leandro Lucarella
wrote:
Jeremie Pelletier, el 13 de septiembre a las 22:58 me escribiste:
[snip]
I understand your points for using a separate memory manager, and
I agree with you that having less active allocations make for faster
sweeps, no matter how li
Jeremie Pelletier, el 13 de septiembre a las 22:58 me escribiste:
> Tom S Wrote:
>
> > Jeremie Pelletier wrote:
> > > Tom S Wrote:
> > >
> > >> Jeremie Pelletier wrote:
> > >>> I myself allocate all my meshes and textures directly on the GC and I'm
> > >>> pretty sure its faster than C's malloc
On Mon, 14 Sep 2009 16:44:48 +0400, Jason House
wrote:
Don Wrote:
I've provided very simple solutions for both of these. I'm getting
pretty irritated that people are acting as though these are difficult
problems and trying to come up with convoluted solutions. Impose minimal
semantics and i
Don Wrote:
>
> I've provided very simple solutions for both of these. I'm getting
> pretty irritated that people are acting as though these are difficult
> problems and trying to come up with convoluted solutions. Impose minimal
> semantics and it becomes trivial.
FWIW, I've liked your proposa
Robert Jacques Wrote:
> On Sun, 13 Sep 2009 18:08:57 -0400, Jeremie Pelletier
> wrote:
> .
>
> Bartosz took the concept one step further: when declared as shared, all
> methods are implicitly wrapped in synchronize blocks. He then added a
> keyword for more manual, lock-free style programm
Jeremie Pelletier:
>I haven't had to use the C heap whatsoever so far in D, could you give me an
>example of where you need it?<
1) I'm able to allocate a bigger single chunk of memory from the C heap, about
1.8 GB, while the GC heap of DMD on Windows allows only for a smaller chunk. In
a prog
bearophile wrote:
Walter Bright:
Yes, all the C functions will have to be gone through and separated.
strlen() is safe, while strcpy() and printf() are not.
For some of the removed functions better C-like ones can be provided:
http://www.ddj.com/cpp/214502214
Bye,
bearophile
Just use D inst
Walter Bright:
> Yes, all the C functions will have to be gone through and separated.
> strlen() is safe, while strcpy() and printf() are not.
For some of the removed functions better C-like ones can be provided:
http://www.ddj.com/cpp/214502214
Bye,
bearophile
Rainer Deyke wrote:
Don wrote:
The pure function memoisation issue:
Certain functions may be marked as 'pure', even though they use floating
point (and are therefore dependent on the FP state). The compiler must
be able to prevent memoisation of those functions in cases where the
rounding mode m
Don wrote:
Walter Bright wrote:
bearophile wrote:
An important purpose of a not bug-prone language is remove as many
undefined situations as possible.
That's right.
If you add that to D2 specs, can
the compiler catch at compile time all cases of violations to that
rule?
Unlikely. But that
Don wrote:
> The pure function memoisation issue:
> Certain functions may be marked as 'pure', even though they use floating
> point (and are therefore dependent on the FP state). The compiler must
> be able to prevent memoisation of those functions in cases where the
> rounding mode may have chang
Walter Bright wrote:
bearophile wrote:
An important purpose of a not bug-prone language is remove as many
undefined situations as possible.
That's right.
If you add that to D2 specs, can
the compiler catch at compile time all cases of violations to that
rule?
Unlikely. But that has to be w
Robert Jacques Wrote:
> On Sun, 13 Sep 2009 18:08:57 -0400, Jeremie Pelletier
> wrote:
>
> > Robert Jacques Wrote:
> >
> >> On Sun, 13 Sep 2009 15:04:57 -0400, Jeremie Pelletier
> >>
> >> wrote:
> >> [snip]
> >> > Unique data could only be used for aggregate properties,
> >> const/immutab
Stewart Gordon wrote:
Don wrote:
Floating point settings are just another case of the same thing,
except that currently violations in relation to the former are allowed.
There's a fundamental difference between them: the floating point
settings are a hardware feature and it is IMPOSSIBLE to
Nick B Wrote:
> Jeremie Pelletier wrote:
> > Tom S Wrote:
> >
> >> Jeremie Pelletier wrote:
> >>> Tom S Wrote:
> >>>
> Jeremie Pelletier wrote:
> > I myself allocate all my meshes and textures directly on the GC and I'm
> > pretty sure its faster than C's malloc and much safer.
> >>
36 matches
Mail list logo
