[m-rev.] for post-commit review: fix mantis bug 361

[Paul Bone]

On Fri, Sep 19, 2014 at 01:51:22PM +1000, Julien Fischer wrote:
>
> On Thu, 18 Sep 2014, Paul Bone wrote:
>
>> I like this and I think it's a step in the right direction.  However it's
>> still a leaky abstraction, by an ideal goal I was thinking of a system with
>> many fewer grades (normal, debugging, profiling) and definitly not multiple
>> backends to the same target language.  I beleive this matches what users
>> want without adding unnecesary complexity, however it's extreamly
>> hypothetical and not something that realistically matches the Mercury
>> project in it's current form or with it's design goals (eg: not paying for a
>> feature like parallelism or trailing when your program doesn't use it).
>
> You've moved on to a different problem there, reducing the number of
> grades and that's a different discussion.
>
> BTW, the two "C" backends do not target the same language: the
> high-level backend targets standard C (or at least it's supposed to),
> the low-level C backend targets GNU C (usually) + a bunch of inline
> assembler.

Telling that to someone who "just wants to use Mercury" will get you a
response along the lines of "so what?".  It's an important distinction from
an engieering or research perspective, but from a user's perspective what's
important is what it can do.

> Actually, I note that the compiler attempts to install the libraries in
> 14 different grades by default on OS X when using clang (i.e. when we
> can't use the asm_fast grades), namely:
>
>    csharp
>    hlc.gc
>    hlc.gc.memprof
>    hlc.gc.prof
>    hlc.gc.trseg
>    hlc.par.gc
>    java
>    none.gc
>    none.gc.debug.stseg
>    none.gc.debug.trseg.stseg
>    none.gc.decldebug.stseg
>    none.gc.prof
>    none.gc.profdeep
>    none.par.gc.stseg
>
> That may be getting a bit excessive ;-)

http://yfl.bahmanm.com/Members/ttmrichter/yfl-blog/mercury-time-to-hello-world


-- 
Paul Bone