zesterer / atto

An insanely simple self-hosted functional programming language
152 stars 6 forks source link

Add new operators for converting between num and "real binary" #9

Open lf94 opened 3 years ago

lf94 commented 3 years ago

It would be very useful if atto could convert numbers to actual bytes. With this, and in combination of outputting to standard output, you could do things such as use terminal graphics modes to output graphics, or output images or other file formats.

lf94 commented 3 years ago

On the other hand converting from bytes to num can enable programmers to even write things like web applications.

zesterer commented 3 years ago

In my view, I see Atto mostly existing as an esolang. Although it's surprisingly practical to write certain kinds of programs in, I don't personally see myself picking up the project for any significant time in the future. If you're interested in taking over development, I'll happily provide you with repository permissions.

lf94 commented 3 years ago

If that's your view, then so be it. I just thought even for an esolang, it can be as powerful as a lisp with some legwork! (As in: people could build a small ecosystem around it, supporting libs, etc.)

zesterer commented 3 years ago

I think a fundamental problem with Atto is that the extremely terse syntax results in a situation in which a syntax error cannot be easily diagnosed. Even omitting a single term in an expression chain immediately gives the parser no choice but to produce an error for the entire function due to the fact that the language is but a whisker away from syntactic ambiguity.

The parser itself necessarily needs to be aware of the arity of all functions before they are used also. As a result, currying and first-order functions are almost precluded.

I did make a moderately successful attempt at integrating them into the language, along with a few other features such as let declarations (see the new-compiler branch and the associated examples). However, in the process, it was necessary to significantly increase the complexity of the parser and the difficulty of writing code in the language (see the f''-style arity specifiers everywhere in core.at).

By virtue of the fact that the syntax is so simple, it's almost painted itself into a corner in terms of future features. There's a very good reason that LISP uses parentheses.

I do recommend taking a look at the new-compiler branch, however. If there is a future in the language, I think that it represents the direction that's most likely to yield promising results.