FLEXLANG: New Language Project

[asl-flex]

Title: FLEXLANG: Feedback & Help Needed for Version 2

Hi everyone,

I’m working on a programming language called FLEXLANG. I started it a while ago but abandoned it, and now I’m planning to continue development with Version 2, including regular updates.

Inside the zip, you’ll find four versions of FLEXLANG for context:

• FLEXLANG BETA 6.05 – the oldest version (earlier history is lost)
• FLEXLANG V1 – supposedly the first stable release
• FLEXLANG V2 PREVIEW 1
• FLEXLANG V2 PREVIEW 2 – the latest preview

I’m looking for feedback, bug fixes, or feature suggestions to help improve FLEXLANG V2. All relevant details, notes, and instructions are included inside the zip.

Planned roadmap after V2:

• Compiler (Source → AST → .bin/.exe)
• Interpreter (AST → directly run)
• Source Compiler (AST → silicon machine code)
• FLEXLANG MICRO – an OS + interpreter for ESP32 (support for Raspberry Pi Pico planned later)

You can download the zip here: [FLEXLANG.zip](https://github.com/user-attachments/files/24836318/FLEXLANG.zip)

I’d appreciate any guidance, contributions, or ideas on how to make FLEXLANG V2 more robust and functional.

[Pranav4628]

Before giving any feedback I would like to know, What is this programming language about?
And where it's used in the real world applications ?
And on which base is this programming language being made ?

[asl-flex]

Hi! Thanks for asking. 😊

FLEXLANG is a multi-purpose programming language I’m developing to experiment with interpreters, compilers, and embedded systems integration. Here’s a quick overview:

1. Purpose & Concept:

   • FLEXLANG is designed to be flexible and lightweight, supporting both interpreted and compiled execution.
   • It explores different execution modes: Source → AST → Run, AST → .bin/.exe, and AST → silicon machine code.
   • It also has a micro-version (FLEXLANG MICRO) aimed at running on ESP32 (and later Raspberry Pi Pico), making it suitable for small embedded systems.

2. Real-world applications:

   • Currently, it’s primarily an experimental and educational project.
   • Once mature, it could be used for tiny embedded control, OS development, high-end apps, server/backend applications, AI/ML, and general-purpose programming, as well as learning compiler/interpreter design.
   • The main goal is to create a general-purpose language so developers can focus on mastering a single language while spending more time on DSA, algorithms, and problem-solving, helping build better software faster.

3. Technical basis:

   • FLEXLANG is built around an AST-based execution model.
   • It supports multiple “modes” (interpreter, compiler, source compiler), allowing code to be translated into different forms of machine or intermediate representations.
   • The language may eventually feature a flex ecosystem, where, for example, a compiled program could import from "AST trees" meant for interpretation.

While this might sound complex or bloated, it’s intended to provide maximum flexibility.

For FLEXLANG V2, the focus will be on adding multiline loops and conditions, arrays, pointers, and maps. Compiler-related features will come later.

In short, it’s part experimental language, part AI/embedded systems exploration, and your feedback would be invaluable in shaping it for real-world use cases.

[asl-flex]

One more thing I forgot to mention about platform support:

• FLEXLANG is officially made for Linux and macOS.

• On Windows, it can work with a little tweaking:

  1. Delete the flex.sh file.
  2. Run main.py directly.

• On Linux/macOS, you can simply run it using ./flex.sh.

This ensures the language runs on all major platforms, though Linux/macOS is the primary target.

[midiakiasat]

Before adding more features, FLEXLANG V2 needs hard constraints, not expansion.

Key points to lock down now:

1. Choose one canonical execution model
   Interpreter-first or compiler-first.
   All other modes must derive from it. Parallel “equal” modes will stall the project.

2. Freeze the AST as a contract
   Treat the AST as a stable interface.
   If the AST keeps changing, compilers, tools, and embedded targets will never converge.

3. Define explicit non-goals
   What does FLEXLANG intentionally not do?
   (e.g. no implicit magic, no hidden control flow, no undefined behavior.)

4. Separate language vs runtime
   The language spec must not depend on Python scripts or shell glue.
   Otherwise it’s a toolchain experiment, not a language yet.

5. Add one defining constraint, not many features
   Examples: deterministic execution, explicit memory model, zero-GC runtime, strict embeddability.
   Constraints create identity. Features create entropy.

If V2 establishes a stable core with strict invariants, the compiler, MICRO version, and ecosystem become realistic.
Without that, they will remain aspirational.

[asl-flex]

@asl-flex (Author)

Thanks for the direct and well-structured feedback. I’ll respond to all five points clearly, since this is exactly what V2 is meant to lock down.

---

1. Canonical execution model

FLEXLANG V2 is interpreter-first and interpreter-only.
There are no parallel or “equal” execution modes in V2. The interpreter defines the language semantics. All compilation, bytecode, or embedded work is planned for later versions and will be derived from this single execution model.

---

2. AST as a contract

V2 will support V1 programs, and from V2 onward the AST structure will be treated as stable and versioned.

Once V2 is finalized:

• the AST will not change arbitrarily
• tooling and future targets will rely on this contract

If a major breaking change is ever required:

• multiple interpreters will coexist (e.g. V1, CURRENT)
• each interpreter targets a specific AST + semantic version
• no silent behavior changes

From now onward, there will be two interpreters only:

• V1 (legacy compatibility)
• CURRENT (actively developed, stable core)

---

3. Explicit non-goals (V2)

V2 intentionally does not aim to:

• introduce implicit or “magic” behavior
• hide control flow
• allow undefined execution semantics
• provide native compilation or embedded targets
• optimize performance at the cost of clarity

V2 is about correctness and stability, not expansion.

---

4. Language vs runtime separation

Agreed. The language definition is independent of its implementation.

Although the current reference interpreter is written in Python and launched via scripts:

• Python is not the language specification
• shell scripts are not part of the language

V2 will clearly separate:

• the language contract (syntax, AST, semantics)
• the runtime implementation (one interpreter)

---

5. One defining constraint

The defining constraint for FLEXLANG V2 is:

Deterministic execution with explicit, predictable rules.

This constraint is chosen to prevent semantic drift and to make future compilation and embedded targets realistic once the core stabilizes.

V2 is about convergence, not growth. Once the rules and AST are locked, the compiler, MICRO version, and ecosystem become achievable rather than aspirational.

Thanks again for pushing on discipline — this feedback is shaping V2 in the right direction.

[healer0805]

This is a solid restart point. A few thoughts after skimming the V2 previews and roadmap.

First, "before adding more surface features", I'd strongly recommend nailing down the -core language contract. Right now the versions feel like they're evolving feature-first instead of rule-first. For V2, it would help a lot to clearly lock in:

• grammar rules (even if informal at first),
• type behavior (strict vs loose, implicit casts, etc.),
• error model (compile-time vs runtime, fail-fast vs recover).

Once that contract is stable, everything downstream (compiler, interpreter, micro version) gets much easier to reason about and extend.

On the "compiler/interpreter split": good call separating AST generation from execution. One thing I'd suggest is to -treat the AST as the product-, not the binary. If the AST is clean, well-typed, and versioned, you can:

• interpret it,
• compile it,
• target ESP32 later,
  without rewriting semantics every time. I'd even add a small AST validator pass early; it'll save you from debugging weird runtime behavior later.

For "V2 specifically", I'd focus on these before adding new syntax:

1. Deterministic parsing (no ambiguous constructs, even if it limits expressiveness).
2. Predictable scoping rules (globals vs locals vs blocks; spell it out).
3. Minimal but explicit standard library (I/O, math, memory; nothing “magic”).

Regarding "FLEXLANG MICRO": this is ambitious but doable if you're disciplined. For embedded targets, I'd strongly recommend:

• no dynamic allocation by default,
• explicit limits (stack size, instruction count),
• a reduced AST subset rather than “full language on tiny hardware”.

Finally, from a community standpoint: if you want contributors, consider adding:

• a short “language philosophy” doc (what problems FLEXLANG is -for-),
• one canonical example program that shows the -intended style-,
• a roadmap that clearly says what is -not- being worked on yet.

Happy to look into specific parts (parser, AST shape, execution model) if you want focused feedback.

[asl-flex]

@asl-flex (Author)

Thanks for the thoughtful review — this is very much aligned with how I want V2 to reset the project.

You’re right that earlier versions evolved feature-first. V2 is intentionally rule-first, and the goal is to lock the core language contract before adding surface syntax.

For V2, I’m explicitly locking down:

• Grammar rules (initially informal but unambiguous)
• Type behavior (explicit rules, minimal implicit casting)
• Error model (well-defined runtime errors, fail-fast by default)

Once this contract is stable, everything downstream becomes much easier to reason about.

On the compiler/interpreter split: agreed completely.
In V2, the AST is the product, not a by-product of execution. The interpreter is simply the reference runtime for that AST. Treating the AST as versioned and stable allows interpretation now and compilation or embedded targets later without redefining semantics.

I also agree on adding an AST validation pass early — that’s planned as part of the V2 execution pipeline to catch structural and semantic errors before runtime behavior gets involved.

For V2 priorities before new syntax, the focus will be:

• deterministic parsing (no ambiguous constructs)
• clearly defined scoping rules (globals, locals, blocks explicitly spelled out)
• a minimal, explicit standard library (I/O, math, basic memory access — no hidden behavior)

Regarding FLEXLANG MICRO: I fully agree this only works with discipline. MICRO will not attempt to run the full language. It will be based on:

• a reduced AST subset
• no dynamic allocation by default
• explicit execution and memory limits
• semantics identical to core FLEXLANG where supported

From a community and contributor standpoint, your suggestions are spot on. I’m planning to add:

• a short language philosophy document
• one canonical example program that demonstrates the intended style
• a roadmap that clearly states what is out of scope for V2

Really appreciate the offer to review specific parts — once the V2 core (grammar + AST + execution rules) is locked, focused feedback on the parser and AST shape would be extremely valuable.

Thanks again for the constructive push toward discipline — it’s helping turn this into a converging language rather than an expanding experiment.

[asl-flex]

@asl-flex (Author)

Based on the valuable feedback received on V2, I’m moving forward with FLEXLANG V2 – PREVIEW 3.

To recognize meaningful contributions, contributors who provided core design feedback will be formally credited in this release.

For FLEXLANG V2 PREVIEW 3, contributions will be recorded with:

• Contributor name
• Date, month, year, and hour of contribution
• A contributor logo/mark inside the project
• A permanent mention in the V2 PREVIEW 3 credits / notes

These credits will acknowledge design-level input that helped shape:

• the interpreter-first execution model
• AST stability and versioning
• language constraints and non-goals
• MICRO and roadmap discipline

FLEXLANG V2 PREVIEW 3 will reflect:

• interpreter-only execution
• a stabilized and versioned AST
• clearer language rules and constraints
• documented design decisions influenced by community feedback

This is my way of making sure contributors are not just commenters, but part of the language’s history.

Thanks to everyone who took the time to give serious, thoughtful feedback — PREVIEW 3 will directly reflect that work.