The Artima Developer Community
Sponsored Link

Weblogs Forum
Macros and Type-Systems

35 replies on 3 pages. Most recent reply: Oct 11, 2005 4:19 AM by Steve Donovan

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 ]
john yates

Posts: 2
Nickname: jsyjr
Registered: Jan, 2005

Re: Macros and Type-Systems Posted: Oct 7, 2005 10:21 PM
Reply to this message Reply

I am a big fan of programs that compute new programs. One of the theses that helped me think about this aspect of programming nearly 2 decades ago was David Booth's "Multiple strongly typed evaluation phases: a programming-language notion". Abstract:

This work introduces the programming language notion of multiple strongly typed evaluation phases, or simply, phases. In general, a program might be executed through several phases. Each phase requires its own input, and acts as compile time relative to the next phase, or runtime relative to the previous phase. Thus, each phase is the execution of a program, and may play the role of compile time or run time. The notion of phases offers a framework for understanding compiled strongly typed languages, and works toward an improved, strongly typed language basis for reusable software. The research shows how types can be manipulated as first-class values, and notions of compile time and runtime can be unified, without sacrificing strong typing (compile time type checking) or runtime speed. The notion of phases is demonstrated by defining a sample source language, Phi, which looks like a typed lambda calculus; an object language, IL, which is syntactically similar to an untyped lambda calculus, but is strongly typed; an associated IL Machine that interprets IL programs; and a translator for converting Phi programs to IL programs.

Having been published in 1986 there does not seem to be a machine readable version anywhere. I remember that the copy I read was a photocopy of output that I believe was generated on a Diablo printer. You can buy a copy for $38 from University Microfilm:

Order number is 8603934.

(Were I still in possession of a copy I would send it to you but allas I am not.)

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Macros and Type-Systems Posted: Oct 8, 2005 3:13 AM
Reply to this message Reply
> I think perhaps the best way to answer this question is: I
> want to be able write a library like Boost (
> ) or the STL, with far less code and
> in a manner which is comprehensible to the average
> programmer. If you are familiar with Boost source code,
> you'll know what I am talking about, check out some source
> code at
> for a prime example.
> Even though it is nightmarish code, it does represent
> something the fact that at least in C++ you can create
> brand new ideas and tools which weren't built directly
> into the language.

Less code would be good. The Boost source (and pretty much all C++ library source) looks complicated but well-written -- I wouldn't call it nightmarish. I don't know that the "average programmer" cares much about the guts of libraries, though. Reading libraries, to say nothing of writing them, is something most average programmers never do or have any reason to do. If the library has a clear API and documentation that's enough for the majority of programmers.

> One major goal of Heron is that the language should be
> able to be extended in new directions with relative ease
> by writing new libraries, which can be as efficient as if
> the features were directly built into the language.

STL and Boost are probably less efficient than if C++ had built-in support for strings and vectors and the data structures and algorithms people use STL and Boost for. But lots of modern languages allow cleaner extensibility -- Ruby comes to mind.

Suppose C had a built-in function to count the number of bytes in an array up to the first zero byte. Would that necessarily be more efficient than a call to strlen()? Would average programmers rather extend a language themselves instead of using a library of functions? Are you talking about syntactic sugar or something more powerful and interesting?

As an application programmer I'm much more interested in the libraries I can use than I am with the language's macro facilities or ability to create closures. And as a manager of programmers I'm pretty sure I don't want to maintain the code if every programmer gets to create their own dialect.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Macros and Type-Systems Posted: Oct 8, 2005 11:47 AM
Reply to this message Reply
> And as a
> manager of programmers I'm pretty sure I don't want to
> maintain the code if every programmer gets to create their
> own dialect.
this is exactely the reason why I would not want to have a multi-paradigm language.

I am much inclined to like the idea of a multi-phase language. I remember when I have used the the C++ preprocessor (which effectively allows for mutiple phases) to create inlined closures (for performance reasons). I was thinking that it would be great to have first-hand support for that.

But when programming in a team, I hate the C++ preprocessor for the very same reason I like it.
#define self this (because somebody liked python) is just
the beginning.
Operator overloading is much more problematic, IMO.
When people start overloading *, ->, and [], it can get
confusing very easily.

I agree, though, that language enhancements that increase productivety are a good thing.
In my experience, however, most of the productivety gains are due to IDE features, especially refactoring support (e.g. Eclipse, IDEA).
Therefore, I would not want to use Heron, even if I liked the language better - if there was no decent IDE for it.

Robert Parnell

Posts: 22
Nickname: robparnl
Registered: Jul, 2005

Re: Macros and Type-Systems Posted: Oct 8, 2005 11:49 AM
Reply to this message Reply

Somehow, I don't know if Chris can get Heron out the door?

First, if you are re-doing C++. Just throw it all out. Or strip "what language" features are available. (Start with 90 %.) Second, build simple, add next, add next.

Third, stop high-level designing - unless you really know where you are going with it. As my Softward Engineering professor used to say; "write out the specification, first." Stick to it and code last. Then, we you have Herrn v00.1 running, add the next level.

Otherwise, I enjoy seeing all these posts about "should I do this or that?" from a presumed language builder. But, if you are asking for our input? Can you just do more building and less asking.

* After all, don't you know - what it is already presumed to be? Otherwise, why are you asking us? (Yes, it must be nice having a brain trust - poitn out "I know the answer" to that question. But, why are you asking us questions? When you don't seem to know - why am I doing this?)

Feel free to flame. I felt it had to be said. Robert

PS. If you want something stupid from me, to criticize. "why is overloading matrix ops hard?" (1) Just throw them in a class. (2) Define the ops. (3) Use as a user & move on to the next math. problem set. (More PS: 3D solids, 2D repeating tiles, geometry, CAS, diff calc, diffy Q, ...)

George Coles

Posts: 2
Nickname: gcoles
Registered: Dec, 2003

Re: Macros and Type-Systems Posted: Oct 8, 2005 1:27 PM
Reply to this message Reply
look at Nemerle. it has very nice macros and two-step compilation.

Steve Donovan

Posts: 24
Nickname: stevedonov
Registered: May, 2005

Re: Macros and Type-Systems Posted: Oct 11, 2005 4:19 AM
Reply to this message Reply
> look at Nemerle. it has very nice macros and two-step
> compilation.

And of course, Nemerle's cousin, Boo. It combines a nice clean Python syntax with infered static-typing, plus optional duck typing for when a static type system becomes too restrictive. I have been doing some non-trivial work in Boo and it is very expressive. It does true closures, and also true lexical macros. (For instance, a macro can be defined that implements Pascal-style with statements.).

True closures are a great pleasure. By defining a function background(), which expects a function, I can put operations into a separate thread in a way which makes the intent very clear:

background() do:

or, here's a quick way to save some typing:
inf = File.OpenText('input')
gets = { return inf.ReadLine() }
first = gets()
second = gets()

On the subject of multi-paradigm languages, I'm remembering here that Christopher also said that the problem of C++ is that it tries to be everyone's language. Isn't there a programming language equivalent of 'imperial overstretch'?

steve d.

Flat View: This topic has 35 replies on 3 pages [ « | 1  2  3 ]
Topic: Announcing Ruby Code & Style Previous Topic   Next Topic Topic: Threading Terminology

Sponsored Links


Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us