![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
The Spirit parser framework - metaprogramming and no macros
On the topic of metaprogramming and macros - there is one excellent example of metaprogramming with minimal macros - the Spirit parser framework (part of the Boost C++ libraries).
The developer who created Spirit is very much against macros - (he says so very forcefully in the docs) and I agree with him.
Anyway - in response to the "let's make a programming language" challenge, rather than my suggesting a completely new language, I'm keen to see Orca (the open-source Rebol clone) developed. At present, it's still pretty basic, but has great potential (given that Syllable will now use it as their default scripting language).
Of all programming languages, only Forth comes close to the "power- to-weight" ratio that Rebol has. Python, Ruby, Perl - all good, but pretty heavyweight. One of Rebol's best aspects is that DSLs are trivial to create, using "dialects". So, there's the "create your own language" thing taken care of ... :-) By obsidian at Sun, 2006-06-04 21:42
| login or register to post comments |
Isn't Spirit written with template metaprogramming techniques? These are C++'s ad hoc version of macros. We aren't talking about the C preprocessor here. Or do you mean the author limited his use of template metaprogramming? By rebooted at Sun, 2006-06-04 22:02
| login or register to post comments |
---
copx 1 day ago
| link |
Some of my relatively obscure favorites:
Dylan: http://opendylan.org/
Euphoria: http://www.rapideuphoria.com/
reply
zem 1 day ago
| link |
i've always felt that had i discovered euphoria earlier in my programming life, i would have really liked it. these days i'd miss all the features more recent languages have borrowed from lisp and/or ml, but it would have been an awesome second or third language (after basic and c).
reply
copx 1 day ago
| link |
I discovered Euphoria back in the DOS days when it was still commercial. I agree that it seems a little dated these days but I still fondly remember it.
Also it is still a great language for non-professional programmers and still has an active community there. Note the recently updated SDL2, SFML2, and Allegro bindings for example.
reply
iso-8859-1 1 day ago
| link |
MetaML?, a language with as many levels of macros as you'd like: http://www.cs.rice.edu/~taha/publications/journal/tcs00.pdf
(implementation as MetaOcaml?)
reply
zem 1 day ago
| link |
if you're looking for interesting systems languages, clay looks good too: http://claylabs.com/clay/
reply
InAnEmergency? 1 day ago
| link |
You may be interested in the Fledgling Languages List: http://fll.presidentbeef.com/
reply
doublec 1 day ago
| link |
For an interesting systems programming language try ATS [1]. It's an ML style functional programming language with dependent types, linear types, macros, generics and compiles to C giving reasonable portability.
reply
epsylon 1 day ago
| link |
Check out fogus' lists of "Perlis languages": http://blog.fogus.me/2011/08/14/perlis-languages/ http://blog.fogus.me/2011/10/18/programming-language-develop...
reply
-- " Frankly, I guess I've become something of a functional zealot, so my problem with Go is that it's so stubbornly imperative. This is why I can't get behind Go, as much as I want to. I feel like it doesn't consider many of the lessons that have been learned about FP making life easier. Set operations (map, filter, reduce) are insanely common, yet doing them imperatively sucks to the point of discouraging them. Excessive mutability is difficult to reason about. Nobody expects the nil/null/none inquisition. We tend to forget about side effects. Without an extensible language, which requires truly first-class functions, you're at the language designer's mercy.
Hell, Scala probably isn't the be-all, end-all answer to all of this. I just don't think that a doggedly-imperative, non-composable, statement-oriented language is the future of programming "in the large", not when the past has shown us that we tend to produce buggy, unmaintainable software this way. I'm pragmatic enough to realize that pure FP isn't a solution, but I feel strongly that sticking to traditional imperative because it's familiar is a costly mistake.
"
---
" Now, static typing is just one kind of static assertion[1] I'd like to have. Side effect isolation (i.e. language-enforced purity) would be another feature I'd like to see become common. For example, the D programming language has a "pure" keyword that lets you mark a function as side-effect free. (In Haskell, all function are pure by default, and you escape the confines of purity via monads.)
I'd like to do research into (inventing) other forms of static assertions. One thing that's been on my mind lately, has been static "complexity assertion" for programs. I don't know if this even possible, but it would be nice to be able to ascertain before running a program, certain time & space complexity bounds on it. This would perhaps require us to drop the programming language itself to some level "slightly below" Turing machines -- but this in itself could be achieved via a keyword like D's "pure" or something more elegant. (Note: my point is not that we're going to make the entire language non-Turing complete -- but rather that we'll have subsets of the language that are not, and this reduction of power would/could bring with it a greater possibility for statically asserting stuff.)
[1] FYI I made this term up. Let me know if there's something better that describes this. "
upvote
sridharvembu 8 hours ago
| link |
Your point on "slightly below" Turning machines caught my attention - exactly the same terminology I have used. I want as many proofs (assertions) as possible about code, and Rice's Theorem is a problem, so slightly below Turing is on the radar. If you are interested, we can discuss this. Shoot me an email at svembu at zoho ...
reply
upvote
chas 6 hours ago
| link |
Total functional programming (and the associated analysis of codata has already been touched on), so I'll just address your interest in static guarantees for space usage. The Virgil programming language[1] has been designed with exactly this in mind. It is aimed at embedded systems where memory is extremely constrained and running out of memory could kill people. Heap allocation is not possible in the language and all data structures are initialized during compilation (like C++ templates, but more sophisticated). The compiler can use the initialization information for advanced optimization and analysis as well as serving as a bound on the memory usage. [2] The language also has some interesting static typing ideas, but they are not as distinct from other languages.
Further discussion on LtU?