Talk:Oberon-2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Invalid attribution[edit]

"Designed by Niklaus Wirth, Hanspeter Mössenböck" gives a wrong impression. Hanspeter Mössenböck designed the language as an extension of Oberon. He is also the first author of the Language report: [1]


Merge?[edit]

This has been discussed here and elsewhere, but I'm not sure what came about from the discussion. Can the Oberon-1 and Oberon-2 pages be merged into just an Oberon page? There wasn't really an "Oberon-1", there was just Oberon, and then Oberon-2, and now Oberon-07. Each of the changes/revisions could just have their own sections. Bishopmartin (talk) 01:19, 26 August 2008 (UTC)[reply]

The source of information for the summary of extensions is Differences between Oberon and Oberon-2 by Hanspeter Mössenböck and Niklaus Wirth.

Chris Burrows 14:24, 10 October 2005 (UTC)[reply]

Niklaus Wirth's languages have very striking differences, hidden among their similarities. Almost Introvert/extrovert. For example Algol could talk to any other language, and be mixed in to build a product, an extrovert. Pascal in it's native form would have to be recompiled to point to a different file, an introvert. Modula II was out there again. Interfacing other languages. It was a great language for real world problems. Definitely an extrovert. Oberon (an Oberon-2) have their own environment again. They don't want to touch the real world. And although they are nicely written languages, they are not good for much beyond teaching. A major introvert.

So Niklaus has had plenty of time to write yet another extrovert language, but I am not seeing anything out there.

Anonymous 14:30, 21 February 2007 (UTC)[reply]


-- Funny analysis :-). To me, the main characteristic of Wirth's languages are the warts :-P (not by evolution, but on purpose... i cannot understand that...). For example: Oberon has operators "&" and "OR". Why the former is a symbol and the latter is a word? This looks stupid (and i'm inclined to think that it is stupid). And Pascal had the wrong precedence for "and" and "or", which forced you to always use parenthesis (among other annoyances). I could never find a rationale for those decisions. -- unsigned

I disagree[edit]

No, that's not right. Oberon-2 is one of my favourite languages simply because it IS useful for things beside teaching. Remember, the Obeon-2 compiler and operating system were written in Oberon-2, so it can certainly claim a place as a systems programming language. Oberon is a bigger better Pascal, and Pascal has been used for a great many real-world applications, including (until recently) the user interface system at the London Stock Exchange.

OrangUtanUK 13:13, 27 April 2007 (UTC)[reply]

Code examples[edit]

Does anyone mind if I make the code examples a bit clearer? Most of them don't do anything when they run, and some of them don't even compile cleanly.

Neuralwarp (talk) 12:23, 10 January 2008 (UTC)[reply]

Good idea. I'm not too worried about the ListClass example as anybody who would be able to understand the additional details could fill in the blanks anyway. However the 'birds' example surely could be replaced with something more realistic. Shapes (rectangles, squares, circles) and their areas perhaps? However, this is an encyclopaedia so again, just a skeleton illustrating the main issues is sufficient. Examples should include valid declarations statements, expressions etc. but it is not necessary (or advisable) to include complete compilable working examples.
Chris Burrows (talk) 01:07, 11 January 2008 (UTC)[reply]

Oh, good. Yes, I agree. Code examples in a dictionary should be primarily (a) understandable - hence short, (b) useful - hence showing a range of language elements, and (c) correct. My concern about compilability relates to the third point.

I think it would be best to take fragments of code from the papers and key reference books, where possible.

Neuralwarp (talk) 16:48, 11 January 2008 (UTC)[reply]

In the example method 

      PROCEDURE (l : List) Add* (v : Integer);

parameter l should be VAR because it is changed, when the List is empty — Preceding unsigned comment added by Bigben.in (talk • contribs) 08:11, 1 November 2012 (UTC)[reply]

Why do the code examples have the pointer variable names declared with * as if this was C? Does Oberon require this?Claystu (talk) 14:20, 15 November 2014 (UTC)[reply]

List Example correct?[edit]

Is the List example actually correct? Procedure Add is bound to the pointer type List, within Add is tested if the receiver parameter l is NIL (same again in Get). But how can Oberon perform dynamic binding to List::Add (sorry for C++ idiomatic expression when talking about Oberon, but I think it clarifies what I mean) when l is NIL and thus doesn't carry any useful type information?

I concede this point does not take effekt until there are more types in a hierarchy, and the static type of the pointer used to call Add is not sufficient to determine whether List::Add or T::Add (where T is any subtype of List) should be called. --Lile221 (talk) 08:23, 21 January 2015 (UTC)[reply]

I replaced the list example altogether because it has several problems and is thus not as illustrative as the example given in the Oberon-2 report:

  • Most compilers generate code that requires the dynamic type of the receiver when calling type-bound procedures. As mentioned above, the dynamic type is not available for NIL pointers.
  • The example relies on changing the pointer value of the receiver. Propagating this change to the preceding node would require the receiver parameter to be variable which is not allowed for pointer types in Oberon-2.
  • The Add procedure uses recursion to traverse the list which potentially causes stack overflows.

212.77.42.35 (talk) 06:59, 14 September 2021 (UTC)[reply]

Image copyright problem with File:OberonLogo.gif[edit]

The image File:OberonLogo.gif is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

  • That there is a non-free use rationale on the image's description page for the use in this article.
  • That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --08:53, 9 February 2009 (UTC)[reply]

Add new page about Keiko bytecode[edit]

In section "Implementations" I suggest to replace external link "Keiko Virtual Machine" by new page Keiko bytecode. An introduction about Keiko is written on http://spivey.oriel.ox.ac.uk/corner/Design_overview_for_OBC#The_Keiko_Abstract_Machine . A text will be as short summary. Its planned to add section History too. Then one can mention Keiko in section Bytecode#Examples.

Thank you for that reference link; I've added it to this article.
It appears that the #Keico_bytecode section is not yet big enough to WP:SPLITOUT into independent Wikipedia article.
For now I've made Keiko bytecode redirect to the #Keico_bytecode section of this article. --DavidCary (talk) 02:54, 2 July 2022 (UTC)[reply]

EBNF grammar mistakes?[edit]

What is "MODULE" in the EBNF? 

 Module        = MODULE ident

Is that supposed to be a literal? E.g. 

 Module        = "MODULE" ident

Hotpine (talk) 07:52, 9 September 2022 (UTC)[reply]

In theory, yes, but ....
The same could be said about all of the other reserved words and keywords (BEGIN, END, PROCEDURE etc) in the EBNF. However, as they are all uppercase they can already easily be distinguished from the 'productions' in the EBNF so the quotation characters are superfluous. Chris Burrows (talk) 22:40, 9 September 2022 (UTC)[reply]

Go (Golang) and V (Vlang) influenced by Oberon-2[edit]

The creators of the programming languages Go and V (Vlang) were both influenced by Oberon-2 (in similar ways), and have publicly stated so on their websites. Refer to Robert Griesemer - The Evolution of Go (V is similar to Go). Wukuendo (talk) 05:55, 13 March 2023 (UTC)[reply]

You need to get an article on V approved before adding references to it elsewhere on Wikipedia. - MrOllie (talk) 17:41, 16 March 2023 (UTC)[reply]
V is an approved article, refer to V (Vlang). However, upon attempting to edit the languages Oberon-2 has influenced, it was immediately reverted back by Chris Burrows (talk). I do not want to get involved in an edit war, so am asking other editors to weigh in on this. If it is not liked or doubted that V belongs there, then the same should hold for Go. These are similar languages, with both creators stating their influence. Please refer to Robert Griesemer's talk to see how this is so, here- Robert Griesemer and Oberon-2 (From 17:00). The code for V would be similar. Thank you for your time and consideration in advance. Wukuendo (talk) 04:26, 4 November 2023 (UTC)[reply]
It should perhaps also be stated or clarified (based on the comment Chris made) that to influence another language doesn't mean that code must be identical, the languages resemble each other in every aspect, or be a direct descendant. Rather the creators of the newer language can be stating what their influences were, that specific aspects of their languages are similar, or are derived from a particular older concept. Wukuendo (talk) 12:44, 4 November 2023 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Oberon-2&oldid=1208542880"