User:Anthonykozar/SCOOP History and Design Goals
The basic idea for SCOOP occurred to me (Anthony Kozar) on Dec. 23, 2024 and was inspired by vague memories of False and Smalltalk. The inspiration came immediately on the heels of another idea for an almost completely different esolang that was inspired while reading about Ropy.
I spent the next month or so working out the basics of the design with these goals in mind:
- a very small set of core language constructs with other functionality relegated to “predefined methods” of objects
- choosing meaningful symbols for the core language concepts and predefined methods at the expense of making the language difficult to type
- support for using the largest possible subset of Unicode characters as identifiers
- fairly easy to parse
- support for many dynamic language features
- enough powerful features to make simple tasks simple and very complex tasks feasible
- hopefully Turing complete
Many concepts, instructions, and methods were added (e.g. object extension and callbacks) or removed (e.g. prototypes and implied getter methods) as I worked through the logic of which features were necessary to achieve my goals. At one point, I was reading up on Smalltalk and was surprised at how similar the list of basic operations in Smalltalk is to those of SCOOP. In my honest opinion, I’m pretty pleased with how well SCOOP meets my goals.
The most fun part of designing SCOOP was searching through the hundreds of possibly relevant Unicode characters and choosing just the right ones for each feature. Some of the choices were quite difficult, especially when I liked more than one symbol for the same purpose.
Unused Ideas
Prototypes
Should objects have prototypes with a predefined member that points to that prototype?
Additional primitive instruction:
|New object from prototype|☆|white star|U+2606|
Other Symbols
Alternate for send a message?
- ✉ Envelope (U+2709)
Other characters considered for None:
- ␢ Blank Symbol (U+2422)
- ∅ Empty Set (U+2205)
Another character considered for the extend object method:
- ⎄ COMPOSITION SYMBOL U+2384
Other characters considered for the string index method:
- ☞ White Right Pointing Index U+261E
- ⌖ Position Indicator U+2316
Additional Methods
Methods for numbers that I decided aren’t necessary:
- identify whether a number object is an integer, fraction, or decimal
- explicit conversions between fractional and decimal numbers
- modulo method
Methods for strings that I decided aren’t necessary:
- find and substring methods
Other Ideas
- names of object properties could be sent as messages to get their values (basically doubling as implied getter methods) making a member access instruction unnecessary. This presented problems for how to manipulate methods as objects.
- allow members of the program object (@) to be accessed without using a member access instruction unless the same identifier exists in the current scope
- add an optional parameter to ⓟ methods for a format object that has properties to control width, fill character, number of decimal places, newline, etc.
- delete identifiers from the current scope when they are encapsulated into a new object definition?