On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
> Paulo Pinto wrote:
>> AST/symbol table manipulation is way faster than reparsing code.
>> 
>> People keep talking about D and Go compilation speed, while I was already
>> enjoying such compile times back in 1990 with Turbo Pascal in computers much
>> less powerfull than my laptop.
>> 
>> But C and C++ with their 70's compiler technology, somehow won the
>> market share,
>> and then people started complaining about compilation speeds.
>> 
>> Adele Golberg, once wrote a paper telling how C made the compiler technology
>> regress several decades.
>
> Do you happen to remember to exact title of that paper?
> Thanks.
>
> Jens

I'll try to find it, as I don't recall the title.

I just remember that it made some remarks how primitive C was in regard
to Algol toolchains.

Paulo Pinto wrote:
> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
> >Paulo Pinto wrote:
> >>AST/symbol table manipulation is way faster than reparsing code.
> >>
> >>People keep talking about D and Go compilation speed, while I
> >>was already
> >>enjoying such compile times back in 1990 with Turbo Pascal in
> >>computers much
> >>less powerfull than my laptop.
> >>
> >>But C and C++ with their 70's compiler technology, somehow won
> >>the
> >>market share,
> >>and then people started complaining about compilation speeds.
> >>
> >>Adele Golberg, once wrote a paper telling how C made the
> >>compiler technology
> >>regress several decades.
> >
> >Do you happen to remember to exact title of that paper? Thanks.
> >
> >Jens
> 
> I'll try to find it, as I don't recall the title.
> 
> I just remember that it made some remarks how primitive C was in
> regard
> to Algol toolchains.

Many thanks.
I couldn't find it myself and I'm interested because Fran Allen said
something similar in Coders at Work.
I didn't understand what she meant. Andrei suggested that it is mostly
(only?) about overlapping pointers to memory. I'm just curious.

Jens

Am 07.05.2012 07:53, schrieb Paulo Pinto:
> I really really think that mankind did a wrong turn when C won over Pascal
> in the 80's.
>
> And that Wirth somehow lost interest in the industry and did not try to push
> Modula-* or Oberon. There are some papers where he states this.
>
> Now we suffer from
>
> - daggling pointers
> - buffer overflows
> - pre-historic compiler toolchains
>
> With luck, Spec#, Go or more nicely D, will put us back on track.

we should collect all the advantages of turbo pascal/delphi object-file-formats and make a small description post to show others in a clear understandable way how good/and longlife these technics are

so the unit-system (turbo pascal: .pas -> .tpu, delphi: .pas->.dcu, free pascal: .pas -> ppu), the tpumover, ppumover for tpl or ppl libraries, the dll delphi solution .bpl

and the advantage of controling the output of source inside the source
program -> exe, unit -> object, library -> dynamic libray etc.

any ideas how to start?

On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> Purity inference won't happen either way. Purity is part of your API and also meant to help you reason about your code. If the compiler just infers purity in a function and you later change the implementation so it's no longer pure, you break your users' code. Also, purity would no longer help you reason about your code if it's not explicit.

It can be pure for the purposes of optimization without affecting code whatsoever.  Inferred purity can be marked separately from explicit purity, and explicitly pure functions would not be allowed to call implicitly pure functions.

-Steve

On Sat, 05 May 2012 03:06:52 -0400, dennis luehring <dl.soluz@gmx.net> wrote:

> Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
>> On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
>> <andrej.mitrovich@gmail.com>  wrote:
>>
>>>  On 5/4/12, foobar<foo@bar.com>  wrote:
>>>>  How about augmenting the object format so that libraries would be
>>>>  self contained and would not require additional .di files? Is
>>>>  this possible optlink by e.g. adding special sections that would
>>>>  be otherwise ignored?
>>>
>>>  How would you use a library you don't even have the interface to? I
>>>  mean if you can't even look at the API in your editor.. that'd be
>>>  insane.
>>
>> Ever heard of Java?
>>
>> -Steve
>
> ever heard about Turbo Pascal (and delphi) got this feature since turbo pascal 4 around 1987

Honestly?  No.  I've heard of those languages, I don't know anyone who uses them, and I've never used them.

I don't mean this as a slight or rebuttal.  Java is just more recognizable.  Using either language (Java or TurboPascal) is still a good way to prove the point that it is possible and works well.

-Steve

On 07-05-2012 13:21, Steven Schveighoffer wrote:
> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
> <xtzgzorex@gmail.com> wrote:
>
>> Purity inference won't happen either way. Purity is part of your API
>> and also meant to help you reason about your code. If the compiler
>> just infers purity in a function and you later change the
>> implementation so it's no longer pure, you break your users' code.
>> Also, purity would no longer help you reason about your code if it's
>> not explicit.
>
> It can be pure for the purposes of optimization without affecting code
> whatsoever. Inferred purity can be marked separately from explicit
> purity, and explicitly pure functions would not be allowed to call
> implicitly pure functions.
>
> -Steve

But that kind of inferred purity is something a compiler back end cares about, not something the language should have to care about at all. In practice, most compilers *do* analyze all functions for possible side-effects and use that information where applicable.

(Note that what you described thus is the current situation, just that inferred purity is not part of the language (no reason it has to be).)

-- 
- Alex

On 05/07/12 13:21, Steven Schveighoffer wrote:
> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> 
>> Purity inference won't happen either way. Purity is part of your API and also meant to help you reason about your code. If the compiler just infers purity in a function and you later change the implementation so it's no longer pure, you break your users' code. Also, purity would no longer help you reason about your code if it's not explicit.
> 
> It can be pure for the purposes of optimization without affecting code whatsoever.  Inferred purity can be marked separately from explicit purity, and explicitly pure functions would not be allowed to call implicitly pure functions.

In WPO mode - it doesn't matter - it's just another internal compiler optimization.
Otherwise in general it can't be done - a change to the function definition would
change its signature - which means that all callers need to be recompiled.
So at best only the intra-module calls can be affected, when the compiler knows that
the caller will always be generated together with the callee. And the latter has to
be assumed impure if it's not private, for the same reasons.

artur

On Thu, 03 May 2012 19:47:19 -0300, Pierre LeMoine <yarr.luben+dlang@gmail.com> wrote:

> Hi!
>
> I'm interested in starting a project to make a linker besides
> optlink for dmd on windows. If possible it'd be cool to run it as
> a gsoc-project, but if that's not an option I'll try to get it
> admitted as a soc-project at my university.
>
> Anyway, the project would aim to be a replacement or alternative
> to optlink on windows. I've personally encountered quite a few
> seemingly random problems with optlink, and the error messages
> are not exactly friendly. My vision is to create a linker in a
> relatively modern language (D) and to release the project as open
> source.
>
> So, I'm curious about some things; Is it too late to get this
> accepted as a summer of code project? Are there any current
> alternative linkers for dmd on windows, or any current projects
> aiming to create one? And do any of you know of a "Everything you
> need to know to write the best linker ever" resource center? ;]

If you are interested in getting results rather than reinventing the wheel,
I would advice you to have a look at the openwatcom.org wlink, and the
forked jwlink as a starting point. The linker is open source, written in
C and has user documentation (not source doc unfortunately).

Roald

On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> On 07-05-2012 13:21, Steven Schveighoffer wrote:
>> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
>> <xtzgzorex@gmail.com> wrote:
>>
>>> Purity inference won't happen either way. Purity is part of your API
>>> and also meant to help you reason about your code. If the compiler
>>> just infers purity in a function and you later change the
>>> implementation so it's no longer pure, you break your users' code.
>>> Also, purity would no longer help you reason about your code if it's
>>> not explicit.
>>
>> It can be pure for the purposes of optimization without affecting code
>> whatsoever. Inferred purity can be marked separately from explicit
>> purity, and explicitly pure functions would not be allowed to call
>> implicitly pure functions.
>>
>> -Steve
>
> But that kind of inferred purity is something a compiler back end cares about, not something the language should have to care about at all. In practice, most compilers *do* analyze all functions for possible side-effects and use that information where applicable.

It affects how callers code will be generated.

If I have a function

int foo(int x);

and I have another function which calls foo like:

int y = foo(x) + foo(x);

Then the optimization is applied to whatever function this exists in.  If the source isn't available for foo, the compiler cannot make this optimization.

I have no idea if this is a back-end or front-end issue.  I'm not a compiler writer.  But I do understand that the compiler needs extra information in the signature to determine if it can make this optimization.

-Steve

This just confirms what I saw yesterday on a presentation.

Many developers re-invent the wheel, or jump to the fad technology of the
year, because they don't have the knowledge of old already proven technologies,
that for whatever reason, are no longer common.

We need better ways to preserve knowledge in our industry.

--
Paulo

"Steven Schveighoffer"  wrote in message news:op.wdxra01ceav7ka@steves-laptop...

On Sat, 05 May 2012 03:06:52 -0400, dennis luehring <dl.soluz@gmx.net>
wrote:

> Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
>> On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
>> <andrej.mitrovich@gmail.com>  wrote:
>>
>>>  On 5/4/12, foobar<foo@bar.com>  wrote:
>>>>  How about augmenting the object format so that libraries would be
>>>>  self contained and would not require additional .di files? Is
>>>>  this possible optlink by e.g. adding special sections that would
>>>>  be otherwise ignored?
>>>
>>>  How would you use a library you don't even have the interface to? I
>>>  mean if you can't even look at the API in your editor.. that'd be
>>>  insane.
>>
>> Ever heard of Java?
>>
>> -Steve
>
> ever heard about Turbo Pascal (and delphi) got this feature since turbo pascal 4 around 1987

Honestly?  No.  I've heard of those languages, I don't know anyone who
uses them, and I've never used them.

I don't mean this as a slight or rebuttal.  Java is just more
recognizable.  Using either language (Java or TurboPascal) is still a good
way to prove the point that it is possible and works well.

-Steve