I believe we should be able to modify, fork, or debug syntax the same way we do libraries. So what about a syntax meant to be read by computer instead of by humans?
# Factorial example, machine syntax
fac
-> int int
\
0 -> 1
n ->
*
n
- n 1
-- Factorial example, Haskell syntax
fac :: int -> int
fac 0 = 1
fac n = n * fac (n - 1)
// Factorial example, C syntax
int fac(int 0) { return 1; }
int fac(int n) { return n * fac(n - 1); }
Try translating at the deeper semantic level and you also discover that you basically can't. The C-semantic equivalent of the Haskell is closer to a for loop, and even that isn't an exact match. (An exact match probably involves "goto".) Non-trivial examples just explode in complexity, and that's long before you get to useful code.
This is in the class of "things that have been possible for decades but haven't taken off for good reasons", right up there with the purely-visual languages and other classic "good ideas".
No need for "syntax skins" in that case.
That was exactly my intention. Translating "at the deeper semantic level" is reserved for actual compilation. Now you may be right about syntax being useful for differentiating languages. My stance right now is that we should try (or look at the failed attempts you speak of, do you have any link?).
Testing my idea will require quite a bit of work: I need to write a compiler and an IDE with some kind disciplined editing. I also will have to bootstrap all this stuff, so it passes the minimum credibility threshold. If I ever get to this point, I will (at last) be able to test my language for actual (f)utility.
Which may seem like a nit, but the reason is because the semantics of Haskell and C are extremely different. Furthermore, the semantics strongly influence the design of the language. In Haskell, whitespace denotes function application, because the most common thing to do in Haskell is to apply a function. C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. In Haskell, you cannot guarantee the exact order in which things happen without going to great lengths (monads, etc.).
In short, I don't think offering a skinnable syntax buys much, and is likely to just generate greater confusion.
On the benefits of skinnable syntax: look at C++, Java, and Javascript. They have two things in common: their popularity, and their syntax. Coincidence? I think not. By stealing the syntax of C, they build on it's original success.
I painfully know that C syntax isn't suited to functional code with gazillions of nested function calls. However, this is a known syntax. It makes learning far easier (or at least looks that way, so people are actually willing to try).
Actually that would be an argument for making newlines delimit statements, like in, say, Python. Instead of requiring extra work by the programmer.
More seriously though:
Interestingly of the two languages that come close to this model - lisp with minimal syntax and perl with very flexible syntax - one remained in academic obscurity while the other became wildly popular.
EDIT: it's the preface to the UNIX haters handbook, of course. A copy is up at http://www.art.net/~hopkins/Don/unix-haters/preface.html
When Lisp Machines lost in the market, the Lisp users moved to UNIX + Lisp. Companies like Franz and Harlequin/LispWorks that came from that market still exist today.
Lisp was always used on different systems. When Lisp Machines were 'popular' (we are talking about less then ten thousand machines that were ever build and sold), Lisp was used on Windows, Macs, Mainframes, Unix and other operating systems.
I should also mention that almost all Lisp Machines were single user personal workstations - initially specially aimed mostly at AI programmers.
Of course, I couldn't make heads or tails of the small demos they've given.
The goodness of a java library has little to do with syntax (because clojure can easily call any java library), but semantics. For instance, java commonly uses mutable state. A fundamental principle of Clojure is that data should be immutable. Immutability makes testing easier, it makes parallelization easier. Clojure was built to make pmap easy. If I have a java library where I have to remember that Foos are thread-safe, but Bars are not, that adds to the incidental complexity of my solution, and reduces my ability to bring Clojure's new tools to bear on the problem.
As another commenter pointed out, syntax of a language is heavily influenced by the semantics of the language. A language starts with a few high level principles, and a favorite hammer or two. The syntax of the language is designed around making those common operations easy. Libraries written in that language will tend to follow those same principles.
Having Java libraries available to Clojure is a huge advantage, but it's not the be-all end-all, because the semantics of those libraries may be incompatible with your new language.
Instead, focus on semantics. Figure out which high level principles are good. What abstractions and design principles result in better, easier to understand solutions? From that follows your libraries and syntax.
I do think that there is a healthy focus on syntax -- at least my own experience bears it out. It was the syntax of doing things the python way that allowed me to grok polymorphism and MVC despite programming in an OO language for .Net for years. I find that if I want to learn a concept, the syntax is extremely helpful. I also find that if I have to program quickly, syntax being close to how I think is also helpful, and will get frustrated having to make yet another translation of my thought into a syntax that wasn't well thought out. I would also bet that a lot of people find a different syntax to intuitive, and others counter-intuitive than I do. And I'm fine w/ that! Just because there is difference doesn't mean there has to be division!
* multi-methods - There are two implementations on CPAN, Class::Multimethods (old) and MooseX::MultiMethods
* rules - Ditto. Perl6::Rules (old) and Regexp::Grammars
* macros - Have a look at Devel::Declare. Not Perl6 macros but still powerful stuff!
* and a whole bunch of other good stuff - Lots have been backported to Perl5 (direct and into CPAN). For eg. smart match, given/when, Perl6::Junction, Perl6::Gather and also things like Moose & Class::MOP which are heavily influenced by Perl6
* multi-methods: MooseX::MultiMethods and MooseX::Method::Signatures add a lot of overhead to subroutine calls (blogged in http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/...). Sometimes this doesn't matter, but they're certainly not a replacement for having a native type system. All the magic is done at runtime.
* rules: Perl6::Rules and Regexp::Grammars are both depended on by a grand total of 0 CPAN modules. They're interesting experiments but not something in use, and not a replacement of rules with its "your regex opcodes are a normal method" model.
* macros: Devel::Declare and the B::* modules are usable but they're a long way away from the Lisp model of being able to easily write macros. TryCatch is 800 lines of Perl and C to implement try { ... } catch { ...}. In any Lisp this would be trivially done with a macro in under 50 lines.
As for the other stuff pretty much anything except smart match (which is now in Perl 5 core), Class::MOP and Moose falls under the "neat but some combination of: underused, slow, unstable, epic hack nobody wants to use".
However I've used them in a number of production applications now and they've never shown up anywhere high on my profiles.
Perl is "very slow" compared to C. That doesn't make it universally a bad idea.
The same could be said of his "epic hack" comment. Everything is an epic hack. Especially Perl.
Devel::Declare is really not that scary.
Thats a sweeping statement. Lets have a look...
* My opinion is only just that. The list is informative to what prior art there is. Always go and test and come to ones own measured conclusion.
* I postfixed old to modules that may have issues.
* Everything else I use and have no issues with (as listed elsewhere in thread)
* Haven't used MooseX::MultiMethods much recently but I do use MooseX::Declare regularly and find this and whole Moose type system a godsend that I couldn't live without now.
* re: Regexp::Grammars is new because its dependant upon 5.10 (replaceable RE engines). So it will have no other modules dependant on it yet but it looks like a worthy successor to the venerable Parse::RecDescent to me.
* re: Devel::Declare - I've already said its no "Perl6 macro" so comparing to a Lisp macro is a tad unfair :)
Hopefully that covers my value of "already" :)
Also, in what way is Moose unstable? Moose, and modules which use Moose, are used in production at a lot of places (if you use a recent Catalyst, you're using Moose).
Edit: doh, totally misread the OP's sentence.
So Moose is not underused. But some of the other modules that draegtun cited are. It's disingenuous to cite some crazy module Damian wrote that nobody uses as an example of Perl 6 features in Perl 5.
However stating that I'm disingenuous to list them at all... is well a very disingenuous slant directed at me :(