Expose tags and styles for sequences and mappings in Text.Libyaml #141
Conversation
This brings sequence and mapping more into line with scalars
And added separate sequence and mapping style enums.
src/Text/Libyaml.hs
Outdated
| data SequenceStyle = AnySequence | BlockSequence | FlowSequence | ||
| deriving (Show, Eq, Enum, Bounded, Ord, Data, Typeable) | ||
|
|
||
| data MappingStyle = AnyMapping | BlockMapping | FlowMapping |
There was a problem hiding this comment.
What's the semantics for AnyMapping?
There was a problem hiding this comment.
See slightly fuller note below. I understand AnyMapping / AnySequence express no preference as to style to emit (block being in most cases the default). The parser should always tell you block or flow.
There was a problem hiding this comment.
This is a reasonable API change. I've just recently discovered the need to expose the flow/block style in HsYAML myself, see haskell-hvr/HsYAML@e93a4d4
src/Text/Libyaml.hs
Outdated
| @@ -77,6 +79,12 @@ data Style = Any | |||
| | PlainNoTag | |||
| deriving (Show, Read, Eq, Enum, Bounded, Ord, Data, Typeable) | |||
|
|
|||
| data SequenceStyle = AnySequence | BlockSequence | FlowSequence | |||
There was a problem hiding this comment.
Is there a case where AnySequence will come back from the parser, or is only useful for the emitter?
There was a problem hiding this comment.
AIUI from a reading of the libyaml source, AnySequence and AnyMapping are never produced by the parser (parser.c only references the flow and block constants). They correspond directly to the C enums and the Anys just express no preference as you'd expect. In reality, block is the default barring a few conditions:
e.g.
if (emitter->flow_level || emitter->canonical
|| event->data.mapping_start.style == YAML_FLOW_MAPPING_STYLE
|| yaml_emitter_check_empty_mapping(emitter)) {
emitter->state = YAML_EMIT_FLOW_MAPPING_FIRST_KEY_STATE;
}
else {
emitter->state = YAML_EMIT_BLOCK_MAPPING_FIRST_KEY_STATE;
}(I admit to some unease about the naming I've chosen here, particularly given this is an API change. Happy to accept alternative suggestions!)
stack.yaml
Outdated
| @@ -3,3 +3,6 @@ resolver: lts-11.10 | |||
| flags: | |||
| yaml: | |||
| no-examples: false | |||
|
|
|||
| docker: | |||
| enable: true | |||
There was a problem hiding this comment.
Please remove this, Docker should not be the default for the repo.
There was a problem hiding this comment.
Oops. Accidental, will do.
| @@ -63,6 +63,12 @@ spec = do | |||
| it "count scalars with anchor" caseCountScalarsWithAnchor | |||
| it "count sequences with anchor" caseCountSequencesWithAnchor | |||
| it "count mappings with anchor" caseCountMappingsWithAnchor | |||
| it "count sequences with custom tag" caseCountSequenceTags | |||
|
I've popped a |
src/Text/Libyaml.hs
Outdated
| bsToTag <$> | ||
| if ytag_len' == 0 | ||
| then return Data.ByteString.empty | ||
| else packCStringLen (ytag', ytag_len') |
There was a problem hiding this comment.
Given that under the surface the C code is just using strlen anyway to look for a null-terminating byte, is there a reason to use packCStringLen instead of packCString? It seems like the latter would allow us to simplify the changeset a bit.
src/Text/Libyaml.hs
Outdated
| @@ -77,6 +79,14 @@ data Style = Any | |||
| | PlainNoTag | |||
| deriving (Show, Read, Eq, Enum, Bounded, Ord, Data, Typeable) | |||
|
|
|||
| -- @since 0.9.0 | |||
There was a problem hiding this comment.
This should be -- | @since 0.9.0 to make Haddock recognize it. Bonus points would be a short sentence explaining what the type is used for.
| tagbs <- | ||
| if ytag_len' == 0 | ||
| then return Data.ByteString.empty | ||
| else packCStringLen (ytag', ytag_len') |
There was a problem hiding this comment.
Heh, doh, now I realize why you have it set up this way with the len, I did it that way in the first place. I think my claim that we can use packCString instead still applies, but your call on whether to include that now or if I try it separately after this gets merged.
There was a problem hiding this comment.
Ha. Yep - was trying to make minimal changes here but I didn't understand why the len approach was there. I'll kill it.
There's also some inconsistency between checking null ptrs in the helper C and in the Haskell but it kinda makes sense to unify null and "" for the case checking in the tag case.
|
Removed the len stuff for tag handling - should be functionally identical. We'd get into trouble anyway if a tag contained a null but that's illegal (at least in YAML 1.2 - http://yaml.org/spec/1.2/spec.html#ns-uri-char). Haven't touched the len stuff with the value. Felt like a step too far for this change. |
|
Oops - and have a failing test. Hold off... |
|
Fixed. |
| | EventMappingEnd | ||
| deriving (Show, Eq) | ||
|
|
||
| -- | Style for scalars - e.g. quoted / folded |
There was a problem hiding this comment.
Thank you for cleanups like this 👍
There was a problem hiding this comment.
Well, thank you for the whole library. 👍
This makes tag and style information available on sequences and mappings as well as scalars (at the Text.Libyaml layer - it is not propagated anywhere else).
This would break code using Text.Libyaml because it adds extra fields into the
Eventdata structure....however, I think this is the only sensible way to expose this information. It's definitely an omission at present (although it might very well be an intentional one!). The
Tagdata type includesMapTagandSeqTagbut they'd never be used because tags on mappings and sequences are simply ignored.