Jump to content

  • Log In with Google      Sign In   
  • Create Account






Gentlemen... BEHOLD!

Posted by ApochPiQ, 18 February 2012 · 998 views

Epoch
I give you Epoch, now with a much better function definition syntax:

//
// 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")

Next up: improving the variable initialization syntax... that one could get interesting.




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.

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

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.

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.

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 :)

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'?

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

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?

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:
apply : string param, (thefunction : string)
This declares a function 'apply' which takes two parameters, and returns nothing:
  • param, which is of type string
  • thefunction, which is of type "function that takes a string and returns nothing"
  • returns: nothing
apply : string param, (thefunction : string -> string) -> string(ret, thefunction(param))
This is an overload of apply which takes the following parameters, and returns a string constructed from the result of calling the function parameter:
  • 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.
mutate : string param -> string(ret, param ; " foo")
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:
//
// 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")

or, in otherwords (in EBNF)...
returnType = typeName identifier ( OPENPAREN expression CLOSEPAREN )?
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.)
PARTNERS