Wikidata:Property proposal/designed for translation to

designed for translation to

Originally proposed at Wikidata:Property proposal/Generic

   Withdrawn

Description	Which language, bytecode or file format this language or file format was designed to be translated to.
Data type	Item
Domain	instance of computer language (Q629206) or file format (Q235557)
Allowed values	instance of computer language (Q629206), bytecode (Q837330) or file format (Q235557)
Example 1	C (Q15777) → machine code (Q55813)
Example 2	Java (Q251) → Java bytecode (Q137496)
Example 3	TypeScript (Q978185) → JavaScript (Q2005)
Example 4	CoffeeScript (Q1106819) → JavaScript (Q2005)
Example 5	Haml (Q1573599) → HTML (Q8811)
Example 6	LESS (Q1107192) → Cascading Style Sheets (Q46441)
Example 7	CartoCSS (Q25975590) → Mapnik XML (Q114901066)

Motivation

There are many computer languages that were specifically created to be converted to other computer languages. It would be nice to have a property to model these relationships.

--Push-f (talk) 05:59, 29 October 2022 (UTC)

Discussion

• WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Push-f (talk) 06:05, 29 October 2022 (UTC)
•  Support --Tinker Bell ★ ♥ 16:09, 29 October 2022 (UTC)
•  Comment "processes to" is a very generic label. I would suggest "transpiles to", but that would also include e.g. C → Rust source-to-source compilers. A more accurate (and awkward) label would be "intended for transcompilation to". We could also go with "intended for compilation to", adding C → assembly language and Java → Java bytecode to the examples. —Dexxor (talk) 08:05, 30 October 2022 (UTC)

  Note that I also intend the property for config file formats (my sixth example) ... for such conversions you usually don't say "compile" or "transpile". I did think about labeling the property "preprocessor for" but didn't go with it because I think that might confuse people into thinking that the property is meant for preprocessor software -> target language instead of source language/format -> target language/format. And "preprocesses to" does not sound right to me. --Push-f (talk) 15:13, 30 October 2022 (UTC)

•  Comment with a label like "processes to" expect it to be used for statements like iron ore → iron and photographic film → negative. Thryduulf (talk) 14:43, 30 October 2022 (UTC)

  Wouldn't the property constraints make such accidental misuses apparent? --Push-f (talk) 15:13, 30 October 2022 (UTC)

•  Comment Given that any formal description can be converted/transcompiled to a semantically equivalent description in another language that is (at least) as expressive, this property could be a gateway for true, but trivial (or otherwise futile) statements (e.g. Java → Common Language Infrastructure, Java → assembly language, Java → Brainfuck and so on). A solid modelling would be, IMO, (at least) one of these:
  • Reify classes of expressiveness (we already have Turing completeness (Q197970) and Turing complete (Q10385523)) and/or levels of abstraction (we already have object-oriented programming (Q79872) or functional programming (Q193076)) and have properties linking languages to their class of expressiveness and/or abstraction paradigm.
  • Create items for individual software (compilers, transpilers, jitters …) or classes of them (such as Java compiler) that process a formal description in one language to a formal description in another language, and endow these with properties indicating source and target language. We do already have Glasgow Haskell Compiler (Q2318908) or GNU C++ Compiler (Q1942864), albeit without source/target language information. The property proposed here would fit quite well with those items. --2A02:8108:50BF:C694:658F:7048:504A:F96A 13:38, 1 November 2022 (UTC)

  I have updated my proposal with a description which should help clarify the use case of my proposed property: "Which language or file format this language, bytecode or file format was designed to be converted to.". So in regards to Java the only target fitting that description would be Java bytecode (Q137496). I agree that it would be nice to have properties to denote the source and target languages of compilers, however that is out of the scope of this property proposal. This proposal is specifically about the relationships of languages/file formats and not about the compilers used for the conversion. --Push-f (talk) 14:35, 1 November 2022 (UTC)

•  Withdrawn I withdraw this proposal in favor of using Xhas goal (P3712)compilation (Q12769326)to languageY, where "to language" is a new qualifying property I propose in Wikidata:Property proposal/from language & to language. So please check out that new proposal :) --Push-f (talk) 13:04, 5 November 2022 (UTC)