• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    625
  • comments
    1446
  • views
    1006530

Gentlemen... BEHOLD!

Sign in to follow this  
Followers 0
ApochPiQ

1237 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.

0
Sign in to follow this  
Followers 0


9 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?
0

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.
0

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.
0

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"
0

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]
0

Share this comment


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

Share this comment


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

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.)
0

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