markvangulik

As for SHRDLU, it was built atop a “language”, PROGRAMMAR, if I recall, which was really a big ball of Lisp, so the syntax was basically tons of parentheses with keywords inside the left one. But given the available languages, memory, and speed of that time, it was amazing that even a library-ish extension of Lisp could come into play.

Note that embedding PROGRAMMAR inside Lisp is exactly the kind of thing we’re doing with Avail… it’s just that the base metarules are more articulate for that sort of thing.

PROGRAMMAR rewritten today in Avail wouldn’t look at all like Lisp — thank goodness. But if you implemented that language via a compiler, you would have the limitations of the compiler technology constantly getting in the way of the linguistic forms you’re trying to express. For example, having to decide on a linear ranking of precedence levels for every operation, even if they couldn’t ever appear next to each other due to type or linguistic constraints.

Even C++ requires custom lexing tweaks because of spurious “>>” tokens in nested templates… and special backtracking rules to distinguish function definitions from stack object creation. But those bypasses aren’t readily usable in the available parsing tools. Avail’s compiling scheme is decades beyond that.

“Implemented in” is the key. If you want, say, a C compiler written in Lisp, you end up writing a compiler. If you want a Haskell compiler written in Lisp, you write another compiler.

If you want Avail to include all of C, you define C language capability in an Avail module and subtract the rest. Then your C program is also an Avail program, so you have the same tool chain you had with core Avail (still lacking, but getting there), you have dynamic optimizing compilation to JVM (and eventually native, perhaps), and you have a program that not only interoperates with programs written in other dialects, but allows direct connection between them. Like if you want Avail exceptions with your C code, you import exceptions and just use them. You don’t build them over and over again for each language. And if you want to support closures in your C, you’d probably just remove the limitation that treated the closures of Avail as contextless C functions. Similarly for backtracking, universal serialization, and sensible module dependencies (maybe call it #import, versus the horrible textual #include mess of C).

And finally, if you want your existing vanilla C code to be able to call “out” efficiently to some FORTRAN or Python code, you no longer have an impedance mismatch. Define those dialects as Avail, and you’ll have real garbage collection, multiplexed lightweight threads (fibers), dynamic optimization, and objects and functions that are reasonably compatible between these dialects.

I forgot to add the interfaces versus classes, inner classes, and lambda notation, with the tons of trivial FunctionalInterface interfaces to deal with a smattering of the combinations of number of inputs, void or primitive or class output, which inputs or inputs can be null, and which exceptions can be thrown by the evaluation method (having many different names, etc).

Almost all of these monstrosities are caused by the “object purity” mindset that kept the designers from including first-class functions in the language. Avail attempts to include a large set of paradigms instead of trying to “axiomatize” the exposed surface (although we do axiomatize the construction of these constructs).

Very true. The core Avail language uses “_=_” for comparison, “_:_” to declare a variable, “_:=_” got assignment, and “_::=_” for constants (think “final”). It also has “_:_:=_” for the case when you want to declare a variable of a general type, but initialize it with something more specific (say a counter that starts at 1).

But yes. There’s a lot of deeply evil things that can be done in Avail, right down to the lexical scanning. Like forbidding certain variable names, or manufacturing a run of tokens every time a certain emoji is encountered. There are also a lot of safeties, like sealing methods to prevent someone overriding “_+_” for [3’s type, 4’s type]->9’s type.

Oh, and writing “x = x + 1;” as a statement will be flagged as a syntax error, because it would produce a Boolean value which is not allowed to be silently discarded like in Java or C. “Discard:_” makes these rarely needed situations absolutely obvious.

I went into this design decision, having looked very closely at the specific success of the SHRDLU system (1971?). Local disambiguation was very effective, and Avail goes even further by having exceptionally strong types to help distinguish meaning. We also have grammatical restrictions to express a unique form of precedence rules, and semantic restrictions to statically identify a large number of inappropriate uses of methods, like “dog”[4], which is a compile-time subscript bounds error.

Some of the keywords and operators (punctuation) of Avail methods are “completely optional”, in that the caller’s choice to include it or not (or alternative prepositions in some cases) is solely to improve readability of the result. For example, the ordinary field-getter has the form “_’s??thing”. The double-question-mark should actually be a single Unicode character (I’m on my phone). The question-mark makes the “s” optional, so you can say “cat’s thing” or “Jess’ thing”. But there’s nothing stopping you from saying “cat’ thing”, other than the derisive laughter of your peers. :-)

Perhaps. But wouldn’t you prefer that COBOL become a mere dialect of Avail?

Right, and that’s why Avail is nothing like that. Kind of the opposite when it gets down to it...

Cheesy, closed languages like C forgot that exponentiation was even a thing, or complex numbers. If you shift over to using C++’s “clevernesses”, you still don’t get exponentiation, because the traditional caret symbol is already used for exclusive-or, which has no sensible ASCII punctuation.

As for someone’s distant comment that Lisp has been used to create languages for years... sure, if the language you wanted was parenthesized lists with keywords inside the left parenthesis. Which is just Lisp with a few more operations and macros. Yuck.

Well said, that’s exactly right. Most languages lack a bottom type, or screw it up by pretending that “null” fits that role and falsely promises everything that every other type promises.

Languages like Java (and many more) fail to even have a top type, which leads to kludgey add-ons to the type system — boxed, @Nullable, erased generics, annotations, dependency injection, purity annotations, etc., all of which should have been part of a single type system.

It’s a big concern, but technically most of the world doesn’t actually use ASCII. We use shortcuts in IntelliJ (and Eclipse before that), so if you want a right arrow, you type “rig”, pause a split second, and hit return to accept the “rightarrow” suggestion, which it replaces with a real right arrow. It’s as easy to use in that environment as any other kind of autocompletion.

Working on it, sorry about that. We lost some things when rehosting some time ago and have prioritized other things. There is no mailing list any more.

The core syntax of Avail does have a prose-like feel to it, and that’s intentional. But when you narrow it or extend it for specific linguistic domains (CSV, tensors, business rules, build rules, expert systems, or a vast number of existing notations), it makes the code read exactly at the right level. No noise. Have a look at the Silly Quiz example for what I mean about getting the right level.

We’re working on tools for writing/viewing Avail more easily. Stay tuned, it’ll be worth the ride...

Yes, that agrees with the shape of Avail’s type hierarchy. There’s a top type and a bottom type, and the latter has no instances.

Haskell has infinite and recursive constructs, lazily computed. That’s what makes their type system undecidable. Avail is constructivist in that sense, so immutable structures must be finite (i.e., you can draw them as a dag). For cyclic structures, you have to include mutable “variable” objects as well, but in that case the type of the construct stops at the boundary of the variable. The type of a tuple of variables is a composition of the declared types of the variables, not their current content. This is essential to ensure an object’s type is permanent, and the immutable acyclicity condition ensures everything reachable without hitting a variable contributes to an object’s type.

If you wouldn’t mind, please post a screenshot where you think an example is supposed to be displayed but isn’t. Or mail it to “mark” at the same address as the website.

If you grab the development branch, you can use the modular lexers to make that a little bit clearer. If memory serves, “a socket address from <192, 168, 1, 1> and 80” can now be written “192.168.1.1:80”. Not because that syntax is designed into the language, but because the language is designed to allow an IPv4 lexer to be defined within the language. See distro/src/avail/Avail.avail/IO.avail/Address.avail:149 for the actual Avail code that lexes (produces tokens from module source) IPv4 addresses.

Slow two days now. Lots of internal errors, no new content since Thursday.

I guess they won’t ever add decades overdue Unicode support after all, since ad revenue will be zero pretty soon.

At this exact moment, Avail can only evaluate expressions left-to-right, except of course for functions (block expressions, using [] notation resembling Smalltalk).

However, I'm close to completing the macro mechanism that will allow the same flexibility of syntax present in method names (keywords/operator tokens, argument positions, guillemet-enclosed repeated argument groups, etc), but for constructs that run at compile time with parse trees instead of values. The actual macro mechanisms have been working for some time, but were disabled until we were able to represent the ~dozen syntactic constructs of Avail purely as macros. Then any new syntax wouldn't be in conflict with existing syntax. When that's working we'll toss the existing compiler (the one that knows anything about Avail's current syntax, like statements and functions and variable declarations), and use the compiler that knows nothing about Avail – just how to parse methods and macros. Then we'll be able to support arbitrary evaluation orders, declaration syntax, treating some expressions as lazy, alternative scoping models, etc.

As for custom types, we're investigating ideas about carrying purity annotations through user-defined control structures. Kind of hard to describe in this forum, though.

It was intended with humor, of course, but really creating a natural language syntax is a tiny capability of Avail. We're working on the details at the moment, but we're fairly certain that every programming language ever written can become a mere dialect of Avail. Except running on the same jitted VM. And trivially able to intermix with code in other languages, even in the same module. Even within a statement. The RPN calculator example might give you an idea of what we can do today. Also, "Quiz DSL.avail" might be of interest, since it's not just traditional programming languages that Avail is going to eat for breakfast. Brace yourself for what's coming.

Unfortunately there's no guide to walk you through the library. However, we have code level documentation in a live searchable form here:

https://www.availlang.org/about-avail/documentation/stacks/l...

There is also a strong beginning of a "cookbook" of expressions here:

https://www.availlang.org/about-avail/documentation/expressi...

There's also coverage of a sizable chunk of Avail's type system here:

https://www.availlang.org/about-avail/documentation/type-sys...

Just to whet your appetite, consider this:

Method "_plus_" is [ a : number, b : number | a + b ]:number;

Print: 5 plus 6;

The entire language is built this way.

I'm one of the authors. If you're concerned that what we built is a mere natural language parsing engine, have a look here:

https://www.availlang.org/about-avail/documentation/faq.html...