Rosetta Code:Village Pump/Automatic omit: Difference between revisions

From Rosetta Code
Content added Content deleted
m (forgot to sign)
(Good match, yes.)
Line 12: Line 12:
* File system operations (implies File access)
* File system operations (implies File access)
--[[User:Ce|Ce]] 08:00, 6 August 2010 (UTC)
--[[User:Ce|Ce]] 08:00, 6 August 2010 (UTC)

: It is indeed a good match for Semantic Mediawiki, but I don't know how to apply it quite yet, as SMW only has limited support for negation (as found in the Unimpl pages). That's going to need to get hacked in there, obviously. I would be wary of applying most semantic properties from within templates, though, because there are often workarounds to apparent dependencies. GUI doesn't need Graphics if you use, e.g. ncurses. OpenGL doesn't need graphics if you're mutating an instruction stream. Generally, I think semantic properties should be expressed within the task description. See, for example, [http://rosettacode.org/mw/index.php?title=User%3AMwn3d&diff=87343&oldid=87340 a change] I made on Mwn3d's user page. (That might be helpful for ensuring better task descriptions, too.)
:
: Really, though, there are dozens of ways we could try using SMW, and I can't accurate predict which will work well and which won't. The best I can suggest is to start applying properties to things, and find out what opportunities turn up. --[[User:Short Circuit|Michael Mol]] 13:37, 6 August 2010 (UTC)

Revision as of 13:37, 6 August 2010

Often several different tasks are about the same general feature (e.g. concurrency, GUI, network access, file system operations, etc.). Now if a language doesn't support any of those, then it will of course support none of the specific tasks for that feature (e.g. a language that doesn't support concurrency will not support any task that involves threads, mutexes or semaphores). Currently you need to have an explicit {{omit from|Language}} for each of the tasks. I think it would be a good idea if there were a defined set of general features, where the task could state whether the features are needed, and the language page may state which features are not supported, and then to automatically omit all languages from a task if they don't support the features (except if there's an explicit example for the language in that task; maybe there's a workaround for the specific tasks in the language).

I don't know how hard this would be, but it sounds like a good match for semantic Wiki. The features could be implemented through categories (actually, some features like supported programming paradigms already are), or maybe through specific structures of semantic Wiki markup. A task would then use either a special template (e.g. {{requires feature|Concurrency}}, or the task template could be extended to allow specifying required features. Similarly, the language would either use specific templates like {{supports featuire|Concurrency}}, or allow specifying them through the language template.

Here's a list of language features where this feature might be useful:

  • Concurrency
  • Network access
  • Graphics
  • GUI (implies Graphics)
  • OpenGL (implies Graphics)
  • File access (i.e. file open, read, write)
  • File system operations (implies File access)

--Ce 08:00, 6 August 2010 (UTC)

It is indeed a good match for Semantic Mediawiki, but I don't know how to apply it quite yet, as SMW only has limited support for negation (as found in the Unimpl pages). That's going to need to get hacked in there, obviously. I would be wary of applying most semantic properties from within templates, though, because there are often workarounds to apparent dependencies. GUI doesn't need Graphics if you use, e.g. ncurses. OpenGL doesn't need graphics if you're mutating an instruction stream. Generally, I think semantic properties should be expressed within the task description. See, for example, a change I made on Mwn3d's user page. (That might be helpful for ensuring better task descriptions, too.)
Really, though, there are dozens of ways we could try using SMW, and I can't accurate predict which will work well and which won't. The best I can suggest is to start applying properties to things, and find out what opportunities turn up. --Michael Mol 13:37, 6 August 2010 (UTC)