Weak typing?

[crusaderky]

It would be a good idea to clarify if Rockstar is weakly or strongly typed.

Specifically:

• can I read a string from stdin and silently convert it into a number?
• can I add a string and a number, obtaining the original string concatenated to the string representation of the number?

For example, can I do this?

Build your words up
The answer is "I love "
Put the answer with your words into my voice
Shout my voice 

stdin: "5" stdout: "I love 6"

[cwfitzgerald]

I think Rockstar basically has to have weak typing. Because there is no easy way of doing method calls, and those would just make the lyrics harder to read, we really want to encourage implicit conversions like this. It is conventional to use If a cat is nothing which is already an implicit conversion from null to number (or vise versa).

Officially defining the semantics would be useful.

[yyyyyyyan]

Weak typing would make parsers in strong typed language way harder. There's not even syntax over string concatenation, I think we should go easy

[cwfitzgerald]

How do you figure that? I wrote my parser in scala, a very strongly typed language, and had no problem getting the semantics we wanted. Yes it's a functional programming language, but I feel like I would have no problem if I had written it in c++ (besides much longer development time :P)

Also we want something like "left" plus "right" to work, and that would only be available in a weekly typed language (or strongly typed with tons of implicit conversions)

[dylanbeattie]

You're right, it would be a very good idea. So far I've basically assumed the type system works like JavaScript - which has some some well-documented idiosyncracies (WAT?) but is widely-understand and works pretty well most of the time in most cases. I certainly wouldn't envisage ever doing type checking at compile time.

[dylanbeattie]

and to @cwfitzgerald's point - it's fairly easy writing a parser for a weak-typed language using a strong-typed language, but if Rockstar was strongly typed implementing a Rockstar parser/transpiler that ran in JavaScript (for the inevitable interactive web Rockstar thing) might become significantly harder. So I think that's another strong point in favour of the language being weakly typed.

[yyyyyyyan]

"left" + "right" is "leftright", and it doesn't do silent type conversions. Strongly typed languages have this syntax (eg Python). The thing is:

My body is perfect
Dylan says 7
If Dylan is the same as my body

If Rockstar was a weakly typed language, this if should evaluate to True. However, in Python it'd check if "7" is equal to 7, which is not. I'd have to do some crazy shit to make this happen. Maybe convert everything to a string in a comparison. Even this way, I'd still have trouble comparing "1.0" with "1"

[cwfitzgerald]

@yanorestes You're totally right, that's what happens when you post things first thing in the morning :smile:.

As for the semantics of that snippet, I would argue that it should evaluate to true. Now, the direction of the conversion is important. I think it should go in the "sane" direction string -> number, and if that fails, don't throw an exception, simply return false.

[yyyyyyyan]

That's plausible. Then I could just have a function that compare two variables, with a try/except inside

[yyyyyyyan]

Should I make these changes on rockstar-py? @dylanbeattie is weak typing official?

[cwfitzgerald]

I think we should define a list of the acceptable conversions before making it official, if you give me a bit I can write up what I think should be an official list.

[yyyyyyyan]

Great! I'll wait;)

[cwfitzgerald]

This list assumes functions are just objects within rockstar's object model. Additionally, the order of arguments is irrelevant. List should be complete, but if I forgot anything, let me know and I'll amend to it.

Binary Comparison

Less than, Less, Greater, and Greater than are only defined if the operands are Numbers or are implicitly converted as such.

• \<Non-Mysterious> \<op> Mysterious => Non equal.
• String \<op> Number => Convert the string to a number, if it fails, return false
• String \<op> Boolean => Convert the string to a boolean.
• String \<op> Null => Convert null to the empty string.
• Number \<op> Boolean => Convert number to boolean by "truthiness". 0 is un-truthy
• Number \<op> Null => Convert null to 0
• Boolean \<op> Null => Convert null to false

Unary Operators

• \<op> String => Error
• \<op> Boolean => Invert Boolean
• \<op> Null => Error
• \<op> Mysterious => Error

Binary Operators

Conversions other than the listed are errors.

• String \<plus> Number => Convert the number to a string
• String \<plus> Boolean => Convert the boolean to true or false
• String \<plus> Null => Convert the null to null
• String \<plus> Mysterious => Convert the mysterious to mysterious
• String \<times> Number => String gets repeated \<Number> times

[wolfgang42]

@cwfitzgerald Looks great! A few questions:

• What do less than etc. do when the operands aren't converted to numbers? Error?
• By unary operators do you mean build up/knock down?
• String Boolean also converts right/wrong/yes/no, correct? What about non-boolean strings?

[cwfitzgerald]

@wolfgang42 To answer your questions:

• I assume when you mean both types are the same, they do the logical thing. String \<less> String does lexicographical comparison, like basically all other languages.
• Yup!
• Yes. Non-Boolean strings return false. If conversion fails, they are not the same.

[wolfgang42]

@cwfitzgerald For #1, I am wondering what you mean by "Less than, Less, Greater, and Greater than are only defined if the operands are Numbers or are implicitly converted as such," especially since you have just defined them for Strings.

[cwfitzgerald]

This attempts to be a more complete overview of Rockstar's type behavior, with better wording and taking into account string operations, and truthiness.

Types

Rockstar uses a very similar type system to that defined by the ECMAScript type system, except undefined doesn't sound very rock'n'roll so we use mysterious instead.

• Mysterious - the value of any variable that hasn't been assigned a value, denoted by the keyword mysterious
• Null - the null type. Evaluates as equal to zero and equal to false. The keywords nothing, nowhere, nobody, empty and gone are defined as aliases for null
• Boolean - a logical entity having two values true and false. (The keywords maybe and definitely maybe are reserved for future use)
  • right, yes and ok are valid aliases for true
  • wrong, no and lies are valid aliases for false
• Number - Numbers in Rockstar are stored using the DEC64 numeric type. The number internally is the closes representable number of the DEC64 type.
• String - Rockstar strings are sequences of 16-bit unsigned integer values representing UTF-16 code units.
• Object - a collection of named data properties, as in ECMAScript.

Functions are just objects with a function call operator.

The following examples all use c style syntax for explaining what things do.

Operator Precedence

The higher, the tighter the binding. This is the precedence we generally expect from our math.

1. Function Call (right-associative)
2. Multiplication and Division (left-associative)
3. Addition and Subtraction (left-associative)
4. Logical Operators (left-associative)

Examples

• A taking B times C plus D times E and F is equivalent to ((A(B) * C) + (D * E)) && F
• A taking B taking C, D is equivalent to A(B(C, D) NOT A(B(C), D).

Truthiness

The results of comparisons often rely on a concept called 'Truthiness'. If the value is truthy, it will be implicitly converted to true. If it is falsy, it will be implicitly converted to false.

• Mysterious - Falsy
• Null - Falsy
• Boolean - Truthy if True, Falsy if False
• Number - If equal to zero, falsy. Otherwise, truthy.
• String - Truthy (null is the falsy equivalent)
• Object - Truthy (null is the falsy equivalent)

Binary Comparison

Equality comparisons (is, ain't, is not) are allowed between any two operands of the same type. Objects are checked by reference equality, all other types are checked by value equality.

Ordering comparisons (is higher than, is lower than, is as high as, and is as low as) are only allowed if the operands are both Numbers or both Strings or they are converted to such an arrangement according to the rules below. Numbers are compared as expected, Strings are compared lexicographically.

• \<Non-Mysterious> \<op> Mysterious => Non equal.
• String \<op> Number => Convert the string to a number using base 10 with leading zeros ignored. If it fails, return false
• String \<op> Boolean => Convert the string to a boolean using all defined aliases.
• String \<op> Null => Non equal.
• Number \<op> Boolean => Convert number to boolean by "truthiness".
• Number \<op> Null => Convert null to 0
• Boolean \<op> Null => Convert null to false

Examples

• "1" is 1 evaluates to true because "1" gets converted to the number 1
• "2" ain't Mysterious evaluates to true because all types are non equal to mysterious, besides mysterious itself.
• "02" < "10" is true because of the lexicographical comparison between 0 and 1 shows that the first string is less than the second string.
• True < 10 is an error because 10 gets coerced into True due to the comparison with a boolean and there is no allowed ordering comparisons between booleans.

Increment and Decrement Operators

• \<op> String => Error
• \<op> Boolean => Invert Boolean
• \<op> Null => Error
• \<op> Mysterious => Error

Binary Operators

Conversions other than the listed are errors.

• String \<plus> Number => Convert the number to a base-10 string, retaining all precision, but removing unnecessary digits. eg. 00.1000 gets serialized to 0.1
• String \<plus> Boolean => Convert the boolean to true or false
• String \<plus> Null => Convert the null to null
• String \<plus> Mysterious => Convert the mysterious to mysterious
• String \<times> Number => String gets repeated \<Number> times

[wolfgang42]

@cwfitzgerald +1, though I still wonder why String is greater than Boolean is undefined rather than an error.

[cwfitzgerald]

@Wolfgang undefined means it's an error, you can't do any undefined operations.

[wolfgang42]

Ah, got it. It's just that everywhere else you say Error, and 'only defined if' brings visions of C and nasal demons.

[cwfitzgerald]

Haha, fair enough, I'll clarify the wording.

I think we should get some input from some other rockstarians, but then I would be willing to make this a PR to the spec.

[cwfitzgerald]

Added operator precedence stuff.

[dylanrenwick]

I'm completely on board with this definition of types and typing in Rockstar

[kentros]

Can you add some rockstar example snippets?

Can you also call out where equality is and is as high/low fits into this picture? How strict should it be?

How are leading zeros, commas, e notation handled if in the string?

• "010" is 10 outputs true/false? (some languages see "010" as octal, e.g. 8)
• "10,000" is 10000 OR "10.000" is 10000 outputs true/false? (assuming the conversion uses default from_string logic from: http://www.dec64.com/dec64_string.html)

[cwfitzgerald]

@kentros Updated it with better language and examples.

[wolfgang42]

@cwfitzgerald Did I miss the PR for this? I don't see one.

(Edit: NVM, #131.)

[cwfitzgerald]

@wolfgang42 #131

[hyiltiz]

For string concatenation, I expected one of the following to work, but I couldn't figure it out after reading through the docs, watching the Youtube video on FizzBuzz guitar rock (fun times!), or just playing with the REPL at codewithrockstar

Example is one
My cat is "left" plus "right"

Another Example is Two,
My cat says left,
My dog says right,
My pets is my cat with my dog,
Whisper my pets.

How are you all doing string concatenation? I am thinking maybe doing something with stack, arrays or redirecting back and forth from STDIN and STIOUT may be possible, but seems too convoluted.