tail rec

tail rec

[skaller]

I have a silly idea. Introduce a new construction:

let tailrec f .. 

This is the same as let rec except it checks every direct call to f
is in tail position (and bombs out the compiler if not).

[Maybe this can be done with camlp4, though I think it might
be hard?]

I think this could be useful for newbies learning functional
programming, and perhaps even experts looking for performance
issues.

If a let closure of f is made, a warning is issued, eg:

let tailrec f x = 
  let g x = f x in (* WARNING *)
  1 + g (x - 1) (* not tail, but not explicit call of f *)

The annotation does NOT prove a function is tail rec,
but if the compiler bombs, it proves the function is
not tail rec.

Comments?

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] tail rec

[Erik de Castro Lopo]

skaller wrote:

> Comments?

I've wanted something like this for a long time :-).

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Ever since GNOME development began, I have urged people to aim
to make it as good as the Macintosh. To try to be like Windows
is to try for second-best." - Richard Stallman

Re: [Caml-list] tail rec

[Basile STARYNKEVITCH]

skaller wrote:
> I have a silly idea. Introduce a new construction:
> 
> let tailrec f .. 
> 
> This is the same as let rec except it checks every direct call to f
> is in tail position (and bombs out the compiler if not).


While I also want a similar construct or help, I believe your proposal 
is wrong. What would be needed is a tailrec operator keyword that makes 
the compiler check that a given call is in tail position. It is not a 
function which is tail recursive, it is a call which is.

In that way, the classical factorial does not have any tail call, so

   let rec fact n = if n <= 0 then 1 else n * tailrec fact (n - 1)
                                              ^^^^^^^

should give a warning, while the equivalent

   let fact n =
      let rec factloop n p =
         if n <= 0 then p
         else tailrec factloop (n - 1) (n * p)
      in factloop n 1


However, I have a more elegant "solution" (actually not a solution but a 
proposal) : that tools like ocaml -dtypes and the emacs mode (or the 
ocamlbrowser) flag (e.g. show in a different color) each tail-recursive 
call.

And yes, tail-recursion is syntactic, so all this could be a big camlp4 
stuff.

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [Caml-list] tail rec

[skaller]

On Sat, 2007-05-19 at 07:28 +0200, Basile STARYNKEVITCH wrote:
> skaller wrote:
> > I have a silly idea. Introduce a new construction:
> > 
> > let tailrec f .. 
> > 
> > This is the same as let rec except it checks every direct call to f
> > is in tail position (and bombs out the compiler if not).
> 
> 
> While I also want a similar construct or help, I believe your proposal 
> is wrong. What would be needed is a tailrec operator keyword that makes 
> the compiler check that a given call is in tail position. It is not a 
> function which is tail recursive, it is a call which is.
> 
> In that way, the classical factorial does not have any tail call, so
> 
>    let rec fact n = if n <= 0 then 1 else n * tailrec fact (n - 1)

Felix actually implements this for procedure calls: instead of

	f x;

or

	call f x;

you can write:

	jump f x;

In that context, it is not a compiler *check* but sugar for

	call f x;
	return;

which forces the call to be tail. This is only for procedure
calls though, not function applications.

For Ocaml, it would seem your suggestion should use the
keyword 'return':

let rec fact n = if n <= 0 then 1 else n * return fact (n-1)

is pretty obviously an error, and a C/C++ programmer would
understand this.

The problem with your idea is that it doesn't allow the
programmer to do this:

let rec fact n = ....

Hum. Is this tail rec? I'm a GOOD programmer => I'm LAZY.
With my suggestion I could just write:

let tailrec fact n = ..

to check a claim that 'fact' isn't gratuitously non-tail rec.

The point is, I'm trying to establish a property of the function
implementation: ALL direct recursion is tailed.

In a longer chain of let rec .. and .. and this is only a single
keyword change.

Your suggestion would require writing 'tailrec' or 'return'
in advance for every call .. and no GOOD programmer would
do that because good programmers are lazy.

It would be the other way. First you write 

	let tailrec  ....

and now you get an error because there is a real and essential
non-tail call .. so you annotated that call:

	else x::(f y)

is an error because f isn't tailed but this is right so:

	else x::(rec f y)

has to be written to disable the check on that f.

In fact, I could go a step further and suggest ALL let rec
should be forced to be tailrec, so the ONLY way to do
a non tail call is write

	rec f y

The compiler then issues a warning when 'rec' is used
but the call actually is in tail position.

Unfortunately this breaks existing code so it would have
to be enabled by a compiler switch.

In summary then: what you (Basile) suggest is technically
sound, and could ALSO be implemented!

However the two features address the same issue from
opposite angles. My proposal assures a whole function
or list of function is directly tail rec, whereas
yours is extremely local and checks individual explicitly
annotated calls.

So from a software engineering/development viewpoint
they have quite different utility .. and they're not
exclusive!

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] tail rec

[Jonathan Bryant]

>>> I have a silly idea. Introduce a new construction:
>>>
>>> let tailrec f ..
>>>
>>> This is the same as let rec except it checks every direct call to f
>>> is in tail position (and bombs out the compiler if not).

A question I have about tail recursion in general:

let f x = (* Do something *)
let g x = (* Do something *); f x
let h x = (* Do something *); g x

Does the compiler optimize the calls (f x) and (g x) into tail  
calls?  If so, how would the

let railrec f x = ...
let tailrec g x = ...
let tailrec h x = ...

syntax handle/help this?  Or would it hinder it?

--Jonathan

Re: [Caml-list] tail rec

[Erik de Castro Lopo]

Jonathan Bryant wrote:

> Does the compiler optimize the calls (f x) and (g x) into tail  
> calls?  If so, how would the
> 
> let railrec f x = ...
> let tailrec g x = ...
> let tailrec h x = ...
> 
> syntax handle/help this?  Or would it hinder it?

The new syntax neither helps nor hinders. The tailrec directive
requests that the compile complain if a function marked as "tailrec"
cannot be made tail recursice.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"I have found that Big Design Up Front environments attract people who
want to talk about software development, while iterative environments
attract people who want to develop software. Is it any surpise that in
companies where BDUF is predominant, nobody wants to stoop to coding?
Everyone wants to be an 'architect' or a 'Business Analyst' or a 
'Product Manager'." -- Reg Braithwaite

Re: [Caml-list] tail rec

[skaller]

On Sat, 2007-05-19 at 16:19 -0400, Jonathan Bryant wrote:
> 
> >>> I have a silly idea. Introduce a new construction:
> >>>
> >>> let tailrec f ..
> >>>
> >>> This is the same as let rec except it checks every direct call to f
> >>> is in tail position (and bombs out the compiler if not).
> 
> A question I have about tail recursion in general:
> 
> let f x = (* Do something *)
> let g x = (* Do something *); f x
> let h x = (* Do something *); g x
> 
> Does the compiler optimize the calls (f x) and (g x) into tail  
> calls?  If so, how would the
> 
> let railrec f x = ...
> let tailrec g x = ...
> let tailrec h x = ...
> 
> syntax handle/help this? 

let tailrec would be a bad idea here because these
functions aren't recursive. However this form:

let g x = (* Do something *); tail f x

would assure you the call to f is tailed.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] tail rec

[Oliver Bandel]

On Sat, May 19, 2007 at 12:56:05PM +1000, skaller wrote:
> I have a silly idea. Introduce a new construction:
> 
> let tailrec f .. 
> 
> This is the same as let rec except it checks every direct call to f
> is in tail position (and bombs out the compiler if not).
> 
> [Maybe this can be done with camlp4, though I think it might
> be hard?]
> 
> I think this could be useful for newbies learning functional
> programming, and perhaps even experts looking for performance
> issues.
[...]

I think this is blocking understanding of how ressources
are allocated, when one uses a certain style of programming
and datastructures.

Ciao,
   Oliver

Re: [Caml-list] tail rec

[Oliver Bandel]

On Sat, May 19, 2007 at 04:28:27PM +0200, Oliver Bandel wrote:
> On Sat, May 19, 2007 at 12:56:05PM +1000, skaller wrote:
> > I have a silly idea. Introduce a new construction:
> > 
> > let tailrec f .. 
> > 
> > This is the same as let rec except it checks every direct call to f
> > is in tail position (and bombs out the compiler if not).
> > 
> > [Maybe this can be done with camlp4, though I think it might
> > be hard?]
> > 
> > I think this could be useful for newbies learning functional
> > programming, and perhaps even experts looking for performance
> > issues.
> [...]
> 
> I think this is blocking understanding of how ressources
> are allocated, when one uses a certain style of programming
> and datastructures.

Forget these words: I misunderstood your email,
because I did not read until end before I answered.
Sorry for the unnecessary traffic.

I thought you want to automatically *convert*
code to tailrec-code. Even if this would
also be a fine thing, it could block understanding,
as mentioned above.

But you only want to have warnings...
...that might be a good helper.
But it might also be annoying?
Such warnings should be off per default, IMHO.

Ciao,
   Oliver

Re: [Caml-list] tail rec

[skaller]

On Sat, 2007-05-19 at 16:46 +0200, Oliver Bandel wrote:

> > I think this is blocking understanding of how ressources
> > are allocated, when one uses a certain style of programming
> > and datastructures.
> 
> Forget these words: I misunderstood your email,
> because I did not read until end before I answered.
> Sorry for the unnecessary traffic.

Actually you make an important point!

> I thought you want to automatically *convert*
> code to tailrec-code.

Well that would be totally cool, but it appears
to be a rather hard problem?

>  Even if this would
> also be a fine thing, it could block understanding,
> as mentioned above.

Actually, you DO have an important point here.
When looking at, say, ordinary Ocaml code,
it is important to learn about recursion.

Examining the syntactic structure of the code
to understand the 'different' uses of a simple
but powerful primitive in an 'idiomatic' way
is important for understanding functional programming.

The use of sugar, annotations, or other device to
assure certain properties may well hide these idioms,
making learning and recognizing them harder.

I say 'may' because I'm only one individual, and not
a teacher familiar with learning experiences of many people.

> But you only want to have warnings...
> ...that might be a good helper.

Actually no: if you write 

let tailrec ...

then if a direct call of f is not in tail position,
you get a hard error, not a warning.

The construction has definite semantics. That applies
to Basile's more local annotation too.

In both cases the error indicates either that the routine
is possibly suboptimal in performance, or even that there
is a semantic bug in it!

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] tail rec

[Brian Hurt]

skaller wrote:

>I have a silly idea. Introduce a new construction:
>
>let tailrec f .. 
>
>This is the same as let rec except it checks every direct call to f
>is in tail position (and bombs out the compiler if not).
>
>  
>
I dislike this idea, even for it's stated purpose (to make it easier for 
people to learn Ocaml).  Wether a particular call is a tail call or not 
is not an attribute of the function, but an attribute of the call.  The 
same function can be called as both a tail call and a non-tail call.  If 
we're going to teach Ocaml, let's at least teach it right.

And this is a non-trivial complaint.  It's very common for me to write 
recursive loops where the call inside the function is a tail call, but 
the original call to the function is not a tail call.  So I couldn't write:
    let tailrec loop i s =
        if i > 0 then
            loop (i-1) (s+i)  (* proper tail call- it's a loop *)
        else s
    in
    let t = 2 * (loop n 0) in ... (* this is not a tail call *)

A better proposal would be one where the call itself is marked as a 
tailcall, and bombs out if that call isn't.  Maybe something like:

    let rec loop i s =
       if i > 0 then
          tailcall loop (i-1) (s+i) (* force this to be a tailcall *)
       else s
    in
    let t = 2 * (loop n 0) in ... (* not a tail call, and that's OK *)

At which point I'm neutral on the idea.  The rules for what is or isn't 
a tail call are not complicated.  On the other hand, it's a little bit 
of extra correctness for not much cost.

Brian

Re: [Caml-list] tail rec

[Robert Fischer]

I'm with Brian on this, although it the "tailrec" specification needs to 
be optional.  I use tail recursion by accident a lot when I'm coding 
("Oh, hey, I guess this is tail recursive.  Nifty!"), and I would be 
really annoyed to have to think about whether my recursion is tail 
recursive or not every time I use it.

~~ Robert.
>
> A better proposal would be one where the call itself is marked as a 
> tailcall, and bombs out if that call isn't.  Maybe something like:
>
>    let rec loop i s =
>       if i > 0 then
>          tailcall loop (i-1) (s+i) (* force this to be a tailcall *)
>       else s
>    in
>    let t = 2 * (loop n 0) in ... (* not a tail call, and that's OK *)
>
> At which point I'm neutral on the idea.  The rules for what is or 
> isn't a tail call are not complicated.  On the other hand, it's a 
> little bit of extra correctness for not much cost.
>
> Brian

Re: [Caml-list] tail rec

[Basile STARYNKEVITCH]

On Mon, 21 May 2007 08:04:37 -0500
Robert Fischer <robert.fischer@SmokejumperIT.com> wrote:

> I'm with Brian on this, although it the "tailrec" specification needs to  be optional.  I use tail recursion by accident a lot when I'm coding 
> ("Oh, hey, I guess this is tail recursive.  Nifty!"), and I would be  really annoyed to have to think about whether my recursion is tail 
> recursive or not every time I use it.


I'm repeating my suggestion: extend the typing annotation (produced by -dtypes) to flag every tail recursive call, and have the emacs mode and ocamlbrowser display every tail call particularily (e.g. in a different color or font).

This don't require any additional language construct.

And BTW, I'm not sure such thing will happen, because I am not sure that the Gallium team is interested in coding it :-) 

Also, tail recursion is IMHO a beginner's puzzle. I'm pretty sure every experimented Ocaml programmer does know inside his code what are his tail recursive calls.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 
8, rue de la Fa_encerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [Caml-list] tail rec

[Robert Fischer]

> I'm repeating my suggestion: extend the typing annotation (produced by -dtypes) to flag every tail recursive call, and have the emacs mode and ocamlbrowser display every tail call particularily (e.g. in a different color or font).
>
> This don't require any additional language construct.
>   
Oh, then we're cool.  :-D

> Also, tail recursion is IMHO a beginner's puzzle. I'm pretty sure every experimented Ocaml programmer does know inside his code what are his tail recursive calls.
>   
If you asked me to point them out, I could.  If you asked me if a given 
function is tail recursive, I could tell you.  I also use tail recursive 
calls unintentionally, and (while I realize now that you're not 
proposing this) I was concerned my code suddenly wouldn't compile 
because I didn't happen to tag a tail recursion.

Robert Fischer
IT Firefighter
Smokejumper Consulting

Re: [Caml-list] tail rec

[Brian Hurt]

Robert Fischer wrote:

>
>> I'm repeating my suggestion: extend the typing annotation (produced 
>> by -dtypes) to flag every tail recursive call, and have the emacs 
>> mode and ocamlbrowser display every tail call particularily (e.g. in 
>> a different color or font).
>>
>> This don't require any additional language construct.
>>   
>
> Oh, then we're cool.  :-D
>
>> Also, tail recursion is IMHO a beginner's puzzle. I'm pretty sure 
>> every experimented Ocaml programmer does know inside his code what 
>> are his tail recursive calls.
>>   
>
> If you asked me to point them out, I could.  If you asked me if a 
> given function is tail recursive, I could tell you.  I also use tail 
> recursive calls unintentionally, and (while I realize now that you're 
> not proposing this) I was concerned my code suddenly wouldn't compile 
> because I didn't happen to tag a tail recursion.

Most of the time you don't care wether a particular call is a tail call 
or not.

I will comment: in my experience, new programmers make simple mistakes 
for simple reasons, while experienced programmers make simple mistakes 
for complicated reasons.

Actually, I can see uses for this, even for experienced, knowlegable 
programmers.  For example, I can imagine scenarios where, during 
maintainance, a try/catch block is introduced, making a tail call that 
needed to be a tail call into a non-tail call.  Opps.  I don't think 
this happens all that often, so it's not that valuable to experienced 
programmers, but every little bit of correctness helps.

Brian

Re: [Caml-list] tail rec

[Daniel Bünzli]

An even simpler first step would be to make tail recursion a faq. For  
example many people don't know that if you have a try ... with around  
your call it won't be a tail call.

Speaking of the faq, it is a little bit sad that the wealth of useful  
information on the old site never migrated to the new one.

Daniel

Re: [Caml-list] tail rec

[Christopher L Conway]

It would be great to have a resource like the Haskell Wiki for the
OCaml community. Such things are not difficult to maintain once they
are set up (although someone will have to volunteer for spam patrol).

Chris

On 5/21/07, Daniel Bünzli <daniel.buenzli@epfl.ch> wrote:
> An even simpler first step would be to make tail recursion a faq. For
> example many people don't know that if you have a try ... with around
> your call it won't be a tail call.
>
> Speaking of the faq, it is a little bit sad that the wealth of useful
> information on the old site never migrated to the new one.
>
> Daniel
>
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] tail rec

[Jon Harrop]

On Monday 21 May 2007 15:24:44 Christopher L Conway wrote:
> It would be great to have a resource like the Haskell Wiki for the
> OCaml community. Such things are not difficult to maintain once they
> are set up (although someone will have to volunteer for spam patrol).

Having had all links to ffconsultancy.com removed from Wikipedia (even my PhD 
thesis!), we discussed this at length in our company recently. Spammers and 
vandals are a major problem for Wikis. I think we dreamt up a good solution: 
replace the standard "type in these letters" with a Turing test.

I think the questions should be hard. Anyone contributing to an OCaml Wiki 
should know some OCaml.

The guy who put up a Wiki for SICP translations did this (albeit with trivial 
questions) and said that it worked very well.

Perhaps this is a case for mod_caml? :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] tail rec

[Richard Jones]

On Mon, May 21, 2007 at 03:36:44PM +0100, Jon Harrop wrote:
> On Monday 21 May 2007 15:24:44 Christopher L Conway wrote:
> > It would be great to have a resource like the Haskell Wiki for the
> > OCaml community. Such things are not difficult to maintain once they
> > are set up (although someone will have to volunteer for spam patrol).
>
> Having had all links to ffconsultancy.com removed from Wikipedia
> (even my PhD thesis!), we discussed this at length in our company
> recently. Spammers and vandals are a major problem for Wikis. I
> think we dreamt up a good solution: replace the standard "type in
> these letters" with a Turing test.

Since forcing people to sign up with an email address, the wikis at
http://www.ocaml-tutorial.org/ and http://cocan.org/ have been spam
free, although people who signed up have complained about getting
notified of all the changes[*] so perhaps that's another sort of spam.

You are right though that CAPTCHAs do not work.  Seriously.  Every
time I've looked at a case of Wiki spam, it's been done by a human
being presumably sitting in a sweat-shop in China or wherever.  Human
beings have no problem typing in CAPTCHAs.

Forcing them to learn OCaml in order to contribute is a good idea.  If
they did it, then even if we get spammed, at least we get more OCaml
coders ...

Rich.

[*] They can turn this off.

-- 
Richard Jones
Red Hat

Re: ocaml faq (was [Caml-list] tail rec)

[Daniel Bünzli]

Le 21 mai 07 à 16:24, Christopher L Conway a écrit :

> It would be great to have a resource like the Haskell Wiki for the
> OCaml community.

You are right. In fact we already have one, it's called cocan.org.  
But we need the authors agreement to migrate their prose there.

> (although someone will have to volunteer for spam patrol).

Richard Jones does it on cocan.org

Daniel

Re: ocaml faq (was [Caml-list] tail rec)

[Christopher L Conway]

My impression is that COCAN has a specific mission (advocating for
OCaml in industry) and target audience (managers) which is not
necessarily compatible with what I had in mind. The Haskell Wiki
encompasses tutorials, FAQs, PLT bibliographies, and language
extension RFCs. The intended audience is programmers, from novices to
compiler hackers. If COCAN wants to expand to fulfill this role, I'm
all for it.

Chris

On 5/21/07, Daniel Bünzli <daniel.buenzli@epfl.ch> wrote:
>
> Le 21 mai 07 à 16:24, Christopher L Conway a écrit :
>
> > It would be great to have a resource like the Haskell Wiki for the
> > OCaml community.
>
> You are right. In fact we already have one, it's called cocan.org.
> But we need the authors agreement to migrate their prose there.
>
> > (although someone will have to volunteer for spam patrol).
>
> Richard Jones does it on cocan.org
>
> Daniel
>
>
>

Re: ocaml faq (was [Caml-list] tail rec)

[Robert Fischer]

I'd be willing to host it and play spam-cop for a developer's Wiki if
    1) COCAN really is limited in scope, and
    2) there's real interest in using it.

I've got lots of space to burn over at SmokejumperIT.com.

Robert Fischer
IT Firefighter
Smokejumper Consulting


Christopher L Conway wrote:
> My impression is that COCAN has a specific mission (advocating for
> OCaml in industry) and target audience (managers) which is not
> necessarily compatible with what I had in mind. The Haskell Wiki
> encompasses tutorials, FAQs, PLT bibliographies, and language
> extension RFCs. The intended audience is programmers, from novices to
> compiler hackers. If COCAN wants to expand to fulfill this role, I'm
> all for it.
>
> Chris
>
> On 5/21/07, Daniel Bünzli <daniel.buenzli@epfl.ch> wrote:
>>
>> Le 21 mai 07 à 16:24, Christopher L Conway a écrit :
>>
>> > It would be great to have a resource like the Haskell Wiki for the
>> > OCaml community.
>>
>> You are right. In fact we already have one, it's called cocan.org.
>> But we need the authors agreement to migrate their prose there.
>>
>> > (although someone will have to volunteer for spam patrol).
>>
>> Richard Jones does it on cocan.org
>>
>> Daniel
>>
>>
>>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: ocaml faq (was [Caml-list] tail rec)

[Daniel Bünzli]

Le 21 mai 07 à 17:17, Robert Fischer a écrit :

> I'd be willing to host it and play spam-cop for a developer's Wiki if
>    1) COCAN really is limited in scope, and

I don't think it is, but it's up to Rich to decide.

FWIW I just make some pointers on this page [1] into the interesting  
bits of the old site.

Daniel

[1] http://cocan.org/faqs_and_programming_guidelines

Re: ocaml faq (was [Caml-list] tail rec)

[Richard Jones]

On Mon, May 21, 2007 at 05:27:56PM +0200, Daniel Bünzli wrote:
> 
> Le 21 mai 07 à 17:17, Robert Fischer a écrit :
> 
> >I'd be willing to host it and play spam-cop for a developer's Wiki if
> >   1) COCAN really is limited in scope, and
> 
> I don't think it is, but it's up to Rich to decide.

Really it's up to whoever has an interest in this to decide.

FWIW, it's trivial to set up a new FAQ site on those servers.  The
hardest part is pulling out my credit card to buy the domain name :-)

Or if people want to use ocaml-tutorial / cocan for a FAQ, if that's
best.

Or another site.

Or do nothing.

Rich.

-- 
Richard Jones
Red Hat

Re: ocaml faq (was [Caml-list] tail rec)

[Robert Fischer]

I'd be inclined to put it up on cocan -- keep things centralized.  The 
biggest problem at that point is keeping them organized.

Robert Fischer
IT Firefighter
Smokejumper Consulting



Richard Jones wrote:
> On Mon, May 21, 2007 at 05:27:56PM +0200, Daniel Bünzli wrote:
>   
>> Le 21 mai 07 à 17:17, Robert Fischer a écrit :
>>
>>     
>>> I'd be willing to host it and play spam-cop for a developer's Wiki if
>>>   1) COCAN really is limited in scope, and
>>>       
>> I don't think it is, but it's up to Rich to decide.
>>     
>
> Really it's up to whoever has an interest in this to decide.
>
> FWIW, it's trivial to set up a new FAQ site on those servers.  The
> hardest part is pulling out my credit card to buy the domain name :-)
>
> Or if people want to use ocaml-tutorial / cocan for a FAQ, if that's
> best.
>
> Or another site.
>
> Or do nothing.
>
> Rich.
>
>   

Re: ocaml faq (was [Caml-list] tail rec)

[Richard Jones]

... or a subdomain like faq.ocaml-tutorial.org

Rich.

-- 
Richard Jones
Red Hat