• entries
    625
  • comments
    1446
  • views
    1007237

Gentlemen... BEHOLD!

Sign in to follow this  
ApochPiQ

1257 views

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.
Sign in to follow this  


9 Comments


Recommended Comments

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?

Share this comment


Link to comment
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.

Share this comment


Link to comment
[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.

Share this comment


Link to comment
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"

Share this comment


Link to comment
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]

Share this comment


Link to comment
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.)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now