Hi, shaun, sorry for the delay. Ambi is apparently a concatenative, stack-based language, similar to Cat. Those are interesting for their own reasons (and they also have their own problems) but it's not exactly what I'm thinking of.
REBOL is much closer, but I would like to have more diversity of approaches with a similar syntax, not just REBOL clones. So what do I want? Let's start with Lisp. It's a great programming language and the syntax is beautiful, because you can always parse an S-expression, even if you don't know what's in there. Also, paren matching is a non-issue with something like Paredit. I want to make it clear, I love the parens, I hate infix notation (except, perhaps, for RDF, where everything is made of triples), and I find indentation-based syntax kind of pointless. The only problem I see with the parens is when you try to "speak" in Lisp. Human language is not like that. People build complex sentences, with higher-order functions, without using anything like parens. The main difference is the use of types. Human language is usually typed. This has been discussed since Montague's "English as a formal language", maybe before that. Nowadays the idea of treating spoken language as a typed formal language is pretty standard in machine translation. For instance, have a look at GF, a modern open source tool to build multi-translation systems: http://www.grammaticalframework.org/ http://www.grammaticalframework.org/lib/doc/synopsis.html http://www.grammaticalframework.org/doc/gf-quickstart.html So it seems clear that a speech-like language should have types, but not types like "integer" or "character", but types like "noun" "noun phrase" and "proposition". But there must be tools to convert from any type to any other, as we also do in natural speech. For instance, we say "Mary walks" but we can also say "walking is healthy". For programming languages, maybe simply-typed lambda calculus, with just one type, would be more adequate. In any case, I'm interested in ways to have a terse, concise, regular *and* highly expressive syntax, with no built-in assumptions about types, but where types can help you use fewer words. Here's a little example I made up of the kind of syntax I would like to see. Don't take it very seriously, it's just to convey the idea of what I'm looking for, because you ask for examples. We have a function definition in Kernel lisp: ($define! print ($lambda (x) (map write-char (string->list x)))) Now, with a pure Polish, simply-typed syntax I think it may be something like this: $type $define! $fun e fun! e e $type $lambda $fun e e $type $map $fun e fun e e $type write-char fun! e e $type string->list fun e e $define! print $lambda x map write-char string->list x The dollar signs mark the operatives (ie the fexprs), so I'm borrowing some syntax from Kernel. Sorry for mixing up two ideas which are very different, but that's how I see it now. Otherwise, I would have to use quotation instead of operatives. Notice that I'm using pure Polish notation even in the type signatures. This is not standard practice in type theory, where instead they use infix arrows and parens, which I find more ugly. For instance, instead of: $type map $fun e fun e e Using a more standard notation it would be like this: map :: e $-> e -> e I had to turn "map" into an operative (hence "$map"), otherwise, as I said, I would have to quote the function. This is because I don't know the type of the function which will serve as argument to "map". In Haskell the type signature of "map" is: "(a -> b) -> [a] -> [b]" Once you are using this kind of trick in the type signature, I wonder whether the type system is pushing the limits of the expressivity of your type signature notation, so I would like to be able to avoid those notation tricks, and one way to do so, I think, is to take as argument the symbol, instead of the function itself. Also, the new version of "$lambda!" only takes one argument (ie, "x") instead of a list of arguments. So, I would need nested lambdas for several arguments. This is not unusual in some notations. I just wanted to show you a version with no lists at all, but of course, there's nothing wrong with having some functions take a list as argument where it makes sense. I just want to reduce the use of lists as much as possible, to make the language more concise. I hope this helps clarify my previous post. Best, -Martin On Thu, Mar 15, 2012 at 5:52 PM, shaun gilchrist <shaunxc...@gmail.com> wrote: > This looks interesting: https://code.google.com/p/ambi/ - instead of > supporting infix it supports both polish and reverse polish. Can you give > some examples of what your ideal syntax would look like which illustrates > the "spoken language" aspect you touched on? -Shaun > _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
