This is a little offtopic, but since you are working on syntax...

I have a lot of conversations with coworkers, students, etc. that end up somewhere like "python would be a better language if it had curly braces", or "Erlang is a interesting concept, but the syntax is unusable" - anyway, you get the idea.

My first thought on glancing at your example above was that the syntax is a little opaque. There appears to be a lot of magic going on: why does the semi-colon concatenate strings? Why does the first apply not need an explicit return specification, while the second does? What's the meaning of the magic parameter 'ret'?

Now, I'm sure I could answer all these questions by spending a few more minutes going over the documentation. But my question is this: how much of a barrier do you think a fairly opaque syntax might be to the eventual adoption of a language? Or in other words, should we go out of our way to make every new language look like C or Python, because those are what people are most familiar/comfortable with?

Personally, I think that having a similar/comfortable syntax is good for adoption, but there's a number of places when doing design where it doesn't work, or fit with the changes.

Magic within this, there is. Confused, I am.

[quote name='swiftcoder' timestamp='1329582033']
This is a little offtopic, but since you are working on syntax...
[/quote]
Hardly off topic, while the syntax of the language is in flux, any sort of commentary on the "syntax" elements of a language is on topic.
[quote]I have a lot of conversations with coworkers, students, etc. that end up somewhere like "python would be a better language if it had curly braces", or "Erlang is a interesting concept, but the syntax is unusable" - anyway, you get the idea.[/quote]
I've never found the lack of brackets in python to be a detriment, but then again, when I picked it up I was hardly a beginner. That being said, most people who feel that way have been exposed to C or C++ and are thinking of scope in terms of closing brackets. I.e. they haven't fully realized that well formatted code is at the heart of scope in python
[quote]My first thought on glancing at your example above was that the syntax is a little opaque. There appears to be a lot of magic going on: why does the semi-colon concatenate strings? Why does the first apply not need an explicit return specification, while the second does? What's the meaning of the magic parameter 'ret'?[/quote]
Semi-colon is just an overload of operators. Kind of randomly chosen. The "ret" parameter is the name of the variable. Which is a bit confusing, since the variable name is then followed by the parameters of the constructor, which in this case is the result of the concatenation of param and " foo". Its something that is still in flux
[quote]Now, I'm sure I could answer all these questions by spending a few more minutes going over the documentation. But my question is this: how much of a barrier do you think a fairly opaque syntax might be to the eventual adoption of a language? Or in other words, should we go out of our way to make every new language look like C or Python, because those are what people are most familiar/comfortable with?
[/quote]
Most functional languages I've used and looked at were HELL to get into for a beginner, simply because the syntax of most functional languages are very opaque. C's syntax is quite simple, honestly, its just the language its self that's such a bitch to get into. THe same is really true of python, the syntax is darned simple to understand.

We can break this bit of code down a bit for a bit of clarity about what is going on:
[code]
apply : string param, (thefunction : string)
[/code]
This declares a function 'apply' which takes two parameters, and returns nothing:[list]
[*]param, which is of type string
[*]thefunction, which is of type "function that takes a string and returns nothing"
[*]returns: nothing
[/list]
[CODE]apply : string param, (thefunction : string -> string) -> string(ret, thefunction(param))[/CODE]
This is an overload of apply which takes the following parameters, and returns a string constructed from the result of calling the function parameter:[list]
[*]param, which is of type string
[*]thefunction, which is a function that takes a string and returns a string.
[*]returns: 'ret', containing the result of the call to thefunction with the first parameter.
[/list]
[CODE]mutate : string param -> string(ret, param ; " foo")[/CODE]
This is a function that takes a parameter of type string and returns another string 'ret' containing param concatenated with " foo"

On the syntax of return parameters...

My personal preference would be something similar to parameter decleration:
[CODE]
//
// FUNCTIONS.EPOCH
//
// Compiler test for higher-order functions
//
entrypoint :
{
apply("test", debugwritestring)
debugwritestring(apply("test", mutate))
}

apply : string param, (thefunction : string)
{
thefunction(param)
}
apply : string param, (thefunction : string -> string) -> string ret(thefunction(param))
mutate : string param -> string ret(param ; " foo")
[/CODE]

or, in otherwords (in EBNF)...
[code]
returnType = typeName identifier ( OPENPAREN expression CLOSEPAREN )?
[/code]

Ok, that makes things a lot clearer. But the return specification is a little weird - I like your suggestion better.

I too liked my suggestion better, until I noticed that the editor added like a hundred million spaces.

Your current function syntax/variable syntax difference is kinda odd.

I think variables (and fields, and parameters) should look more like how functions look - e.g.
example_field1 : string = "pie"
example_field2 := "pizza" // short form, type = typeof(initializer-expression)

example_function : param : string, (thefunction : string -> string) -> ret : string(thefunction(param))

On the other hand, this highlights how weird your parameter syntax is. (an extra set of parentheses changes a string parameter into a string->void function? thanks, but no thanks.)