Talk:RPL (programming language)

RPL acronym

Is Reverse Polish LISP truly a synonym for Reverse Polish Language, or is RP LISP a separate thing that uses the concept of RP Language within the context of the LISP language? If the latter, Reverse Polish LISP should have its own page and not be a redirect, or should have a separate paragraph within this article. -- Jeff Q 02:20, 3 May 2004 (UTC)

Thanks for the comment; the article is now updated to reflect this. In fact the term Reverse Polish language is unheard-of, since it might just as well mean FORTH... --Wernher 03:18, 3 May 2004 (UTC)

Thank you for clearing that up. I made a few minor changes to conform to standard English punctuation practices. Please revert if I have inadvertently changed the meaning of your excellent description. And thanks for providing this interesting article! -- Jeff Q 06:43, 3 May 2004 (UTC)

I always heard (from many engineers) that RPL = "Reverse Polish Logic". Anyone else? Reverse Polish LISP and Reverse Polish Language make no sense in the context of a calculator. Tvaughan1 (talk) 00:45, 26 June 2009 (UTC)

Actually RPL stands for Rom-based Procedural Language (source : HP journal) --Apc005 (talk) 18:31, 15 July 2009 (UTC)

There is a definite controversy; I shall edit the article to reflect this. 98.225.16.76 (talk) 00:26, 27 May 2015 (UTC)

There is no controversy. This is just made up. Over all those decades, RPL stood for "Reverse Polish Lisp" (but was used only as an acronym). This can be sourced in uncountable sources. The fact that a single source tried to be "smart" and invented the term "ROM-based procedural language" out of blue air does not change this a bit. While we should write from a neutral point of view, we also have a responsibility not to present and further spread false information or give undue weight to unimportant stuff, and we certainly have no obligation to pick the single source which got it wrong. "ROM-based procedural language" is a meaningless and misleading invention by someone who was obviously clueless about RPL's actual meaning, but who also must have been clueless about the technical background, as being ROM-based and being a procedural language are both common-place properties found in uncountable other languages as well and not describing anything special or important in RPL, whereas the properties, which stand out, being stack-based and object-oriented, don't get mentioned. "ROM-based procedural language" is as wrong as "Reverse Polish Logic" (mentioned further above) or "Rich People's Language" (as Bill Wickes suggested jokingly when asked about the actual meaning of the term RPL).

For comparison: There are also people, who have no clue about the meaning of the term BIOS and call it "Binary operating system" or claim it to be derived from the Greek word for "life". If you search the net you will even find reliably looking references citing this. However, BIOS always stood and still stands for "Basic Input/Output System" (a term coined by Gary Kildall, nothing else, so we don't even mention some clueless people's guesswork in our BIOS article. Similarly, we shouldn't even mention "ROM-based procedural language" in our article about RPL, but if we do, not in any prominent way (as we do now). It's deliberately misleading. --Matthiaspaul (talk) 14:01, 12 August 2015 (UTC)

Postfix conditional structures

There is a simple postfix-based way to implement if/then/else structures, which RPN purists would prefer.

The following example uses the IFT ("if-then") function to pop an object from the bottom of the stack, and if it is equal to 1, replace it with "One":

« 1 == "One" IFT »

The following example uses the IFTE ("if-then-else") function to pop an object from the bottom of the stack, and if it is equal to 1, replace it with "One", otherwise replace it with "Not one":

« 1 == "One" "Not" IFTE »

These structures can of course be nested. Both of the following examples pop an object from the bottom of the stack, and replace it with "One", "Less", or "More", depending on whether it is equal to, less than, or greater than 1.

«
  DUP 1 ==
  « DROP "One" »
  « 1 < "Less" "More" IFTE »
  IFTE
»

« -> x
  «
    x 1 ==
    "One"
    « x 1 < "Less" "More" IFTE »
    IFTE
  »
»

Tony.

I added a section for IFT/IFTE, using some of the content you've placed here. --MatthewMastracci 19:27, 12 May 2005 (UTC)

REALITY

The recently-added content about the REALITY Programming Language is a different subject altogether. It should be moved to a new article, and a disambiguation page created. Rwxrwxrwx 11:11, 10 July 2007 (UTC)

Four level stack?

"Contrary to previous HP RPN calculators, which had a fixed four-level stack, the stack used by RPL is only limited by available calculator RAM."

I have a 48gx and it is not stack limited. A quick test gave me more than 50 items in the stack. I assume it is limited only by memory.

I don't know if other RPN calculators are stack limited. Ponjo (talk) 01:01, 12 July 2008 (UTC)

Since the 48 is an RPL calculator, what is your point? My 41 has a four level stack. Thyl Engelhardt 213.70.217.172 (talk) 08:36, 10 December 2008 (UTC)

Recursive functions etc

I just got a HP 50g yesterday, and this is my first 'advanced' calculator so I'm in heaven :) I think this article could discuss the actual features of rpl a bit more. If no one else does so, I'll add the stuff myself but I guess I should get a few months of experience first.

Some questions I'd like answered are: How to make recursive function calls? Can the compiler/interpreter transform tail recursion into simple loops? Are the types ordered in some kind of hirarchy or is the type space flat? Can one add new types (e.g. 'quaternions') and have them work with e.g the '+' function?

I'll find out soon enough, but as I said, the article could mention this. —Preceding unsigned comment added by 188.126.207.212 (talk) 04:26, 14 September 2009 (UTC)

general purposeness

If this is basically usable aas a general purpose language who's main availability happens to be calculator programming (as it appears on cursory glance it might, or might mostly), I (just little old me) think such should be 1 of the most obviouse aspects of the article itself. If not how far away is it from such, and in what way. My bias is great, here. I basically no nothing about computers, and thats the 1st thing I wanted to know and looked to the article to find. Slarty2 (talk) 23:36, 5 January 2011 (UTC)

RPL syntax highlighting is missing

It needs it (though it is mainly use case). Daemonicky (talk) 12:42, 31 August 2011 (UTC)

Change << to « by MatthewMastracci

[1] is correct? Could somebody provide a source that guillemets (namely, U+00AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK and U+00BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK) have such syntactic meaning in this language? Incnis Mrsi (talk) 08:45, 19 July 2012 (UTC)

Variants: wrong and overblown

In Variants: the language is overblown. Serious crash? Who dies from it? It's just a calculator. Reset it and move on.

As far as System RPL only being available via external tools, this certainly does not apply to the 50g. The HP doc (Advanced User Guide) explains how to code in Sys RPL and even ARM assembly with onboard tools that come preloaded from the factory. I don't know how far back this goes, but I believe Sys RPL was available natively on the 48 series as well. Someone who knows definitely should fix this all at once.87.68.23.11 (talk) 08:02, 4 December 2013 (UTC)

Lisp?

And what's the relation to Lisp? The resemblance of RPL to FORTH is obvious, one could even argue that it is a FORTH system (and if not, it should be explained why not and what the differences are), but Lisp? Where are the lists, Symbols, Macros? How are functions defined and as argument given to other functions? Or was the name in the end just a marketing-stunt? — Preceding unsigned comment added by 69.181.225.53 (talk) 18:57, 20 January 2019 (UTC)

If I may quote William C. Wickes, the creator of RPL, "Several existing operating systems and languages were considered, but none could meet all of the design objectives. We therefore proceeded with the development of a new system, which merges the threaded interpretation of Forth with the functional approach of Lisp."

RPL is a concatenative programming language, at least in System-RPL. This means that operations in the RPL runstream consist of postfix function composition. In RPL, a "composite object", such as an RPL "secondary" ( basically an anonymous function ) can be concatenated with other composite objects of the same type, which was influenced by Lisp. Composite objects are essentially collections of other objects and composite objects, like lists in Lisp. RPL also has traditional lists, which are another type of composite object that are structurally almost the same as secondaries. Jdbtwo (talk) 20:15, 20 January 2019 (UTC)

Object oriented?

I don't know why this article's main infobox lists RPL as "object oriented." For a language data type to qualify as "object oriented" it must at least exhibit encapsulation, inheritance and polymorphism, none of which RPL "objects" exhibit. If there are no complaints, I'll go ahead and remove "object oriented" from the main infobox. Jdbtwo (talk) 18:24, 27 November 2021 (UTC)

I do object. :-) Object-oriented can mean a lot of things and certainly not everything that may be associated with it in more current programming languages. I therefore restored the term, and added "partially" as a compromise. --Matthiaspaul (talk) 12:53, 3 December 2021 (UTC)

rpl has no concept of 'fields' or 'methods' which are required concepts for a language to be considered "oo", as per wikipedia's _own article_. Secondly, rpl objects are neither 'data' or 'code' because rpl has no distinction between 'data' and 'code'. Everything is a self-identifying, self-executing binary blob, even constants such as 1 and strings such as "1". Third, rpl has no concept of neither inheritance, polymorphism nor encapsulation. Functions such as NEG which can take various types of arguments, from numbers to lists to bitmaps, are simply functions that delegate the processing to other more specific functions. Saying rpl is object-oriented is at best just plain wrong. Finally, user rpl and system rpl are not dialects. There is no, nor can be, a system that runs one but not the other, as per the description of the language in its definitive documentation, rplman.doc --gtsiros

-- (unsigned) 2021-12-07T04:58:11‎ 91.140.68.150

George, while it is true that many of the concepts you list are associated with object-oriented programming languages today, it is not true that they are part of the core definition, and our own article on object-oriented languages also does not state so. The very concept you describe that there's a structure (the stack) which can not only hold one particular type of operand(s) (like plain numbers), but almost anything from scalars, lists, vectors, matrices to bitmaps or programs, and that operators act differently depending on the type of operands applied to them is what makes it object-oriented. I changed the wording to "partially" to indicate that this must not be understood as if RPL would support all new concepts implemented in object-oriented languages today.

--Matthiaspaul (talk) 11:18, 18 December 2021 (UTC)

George, while it is true that many of the concepts you list are associated with object-oriented programming languages today, it is not true that they are part of the core definition, and our own article on object-oriented languages also does not state so.
— User:Matthiaspaul

According to Wikipedia's own article on OOP, at a bare minimum, a language is considered to be OO if it conforms to the "programming paradigm based on the concept of 'objects', which can contain data and code. The data is in the form of fields (often known as attributes or properties), and the code is in the form of procedures (often known as methods)."( Quoted from Object-oriented programming (this version) ) RPL "objects" *have no concept of fields/attributes/properties* -- they are just code or data prefixed with an address, called the object prolog, which handles the execution of the specific type of data or code that is contained in the object body. Furthermore, RPL objects *do not contain* procedures/methods associated with the data or code in the object body. RPL "objects" are not even "object-based" because of this : "The term object-based language may be used in a technical sense to describe any programming language that uses the idea of encapsulating state and operations inside objects." (Quoted from Object-based language (this version))

The very concept you describe that there's a structure (the stack) which can not only hold one particular type of operand(s) (like plain numbers), but almost anything from scalars, lists, vectors, matrices to bitmaps or programs, and that operators act differently depending on the type of operands applied to them is what makes it object-oriented.
— User:Matthiaspaul

Given, RPL, being a TIL, has an associated data stack ( like eg. Forth ), but that does not make it OO. The stack is just a collection of pointers to RPL "objects." The behavior you describe is not present in System-RPL, which IMO, isn't adequately described in this article. You're describing the behavior of *User-RPL* which utilizes System-RPL routines to perform argument number and type checking and System-RPL routines to delegate operations on different types of RPL "objects" (defined by their prologs) to the associated appropriate System-RPL code.

I think the confusion here is the word "object" in the context of RPL, which was originally introduced by W.C. Wickes' "RPL : A Mathematical Control Language". In the aforementioned paper, the author *never mentions* OOP -- what defines RPL is the generalized RPL inner loop which has no relation to OOP.

Jdbtwo (talk) 17:44, 24 December 2022 (UTC)

Also, the web pages / documents referenced to support the premise that RPL is in any way OO is, AFAIK, not supported by said web pages / documents. Unless someone can provide a definitive reference that shows that RPL is OO (which is unlikely, given the abundance of sources that contradict this and not *one* reliable source that explicitly states that RPL is OO), I recommend that "object oriented" be taken out of the main infobox.

Jdbtwo (talk) 17:19, 25 December 2022 (UTC)

The sources referenced in the main infobox to support that RPL is OO seem cherry picked and in error -- they are secondary or tertiary sources that contradict the definition of what RPL "objects" are and *provide no substantiation in the how or why* : Why RPL is OO and how it is implemented. To quote the "Procedural programming and object-oriented programming" section of the first source ("Programming the HP 49 G Calculator in User RPL Language" by Gilberto E. Urroz ) :

In this chapter we have covered a number of relatively simple programming examples that include the basic ideas of sequential, branching, and looping programs. This type of programming in which the programmer is controlling the program flow at an elementary level is called procedural programming. In the last decade or so, there has been an emphasis in the development and use of object-oriented programming. In this approach the user takes advantage of pre-programmed functions (objects) for which he or she provides the appropriate input, and from which he or she receives a pre-specified type of output. Most of the functions provided by the HP 49 G calculator emphasize object-oriented programming (OOP). For example, to solve a quadratic equation in the HP 49 G calculator, you need to enter a quadratic expression, the variable to solve for, and then use the function QUAD. The user is not concerned with the details of how the roots of the equation were calculated. All that he or she cares about is that the proper type of input is provided to the function or object, and that the calculator will return the desired output.
— Programming the HP 49 G Calculator in User RPL Language By Gilberto E. Urroz 17:11, 27 December 2022 (UTC)

In terms of somehow claiming that RPL is OO, the author provides no substantive explanation of why this is or how it is implemented and the whole section is a non sequitur in the specific context of OOP as regards RPL. The second source does not mention OOP in any way. For the third source, we have someone on the HP Museum forums stating "On the other hand, RPL is a full-fledged, complicated, object-oriented language, which requires the user to deal with the vagaries and complications necessarily associated with such an OOP language, thus negating all simplicity and requiring its users to become what they'd rather not.", again, without providing any substantive proof regarding whether RPL is OO -- including this as a reference for OO seems to be cherry picking.

I will now go ahead and remove OO from the main infobox.

Jdbtwo (talk) 17:15, 26 December 2022 (UTC)

I do not agree with the removal of the phrase. I have therefore restored what was meant as a compromise "partially objected-oriented". There is no single and fixed definition of "object-oriented", in fact, language designers, scholars and standards have quite different and sometimes contradicting ideas of what properties define "object-oriented", definitions even changed over time.

--Matthiaspaul (talk) 21:15, 20 August 2023 (UTC)

You likely also do not agree with the statement your statements make you read as being a complete fool, but that doesn't make it untrue. HP RPL is slightly more object-oriented than assembly language. The stack being able to handle multiple types of data or operators behaving differently depending upon data type is a common property of interpreted computer programming languages. HP RPL has a number of fixed types, you cannot attach methods/functions to a type.

Since I do not wish to participate in an edit war, I am not modifying the page. Tagging HP RPL as object-oriented is the most ignorant claim I've run across in the past year. Are you presently or do you plan to be employed as a comedian? Alas most engineers are disgusted by this sort of inaccuracy. 74.104.188.4 (talk) 04:13, 30 November 2023 (UTC)

@Matthiaspaul:It seems that you ignored my systematic deconstruction of each of the references and my conclusion that none of said references provide verifiable proof that supports the claim that RPL is in any way “object oriented.” As I said before, RPL “objects” are just plain data types which do not posses even the weak “object based” structure : they do not encapsulate state with executable code ( ie. methods ) which operates on that state. I think that if Wickes’ paper had use “structure” instead of “object” there’d be no contention on this issue.

@Matthiaspaul:In the interest of preventing an edit war, I’m sending this to dispute resolution. Jdbtwo (talk) 18:54, 17 January 2024 (UTC)

@Matthiaspaul:As you did not respond to the request for dispute resolution and a moderated discussion, and, because the moderator and I reached a “rough consensus” that RPL is in no way OO, I am ( again ) removing the “partially object-oriented” paradigm from the main infobox. Jdbtwo (talk) 18:50, 25 January 2024 (UTC)

@Matthiaspaul:

I do not agree with the removal of the phrase. I have therefore restored what was meant as a compromise "partially objected-oriented". There is no single and fixed definition of "object-oriented", in fact, language designers, scholars and standards have quite different and sometimes contradicting ideas of what properties define "object-oriented", definitions even changed over time.

There is indeed one "single and fixed definition of 'object-oriented'." Namely object-based languages. This minimal definition of an OO language at least requires that the language in question has data types that incorporate state on which procedures associated with those data types, or are in other words encapsulated with the state ( methods ) act on said state -- RPL has none of this. The first OO languages -- languages like Simula, Modula or Smalltalk -- at least fit the definition of "object-based." The languages in the start of the evolution of OOP, the ones that "language designers, scholars and standards have quite different and sometimes contradicting ideas of what properties define 'object-oriented'", definitions even changed over time", all at least share the property of "object-based" and I should mention that "Object-based languages that do not support inheritance or subtyping are usually not considered to be true object-oriented languages" ( Quoted from Object-based_language (this version) ) -- RPL supports none of this. RPL supports no encapsulation, polymorphism or inheritance, and certainly no message passing. An RPL "object" is data or executable code that is prefixed by the address of the code which determines what to do with said "object" depending on whether it is executed directly or indirectly. Furthermore, in RPL, there is no concept of "method", "member" ( encapsulation ) or even "function" -- everything ( except so-called "PCOs" or "primitive code objects" ) is just an address that is followed by a type-specific number of nibbles/bytes, where the code at said address determines what happens upon direct or indirect evaluation. In other words, RPL "objects" are just data types from a fixed set of data types supported by the RPL OS, and on the Saturn RPL calculators a significant number of those data types are not accessible by the user. Stating that RPL is even *close* to being an OOP is like saying that since ANSI C can create structures with data and function pointers in them ( ala GNU Gobject ) then ANSI C is a fully blown OOP. This argument can even be applied to assembly language which, with the help of macros, can do the same -- so is assembly language OO? Jdbtwo (talk) 16:12, 28 January 2024 (UTC)