What Can NSL Actually Do? — A Look at Nova Signal Language

NSL developer — Fri, 02 Oct 2026 03:14:24 +0000

I built my own programming language.

It is called NSL — NOVA SIGNAL LANGUAGE.

NSL started as an experiment in language design, but it has grown into something much larger: an interpreter, an IDE, a UI runtime, libraries, a package-management system, protected extensions, a profiler, Web UI support, and an NSL → C++ pipeline.

The current milestone is NSL v1.0 BETA.

This post is a technical tour of what NSL can do today, what has actually been tested, and what is still under development.

«🐙 NSL | NOVA SIGNAL LANGUAGE ¦ HYBRID EDITION»

The octopus represents the idea behind NSL:

many directions at once.

What is NSL?

NSL is a programming language designed around a hybrid architecture.

The current project contains:

an NSL interpreter
an IDE built with Python/Kivy/KivyMD
a UI system
a Web UI runtime
a File Manager
a Profiler
a package-management ecosystem
native standard-library modules
protected system extensions
an NSL → C++ translation pipeline
validation and security layers

The v1.0 BETA ZIP contains 107 files.

The project is still BETA, not a finished stable language.

The basic syntax

The language is designed to keep common operations readable.

For example:

™ NSL ° 1.0

VAR name = "NSL"
VAR version = "1.0 BETA"

PRINT[name]
PRINT[version]

Variables can contain strings, numbers, arrays and other supported values.

VAR a = 5
VAR b = 3

PRINT[a + b]
PRINT[a * b]
PRINT[a - b]

The syntax can also be used for calculations:

VAR result = 25 + 17

PRINT[result]

Functions

NSL supports user-defined functions and return values.

FUN add(a, b) {

VAR result = a + b

RETURN [ : result : ]

}

VAR answer = add(25, 17)

PRINT[answer]

A function can also update the UI:

FUN greet(name) {

UPDATE["welcome_label"] {
    TEXT["WELCOME, #{name}"]
    COLOR["ORANGE"]
}

}

String interpolation uses the "#{...}" form:

VAR name = "NSL"
PRINT["Hello #{name}"]

Conditions

NSL supports "IF" and "ELSE".

FUN condition_engine(value) {

IF value > 10 {

    PRINT["VALUE > 10"]

} ELSE {

    PRINT["VALUE <= 10"]
}

}

This gives programs normal conditional control flow while keeping the syntax compact.

Loops

NSL has "FOR", "WHILE", "BREAK" and "CONTINUE".

FOR

VAR numbers = [1, 2, 3, 4, 5]

FOR value IN numbers {

PRINT[value]

}

BREAK and CONTINUE

VAR numbers = [1, 2, 3, 4, 5]
VAR sum = 0

FOR value IN numbers {

IF value == 2 {
    CONTINUE
}

IF value == 5 {
    BREAK
}

sum = sum + value

}

PRINT[sum]

WHILE

VAR index = 0
VAR result = 0

WHILE index < 5 {

result = result + index
index = index + 1

}

PRINT[result]

Arrays

Arrays can be modified using operations such as "push()" and "pop()".

VAR data = [10, 20, 30]

data.push(40)

VAR removed = data.pop()

PRINT[data]
PRINT[removed]

NSL also supports operations such as "LEN()" and joining array contents:

VAR data = [10, 20, 30]

VAR length = LEN(data)
VAR text = data.join(";")

PRINT[length]
PRINT[text]

Strings

The standard library provides string operations.

VAR text = "nova signal language"

VAR upper_text = text |> stdlib.upper
VAR lower_text = text |> stdlib.lower
VAR reverse_text = text |> stdlib.reverse

VAR text_length = stdlib.length(text)

PRINT[upper_text]
PRINT[lower_text]
PRINT[reverse_text]
PRINT[text_length]

The pipe operator allows function-style processing:

VAR result = "hello" |> stdlib.upper

Error handling

NSL supports "TRY / CATCH".

TRY {

VAR first = 100
VAR second = 0

VAR result = first / second

} CATCH error {

PRINT["CATCH: #{error}"]

}

This allows a program to handle runtime errors without immediately terminating the whole operation.

MATCH

NSL has a "MATCH¿" construct for condition-based branching.

FUN match_engine(value) {

MATCH¿ {

    CASE value == 1 {

        PRINT["MATCH: ONE"]
    }

    CASE value == 2 {

        PRINT["MATCH: TWO"]
    }

    CASE value == 3 {

        PRINT["MATCH: THREE"]
    }

    DEFAULT {

        PRINT["MATCH: OTHER"]
    }
}

}

Classes and objects

The interpreter also supports classes, constructors through functions such as "init", object creation and "THIS".

CLASS Signal {

VAR value = 0
VAR name = "SIGNAL"

FUN init(start) {

    THIS.value = start
    THIS.name = "NOVA"
}

FUN amplify(amount) {

    THIS.value = THIS.value + amount

    RETURN [ : THIS.value : ]
}

}

An object can then be created and used:

VAR signal = NEW Signal(100)

VAR result = signal.amplify(25)

PRINT[result]

RANGE

NSL also provides "RANGE()".

VAR sequence = RANGE(1, 6)

PRINT[sequence]
PRINT[LEN(sequence)]

An array can then be transformed into text:

VAR sequence = RANGE(1, 6)

VAR sequence_text = sequence.join(";")

PRINT[sequence_text]

Libraries

NSL has a library system.

For example:

IMPORT [,

The current bundled library set includes libraries such as:

math
colors
units
physics
chemistry
geography
currency
HTTP status values
network ports
timezones
file types
text encodings
regular-expression patterns
date/time constants
ASCII table values

The bundled SLI catalog contains 15 ".nsl" libraries.

Some libraries provide constants rather than functions.

For example:

VAR pi = math.PI
VAR tau = math.TAU

PRINT[pi]
PRINT[tau]

STDLIB

NSL v1.0 BETA also includes a native standard library system.

The current package contains 15 native STDLIB modules.

These cover areas such as:

math
string
list_utils
dict_utils
datetime
random
json
validation
conversion
statistics
text
network
system
path
file

Together with the existing built-in functions, the project reports 140 available native standard-library functions and 145 standard-library constants.

Some functions intentionally have restricted scope.

For example, the file module is designed to operate inside the current NSL project directory rather than providing unrestricted filesystem access.

The system and network modules also expose information-oriented functionality rather than providing arbitrary shell or socket execution.

DUO + SLI + SPE

NSL v1.0 BETA also introduces its own package ecosystem.

The main components are:

DUO
SLI
SPE
STDLIB
Key Manager
Security / Permissions
Translation Pipeline

DUO

DUO is responsible for package discovery and package operations such as searching and downloading/updating packages.

SLI

SLI — Special Libs Installer

SLI installs packaged ".nsl" libraries and verifies their integrity.

The BETA includes 15/15 SLI catalog entries.

SPE

SPE — System Protected Extensions

SPE is different from normal libraries.

A SPE entry cannot simply be accessed with:

IMPORT []

The system uses a gateway and authorization mechanism instead.

In the current BETA:

15/15 SPE entries
4 implemented capabilities
11 authorization-only placeholders

The four implemented capabilities are:

ai_core
system_utils
crypto_operations
compiler_backend

The remaining 11 entries can participate in authorization but honestly report that their privileged capability is not implemented yet.

This is deliberate. I would rather show "not implemented" than pretend an unsupported Android or device-level feature already works.

AI metadata

NSL also has a metadata system using special AI-oriented blocks.

WHY¿ {
PURPOSE = "NOVA SIGNAL LANGUAGE"
}

WHAT¿ {
SYSTEM = "HYBRID EDITION"
}

WHEN¿ {
STAGE = "v1.0 BETA"
}

WHERE¿ {
TARGET = "NSL IDE"
}

WHO¿ {
OWNER = "NSL"
}

HOW¿ {
MODE = "INTERPRETER + UI"
}

SAFE||| {
VERIFY = TRUE
}

These blocks are part of the current interpreter's metadata system.

An important detail is that the language requires the special "¿" form for these AI metadata blocks.

For example:

WHY¿ {
PURPOSE = "NOVA SIGNAL LANGUAGE"
}

is not equivalent to:

WHY {
PURPOSE = "NOVA SIGNAL LANGUAGE"
}

UI development

One of the main goals of NSL is to let code control UI elements.

A simplified UI example looks like this:

UI APP {

STATE status = "READY"
STATE counter = 0

TEXT = "NOVA SIGNAL"
TEXT = status

INPUT = "Ismingizni kiriting"
IMAGE = "logo.png"

ROW {

    BUTTON = "RUN" {

        CLICK {

            status = "RUNNING"
            counter = counter + 1
        }
    }

    BUTTON = "CLEAR" {

        CLICK {

            status = "READY"
            counter = 0
        }
    }
}

COLUMN {

    TEXT = "Holat paneli"
    TEXT = status
    TEXT = counter
}

CARD {

    TEXT = "NSL - Nova Signal Language"
}

}

The larger UI system also has concepts such as:

SCREEN
LABEL
BUTTON
ROW
COLUMN
CARD
LIST
GRID
INPUT
IMAGE
STYLE
CLICK
UPDATE
ID
POS
SIZE
COLOR

For example:

BUTTON {
ID["run_button"]
TEXT["RUN ALL"]
POS[15, 255]
SIZE[330, 50]
COLOR["ORANGE"]
CLICK[click_run]
}

And UI elements can be updated from functions:

UPDATE["status_label"] {

TEXT["STATUS: RUNNING"]
COLOR["GREEN"]

}

The project also supports "ONCLICK" blocks:

ONCLICK["run_button"] {

UPDATE["welcome_label"] {

    TEXT["NSL | FULL RUNTIME"]
    COLOR["ORANGE"]
}

}

The UI architecture is implemented in the project, but the final Kivy screens and touch interactions have not yet been verified on a real Android/Pydroid3 device.

Web UI

NSL also includes Web UI components.

The BETA contains:

WebUIModel.py
WebUIScript.py
WebUIMarkup.py
WebUIRenderer.py
WebUIRuntime.py
WebUIStyle.py
WebUISecurity.py
AndroidWebView.py

The idea is to allow NSL projects to work with a WebView-oriented runtime while keeping the main NSL environment separate from the browser layer.

The WebView system is part of the project, although one known issue remains: the behavior of empty space inside the WebView has not been fully resolved.

File Manager

The IDE has a dedicated File Manager.

The current UI includes a file menu with operations such as:

Open
Rename
Move
Info
Properties
Delete

There is also a Library Manager connected to the package-management system.

The logic has been implemented and tested at the code level, but the visual behavior and touch interaction of these Kivy screens still need real-device verification.

Profiler

NSL also includes a profiler.

The project contains:

Profiler.py
ProfilerUI.py

The purpose is to measure runtime behavior, including execution time and call counts.

For example, a profiling run can expose measurements such as execution time and how many calls were made during the run.

This is important because NSL is not only trying to provide syntax; it is also becoming a development environment.

NSL → C++

One of the biggest additions in v1.0 BETA is the NSL → C++ pipeline.

The pipeline contains three important layers:

NSL Source
↓
Parser
↓
Layer 3 — Security Check
↓
Layer 2 — Validation
↓
Layer 1 — NSL → C++ Translation
↓
C++ Backend
↓
g++

The actual implementation is organized around:

translator.py
validator.py
security_check.py
pipeline.py
backend.py

The system uses the existing NSL lexer/parser from "Interpreter.py".

Interpreter and compiler parity

The C++ pipeline is not just a text converter.

The BETA's real test suite compiles NSL programs with g++ and executes them in the test environment.

Five programs were used in the reported verification of the C++ path, and their outputs matched the interpreter results.

For example:

VAR a = 5
VAR b = 3

PRINT[a + b]
PRINT[a * b]
PRINT[a - b]

The important goal is:

NSL Interpreter
↓
output A

NSL → C++
↓
output B

A == B

At this stage, the C++ translator supports a limited internal subset.

The verified direction includes constructs such as:

variables
IF
WHILE
FOR
functions
arrays
string interpolation

It does not currently translate every NSL feature.

For example, UI, "CLASS", "MATCH" and "TRY" are outside the current supported C++ translation subset.

Security in the compiler pipeline

This is one of the parts I care about most.

During development, I found a real security issue.

A dangerous NSL call such as:

system("echo pwned")

could otherwise become a dangerous C++ call:

system("echo pwned");

That means the compiler pipeline could accidentally turn a restricted NSL environment into native process execution.

So the security layer was designed to block this before native execution.

The conceptual flow is:

NSL source
↓
Security Check
↓
UNSAFE
↓
BLOCK
↓
No native execution

The Layer-3 security checker also blocks other dangerous execution paths and prevents SPE imports from bypassing the SPE authorization model through compilation.

This is not a claim that NSL security is finished.

It means the current BETA already has explicit security gates and regression tests around the compiler pipeline.

One important compiler rule

SPE imports are deliberately blocked during native translation.

Even if a SPE capability has authorization support, allowing it to silently enter a compiled binary would potentially bypass the runtime gateway.

So:

IMPORT []

does not become a normal C++ dependency.

That restriction exists specifically to keep the SPE authorization model meaningful.

The complete NSL example

Here is a simplified version of the larger runtime demonstration used during development:

™ NSL ° 1.0

IMPORT [,

VAR app_name = "NOVA SIGNAL"
VAR version = "1.0 BETA"

VAR counter = 0
VAR total = 0
VAR status = "READY"

VAR numbers = [1, 2, 3, 4, 5]
VAR logs = []

WHY¿ {
PURPOSE = "NOVA SIGNAL LANGUAGE"
}

WHAT¿ {
SYSTEM = "HYBRID EDITION"
}

WHEN¿ {
STAGE = "v1.0 BETA"
}

WHERE¿ {
TARGET = "NSL IDE"
}

WHO¿ {
OWNER = "NSL"
}

HOW¿ {
MODE = "INTERPRETER + UI"
}

SAFE||| {
VERIFY = TRUE
}

FUN add_log(message) {

logs.push(message)

UPDATE["log_label"] {
    TEXT["LAST: #{message}"]
}

}

FUN set_status(message) {

status = message

UPDATE["status_label"] {
    TEXT["STATUS: #{status}"]
}

}

FUN increment_counter() {

counter = counter + 1

total = total + counter

UPDATE["counter_label"] {
    TEXT["COUNTER: #{counter}"]
    COLOR["GREEN"]
}

set_status("COUNTER UPDATED")

add_log("Counter -> #{counter}")

}

FUN string_engine() {

VAR text = "nova signal language"

VAR upper_text = text |> stdlib.upper
VAR lower_text = text |> stdlib.lower
VAR reverse_text = text |> stdlib.reverse

VAR text_length = stdlib.length(text)

PRINT[upper_text]
PRINT[lower_text]
PRINT[reverse_text]
PRINT[text_length]

}

FUN array_engine() {

VAR data = [10, 20, 30]

data.push(40)

VAR removed = data.pop()

VAR data_length = LEN(data)

VAR joined = data.join(";")

PRINT[joined]
PRINT[data_length]
PRINT[removed]

}

FUN loop_engine() {

VAR sum = 0

FOR value IN numbers {

    IF value == 2 {
        CONTINUE
    }

    IF value == 5 {
        BREAK
    }

    sum = sum + value
}

PRINT[sum]

}

FUN while_engine() {

VAR index = 0
VAR result = 0

WHILE index < 5 {

    result = result + index
    index = index + 1
}

PRINT[result]

}

FUN match_engine(value) {

MATCH¿ {

    CASE value == 1 {
        PRINT["ONE"]
    }

    CASE value == 2 {
        PRINT["TWO"]
    }

    DEFAULT {
        PRINT["OTHER"]
    }
}

}

FUN safe_engine() {

TRY {

    VAR first = 100
    VAR second = 0

    VAR result = first / second

} CATCH error {

    PRINT["ERROR: #{error}"]
}

}

FUN library_engine() {

VAR pi = math.PI
VAR tau = math.TAU

PRINT["PI = #{pi}"]
PRINT["TAU = #{tau}"]

}

FUN run_all() {

set_status("RUNNING")

increment_counter()
string_engine()
array_engine()
loop_engine()
while_engine()
match_engine(2)
safe_engine()
library_engine()

set_status("ALL SYSTEMS READY")

}

This example demonstrates the general direction of NSL:

language features + standard library + metadata + UI integration + runtime state.

What was actually verified?

The BETA release includes a test suite with 15 test files and 91 reported verification checks.

The reported desktop sandbox verification passed:

15/15 test files
91/91 reported checks

The tests cover areas including:

STDLIB
SLI
SPE gateway
SPE bypass prevention
key management
C++ translation
C++ security
compiler backend
File Manager actions
UI integration simulation
WebView regression
interpreter/package-manager parity

This is important to me because I do not want to describe an untested feature as finished.

What is NOT verified yet?

NSL v1.0 BETA is still a BETA.

The following areas are explicitly not verified:

Kivy screen rendering
Kivy touch interaction
Library Manager on a real device
File menu interaction on a real device
Real Android/Pydroid3 execution
C++ compiler availability on Android
Android Keystore integration

The Android Keystore has not been implemented in this BETA.

On environments such as Pydroid3, the key system falls back to session-only behavior instead of pretending that secure persistent storage exists.

There is also a known unresolved WebView empty-space issue.

Current limitations

NSL is growing quickly, but it still has technical limitations.

The current C++ translator only handles a subset of the full language.

The following are examples of current language facts that matter:

PRINT[x] → used for array printing in the current runtime

Dictionary literals such as:

{ "key": "value" }

are not currently part of the language grammar in the intended way.

"IN" is a reserved language construct.

AI metadata uses:

WHY¿ { ... }

rather than:

WHY { ... }

There are also some cosmetic runtime messages that still need improvement, such as blocked imports being reported with wording that can look like they were loaded even though access was blocked.

These are BETA-level issues, not things I want to hide.

What is next?

The roadmap is larger than v1.0.

The general direction looks like this:

v1.0 BETA
↓
v2.0 DEMO
↓
v2.5 AI DEMO / BETA
↓
v3.0 AI DEMO
↓
v4.0 AI STABLE
↓
v5.0 STABLE + Preparation
↓
v6.0 Independent Language & Bootstrapping

Future development includes areas such as:

Android compiler strategy
more SPE capabilities
real licensing/key infrastructure
real-device UI verification
WebView improvements
larger compiler coverage
stronger package ecosystem
AI capabilities
single-IDE / multi-backend workflow

The long-term idea is not simply to make another scripting language.

The goal is to make NSL capable of moving between multiple directions while keeping one language at the center.

Why "Hybrid Edition"?

NSL is intentionally not limited to one execution path.

Today, the project already connects several worlds:

             ┌── Interpreter
             │

NSL ─────────────┼── UI Runtime
│
├── Web UI
│
├── Package Ecosystem
│
└── C++ Pipeline

That is the reason behind the name:

HYBRID EDITION.

Final thoughts

NSL is not finished.

It is not a stable production language yet.

It is not fully verified on Android.

It does not have every planned compiler feature.

And some of its most ambitious components are still prototypes or controlled placeholders.

But v1.0 BETA is far beyond the original experiment I started with.

It now has a language runtime, IDE infrastructure, UI concepts, package management, protected extensions, standard libraries, a profiler, Web UI support, and a tested NSL → C++ path.

Most importantly, the project is being built with one rule:

«Do not call something finished until it has actually been verified.»

That is what makes this BETA useful.

Not because it is perfect, but because there is now a real foundation to build on.

NSL

NOVA SIGNAL LANGUAGE

🐙 ONE LANGUAGE. MULTIPLE DIRECTIONS.

™ NSL ° 1.0
HYBRID EDITION
BETA

This is only the beginning.

DEV Community: NSL developer

# NSL v1.0 BETA — To'liq yakuniy hisobot Paket: `NSL_v1.0_BETA.zip` (107 fayl) · Holat: BETA — "100%" emas, sababi 15-bo'limda. Bu hisobotdagi har bir "ishlaydi" faqat real test natijasiga tayanadi; tekshirilmagan narsa NOT VERIFIED deb belgil

What Can NSL Actually Do? — A Look at Nova Signal Language

NSL: A New Language Begins

programming #programminglanguage #opensource #developers #python #compiler #devcommunity

DEV Community: NSL developer

# NSL v1.0 BETA — To'liq yakuniy hisobot **Paket:** `NSL_v1.0_BETA.zip` (107 fayl) · **Holat: BETA** — "100%" emas, sababi 15-bo'limda. Bu hisobotdagi har bir "ishlaydi" faqat real test natijasiga tayanadi; tekshirilmagan narsa **NOT VERIFIED** deb belgil

What Can NSL Actually Do? — A Look at Nova Signal Language

NSL: A New Language Begins

programming #programminglanguage #opensource #developers #python #compiler #devcommunity

# NSL v1.0 BETA — To'liq yakuniy hisobot Paket: `NSL_v1.0_BETA.zip` (107 fayl) · Holat: BETA — "100%" emas, sababi 15-bo'limda. Bu hisobotdagi har bir "ishlaydi" faqat real test natijasiga tayanadi; tekshirilmagan narsa NOT VERIFIED deb belgil