>>4 >>2-chan can also enjoy their lack of: machine integers O(1) access memory recursion (without either spending ages figuring out how to get it past the termination checker or using Program and ending up with irreducible gobbledy-gook) turing completeness being able to get anything done, ever
S-exp syntax. Macros like in CL. Static typing but without overly strict gimmicks like dependent or linear types. Immutable and mutable collections. No GC. Good interop with C and Sepples.
The perfect language should look exactly like R7RS-large.
Name:
Anonymous2017-02-27 23:08
Rust with OCaml-ish syntax instead of that C++-ish monstrosity.
Name:
Anonymous2017-02-28 1:39
user defined syntax, gc, types, cache access / storage with sane defaults and good documentation
Name:
Anonymous2017-02-28 1:55
I suppose you could also have function alias groups to further support `language emulation', ie so we can mimic the function names of language X, along with the syntax / etc
It shall probably be called language X
Name:
Anonymous2017-02-28 4:18
Just use lisp instead, you can easily support other languages with macros.
Name:
Anonymous2017-02-28 5:45
>>13 Just use assembly, you can easily support other languages with macros.
Name:
Anonymous2017-02-28 5:58
McCarthy's original notation used bracketed "M-expressions" that would be translated into S-expressions. As an example, the M-expression car[cons[A,B]] is equivalent to the S-expression (car (cons A B)). Once Lisp was implemented, programmers rapidly chose to use S-expressions, and M-expressions were abandoned.
The reality is that when all datatypes are appropriately declared, a typical commercial Lisp compiler produces native machine code that is comparable in speed ...
Name:
Anonymous2017-02-28 6:06
Doesn't greenspuns rule imply it is relatively easy to implement a lisp in most languages
Name:
Anonymous2017-02-28 6:50
>>16 Greenspun's rule is a scam. The Lispers swindled features from other languages, using their control over academia to stop the teaching of these languages, and claimed them as Lisp features.
One feature of IPL V is excluded from FLPL by the nature of a compiler. Sequences of IPL instructions to be intrepreted are stored in the computer as NSS lists, just as are the data. Although this property has been largely irrelevant to all programs written to date, it is conceivable that one might want to write a program in which the symbolic entities that are processed are IPL instructions themselves, and in which transfers of control take place between the meta-program and the machine-generated one. The fact that the transformation of FLPL expressions into computer activity is a two-stage, irreversible process places this kind of behavior beyond the range of our language, even though it is quite feasible to manipulate FLPL expressions within FLPL.
Does this sound familiar?
Name:
Anonymous2017-02-28 6:50
>>16 Partially. Most Lisp implementations are written in C, but C cannot express these constructs natively(some parts like eval and most macro functionality will be very hard to do).
Name:
Anonymous2017-02-28 7:20
high-level: racket with python libraries. unfortunately, neither python implementation in racket (incomplete py2) nor hy (quirky. bad documentation and worse error messages) do the job.
low-level: 'boring C' (that is, a C implementation which defines all undefined behavior in a deterministic way) with an idiomatic (so no unstandarized macros or compiler extensions) way to write machine-specific code and inline assembly.
Name:
Anonymous2017-02-28 7:51
>>18 eval is a bit of a weird command, and macros are just mini-programs that run over your code beforehand?
Name:
Anonymous2017-02-28 9:21
Type-inferred M-Expression LISP-1(with fexpr and quasiquote/readmacros) based on nested Judy Arrays instead of lists and real-time reference-counting instead of garbage collection.
