May 07, 2012
I think it was there where I read about it.

I'll update you if I have any success, otherwise I need to retract my statement. :(

--
Paulo

"Jens Mueller"  wrote in message news:mailman.380.1336380192.24740.digitalmars-d@puremagic.com...

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 

May 07, 2012
On 07-05-2012 14:50, Steven Schveighoffer wrote:
> 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

OK, point taken; didn't consider that. But in the first place, for inference of purity to work, the source would have to be available. Then, that inferred property has to be propagated somehow so that the compiler can make use of it when linking to the code as a library...

-- 
- Alex
May 07, 2012
I like the idea, need to check what information I could provide.

Wirth's books about Oberon also provide similar information.

--
Paulo

"dennis luehring"  wrote in message news:jo85t1$1n9b$1@digitalmars.com...

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? 

May 07, 2012
On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto <pjmlp@progtools.org> wrote:

> 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.

Again, don't take offense.  I never suggested Java's use of an already existing technology was in some way a "new" thing, just that it proves it can work.

I'm sure back in the day, TurboPascal had to walk uphill through the snow to school both ways too. :)

-Steve
May 07, 2012
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> On 07-05-2012 14:50, Steven Schveighoffer wrote:
>> 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.
>>
>
> OK, point taken; didn't consider that. But in the first place, for inference of purity to work, the source would have to be available. Then, that inferred property has to be propagated somehow so that the compiler can make use of it when linking to the code as a library...

That's exactly what storing the interface in the object file does.  You don't need the source because the object file contains the compiler's interpretation of the source, and any inferred properties it has discovered.

-Steve
May 07, 2012
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
> 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

Thanks for the tip! :)
What level of reinventing the wheel are we talking about? Did you suggest i fork (j)wlink or somesuch, or that i take a look at how it's implemented instead of reinventing from scratch? :)
And does anyone know if wlink is able to link programs from dmd? I made a half-hearted attempt myself, but didn't manage to get it to work ;p

/Pierre
May 07, 2012
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen < xtzgzorex@gmail.com> wrote:
>
>  On 07-05-2012 14:50, Steven Schveighoffer wrote:
>>
>>> 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.
>>>
>>>
>> OK, point taken; didn't consider that. But in the first place, for inference of purity to work, the source would have to be available. Then, that inferred property has to be propagated somehow so that the compiler can make use of it when linking to the code as a library...
>>
>
> That's exactly what storing the interface in the object file does.  You don't need the source because the object file contains the compiler's interpretation of the source, and any inferred properties it has discovered.
>

Putting inferred purity into an object file sounds like a bad idea. It's
not hard to imagine this scenario:
-function foo in libSomething is inferred as pure (but not declared pure by
the author)
-exeSomethingElse is compiled to use libSomething, and the compiler takes
advantage of purity optimizations when calling foo
-libSomething is recompiled and foo is no longer pure, and exeSomethingElse
silently breaks

Purity inference is fine for templates (because recompiling the library won't change the generated template code in an executable that depends on it), but in all other cases, the API needs to be exactly what the author declared it to be, or strange things will happen.


May 07, 2012
On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley <wiley.andrew.j@gmail.com> wrote:

> On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:
>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>
>> That's exactly what storing the interface in the object file does.  You
>> don't need the source because the object file contains the compiler's
>> interpretation of the source, and any inferred properties it has discovered.
>>
>
> Putting inferred purity into an object file sounds like a bad idea. It's
> not hard to imagine this scenario:
> -function foo in libSomething is inferred as pure (but not declared pure by
> the author)
> -exeSomethingElse is compiled to use libSomething, and the compiler takes
> advantage of purity optimizations when calling foo
> -libSomething is recompiled and foo is no longer pure, and exeSomethingElse
> silently breaks

no, it just doesn't link.

> Purity inference is fine for templates (because recompiling the library
> won't change the generated template code in an executable that depends on
> it), but in all other cases, the API needs to be exactly what the author
> declared it to be, or strange things will happen.

I agree that's the case with the current object/linker model.  Something that puts inferred properties into the object file needs a new model, one which does not blindly link code that wasn't compiled from the same sources.

-Steve
May 07, 2012
Am 07.05.2012 15:30, schrieb Steven Schveighoffer:
> On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto <pjmlp@progtools.org>
> wrote:
>
>> 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.
>
> Again, don't take offense. I never suggested Java's use of an already
> existing technology was in some way a "new" thing, just that it proves
> it can work.
>
> I'm sure back in the day, TurboPascal had to walk uphill through the
> snow to school both ways too. :)
>
> -Steve


No offense taken.

My reply was just a small rant, based on your answer on lack of contact
with Turbo Pascal and other languages I mentioned.

Yesterday I watched a presentation, where the guy complains on knowledge
being lost due to the lack of proper mentors in the industry,

http://www.infoq.com/presentations/The-Frustrated-Architect

I have spent a huge time in the university learning about compiler
development, reading old books and papers from the early computing days.

So in a general way, and not directed to you now, I saddens me that a great part of that knowledge is lost to most youth nowadays.

Developers get amazed with JavaScript JIT compilation, and yet it already existed in Smalltalk systems.

Go advertises fast compilation speeds, and they were already available
to some language systems in the late 70's, early 80's.

We are discussing storing module interfaces directly in the library files, and most seem to never heard of it.

And the list goes on.

Sometimes I wonder what do students learn in modern CS courses.

--
Paulo


May 07, 2012
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley <wiley.andrew.j@gmail.com> wrote:
>
>  On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy@yahoo.com
>> >wrote:
>>
>>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>>
>>> That's exactly what storing the interface in the object file does.  You don't need the source because the object file contains the compiler's interpretation of the source, and any inferred properties it has discovered.
>>>
>>>
>> Putting inferred purity into an object file sounds like a bad idea. It's
>> not hard to imagine this scenario:
>> -function foo in libSomething is inferred as pure (but not declared pure
>> by
>> the author)
>> -exeSomethingElse is compiled to use libSomething, and the compiler takes
>> advantage of purity optimizations when calling foo
>> -libSomething is recompiled and foo is no longer pure, and
>> exeSomethingElse
>> silently breaks
>>
>
> no, it just doesn't link.
>
>
>  Purity inference is fine for templates (because recompiling the library
>> won't change the generated template code in an executable that depends on it), but in all other cases, the API needs to be exactly what the author declared it to be, or strange things will happen.
>>
>
> I agree that's the case with the current object/linker model.  Something that puts inferred properties into the object file needs a new model, one which does not blindly link code that wasn't compiled from the same sources.
>

Then all you've done is to make attributes the author can't control part of the API, which will force library users to recompile their code more often for non-obvious reasons. Avoiding that is one of the points of shared libraries.

I think we're actually talking about different contexts. I'm speaking in the context of shared libraries, where I think the API needs to be exactly what the author requests and nothing more. With object files, static libraries, and static linking, I agree that this sort of thing could work and wouldn't cause the same problems because it's impossible to swap the library code without recompiling/relinking the entire program.