In the [p]map command, we now support a comma-delimited list of species. It would be good to formally support multiple species in the parser, and also a shorthand for multiple in the same genus, e.g. instead of:
[p]map Spilomyia sayi, S. fusca, S. longicornis
[p]map Spilomyia sayi, S fusca, S longicornis
and this should be subtly different, in that the Genus is plotted on the map separately, and then the 3 species:
[p]map Spilomyia, S sayi, S fusca, S longicornis
Because of autocapitalization and other usability difficulties on mobile devices, case should not be significant, i.e. this should be equivalent:
[p]map spilomyia, s sayi, s fusca, s longicornis
To avoid confusion, limit the abbreviation expansion to:
an earlier genus query appeared in the list
that started with the same initial
that matches the first letters of the genus
So this would be valid following this rule:
[p]map spi in syrph, s sayi, s fusca, s longi
But this would fail on the 3rd point:
[p]map hawkweed, h venosum
The problem is that although "hawkweed" matches Hieracium, that they both start with "h" is accidental, and therefore not something that is reliable or dependable. Therefore, it's best not to make it seem like it is supported.
Currently there are only these two kinds of query:
SimpleQuery
is a query for a single taxon
CompoundQuery
is a query for two taxa: the main (child) query and ancestor query, which are performed ancestor first, and child 2nd
To this, we'd add a third kind:
ListQuery
one or more comma-delimited queries in a list
returning a list containing one taxon per successful query
if any are missing, normally a LookupError would be raised
though it would be up to the command using the ListQuery to decide how to implement this
i.e. it may in some contexts be helpful to just omit the non-matching query, though this is not the case with [p]inat map at this time; it fails the whole query
A ListQuery would be processed right-to-left with any entries that are genus (see Note below) or lower having their genus put temporarily into a dict by 1st letter of the genus as the list is processed (provided the query had one term and all its letters are the 1st letters of the matched genus). Then if any subsequent query terms starts with a single letter, the most recently matching genus would be substituted. if that fails, then the letter should simply be looked up in the usual way.
Note: Hybrids are a tricky corner case. I guess it's possible to have a query like "Agenusepithet1 × A epithet2" or even, once the genus is named: "Agenus, A epithet1 x epithet2", or even "Agenus1epithet1 × Bgenus2epithet2", "A epithet3", "B epithet4". Ideally, any convention that is used in the literature should be supported, but we could start with the simple cases first and leave these until later.
That reminds me that this isn't the only case that should be supported. Trinomial names are another to support in a list, e.g. "Agenus bepithet1, A b epithet2" should supported.
In the
[p]mapcommand, we now support a comma-delimited list of species. It would be good to formally support multiple species in the parser, and also a shorthand for multiple in the same genus, e.g. instead of:either of these should be equivalent:
and this should be subtly different, in that the Genus is plotted on the map separately, and then the 3 species:
Because of autocapitalization and other usability difficulties on mobile devices, case should not be significant, i.e. this should be equivalent:
To avoid confusion, limit the abbreviation expansion to:
So this would be valid following this rule:
But this would fail on the 3rd point:
The problem is that although "hawkweed" matches Hieracium, that they both start with "h" is accidental, and therefore not something that is reliable or dependable. Therefore, it's best not to make it seem like it is supported.
Currently there are only these two kinds of query:
To this, we'd add a third kind:
[p]inat mapat this time; it fails the whole queryA ListQuery would be processed right-to-left with any entries that are genus (see Note below) or lower having their genus put temporarily into a dict by 1st letter of the genus as the list is processed (provided the query had one term and all its letters are the 1st letters of the matched genus). Then if any subsequent query terms starts with a single letter, the most recently matching genus would be substituted. if that fails, then the letter should simply be looked up in the usual way.
Note: Hybrids are a tricky corner case. I guess it's possible to have a query like "Agenus epithet1 × A epithet2" or even, once the genus is named: "Agenus, A epithet1 x epithet2", or even "Agenus1 epithet1 × Bgenus2 epithet2", "A epithet3", "B epithet4". Ideally, any convention that is used in the literature should be supported, but we could start with the simple cases first and leave these until later.
That reminds me that this isn't the only case that should be supported. Trinomial names are another to support in a list, e.g. "Agenus bepithet1, A b epithet2" should supported.