Extension talk:NaturalLanguageList

#data:/#ignore: as parameters?
Ever since the introduction of #data: and #ignore:, people have complained about their strange appearance. An intention I made since they were different, but Conrad.Irwin have suggested to use regular parameters instead, then one for each element to ignore, e.g.

Would yield 1, 2, 4 and 6.

data= could be retained to retain what would otherwise be understood as a parameter, e.g. Would yield pie=1, hi=2, ignore=5 and data=9.

I would also suggest to retain 's separator even for the ignore= parameter, e.g.

Would yield 1, 2, 4 and 6.

Reactions? --Svippong 13:17, 25 March 2010 (UTC)

What do with intervals?
I have been talking to cirwin on #mediawiki, and - well - we seem to be in disagreement with what exactly to do with. My argument is that since it is now its own parser function, we can do some more fancy stuff, like steps.

cirwin propose the syntax of a..step..b, e.g. (0..2..10 becoming 0, 2, 4, 6, 8, 10) but also perhaps a variable of |step= such as would produce the exact same list. But since this creates two methods of doing the same thing, cirwin is not entirely in favour of this. At which point I would prefer a..step..b over |step=. But I remain unsure.

In addition, I hope I have not strawman'ed cirwin's comments. --Svippong 21:56, 11 April 2010 (UTC)


 * This is an accurate representation of what I said. And I would prefer to allow only the 1..2..4 syntax.
 * In an ideal world, I would delete as it is not orthogonal to  and, and allow each of the latter to take any number of "interval=1..3" paramters (and if I was being really picky, I'd rename "interval" to "range"). Conrad.Irwin 22:02, 11 April 2010 (UTC)


 * I am still split on this matter. I want to hear Happy-melon's stance.  Maybe he has been swayed. --Svippong 22:14, 11 April 2010 (UTC)


 * They're not split because they're orthogonal, they're split because it stops #list getting so spectacularly feature-rich that it's unusable by ordinary mortals. #rawlist and #list aren't "orthogonal" either. I would definitely oppose a move to recombine them.
 * I'm still not entirely sure about the range syntax generally, but the start..interval..end syntax is definitely better than a mixture. A less flexible, but probably more user-friendly, implementation would be the other side of the coin:   .  But either extreme is better than a medley of the two. Happy ‑ melon 11:40, 13 April 2010 (UTC)


 * My general reasoning for preferring a..i..b over |start=a|step=i|end=b is simple. The latter only allows a single range per    usage.  This may seem trivial (and I realise a combination with  can compensate for this lacking feature), but it would seem vastly problematic to have to create 'hacks' by mere mortals to compensate for us make a flawed design decision. --Svippong 11:52, 13 April 2010 (UTC)


 * Oh and while you both make excellent cases for not including both methods, I am still sort of swayed by the devilish ideals of more than one way to do a thing. The parameter-version is easy on new users, even if it only allows a single indication.  As they grow more advance the syntax-version will become more accustomed to them.  But prove me wrong. --Svippong 11:54, 13 April 2010 (UTC)
 * What happens if you do ? Conrad.Irwin 14:49, 13 April 2010 (UTC)

Random
===

I think you wrote a Turing-complete language :D Happy ‑ melon 21:50, 14 April 2010 (UTC)


 * Are you certain? I cannot get this to work. --Svippong 20:44, 20 April 2010 (UTC)


 * Works. Even though you wrote it, I post it. --Svippong 21:33, 21 April 2010 (UTC)
 * Works. Even though you wrote it, I post it. --Svippong 21:33, 21 April 2010 (UTC)

Issues
Magic word 'list' not found Backtrace:
 * 1) 0 /includes/MagicWord.php(244): Language->getMagic(Object(MagicWord))
 * 2) 1 /includes/MagicWord.php(197): MagicWord->load('list')
 * 3) 2 /includes/parser/Parser.php(4034): MagicWord::get('list')
 * 4) 3 /extensions/NaturalLanguageList/NaturalLanguageList.php(68): Parser->setFunctionHook('list', Array, 2)
 * 5) 4 [internal function]: NaturalLanguageList::onParserFirstCallInit(Object(Parser))

I've installed the extension via require_once( "$IP/extensions/NaturalLanguageList/NaturalLanguageList.php"); but it throws the above errors. --Mhn 15:03, 12 May 2010 (UTC)