I wrote this a while back on creating your own language: http://digitalmars.com/articles/b89.html
The Rewards of Creating a Programming Language
41–50 of 88 posts
Re: The Rewards of Creating a Programming Language
#42> Notice how not a single variable in this code has a name. They all only have types. Pretty cool, never even thought about this being possible.
That's how I find functions in Haskell! [1] Most of the time searching the type will give you the function you need.
[1] https://www.haskell.org/hoogle/?hoogle=%28a+-%3E+b%29+-%3E+%...
Re: The Rewards of Creating a Programming Language
#43Earlier quoted context omitted.
I've been playing around with an idea to replace variable names with brands. So say you have an argument to a procedure: brand position Position is a point, but is not a distinct type. You can document it centrally and not for each time it is used as an argument to a procedure or as a variable. E.g. def Set(position): ... You have define brands before you can define your procedure, but multiple procedures can share b…
So position is like a typedef that you can use without a name, because it is self-naming. Obvious problem: def Drawline(position, position): ... Oops! We now need a position0 brand and a position1 brand, both of which are aliases for Point.
They aren't just type aliases, they actually have unique slots in the symbol table when used so...you define more brands :)
brand position brand position I've been thinking about this for awhile, but haven't put it into a prototype yet.
Re: The Rewards of Creating a Programming Language
#44I've recently discovered PEG.js [0] and prototyped a small DSL in the browser [1]. Amazing stuff! I've dealt with ANTLR [2] before, but PEG.js feels so much nicer although it may not be as powerful! [0] http://pegjs.org/ [1] http://pegjs.org/online [2] http://www.antlr.org/
PEG.js is definitely fun to prototype ideas in the browser.
My new love is Parsec [1] + doctest [2]. You start building simple little parsers, and build on top of them, plus inline testing makes it easy to write the parsers correctly. Also Haskell's algebraic datatypes and pattern matching make it nice to build and work with the AST. [1] https://wiki.haskell.org/Parsec [2] https://hackage.haskell.org/package/doctest
Re: The Rewards of Creating a Programming Language
#45Earlier quoted context omitted.
Can you explain how? Obviously at least two people either disagree or aren't privy to the knowledge you hold!
I suspect a reasonable person might expect you to explain how you came to the conclusion that a language with a smaller or comparative user base / popularity to Haskell "popularised" type classes.
Huh, I interpreted it differently, as in questioning whether Go's interfaces have much in common with Haskell's typeclasses. But now I'm intrigued — does Haskell really have a larger or comparative popularity as Go? That would surprise me, but I don't have any data, do you?
Re: The Rewards of Creating a Programming Language
#46Inaccurately, programming language = syntax + semantics. Do not waste your time on syntax, if you are going to create a new language, rather than a parser. I'm not saying that syntax is not important. But I feel semantics deserves much more attention.
I think syntax may actually be more important for adoption than semantics. But for just learning semantics is king.
Re: The Rewards of Creating a Programming Language
#47Earlier quoted context omitted.
I suspect a reasonable person might expect you to explain how you came to the conclusion that a language with a smaller or comparative user base / popularity to Haskell "popularised" type classes.
Huh, I interpreted it differently, as in questioning whether Go's interfaces have much in common with Haskell's typeclasses. But now I'm intrigued — does Haskell really have a larger or comparative popularity as Go? That would surprise me, but I don't have any data, do you?
It's remarkably difficult to find anything approaching hard numbers :-) However, I am going off:
* http://redmonk.com/sogrady/2015/01/14/language-rankings-1-15... (Haskell slightly ahead in their numeric ranking) * http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... (Golang slightly ahead in their ranking) * Slightly more published books on Haskell that I can find (although obviously it's been around a lot longer)
I have no doubt that Go will eventually surpass Haskell in terms of popularity, and may even have a slight edge, but suggesting that Go popularized typeclasses smacks of fanboyism, and reminds me - in no small measure - of: https://www.youtube.com/watch?v=bzkRVzciAZg
Re: The Rewards of Creating a Programming Language
#48I was reading something similar here about creating your own language using LLVM (and also using the Ruby bindings for LLVM as opposed to C++) ... http://macournoyer.com/blog/2008/12/09/orange/
Re: The Rewards of Creating a Programming Language
#49Earlier quoted context omitted.
no?
Can you explain how? Obviously at least two people either disagree or aren't privy to the knowledge you hold!
There's a bit of writing on StackOverflow about it:
http://stackoverflow.com/questions/2982012/haskells-typeclas...
The main similarity is that 'methods' are defined 'outside' the data type they belong to. But there are a huge number of differences: Haskell's typeclasses are used for many things that don't look like methods at all, while Go's behave more like a classic OOP interface you'd find in Java.
So, perhaps superficially similar-looking, but they work quite differently in practice.
Re: The Rewards of Creating a Programming Language
#50If you’re thinking of writing a language in earnest, you will create something much more valuable if you start from a novel semantics, and only then come up with a syntax to express those semantics, than if you were to start from syntax. The world does not need yet another reskin of Java, but it could use new programming paradigms and new ways of solving problems. As a learning exercise, implementing a language is wo…
If you're looking to build something that people will actually use, you're better off not doing anything novel at all, but rather combining novel ideas that have shown promise in research languages into a package that people might actually want to use for everyday programming. There's a rule of thumb among language designers that your language should either focus on proving out one big language feature , or it should…
> If you're looking to build something that people will actually use
Why bother? I mean, at some point some bigger "name-brand" language is going to take your feature and subsume it anyway. Why compete for mindshare?
If you really have an idea for some new language semantics, then skip the whole syntax phase: express your language as a DSL in another language you already know, use that DSL to write programs and libraries, and see if it helps you compared to not using the DSL. The great thing about this is that you can still rely on all the features and libraries of the parent language while you're doing this! Your DSL only gives you the option of using the new, extra semantics you wanted to test, where and when it adds a benefit.
Now, of course, this might not work if your idea is for a reduction in or purification of semantics—if, merely by having the option of "calling through" to the parent language, the value of your language semantics is destroyed. But if it's just an idea for a feature? Building an interpreter and defining a grammar and create a whole new ecosystem around it is putting the cart before the horse.