design of the Wombat Programming Language
41 views
Skip to first unread message
Robert Smart
May 13, 2012, 5:50:23 PM5/13/12
to fp-...@googlegroups.com
Some folk might be interested in my design of a functional-oriented language. I'm happy to give a talk about it to any group that's interested. From my google+ post:
Programming languages have been annoying me for over 35 years. Still it's not so easy to get them right. I've got a fair way with the design of the Wombat Programming Language, but I can't get the interface-like part of it (Behaviour) working well. So rather than wait for perfection I thought I'd put it out there and see if anyone is interested in helping me with it.
I know my design would be better if I understood more of: Scalaz; Typeclassopedia; HoTT; and lots of other stuff. But maybe the people who do would like to comment (at least to the extent of recommending what to learn and where).
The "Wombat Summary and Rationale" document is at https://docs.google.com/document/d/1MXH4y75gViHDTldrAhXVMVUOXZJhwh3EwjXgn6k5Ncs/edit, with comments enabled. Or you can comment here. Or in my blog post: http://grampsgrumps.blogspot.com.au/2012/05/wombat-hasnt-landed.html. Or post an issue at http://wombatlang.googlecode.com. Or email me.
I know my design would be better if I understood more of: Scalaz; Typeclassopedia; HoTT; and lots of other stuff. But maybe the people who do would like to comment (at least to the extent of recommending what to learn and where).
The "Wombat Summary and Rationale" document is at https://docs.google.com/document/d/1MXH4y75gViHDTldrAhXVMVUOXZJhwh3EwjXgn6k5Ncs/edit, with comments enabled. Or you can comment here. Or in my blog post: http://grampsgrumps.blogspot.com.au/2012/05/wombat-hasnt-landed.html. Or post an issue at http://wombatlang.googlecode.com. Or email me.
Jack Kelly
May 13, 2012, 6:30:22 PM5/13/12
to fp-...@googlegroups.com
Hi Robert,
I can't comment meaningfully about the language design itself, but if
you're looking to build an ahead-of-time compiler, may I make some
suggestions?
The way I see it, if your new compiler can't play nice with make(1),
it's going to be very hard for it to gain traction. To do that, I
propose the following:
#1: You're almost certainly going to have object files that depend on
more than just the source file (be it headers, other module
interfaces, whatever). Therefore, any compiler should have an option
to produce makefile fragments describing the dependencies. See the -M
-MM -MD -MMD -MF -MG -MP -MT -MQ options to gcc(1). You may also want
to output this metadata in a more modern format for other build tools
to consume (sexp? json?).
#2: Your compiler should have options to produce files one at a time.
O'Caml is a particularly bad offender, where compiling a .ml can
produce .cmo, .cmi, .cmx and .o files depending on whether you use
ocamlc or ocamlopt and whether or not you've got a separate .mli file.
make's not good at handling multiple output files, and although you
can do it with GNUmake's pattern rules, I would recommend something
that works with across other makes. Making it easy to use across all
makes means automake users can add it to their build systems
relatively easily.
#3: Despite #2, the compiler should be able to compile and link a
standalone program in one invocation. It should also be able to
compile a source file into an object and associated metadata in a
single invocation. Compiling and linking with a single command makes
getting started easier, and you want something that people can pick
up. Having the option to compile (to an object), generate dependencies
and metadata in a single invocation means that when the glorious
revolution of modern build tools comes around (that is, something that
doesn't just spit out makefiles), you'll be ready.
I hope that's some use. Build systems are a pet topic of mine.
-- Jack
I can't comment meaningfully about the language design itself, but if
you're looking to build an ahead-of-time compiler, may I make some
suggestions?
The way I see it, if your new compiler can't play nice with make(1),
it's going to be very hard for it to gain traction. To do that, I
propose the following:
#1: You're almost certainly going to have object files that depend on
more than just the source file (be it headers, other module
interfaces, whatever). Therefore, any compiler should have an option
to produce makefile fragments describing the dependencies. See the -M
-MM -MD -MMD -MF -MG -MP -MT -MQ options to gcc(1). You may also want
to output this metadata in a more modern format for other build tools
to consume (sexp? json?).
#2: Your compiler should have options to produce files one at a time.
O'Caml is a particularly bad offender, where compiling a .ml can
produce .cmo, .cmi, .cmx and .o files depending on whether you use
ocamlc or ocamlopt and whether or not you've got a separate .mli file.
make's not good at handling multiple output files, and although you
can do it with GNUmake's pattern rules, I would recommend something
that works with across other makes. Making it easy to use across all
makes means automake users can add it to their build systems
relatively easily.
#3: Despite #2, the compiler should be able to compile and link a
standalone program in one invocation. It should also be able to
compile a source file into an object and associated metadata in a
single invocation. Compiling and linking with a single command makes
getting started easier, and you want something that people can pick
up. Having the option to compile (to an object), generate dependencies
and metadata in a single invocation means that when the glorious
revolution of modern build tools comes around (that is, something that
doesn't just spit out makefiles), you'll be ready.
I hope that's some use. Build systems are a pet topic of mine.
-- Jack
Erik de Castro Lopo
May 14, 2012, 2:16:57 PM5/14/12
to fp-...@googlegroups.com, Robert Smart
Robert Smart wrote:
> Some folk might be interested in my design of a functional-oriented
> language. I'm happy to give a talk about it to any group that's interested.
Hi Robert,
> Some folk might be interested in my design of a functional-oriented
> language. I'm happy to give a talk about it to any group that's interested.
FP-Syd is always open to new functional-X languages and there are a
number of people in the group very interested in compilers.
You should come along some time and meet the group and then at some later
time present Wombat. Either that or if you'd like, I could just slot
you in for June 15th.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Robert Smart
May 14, 2012, 3:44:05 PM5/14/12
to fp-...@googlegroups.com, Robert Smart
Hi Erik,
I have been a few times. Thursday is often difficult for me. I doubt if most of your group would be interested in my language as such: just idle speculation at this stage. But maybe I could give a talk on "Programming Languages: a catalogue of design disasters and triumphs" or some such. Slot me in when you're having trouble filling the schedule.
number of people in the group very interested in compilers.
Certainly Wombat has some interesting challenges for the compiler writer.
you in for June 15th.
Your web site gives 21st as a date.
Robert
Reply all
Reply to author
Forward
0 new messages