On 14/02/2018 10:32 AM, Jonathan M Davis wrote:
> On Wednesday, February 14, 2018 10:14:44 Kagamin via Digitalmars-d-announce
> wrote:
>> It looks like EntityRange requires forward range, is it ok for a
>> parser?
> 
> It's very difficult in general to write a parser that isn't at least a
> forward range, because without that, you're stuck at only one character of
> look ahead unless you play a lot of games with putting data from the input
> range in a buffer so that you can keep it around to look at it again after
> you've looked farther ahead.
> 
> Honestly, pure input ranges are borderline useless for a _lot_ of cases.
> It's generally only the cases where you only care about operating on each
> element individually irrespective of what's going on with other elements in
> the range that pure input ranges are really useable, and parsing definitely
> doesn't fall into that camp.
> 
> - Jonathan M Davis

See lines:
- Input!IR temp = input;
- input = temp;

           bool commentLine() {
		Input!IR temp = input;

		if (!temp.empty && temp.front.c == '/') {
			temp.popFront;
			if (!temp.empty && temp.front.c == '/')
				temp.popFront;
			else
				return false;
		} else
			return false;

		if (!temp.empty) {
			size_t endOffset = temp.front.location.fileOffset;

			while(temp.front.location.lineOffset != 0) {
				endOffset = temp.front.location.fileOffset;
				temp.popFront;

				if (temp.empty) {
					endOffset++;
					break;
				}
			}
			
			current.type = Token.Type.Comment_Line;
			current.location = input.front.location;
			current.location.length = endOffset - input.front.location.fileOffset;
			
			input = temp;
			return true;
		} else
			return false;
	}

On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
> See lines:
> - Input!IR temp = input;
> - input = temp;
>
>            bool commentLine() {
> 		Input!IR temp = input;
>
> (...)
> 		if (!temp.empty) {
> (...)		
> 			input = temp;
> 			return true;
> 		} else
> 			return false;
> 	}

`temp = input.save` is exactly what you want here, which means forward range is required. Your example won't work for range objects with reference semantics.

On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
>> See lines:
>> - Input!IR temp = input;
>> - input = temp;
>>
>>            bool commentLine() {
>>         Input!IR temp = input;
>>
>> (...)
>>         if (!temp.empty) {
>> (...)
>>             input = temp;
>>             return true;
>>         } else
>>             return false;
>>     }
> 
> `temp = input.save` is exactly what you want here, which means forward range is required. Your example won't work for range objects with reference semantics.

Ah I must be thinking of ranges that support indexing.

On Wednesday, February 14, 2018 14:09:21 rikki cattermole via Digitalmars-d- announce wrote:
> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> > On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
> >> See lines:
> >> - Input!IR temp = input;
> >> - input = temp;
> >>
> >>            bool commentLine() {
> >>         Input!IR temp = input;
> >>
> >> (...)
> >>         if (!temp.empty) {
> >> (...)
> >>             input = temp;
> >>             return true;
> >>         } else
> >>             return false;
> >>     }
> >
> > `temp = input.save` is exactly what you want here, which means forward range is required. Your example won't work for range objects with reference semantics.
>
> Ah I must be thinking of ranges that support indexing.

Random access ranges are also forward ranges and would require a call to save here.

- Jonathan M Davis

On 14/02/2018 5:13 PM, Jonathan M Davis wrote:
> On Wednesday, February 14, 2018 14:09:21 rikki cattermole via Digitalmars-d-
> announce wrote:
>> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
>>> On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
>>>> See lines:
>>>> - Input!IR temp = input;
>>>> - input = temp;
>>>>
>>>>             bool commentLine() {
>>>>          Input!IR temp = input;
>>>>
>>>> (...)
>>>>          if (!temp.empty) {
>>>> (...)
>>>>              input = temp;
>>>>              return true;
>>>>          } else
>>>>              return false;
>>>>      }
>>>
>>> `temp = input.save` is exactly what you want here, which means forward
>>> range is required. Your example won't work for range objects with
>>> reference semantics.
>>
>> Ah I must be thinking of ranges that support indexing.
> 
> Random access ranges are also forward ranges and would require a call to
> save here.
> 
> - Jonathan M Davis
> 

Luckily in my code I can forget that ;)

On Thursday, February 15, 2018 01:55:28 rikki cattermole via Digitalmars-d- announce wrote:
> On 14/02/2018 5:13 PM, Jonathan M Davis wrote:
> > On Wednesday, February 14, 2018 14:09:21 rikki cattermole via
> > Digitalmars-d->
> > announce wrote:
> >> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> >>> On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole
wrote:
> >>>> See lines:
> >>>> - Input!IR temp = input;
> >>>> - input = temp;
> >>>>
> >>>>             bool commentLine() {
> >>>>
> >>>>          Input!IR temp = input;
> >>>>
> >>>> (...)
> >>>>
> >>>>          if (!temp.empty) {
> >>>>
> >>>> (...)
> >>>>
> >>>>              input = temp;
> >>>>              return true;
> >>>>
> >>>>          } else
> >>>>
> >>>>              return false;
> >>>>
> >>>>      }
> >>>
> >>> `temp = input.save` is exactly what you want here, which means forward range is required. Your example won't work for range objects with reference semantics.
> >>
> >> Ah I must be thinking of ranges that support indexing.
> >
> > Random access ranges are also forward ranges and would require a call to save here.
> >
> > - Jonathan M Davis
>
> Luckily in my code I can forget that ;)

LOL. That's actually part of what makes writing range-based libraries so much harder to get right than simply using ranges in your program. When a piece of code is used with only a few types of ranges (or even only one type of range, as is often the case), then it's generally not very hard to write code that works just fine, but as soon as you have to worry about arbitrary ranges, you get all kinds of nonsense that you have to worry about in order to make sure that the code works correctly for any range that's passed to it. save is the classic example of something that a lot of range-based code gets wrong, because for most ranges, it really doesn't matter, but for those ranges where it does, a single missed call to save results in code that doesn't work properly. To get it right, you basically have to call save every time you pass a range to a range-based function that is not supposed to consume the range, and folks rarely get that right. Certainly, pretty much any range-based code that doesn't have unit tests which include reference-type ranges is going to be wrong for reference-type ranges. Even Phobos has had quite a few issues with that historically.

- Jonathan M Davis

On Thursday, 15 February 2018 at 02:40:03 UTC, Jonathan M Davis wrote:
>
> LOL. That's actually part of what makes writing range-based libraries so much harder to get right than simply using ranges in your program. [snip]

That sounds like an interesting topic for a blog post.

On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis wrote:
> dxml 0.2.0 has now been released.
> Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/
> Github: https://github.com/jmdavis/dxml/tree/v0.2.0
> Dub: http://code.dlang.org/packages/dxml
>
> - Jonathan M Davis

This is absolutely awesome. It is a little low level (compared to SAX) so there is more to deal with, but having this provide a range (and flat) makes it so much clearer the ordering of elements. If I need to handle nesting then I can build that out, but if I don't I can just fly by the seat of my pants and grab the elements I want.

This will definitely be my goto for XML parsing.

On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis wrote:
> Folks are free to decide to support dxml for inclusion when the time comes and free to vote it as unacceptable. Personally, I think that dxml's approach is ideal for XML that doesn't use entity references, and I'd much rather use that kind of parser regardless of whether it's in the standard library or not. I think that the D community would be far better off with std.xml being replaced by dxml, but whatever happens happens.
Bump!
I'm using dxml now, and it's a very good library. So I thought "it should be in Phobos instead of std.xml" and searched the newsgroup. Sorry for necroposting. Anyway, what I wanted to say is just take an example from Perl and call it std.xml.simple. Then people would know what to expect from it and would use it (because everyone likes simple). That would also leave a way to include std.xml.full (or some such) at some indefinite point in the future. Which is, in practice, probably never - and that's fine, because who needs DTD? screw it...
Anyway, thanks for the library, Jonathan.

On Thu, Aug 30, 2018 at 07:26:28PM +0000, nkm1 via Digitalmars-d-announce wrote:
> On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis wrote:
> > Folks are free to decide to support dxml for inclusion when the time comes and free to vote it as unacceptable. Personally, I think that dxml's approach is ideal for XML that doesn't use entity references, and I'd much rather use that kind of parser regardless of whether it's in the standard library or not. I think that the D community would be far better off with std.xml being replaced by dxml, but whatever happens happens.

+1.  I vote for adding dxml to Phobos.


[...]
> I'm using dxml now, and it's a very good library. So I thought "it should be in Phobos instead of std.xml" and searched the newsgroup. Sorry for necroposting. Anyway, what I wanted to say is just take an example from Perl and call it std.xml.simple. Then people would know what to expect from it and would use it (because everyone likes simple). That would also leave a way to include std.xml.full (or some such) at some indefinite point in the future. Which is, in practice, probably never - and that's fine, because who needs DTD? screw it...
[...]

That's a good idea, actually.  That will stop people who expect full DTD support from complaining that it's not supported by the standard library.

I vote for adding dxml to Phobos as std.xml.simple.  We can either leave std.xml as-is, or deprecate it and work on std.xml.full (or std.xml.complex, or whatever).  The current state of std.xml gives a poor impression to anyone coming to D the first time and wanting to work with XML, and having std.xml.simple would be a big plus.


T

-- 
This is not a sentence.