The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.

I'd like to make imports work better for reusing code. The change is big enough that I thought it made sense to write it up like an actual "RFC" proposal as a separate doc. This PR tracks the proposal text itself. Feel free to comment on it here or on the mailing list.

Rendered proposal

Regarding https://github.com/wren-lang/wren/issues/891

This implementation is not UTF-8 complete (no emojis). But at least it gives a room for most roman/latin languages to use variable names with non ascii chars + some symbols.

• Supported Characters: A small subset of https://en.wikipedia.org/wiki/ISO/IEC_8859-1

(Forked off @PureFox48's https://github.com/wren-lang/wren/pull/987#issuecomment-826284806 for visibility)

At present,

... 0, empty strings, and empty collections are all considered “true” values.

This proposal is to change +0 and -0 to be falsy. Per @mhermier's https://github.com/wren-lang/wren/pull/987#issuecomment-826361383, that is pretty easy to do.

This change would reduce the surprise for programmers coming from other languages --- falsy zero is the case in at least the C- and Perl-family languages, and in PHP (just to pick another random example :) ).

At present, the in keyword isn't an operator as such but a particle whose only use is within a for statement:

for (e in seq) // blah

Despite this, I keep finding myself wanting to type stuff like this:

if (e in list)   // list
if (i in 0..5)   // range
if ("e" in str)  // string

Now all of these scenarios can be dealt with by using the Sequence.contains method or an override thereof for a particular class:

if (list.contains(e))   // list
if ((0..5).contains(i)) // range
if (str.contains(e))    // string

but I think most folks would agree that it's not as nice.

So do you think it would be worthwhile re-classifying in as an overloadable binary operator (perhaps with the same precedence as is) which would enable us to use it as syntax sugar for the contains method?

For example:

class String {
   // ...
   in(str) { (str is String) && str.contains(this) }
}

One thing I miss when programming in Wren is not being able to perform (full) 64 bit integer arithmetic, as we are effectively limited to no more than 53 bits because of the way that Nums are represented.

I've been wondering whether there might be a way to achieve this without impacting on the simplicity of dealing with smaller integers and numbers generally that the Num class gives us and have come up with an idea.

This is a fairly rough sketch so please bear with me.

The basic idea is to introduce a Long class into the core library. A Long object would be 8 bytes long and would be represented internally by a C99 signed long long. It would be immutable as numbers are now.

Consequently, a Long would be a value type as a variable of that type would hold its value directly.

The Long class would not have constructors but instead a Long object could be created in one of three ways:

1. From a literal - an integer with an 'L' suffix. Lower case 'l' would not be allowed as it's too easily confused with the digit '1'.

2. From a string by giving the String class a toLong method which could optionally specify a base from 2 to 36.

3. From a number by giving the Num class a toLong method.

The Long class itself would support all the usual integer operators:

+ - * / % & | ^ ~ << >> < <= == != >= and >.

However, the operands would always need to be Long objects - mixed operations with Nums would not be allowed.

We'd also need a few methods such as: largest, smallest, min, max, pow and sign as well as toNum and toString.

Here's a few simple examples to show how some of this would look:

var r = 123456789L                  // Long created from a literal
var s = "123456789123456789".toLong // Long created from a String
var t = 12345678912345.toLong       // Long created from a Num
var u = "abcdef".toLong(16)         // Long created from a base 16 string
var v = s + t * u                   // arithmetic operations on Longs
var w = (s > t) && (t > u)          // relational operations on Long
var x = s + 6                       // not allowed, can't add Num to a Long
var y = s + 6L                      // fine
var z = r.toNum                     // Long converted to Num 

Internally all operations would be performed from the C side using long long arithmetic and conversion functions such as strtoll.

There would clearly be a lot of work needed to implement this and so the question is would it be worth it?

On the plus side:

1. We'd get full 64-bit integer representation and arithmetic including bit-wise operations though the latter might necessitate an internal conversion to unsigned long long. It would probably be best for overflows to wrap rather than producing an error.

2. As we'd just be dealing with integers, base conversions would be straightforward to implement.

3. Integer division would be just that (i.e. any remainder would be discarded) which is something I was banging on about in #907.

4. There would be no impact whatsoever on Num arithmetic.

5. It would be backwards compatible.

On the minus side:

1. There would be a certain amount of inconvenience in not permitting mixed arithmetic with Nums.

2. There would inevitably be an impact on the size of the core library though I don't really see how it could done as an optional module as you'd need support for Long literals in the language itself.

3. Using a numeric suffix for literals is arguably a bit ugly but I can't think of a sensible alternative and, of course, C has used suffixes from day one.

4. A Long would have a lower range than an unsigned 64 bit integer but I feel that the convenience of having signed integers outweighs this.

5. There would be more for newcomers to the language to learn.

Finally, I'd add that you could do a lot of this with a custom type which is represented internally by a List of two Nums. However, the trouble with this is that it's relatively slow and, as it's a reference type, it will be subject to garbage collection and can't be used directly as a Map key.

I look forward to hearing what you all think.

This PR:

• Implements the sum method of the Sequence class; includes tests
• Adds documentation for the sum method.

Examples:

System.print([1, 3.14].sum)  //> 4.14
System.print((1..3).sum)  //> 6
System.print([].sum)  //> 0

System.print(["string", 1, 2].sum)  //> runtime error "Can't sum non-numeric values"

References https://github.com/wren-lang/wren-cli/issues/95

System.version

It returns WREN_VERSION_NUMBER. Was thinking of retrieving the string, or having version.major, version.minor, but I think keeping it dead simple like this is best.

Currently, due to C's double nature (and IEEE-754), you can get NaN via 0 / 0, Infinity via 1 / 0, and -Infinity via -1 / 0 (or -(1 / 0), i.e. -Infinity). Example:

var NaN = 0 / 0
var Infinity = 1 / 0
var MinusInfinity = -Infinity
System.print("NaN: %(NaN), Infinity: %(Infinity), MinusInfinity: %(MinusInfinity)") // NaN: nan, Infinity: infinity, MinusInfinity: -infinity
System.print("NaN == NaN? %(NaN == NaN)") // NaN == NaN? false

I think there are two things two improve here:

1. The .toString is bad. Really 😺. I think it would be better to capitalize it, that is, NaN, Infinity, and -Infinity.
2. We should have a way to construct them. There are two manners in different programming languages (you're welcome to add more languages):
   1. JavaScript uses keywords: NaN and Infinity. C and C++ use macros (NAN and INFINITY in <math.h> or <cmath>, since C99 and C++ 11), which are similar.
   2. Python, C#, Java and Rust uses methods/properties/constant. In C# it's double.NaN, double.PositiveInfinity, and double.NegativeInfinity (or their float counterparts). Java has similar names: Double.NaN, Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY. Python has math.nan and math.inf since 3.5; before that, the recommended way was to convert from string (see https://stackoverflow.com/a/7781273/7884305, https://stackoverflow.com/a/19374296/7884305). Rust has f64::NAN, f64::INFINITY, and f64::NEG_INFINITY (or f32 counterparts). C++ also has methods, inside <limits>, std::numeric_limits<{double, float, long double}>::{infinity, quiet_NaN, signaling_NaN}().

I think the methods approach is better. However, do we need to also insert Num.negativeInfinity or no because users can just do -Num.infinity?

The purpose of this proposal is to make procedural programming in Wren easier and more familiar to users of other languages by introducing top-level static (TLS) methods. This is how they'd look compared to top-level functions:

static method(s) {
  System.print(s)
}

var function = Fn.new { |s|
  System.print(s)
}

method("I'm a static top-level method")
function.call("I'm a top-level function")

Unlike functions, TLS methods would not be objects and so they could not be passed to, or returned from, other methods or functions or assigned to variables. However, this means that they could be defined in the same way as class-based static methods and would not need to be invoked with 'call' as functions do to avoid the ambiguities that would otherwise arise (see #1045).

One could perhaps think of them as if they were members of an anonymous top-level class though it would not be a precise analogy.

Other aspects of TLS methods:

1. Parentheses would always be needed whether they took parameters or not.

2. They could only be defined at top-level, never within a block or nested scope.

3. They could be recursive.

4. They would see other top-level entities in exactly the same way as a top-level function and their internal implementation could therefore be similar.

5. Class based methods would see TLS methods in the same way as other top-level entities and you would therefore need to observe the usual capitalization rules if you wanted to invoke them from within a class.

6. This proposal would be backwards compatible as no new keyword would be needed and, at present, the static keyword cannot be used at top-level. Functions would continue to work exactly the same as they do now.

This would, of course, make Wren a bit more complicated but I think it would be worthwhile as I regard the current situation of always having to use top-level functions (and their associated 'call' method) for procedural code to be not only an irritation for many existing users but an obstacle to the wider adoption of Wren for simple scripts.

I look forward to comments.

Likewise, when you access a field in other languages, the interpreter has to look it up by name in a hash table in the object.

I ran some tests in Swift:

• 0.0005 for hash table
• 0.00000618 for pointers

Sorry for the beginner question, but why does the hash table approach differ by orders of magnitude in performance? I did not expect this.

I'm studying how to implement binding Wren to my classes at runtime based on my own reflection metadata, in a similar fashion as I bound lua. (https://github.com/hugoam/mud/blob/master/src/lang/Lua.cpp) I'm almost in a dead end, or all designs I can think of will end up way too complex. So I want to know if you can help me or give me some pointers :)

The crux of the problem is that, unlike in lua where there is a function call mechanism with upvalues (for closures) at the core of the library, in Wren everything is the other way around: everything is an object, so you only ever call methods, and the C API method binding mechanism doesn't allow you to store any closure data with it : you only give a bare function pointer, which is biased towards implementing all your foreign methods manually (or generating C++ code).

I can't bind C/C++ primitives at runtime without being able to store some "closed-over" values somehow (like a wren handle) together with the bound method in bindForeignMethod. Which, if I'm starting to understand Wren design, seems likely to be impossible.

So I've been trying to think of ways to store a Wren handle (to a foreign class that I defined to store my callable), but since I have no way to attach it to the bound method in the bindForeignMethod handler, I need an alternative.

Since in Wren closures seem to be a higher level construct based on the former mechanisms (objects, methods, etc...), I can think of some very contrived workarounds where I would define my closure classes, create instances of these closures for each of my primitives, and write boilerplate "proxy" methods that would call these closures in the body of the foreign class, and then compile all this Wren boilerplate. But there are two things about such a design :

1. I'm still not sure it's entirely possible
2. that's more an argument towards not using Wren so far, and I really wanted to provide this otherwise very neat language :)

Did I miss something crucial that would help me implement this with Wren ? If I haven't been clear or making sense let me know too :)

While exploring something else I noticed this, the closure passed to wrenCall checks arity but it's 0 in the cases I've seen. #1124 is likely related, but good to add tests for when there.

 ASSERT(vm->fiber->stackTop - vm->fiber->stack >= closure->fn->arity,
        "Stack must have enough arguments for method.");

Although System.Write(object) and System.print(object) both return their arguments, which is useful for method chaining etc., this isn't documented. The aim of this PR is therefore to remedy that.

Hi,

The following change sets adds basic interface capabilities to the language.

For now, only the implements operator is added. But I also plan to add class definitions checks soon (I won't have the time to implement it, until the end of weekend).

If there is enough interest, I consider adding interfaces definitions to the language. I started prototyping it but It needs to be more polished.

Exposing these List methods allow to grow the underlying container to a size reducing unnecessary allocations and copying, and can bring performance when the final size/required capacity of the list is known in advance.

ObjFn->arity was only populated for functions. Fix that with wren call handles, and regular methods, so the stack can be properly adjusted when invoking wrenCallFunction.