On Wed, Aug 1, 2012 at 11:03 PM, Brian Schott <briancschott@gmail.com> wrote:

> It's more likely that I'll remember things if they're enhancement requests/bugs on Github.

Right, I say the same to people asking for things in my projects :) OK, done.

Am Wed, 1 Aug 2012 22:39:41 +0200
schrieb Philippe Sigaud <philippe.sigaud@gmail.com>:

> I just tested the JSON output and it works nicely. Finally, a way to get imports!

What does it do if you import from _inside_ a function ? Not that this would happen often, but it can. :-]

-- 
Marco

On Wednesday, 1 August 2012 at 21:35:08 UTC, Marco Leise wrote:
> Am Wed, 1 Aug 2012 22:39:41 +0200
> schrieb Philippe Sigaud <philippe.sigaud@gmail.com>:
>
>> I just tested the JSON output and it works nicely. Finally, a way to
>> get imports!
>
> What does it do if you import from _inside_ a function ?
> Not that this would happen often, but it can. :-]

It ignores the insides of functions, mostly because writing a full D parser was not a design goal. I'm mostly concerned with autocomplete, ctags, and summarizing. Unfortunately it also ignores the insides of static if and version statements as well. I've thought about having versions be a command line or configuration option, but the only way to handle static if is to actually be a compiler.

On Wed, Aug 1, 2012 at 11:35 PM, Marco Leise <Marco.Leise@gmx.de> wrote:
> Am Wed, 1 Aug 2012 22:39:41 +0200
> schrieb Philippe Sigaud <philippe.sigaud@gmail.com>:
>
>> I just tested the JSON output and it works nicely. Finally, a way to get imports!
>
> What does it do if you import from _inside_ a function ? Not that this would happen often, but it can. :-]

I use them quite frequently in unittest {} blocks, if only to import std.stdio to get why my unittests don't work :)

> I think the best way here is to define a BufferedRange that takes any
> other range and supplies a buffer for it (with the appropriate
> primitives) in a native array.
>
> Andrei

Don't you think, this range stuff is overdone? Define some fancy Range stuff, if an array just works perfectly?

Ranges > Iterators, yes, but I think they are overdone.

> I use them quite frequently in unittest {} blocks, if only to import
> std.stdio to get why my unittests don't work :)

version(unittest) { private import std.stdio; }

^ Place this where you have your other imports and you don't have to import it in your unittest{} blocks.

On 8/1/12 6:23 PM, David wrote:
>> I think the best way here is to define a BufferedRange that takes any
>> other range and supplies a buffer for it (with the appropriate
>> primitives) in a native array.
>>
>> Andrei
>
> Don't you think, this range stuff is overdone? Define some fancy Range
> stuff, if an array just works perfectly?
>
> Ranges > Iterators, yes, but I think they are overdone.

I don't.

Andrei

On Wednesday, 1 August 2012 at 22:31:39 UTC, Andrei Alexandrescu wrote:
> On 8/1/12 6:23 PM, David wrote:
>> Ranges > Iterators, yes, but I think they are overdone.
>
> I don't.

I think the main problem is that you need that abstraction
for Phobos. Whereas if you're writing stuff for yourself,
you don't bother. Even if it's a library for consumption.

I wonder if there's an abstraction that would make defining
a range around some data trivial. Maybe even just a good
article on "why use ranges over X" where X == array of data,
or iterators for the C++ crowd.

I know in SDC's lexer we actually do have things that could
be turned into input and output ranges fairly trivially.

I would be concerned with potential performance ramifications,
though.

-Bernard.

Brian Schott wrote:
> On Wednesday, 1 August 2012 at 17:36:16 UTC, Walter Bright wrote:
>>
>> I suggest proposing the D lexer as an addition to Phobos. But if that
>> is done, its interface would need to accept a range as input, and its
>> output should be a range of tokens.
>
> It used to be range-based, but the performance was terrible. The
> inability to use slicing on a forward-range of characters and the
> gigantic block on KCachegrind labeled "std.utf.decode" were the reasons
> that I chose this approach. I wish I had saved the measurements on this....

Ranges are usually taken as template parameters, so you can use static if to provide different code for arrays and regular ranges.

Le 01/08/2012 23:19, Andrei Alexandrescu a écrit :
> On 8/1/12 5:09 PM, deadalnix wrote:
>> Le 01/08/2012 19:58, Brian Schott a écrit :
>>> On Wednesday, 1 August 2012 at 17:36:16 UTC, Walter Bright wrote:
>>>>
>>>> I suggest proposing the D lexer as an addition to Phobos. But if that
>>>> is done, its interface would need to accept a range as input, and its
>>>> output should be a range of tokens.
>>>
>>> It used to be range-based, but the performance was terrible. The
>>> inability to use slicing on a forward-range of characters and the
>>> gigantic block on KCachegrind labeled "std.utf.decode" were the reasons
>>> that I chose this approach. I wish I had saved the measurements on
>>> this....
>>
>> Maybe a RandomAccessRange could do the trick ?
>
> I think the best way here is to define a BufferedRange that takes any
> other range and supplies a buffer for it (with the appropriate
> primitives) in a native array.
>
> Andrei
>

This make sense. The stuff can be a noop on arrays, and that solve everything.