Jump to content

User talk:Dcoetzee/Wikicode

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< User talk:Dcoetzee
This is an old revision of this page, as edited by Dcoetzee (talk | contribs) at 02:24, 13 October 2004 (→Types: Response). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Prologue

See also Wikipedia talk:Wikicode/Specification for discussions. -- Kaihsu 15:54, 2004 Sep 27 (UTC)

For background see also Talk:Pseudocode and Talk:Algorithms on Wikipedia.

Discussion begins

Um, the bit in the opening of Wikipedia:Wikicode where it says Wikicode is a new standard and Whenever you write pseudocode in an article, this style should be used -- that's just wishful thinking, right? Did I miss a vote making this an official policy, or is someone jumping the gun here? -- See also my comments at Wikipedia talk:Wikicode/Specification for some context. Wile E. Heresiarch 06:21, 24 Sep 2004 (UTC)

  • I agree with Wile E -- I don't intend to use this should it ever come up unless we have a serious proposal and voting, and am forced to by consensus. I feel it's a bad move to invent a language for pseudocode for an encyclopedia. --Improv 04:31, 30 Sep 2004 (UTC)

I do not know the reasons of writing a mixture of C and Pascal: in my opinion it's better to move to only one side. Since I have written in both languages, I feel I can suggest to move towards C because it is well known, has more syntax capabilities, and (for what it may weight for) I do prefer it over Pascal. --Enrico. 13:38, 05 Oct 2004 (UTC)

Again, Wikicode is not a mixture of C and Pascal, and I don't understand why it continues to be characterized in this way. It does not use machine integers, the braces are optional almost everywhere, and at one time it used to use parenthesized comments and ML-style type declarations (I still would prefer the latter). This is not a C/Pascal pseudocode, although it is an imperative pseudocode. Derrick Coetzee 16:09, 5 Oct 2004 (UTC)

My attempt to fix the first example uses unsigned types, which it turns out we don't have. I'm trying to think of a way to fix that issue without over-complexifying things too much, I'd appreciate help. Pakaran. 13:02, 24 Sep 2004 (UTC)

This simple example points up a serious flaw in the whole notion of Wikicode: User:Pakaran wants to invoke unsigned integers but he feels prevented by "the standard" -- it turns out we don't have [that type]. Even in this trivial example, Wikicode is keeping someone from expressing what they want and should express. In pseudocode, people customarily make up stuff as they go along, as demanded by the problem at hand. Limiting Wikipedia writers to the subset of concepts embodied in Wikicode is unnecessary and counterproductive. Wile E. Heresiarch 14:58, 24 Sep 2004 (UTC)
The standard specifically says that you can invent new types wherever they are needed, or any particular other construct that is handy for the situation. If a real language fits particularly well, this can be used too. This will be clarified. Again, the point of the standard is not to restrict but to avoid unnecessary inconsistency. Derrick Coetzee 18:05, 1 Oct 2004 (UTC)

Language Enhancements

Right now Wikicode looks like some strange mixture of Pascal and C. Not that I mind, but it seems better to make it somewhat closer resemble one of those rather than hang in the middle, so as to prevent confusion. For instance, type declarations are probably better put after the variable, as in: 

 var x: int := 2
Originally the definitions were exactly like this. This was violently opposed by User: Wrp103, so was changed. Derrick Coetzee 18:02, 1 Oct 2004 (UTC)

I don't understand why comments on separate lines use brackets instead of double-slash. The latter is so common nowadays that pretty much anyone will instantly recognize it as a comment; besides, a comment on a separate line can (and usually is) treated as a comment at the end of a blank line, so why add more special cases?

Sounds good to me. This was a result of a strange evolution of compromise. Changed. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

I'm not sure if I like the idea of implicit line continuation in absence of explicit statement separator. Relying on indentation for that would be nice if the language as a whole used the same concept. But the way it is now, it is possibly confusing. How about using backslash instead?

The language as a whole does use this concept. Braces are optional almost everywhere. Maybe the examples should emphasize this more. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Data type names. Again, a strange mixture. On one hand, shortened versions such as bool and int. On other hand, character rather than char. Perhaps better to make them all long? Would probably make it somewhat more readable, especially for someone with no background in C-derived languages.

Good point. I'm going to leave int alone, just because that's so common, but boolean is good. Changed. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Operators. First, in begs for not in (as in Python). Logical implication operator, e.g. implies, would be nice for some cases. Also, what about bitwise operators? We might need them. Perhaps C-style? But ^ is already used for exponentiation... How about replacing it with **? Oh yes, and what are the precedence rules?

Operators can be invented wherever necessary. A lot of code that does a lot of bit manipulation should just be written in C. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Description of control flow constructs is somewhat ambiguous. For example, it is not clear whether if-else requires then in it or not - some samples are with it, some are without. I'd suggest to leave it there, if only just for readability: if cond then action is easier to read than if cond action. In similar vein, while should perhaps have do after condition. do-while can be replaced with repeat-while. Oh, and while we're at it, how about repeat-until? for desperately needs a step keyword, and perhaps also do before the code block.

Actually the spec says that then is only required where the condition and action are on the same line, specifically to clear up the potential confusion you demonstrate. Derrick Coetzee 18:19, 1 Oct 2004 (UTC)

Syntax for list and sets is strangely different. For list, an insert-at-of statement is used to add elements to the list. For sets, an insert() function is used. They should probably be made similar. Also, syntax for declaring variables of set, list, and map types is not defined. I suggest set, list-of and map-of-to as in the following example: 

 var aSet: set
 var aList: list of string
 var aMap: map of string to integer

--Int19h 04:49, 25 Sep 2004 (UTC)

Wikicode is pseudocode and not intended to be a machine-runable language. As stated in the article, If any particular article requires you to make up functionality or change syntax, you're free to do so. Perhaps that statement needs more emphasis though.
Obviously. However, such made-up functionality and additional syntax are best be organized. Otherwise we'll eventually end up with articles written in several, subtly different, dialects of WikiCode. --Int19h 08:31, 25 Sep 2004 (UTC)
Also note that being pseudocode I'd prefer to follow mathematical conventions more than traditional programming languages. For instance rather than "unsigned int", why not natural number or non-negative. Also I'd prefer to avoid unnecessary shortening of keywords; why not variable rather than var, just like function was chosen rather than fun. int is perhaps so well known as to not matter, but still, perhaps the fully spelled-out integer would be better for pseudocode. Keep in mind that pseudocode may be used in articles other than those familiar to programmers, such as in mathematics. Complete words make it more readable. -- Dmeranda 04:57, 25 Sep 2004 (UTC)
Agreed. Especially since we can use formatting, so identifiers (and thus data types) can consist of several tokens. --Int19h 08:31, 25 Sep 2004 (UTC)

This is a terrible idea. One of the things which makes the code examples useful is that they are real languages illustrating a variety of concepts of both the article topic and the language used. Jamesday 17:16, 1 Oct 2004 (UTC)

Types

Types are confusing to those who do not need them, and those who do can figure them out.

Luckily, types are entirely optional. They're only placed where the author judges the type to be unclear and/or important. If the guide does not make this clear, I'll update it. Your statement is also not always true; types are sometimes an effective form of compiler-checked documentation, particularly in module interfaces. Derrick Coetzee 02:24, 13 Oct 2004 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Dcoetzee/Wikicode&oldid=7670442"