What I want from a programming language (by alaric)
So here's a wishlist.
- I like Smalltalk's message sending syntax. Rather than the Lispy
(if x y z), or the Cif (x) { y } else { z };, we instead havex ifTrue: [ y ] ifFalse: [ z ].. That constitutes a call to theifTrue:ifFalsemethod on objectx(which had better be some kind of boolean!). I'm a fan of Lisp's Homoiconicity, so would use a uniform syntax for the language's data model, then represent source code on top of that. I'm imagining that(x y z)would delimit a list as in Lisp, but that[if: x then: y else: z]would delimit a 'record' of typeif:then:else:with fieldsif,then, andelse. Function/macro calls would either be represented as records or lists. If it's a record, the the record's type (made by composing the names of all the fields) is looked up in the environment to find the function/macro binding; if it's a list, then the first element is used, as in the Lisp tradition. That gives you a nice syntax, IMHO. And, by implication, I want an easily accessible symbol type, as in Lisp. - I like the power, flexibility, and simplicity afforded by dynamic typing (as seen in Lisp and just about any scripting language), but sometimes it's confusing to not know what types the arguments of some function are supposed to be. So I think the system should be inherently dynamically typed, but with easy to use optional type declarations, for efficiency, early catching of type errors, and ease of reading source code.
- First class continuations, as in Scheme
- First class closures
- Reflection
- In general, powerful features to make programming easy and fun. For example, type safety and no pointer arithmetic, but dynamically typed - so the type safety is just the system making life easy for the programmer, not restricting me. Reflection, but not so that it can be used to break out of sandboxes and thus make handling untrusted code dangerous. In other words, the language designed for power rather than speed, and the implementation designed for speed by using intelligence and optional programmer-supplied declarations to optimise the user program. Common Lisp is good in this respect.
- I want proper Common Lisp-style
defmacromacros, not the pansy little things in Dylan or Scheme. Not even the new R6RSsyntax-casemacros. Gimmeedefmacro. I can handle my own hygiene, thankyouverymuch. - A pure functional language. No assignments. But with Clean-esque unique types to handle mutation.
- An interactive prompt for development, and as a basic user interface. One of the wonderful things FORTH and Lisp have in common is that they both define a system with a command prompt, which lets you mess about with an environment of variable and function definitions. This is a lovely environment to work with, rather than edit/compile/debug cycles. This is the kind of environment that BASIC on 8-bit micros had, and it taught my generation to program.
- An implementation that'll compile and run on any decent modern Unix clone (perhaps based around the excellent work of Anton Ertl) for broad reach. But supporting compilation to native code on supported processors, for speed.
- Easy access to the native features of the platform, like the POSIX APIs, but in platform-dependent extension libraries rather than as part of the core language.
- Common Lisp/Dylan-style exception handling with restarts
- And, yes, Paul Graham has now sold me on the idea of pronouns in programming languages. I think I was turned off of them by Perl's horrible
$_, but theacondetc. macros he defines in On Lisp have turned me back around. - A clean design with a minimal core language. More Scheme than Lisp.
If Scheme had defmacro rather than all that syntax-rules and syntax-case stuff, then I'd choose Scheme and extend it with my own macros and live without the unique types, declarations that allow for efficient compilation of annotated code, and record syntax. For now.
But for ARGON, I'm reinventing every other wheel, so CHROME is being designed from the ground up according to the above principles...
Mon 16th Apr 2007 10:41 am 
Subscribe