[bitc-dev] Application vs. Systems programming

[James Graves]

On Fri, Feb 17, 2006 at 07:46:48PM -0500, Jonathan S. Shapiro wrote:

> Multiple return values are already present. Use PAIR. There is
> absolutely no need for syntactic support, and quite a number of reasons
> to avoid it.

Well, I meant multiple values as in Common Lisp.  Where there is a main
value that you use, and additional values you can safely ignore if you
desire.  

I realize it does make things more complex.  Lots of people don't like
multiple return values.  Heck, there was discussion among the editors of
R6RS to remove them from the next Scheme.

> BitC is intended to be a general purpose language with support for
> writing verifiable sub-programs. In fact, BitC is *already* a useful
> language for application development. More on this to follow shortly
> (next email or so).
> 
> > It sounds like what we need is some means to compile a more
> > general-purpose application development language into BitC.
> 
> You are about to be preempted by a release announcement. I think that
> before you undertake this you may want to pause to see what BitC
> currently is. It is further along than you think, and this may
> significantly alter your view. More coming on this.

That's cool, I just saw the announcement.  And I'll spend some time
learning ML too.

[... tail call optimization...]

> Marc Feely's talk presents a subset of the techniques covered in these
> papers. A fair summary of these papers is (a) it's definitely doable to
> use C as a target assembly language, but (b) if you want full proper
> tail recursion, and you want to target C, it's going to cost you an
> unavoidable factor of 2. Marc doesn't really deal with proper tail
> recursion in his talk. See Bartlett's discussion.

Gotcha.  Do we envision that BitC will always have C as a target, or
will we eventally move to native code generation... and never look back?

ISTM, the main benefit of keeping C as a target is that, in our current
environment, there's always someone else willing to port a C compiler to
the next new platform.

> > I was also reading the section on optimization in Norvig's PAIP too.
> 
> Can you send out the full title of this?

I was talking about chapter 10 of Peter Norvig's "Paradigms of
Artificial Intelligence Programming: Case Studies in Common Lisp",
published 1992.  Main website:

    http://www.norvig.com/paip.html

I like his writing style and the way the concepts are introduced.

[... varargs ...]

> It is instructive to note that in the entire C library there are only
> two varargs functions:
> 
> 	[f]printf
> 	[f]scanf
> 
> and that essentially all other uses of varargs functions are for the
> purpose of implementing some variant on these, such as printf to a log.

Very true.  

Though I must add this: varargs are more of a hassle to set up than in C
than in higher-level languages.  But that wouldn't explain why they are
not often used.

At any rate, with a dynamic language background, I am used to being able
to do this in Scheme:

(map * (list 1 2 3) (list 4 5 6)) -> '(4 10 18)

and turning right around and doing this:

(map * (list 1 2 3) (list 4 5 6) (list 7 8 9)) -> '(28 80 162)

without giving it a second thought. (*)

Actually, I'm of the opinion that varargs shouldn't be in BitC.  In the
context of operating systems development, the benefit of varargs is far,
far outweighed by the cost of implmenetation (speed, safety, validation).

But when I am wearing my application developer hat, I would like to have
varargs.  Somehow.  If it can be safe.  That is what sent me along the
track of making an application development language which compiles into
BitC.

At any rate, it is my opinion that including varargs in BitC should be
postponed for a while, if not indefinitely.

Thank you for taking the time to patiently explain things.  I really
appreciate it.

James Graves

(*) BTW, I notice OCaml has List.map, which takes a function of one
argument and a list, and returns another list.  Then it has List.map2,
which takes a function of two arguments, and two lists, and returns
another list.

I bet that someone coded up a List.map3 at some point...