Jancy is the first and only scripting language with safe pointer arithmetics, high level of ABI and source compatibility with C, support for spreadsheet-like reactive programming, built-in generator of incremental lexers/scanners, dynamic structures with array fields of non-constant sizes, dual error handling model which allows you to choose between error-code checks and throw semantics at each call-site, and a lot of other unique and really useful features.

• Statically typed C-family scripting language for IO and UI domains

  Python is the scripting language of hackers. I hope Jancy will one day become the scripting language of those hackers who prefer to stay closer to C.

• High level of ABI and source compatibility with C

  Calling from Jancy to native code and vice versa is as easy and efficient as it gets. So is developing Jancy libraries in C/C++ and Jancy bindings to popular libraries. So is porting publicly available algorithms from C to Jancy -- copy-paste often suffices!

• Automatic memory management via accurate GC

  Losing manual memory management (together with the vast class of bugs and leaks associated with it) in favor of the GC employment has its price, but for scripting languages, it's 100% worth it.

• LLVM as a back-end

  This was a no-brainer from the very beginning. I started with LLVM 3.1 a few years ago; at the present moment Jancy builds and runs with any LLVM version from 3.4.2 all the way up to the latest and greatest LLVM 8.0.0

Use pointer arithmetic -- the most elegant and the most efficient way of parsing and generating binary data -- and do so without worrying about buffer overruns and other pointer-related issues!

IpHdr const* ipHdr = (IpHdr const*)p;
p += ipHdr.m_headerLength * 4;

switch (ipHdr.m_protocol)
{
case Proto.Icmp:
        IcmpHdr const* icmpHdr = (IcmpHdr const*)p;
        switch (icmpHdr.m_type)
        {
        case IcmpType.EchoReply:
                ...
        }
        ...
}

If bounds-checks on a pointer access fail, Jancy runtime will throw an exception which you can handle the way you like.

You can also safely pass buffers from C/C++ to Jancy without creating a copy on the GC-heap:

void thisIsCpp(
        jnc::Runtime* runtime,
        jnc::Function* function
        )
{
        char buffer[] = "I'm on stack but still safe!";

        JNC_BEGIN_CALL_SITE(runtime)
                // create a call-site-local foreign data pointer
                jnc::DataPtr ptr = jnc::createForeignBufferPtr(buffer, sizeof(buffer), true);
                jnc::callFunction(function, ptr);
        JNC_END_CALL_SITE() // here ptr is invalidated and Jancy can't access it anymore
}

Write auto-evaluating formulas just like you do in Excel -- and stay in full control of where and when to use this spreadsheet-likeness:

reactor m_uiReactor
{
        m_title = $"Target address: $(m_addressCombo.m_editText)";
        m_localAddressProp.m_isEnabled = m_useLocalAddressProp.m_isChecked;
        m_isTransmitEnabled = m_state == State.Connected;
        ...
}

m_uiReactor.start();
// now UI events are handled inside the reactor...

m_uiReactor.stop();
// ...and not anymore

This, together with the developed infrastructure of properties and events, is perfect for UI programming!

Schedulers allow you to elegantly place the execution of your callback (completion routine, event handler, etc) in the correct environment -- for example, into the context of a specific thread:

class WorkerThread: jnc.Scheduler
{
        override schedule(function* f())
        {
                // enqueue f and signal worker thread event
        }
        ...
}

Apply a binary operator @ (reads "at") to create a scheduled pointer to your callback:

void onComplete(bool status)
{
        // we are in the worker thread
}

WorkerThread workerThread;
startTransaction(onComplete @ workerThread);

When the transaction completes and completion routine is finally called, onComplete is guaranteed to be executed in the context of the assigned workerThread.

The async-await paradigm is becoming increasingly popular during recent years -- and righfully so. In most cases, it absolutely is the right way of doing asynchronous programming. As a language targeting the IO domain, Jancy fully supports async-await:

async transact(char const* address)
{
        await connect(address);
        await modify();
        await disconnect();

catch:
        handleError(std.getLastError());
}

jnc.Promise* promise = transact();
promise.blockingWait();

A cherry on top is that in Jancy you can easily control the execution environment of your async procedure with schedulers -- for example, run it in context of a specific thread:

// transact() will run in the worker thread
jnc.Promise* promise = (transact @ m_workerThread)("my-service");

You can even switch contexts during the execution of your async procedure:

async foo()
{
        await thisPromise.asyncSetScheduler(m_workerThread);
        // we are in the worker thread

        await thisPromise.asyncSetScheduler(m_mainUiThread);
        // we are in the main UI thread
}

Create efficient regex-based switches for tokenizing string streams:

jnc.RegexState state;
reswitch (state, p, length)
{
case "foo":
        ...
        break;

case r"bar(\d+)":
        print($"bar id: $(state.m_subMatchArray[0].m_text)\n");
        break;

case r"\s+":
        // ignore whitespace
        break;

...
}

This statement will compile into a table-driven DFA which can parse the input string in O(length) -- you don't get any faster than that.

But there's more -- the resulting DFA recognizer is incremental, which means you can feed it the data chunk-by-chunk when it becomes available (e.g. once received over the network).

Define dynamically laid-out structures with non-constant sizes of array fields -- this is used in many file formats and network protocol headers (i.e. the length of one field depends on the value of another):

dynamic struct FileHdr
{
        ...
        char m_authorName[strlen(m_authorName) + 1];
        char m_authorEmail[strlen(m_authorEmail) + 1];
        uint8_t m_sectionCount;
        SectionDesc m_sectionTable[m_sectionCount];
        ...
}

In Jancy you can describe a dynamic struct, overlap your buffer with a pointer to this struct and then access the fields at dynamic offsets normally, just like you do with regular C-structs:

FileHdr const* hdr = buffer;

displayAuthorInfo(hdr.m_authorName, hdr.m_authorEmail);

for (size_t i = 0; i < hdr.m_sectionCount; i++)
{
        processSection(hdr.m_sectionTable[i].m_offset, hdr.m_sectionTable[i].m_size);
}

You can write to dynamic structs, too -- just make sure you fill it sequentially from top to bottom. And yes, dynamically calculated offsets are cached, so there is no significant performance penalty for using this facility.

Both throw-catch and error-code approaches have their domains of application. Why force developers to choose one or another at the API design stage?

In Jancy you can write methods which can be both error-checked and caught exceptions from -- depending on what is more convenient at each particular call-site!

class File
{
        bool errorcode open(char const* fileName);
        close();
        alias dispose = close;
}

Use throw-catch semantics:

foo(File* file)
{
        file.open("data.bin");
        file.write(hdr, sizeof(hdr));
        file.write(data, dataSize);
        ...

catch:
        print($"error: $!\n");

finally:
        file.close();
}

...or do error-code checks where it works better:

bar()
{
        disposable File file;
        bool result = try file.open("data.bin");
        if (!result)
        {
                print($"can't open: $!\n");
                ...
        }
        ...
}

On a side note, see how elegantly Jancy solves the problem of deterministic resource release? Create a type with a method (or an alias) named dispose -- and every disposable instance of this type will get dispose method called upon exiting the scope (no matter which exit route is taken, of course).

Jancy introduces yet another cool feature called dual type modifiers -- i.e. modifiers which have different meaning depending on the context. One pattern dual modifiers apply really well to is read-only fields:

class C
{
        int readonly m_readOnly;
        foo();
}

The readonly modifier's meaning depends on whether a call-site belongs to the private-circle of the namespace:

C.foo()
{
        m_readOnly = 10; // ok
}

bar(C* c)
{
        print($"c.m_readOnly = $(c.m_readOnly)\n"); // ok
        c.m_readOnly = 20; // error: cannot store to const-location
}

No more writing dummy getters!

Another common pattern is a pointer field which inherits mutability from its container:

struct ListEntry
{
        ListEntry cmut* m_next;
        variant m_value;
}

The cmut modifier must be used on the type of a member -- field, method, property. The meaning of cmut then depends on whether the container is mutable:

bar(
        ListEntry* a,
        ListEntry const* b
        )
{
        a.m_next.m_value = 10; // ok
        b.m_next.m_value = 10; // error: cannot store to const-location
}

Implementing the equivalent functionality in C++ would require a private field and three accessors!

Finally, the most obvious application for dual modifiers -- event fields:

class C1
{
        event m_onCompleted();
        work();
}

The event modifier limits access to the methods of the underlying multicast depending on whether a call-site belongs to the private-circle of the namespace:

C.work()
{
        ...
        m_onCompleted(); // ok
}

foo(C* c)
{
        c.m_onCompleted += onCompleted; // adding/remove handlers is ok
        c.m_onCompleted(); // error: non-friends can't fire events
}

• Multiple inheritance
• Properties -- the most comprehensive implementation thereof!
• Weak events (which do not require to unsubscribe)
• Partial application for functions and properties
• Function redirection
• Extension namespaces
• Thread local storage
• Bitflag enums
• Big-endian integers
• Perl-style formatting
• Hexadecimal, raw and multi-line literals
• Opaque classes
• break<n>, continue<n>

...and many other cool and often unique features, which simply can't be covered in the quick intro.

• Jancy Language Manual
• Jancy Standard Library Reference
• Jancy C API Reference
• Jancy Compiler Overview
• Jancy Grammar Reference
• Jancy Build Guide