Fog Creek Software
Discussion Board




Dogfood

Friday April 26th's brief mention of "eating your own dogfood" inspired me to use my programming language Heron to write a documentation generator for itself. You can see the results at http://www.heron-language.com/toc.html .  Thanks Joel!

Christopher Diggins
Monday, July 05, 2004

Sorry if loads of people have already mentioned this, but your home page has next year's news on it: "July 5th, 2005 - A new major release...".

Some people round here will call me a perfectionist for pointing this kind of stuff out*, but who cares. If it was my site, I'd want to know.


* http://www.joelonsoftware.com/items/2004/04/22.html

Steve Jones (UK)
Tuesday, July 06, 2004

May I complement you on the excellent design of your site. 

I can't wait to give Heronn a try.  I always love to tinker with a new langauge.

Best of all - you have DbC!

Ged Byrne
Tuesday, July 06, 2004

What is DbC?

Ignore my ignorance
Tuesday, July 06, 2004

== Design by Contract ==

  * http://en.wikipedia.org/wiki/Design_by_Contract
  * http://archive.eiffel.com/doc/manuals/technology/contract/
  * http://www.artima.com/intv/contracts.html
  * http://www.heron-language.com/design-by-contract.html

Ged Byrne
Tuesday, July 06, 2004

I agree with Ged, really nice website design.

Steve Jones (UK)
Tuesday, July 06, 2004

Thank you for the positive comments, and the correction on the date. I will pass the compliments on the design to my wife Melanie Charbonneau who did the graphic design and layout.

Christopher Diggins
Tuesday, July 06, 2004

I have used the C++ style of metaprogramming, but I prefer the Lisp style.  The C++ style essentially makes up for the fact that C++ programs aren't really expressions that you can manipulate in C++.  It would be valuable if you had a facility like that in your language.  It would essentially be what you've got right now, but all the 'meta' types would be hidden from the programmer (so instead of meta_int<2> your compiler would infer meta_int<2> from the context).  If this inference procedure could *also* be used by the programmer, then his procedures could easily parse Heron expressions himself (and your compiler could decide whether such procedures are compile-time only).  The common example is the derivative function.  In your language, d(x * 2, x) could return a function of a parameter x that computes 2 * x (and this example could be done completely at compile-time ... but it could be extended easily to work at run-time with user-entered functions).

Also, are you working on the details of your standard library?  Your standard library page only features your working principles.

Kalani
Tuesday, July 06, 2004

>then his procedures could easily parse Heron expressions himself

should be

then he could easily parse Heron expressions himself

Kalani
Tuesday, July 06, 2004

C++ meta programming is worst hack being widely used in any language.  IMHO.  It blows my mind that a lot of really smart people can convince themselves that this is a good thing for C++. 

christopher baus.net
Tuesday, July 06, 2004

I agree that it's horrible, but it's not as bad as no meta-programming at all.

Kalani
Tuesday, July 06, 2004

I was unaware of the Lisp style of metaprogramming, thank you for bringing it to my intention.

I am considering removing the meta_XXX declaration on primitives being used in meta expressions. The more I think about it the more it seems that the current restrictions are little more than an inconvenience for the programmer.

I want Heron metaprogramming to be completely unambiguous when it occurs. The big problem in C++ metaprogramming, is when something is legal or not. I had to figure out the whole C++ mechanism through trial and error, it was not intuitive.

In response to christopher baus.net 's post, Heron metaprogramming is planned and intentional rather than incidental like C++ metaprogramming, despite being somewhat similar in style.  For more info see http://www.heron-language.com/metaprogramming.html

I do want to go on the record as saying that C++ metaprogramming is a definite improvement over macro programming with the pre-processor.

Concerning the standard library, it is a work in progress currently in an embryonic stage.  It would be premature right now to write anything else about the library.

Christopher Diggins
Tuesday, July 06, 2004

Thanks for responding, Christopher.

>I want Heron metaprogramming to be completely
>unambiguous when it occurs.

Why do you want that?  Have you got some application in mind whose code is 'cleaner' when you impose that restriction?

Kalani
Tuesday, July 06, 2004

> TMTOWTDI : "There's More Than One Way To Do It". This is
> the motto for the Perl programming language. This is at odds
>  with everything that Heron stands for. TMTOWTDI is in
> direct conflict with principles of KISS, least surprise,
> readability, scalability etc.

How does TMTOWTDI conflict with principles of KISS, least surprise,  readability, scalability?

Matthew Lock
Tuesday, July 06, 2004

w.r.t the question on TMTOWTDI I wrote a blog entry to respond to it, because I didn't want to take up too much room, it is at http://www.heron-language.com/2004/07/tmtowtdi-or-theres-more-than-one-way.html

w.r.t ambiguity in metaprogramming (x * y) is expected to consistently behave in heron as _mult(x, y) with all associated typecasting rules, neccessary constructor calls, function overload resolution etc. The metacompiler does none of this so meta_mult_int<X, Y> behaves much differently. A meta_int can not be used interchangeably with an Int which is not known until afer the parsing phase.

Christopher Diggins
Wednesday, July 07, 2004

So that restriction is essentially there to make it easier to implement the compiler, given your existing code?  That's understandable.  But what structures do you use to represent expressions internally?  You've essentially got something like meta_int<X> for Int x.  You could use that to your advantage in your language.  How about defining a set of types that relate to the non-terminals of the grammar for your language?

eg:

void f(Heron::Grammar::IfStatement ifs)
{
  // do something with this 'if-then-else' statement
}

As for when you'd evaluate f, there are a number of interesting ways to do it.  You could have a special syntax for invoking functions at compile-time instead of runtime.  You could use a markup on functions to allow the programmer to specify which ones work at compile-time and which ones work at runtime.  You could infer compile/run time from the context of the invocation (a constant expression is passed and the function uses no functions marked to run only at run-time).

I think that something like this would make meta-programming much simpler in your language.

Kalani
Wednesday, July 07, 2004

>You've essentially got something like meta_int<X> for Int x.

What I actually meant here is that 2 has type meta_int<2>.  Int x would have some type like meta_expression<meta_symbol<meta_int, x>>.

Kalani
Wednesday, July 07, 2004

Concerning my blog entry on TMTOWTDI at http://www.heron-language.com/2004/07/tmtowtdi-or-theres-more-than-one-way.html . Anonymous comments were not enabled, so I apologize if anyone had wanted to comment on that entry.

Kalani brings up some interesting ideas with regards to metaprogramming in Heron but my instincts are telling me they would require too many changes to the core language and end up increasing the complexity of Heron code in order to make metaprogramming code mesh with non-metaprogramming code without neccessarily increasing the expressivity significantly. I am open to further discussion on this topic but I would recommend doing so on my Heron language forum which has more features and perhaps a more relevant location for this discussion at http://forum.skrud.net/viewforum.php?f=18

Christopher Diggins
Wednesday, July 07, 2004

Thanks for the feedback Christopher.  I'd be interested in knowing how your project develops over time.  I'm working on a language project myself.

Kalani
Wednesday, July 07, 2004

*  Recent Topics

*  Fog Creek Home