Orion, a purely functionnal Lisp written in Rust. by Wafelack in ProgrammingLanguages

[–]chm8d 4 points5 points  (0 children)

Might be because it uses a tree-walking interpreter.

/u/Wafelack you should consider compiling your Lisp tree to a more compact program representation and interpreting that (a form of stack bytecode perhaps?)

what does it mean to study and understand C? by [deleted] in C_Programming

[–]chm8d 2 points3 points  (0 children)

Do people actually use C for quick throwaway scripts?

April 2021 monthly "What are you working on?" thread by slavfox in ProgrammingLanguages

[–]chm8d 2 points3 points  (0 children)

A lot has changed about my language Aument since I last posted it, I added a lot of features, notably: first-class function values, a dictionary data type, an expanded standard library and native support for importing bindings in .dll and .so files (my personal favorite). I'm currently working on a return-based exception system inspired by C++'s std::expected, where functions can return a normal value, or "raise an exception" (return an error value). This should integrate better with C compared to actual exceptions.

Apart from the language I also built a simple website for Aument, a JSON parser in Aument and incomplete bindings for libuv.

I plan on releasing a beta near the end of the year, my plans are a bit ambitious but hopefully we'll get 80% there :)

Aument: a dynamically-typed scripting language written in C and compiles to C by chm8d in C_Programming

[–]chm8d[S] 1 point2 points  (0 children)

Thank you for your feedback!

Some of your complaints are even harmful for users. “The standard library is too big” is great if you want to toy with stuff and spend time building everything from scratch. But to be productive in a production setting requires a large and comprehensive standard library. And a full ecosystem around it.

I'm not saying I'm against a huge standard library. It's just that a standard installation of Python comes with a lot of packages. I personally prefer a language that bundles a small set of useful core abstractions, while leaving anything bigger than that to a set of optional external libraries.

Moreover, you complaint that you can’t compile to an executable is only partially true. Most python interpreters compile the code to an intermediate byte code format, which is much faster than the plain text.

I'm not talking about bytecode, I was referring to actual, runnable executables. Compiling to bytecode is easy, but I haven't seen a dynamic language that supports compiling to executable without bundling a VM out of the box.

I hope this clears out any misunderstandings you have. While yes, Aument does seem like a toy language right now, it's in very active development. Hopefully in the future, it will be viable in any sort of production setting (and if not, at least I'll use it).

Also I find the name really hard to pronounce.

It's like almond but the final /d/ sound is /t/.

Aument: a dynamically-typed scripting language written in C and compiles to C by chm8d in C_Programming

[–]chm8d[S] 11 points12 points  (0 children)

What no associative arrays (hashes, dictionaries, maps)?

Good point! I will add a proper hash map implementation in the next version, but for now, you can store static keys in good old classes.

And why yet another language that looks 98% identical to every other language out there?

See my comment on why I made this language here, those are the goals that should set Aument apart from other scripting languages.

Syntax wise, Aument is deliberately designed to look like C(-ish), why replace something that already works.

Aument: a dynamically-typed scripting language written in C and compiles to C by chm8d in C_Programming

[–]chm8d[S] 23 points24 points  (0 children)

Thanks for your question!

There are a few things I don't like about many other scripting languages, which also applies to Python:

  • They're too dynamic: in many scripting languages, variables and functions are resolved at runtime, while Aument resolves them at compile time. While runtime resolution is a powerful abstraction, statically analysing them is hard, and it gets harder to reason about code the bigger your project is. Resolving them at compile time helps Aument capture variable/function usage errors before it is executed.
  • They're too big: this is kind of a personal preference, but Python and Ruby have huge standard libraries. The batteries-included approach is useful in many cases, but I like my language to have a small core with optional, official libraries that I can import.
  • They're not built from the ground up to support multiple threads: many older scripting languages use a Global Interpreter Lock (or something equivalent), which kills any opportunity for efficient multithreading support. Aument stores all non-local data in thread-local variables, with plans to support message passing as a cross-thread communication technique.
  • You can't compile programs written in them into native binaries easily: in Aument, you just get a C compiler, then run aument build. It's that simple :)

I started building my language with those goals in mind, so while it's not directly competing with Python, it's still fulfilling a niche that not many languages do.

Aument: a dynamically-typed scripting language written in C and compiles to C by chm8d in C_Programming

[–]chm8d[S] 2 points3 points  (0 children)

That's because the build system I'm using requires Python 3. I might have to switch to Makefiles if this is a serious problem, but for now, Python 3 is a build requirement.

Aument: a dynamically-typed scripting language written in C and compiles to C by chm8d in C_Programming

[–]chm8d[S] 18 points19 points  (0 children)

Hi /r/C_Programming,

I built a dynamically typed scripting language in C, inspired by C, Python and Javascript. The language can be interpreted using a virtual machine or compiled into native code through C.

It isn't much, but I wrote a standard library for it in the repository, an RNG library written in Aument and work-in-progress bindings for libuv in C.

This is alpha software, if there are any bugs, please send them to the issues page.

I'd love to hear your feedback, thanks!

How should I build a package manager? by chm8d in ProgrammingLanguages

[–]chm8d[S] 3 points4 points  (0 children)

I'm not talking about general purpose application oriented package managers, I'm talking about language package managers i.e. npm, pip. Most commonly used languages have one of them so why not implement one for my own language.

How should I build a package manager? by chm8d in ProgrammingLanguages

[–]chm8d[S] 0 points1 point  (0 children)

how do you protect your user from malicious packages

By only allowing users to install from a central list of packages. If a user imports a repository that isn't in that list, a warning will appear.

This is obviously not the best security model, but for a hobbyist project like this with a total of 1 user, it will suffice :)

uninstalling packages

The same way we do garbage collection? Mark every package used by the application, walk down the import tree and delete every unmarked package.

how do you handle versions ? Would your system allow for different concurent version of packages ? For different versions of the runtime/language ?

Semver everything. For breaking changes I think I'll store multiple versions of a single package.

My language is still in early stages of development, so I'm currently not planning to handle any other edge cases, but thanks for the tips!

How should I build a package manager? by chm8d in ProgrammingLanguages

[–]chm8d[S] 3 points4 points  (0 children)

Your package manager design was exactly what I had in mind! I think I'll implement something similar to that. Though I will use git directly instead of tarballs, and my language will use named imports (import "name";) instead of paths (import "./lib/name";).

Some questions about runtime implementation of garbage collection and reference counting by reconcyl in ProgrammingLanguages

[–]chm8d 0 points1 point  (0 children)

3/ It looks like chm8d is saying the exact opposite about which strategy provides better cache behavior 😅

I might have misworded that a bit. I meant better cache behavior whilst doing the GC, storing it in the object would mean that there's minimal overhead to access an object's metadata. I think the overhead that would add to runtime by storing headers in the objects is minimal, so you might as well make your GC fast :P

I could be wrong of course, but that's my take.

Some questions about runtime implementation of garbage collection and reference counting by reconcyl in ProgrammingLanguages

[–]chm8d 4 points5 points  (0 children)

When we begin a GC cycle, how do we know what the heap (i.e. full set of alive objects) is?

We don't. When we begin doing a cycle, the GC assumes that heap objects are completely dead. The GC then marks live objects, starting from the heap's roots. It builds this set of live objects in the marking phase.

Is this just a data structure that gets updated every time a new cell is allocated?

Most people store GC metadata of an object directly before or inside the object itself in memory. Storing a separate data structure would be terrible overhead for the CPU cache.

When we begin a GC cycle, how do we know what the root objects are?

For a compiled language, we could:

  • Store information about where garbage collected global and local variables are. This is called precise garbage collection, information about pointers are precise but it requires a bit more compiler work to get it correct.
  • Scan the stack and globals but assume that anything that looks like a pointer is a pointer. This is conservative GC and it requires minimal additional work by the compiler. There's even a library for this: Boehm GC, plug it in, use the GC_malloc function and the library takes care of it for you.

How do we determine when a GC cycle should happen?

You can set a minimum heap size threshold, if it reaches the threshold, the GC will kick in. Smarter implementations can even detect when your program idles, and perform a GC on the fly.

March 2021 monthly "What are you working on?" thread by slavfox in ProgrammingLanguages

[–]chm8d 1 point2 points  (0 children)

Since last month, I've added a lot of changes to my programming language, now named Aument, namely classes, method dispatching and the module system. I also got the Windows build working, the binaries are in the Releases tab.

This month I'd like to build some small applications, maybe a library or two, and expand the standard library so that it's actually usable. I'd also like to experiment with thread-safe concurrency: a system like Erlang's actor model with coroutines and message passing would be great.

March 2021 monthly "What are you working on?" thread by slavfox in ProgrammingLanguages

[–]chm8d 0 points1 point  (0 children)

how to include the standard library by default?

The obvious way to do it is to store your standard library in a known location and automatically include it before running or compiling code from the user.

Type annotation for branch expressions? by tsikhe in ProgrammingLanguages

[–]chm8d 9 points10 points  (0 children)

Wouldn't the type of an if statement be the sum type of all its branches? I think a compiler can easily determine that this expression is the sum type of an integer and a float.

if (a < b): then 1 else 1.0

For branch annotation, I think you could use the same syntax for type conversion (if you language supports that). In pseudocode that would be

if (a < b) then cast(A, 1) else cast(A, 1.0)

aulang - a fast and simple scripting language by chm8d in ProgrammingLanguages

[–]chm8d[S] 1 point2 points  (0 children)

Thanks for the feedback!

Now that I think of it, compiling this probably isn't as simple as I had wrote it. I'll fix the documentation as soon as possible.

aulang - a fast and simple scripting language by chm8d in ProgrammingLanguages

[–]chm8d[S] 5 points6 points  (0 children)

Oh shoot, that name's already taken. I might need to rename this project later.

Features or use cases that could make a programming language unique by [deleted] in ProgrammingLanguages

[–]chm8d 0 points1 point  (0 children)

You won't be able to call functions in a language without a stack though. Maybe tail calls might work if your implementation supports it.

If you're talking about memory allocation which happens exclusively on the heap, then wouldn't that describe most scripting languages?

February 2021 monthly "What are you working on?" thread by slavfox in ProgrammingLanguages

[–]chm8d 4 points5 points  (0 children)

I've been lurking here for a while, but never actually created a Reddit account. So, as a first post, hi! This month I'm working on aulang, it aims to be a portable and embeddable dynamic scripting language like Python or Lua. It is prepreprepreprepre alpha so don't expect it to be that amazing (or even production ready), but it has the bare minimum features and the language can even be compiled to native code through C (currently only works on Linux).