On 12/10/2014 2:24 AM, Paulo Pinto wrote:
> This cannot be the solution if D aspires to be used in contexts where binary
> libraries are used.
>
> C++ is excused to have template code in headers given the primitive tooling, but
> languages like Ada and Modula-3 support proper information hiding for generic code.

There's no way you can hide the implementation of a function from the user if it is available to the compiler.

Quite a few people thought C++ "exported templates" would make this work, but there is no known way to implement it and keep it hidden from the user, not even if it is encrypted since the compiler must decrypt it.

On Wednesday, 10 December 2014 at 10:48:12 UTC, Walter Bright wrote:
> On 12/10/2014 2:24 AM, Paulo Pinto wrote:
>> This cannot be the solution if D aspires to be used in contexts where binary
>> libraries are used.
>>
>> C++ is excused to have template code in headers given the primitive tooling, but
>> languages like Ada and Modula-3 support proper information hiding for generic code.
>
> There's no way you can hide the implementation of a function from the user if it is available to the compiler.
>
> Quite a few people thought C++ "exported templates" would make this work, but there is no known way to implement it and keep it hidden from the user, not even if it is encrypted since the compiler must decrypt it.

My remark had nothing to do with IP.

I prefer the model used by the referred languages, where binary libraries and metadata is used, instead of the C toolchain model.

For example, just shipping the .TPU/.DCU libraries in the Object Pascal world.

--
Paulo

On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo  Pinto wrote:
> On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
>> On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
>>> Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution.
>>
>> You can compile against phobos sources instead of interface files.
>
> This cannot be the solution if D aspires to be used in contexts where binary libraries are used.
>
> C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code.
>
> --
> Paulo

A binary blob requirement makes no sense for a standard library.

Would you like to explain how the proper information hiding support works for generic code in Ada? I'm really curious how that could work in D.

On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath wrote:
> On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo  Pinto wrote:
>> On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
>>> On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
>>>> Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution.
>>>
>>> You can compile against phobos sources instead of interface files.
>>
>> This cannot be the solution if D aspires to be used in contexts where binary libraries are used.
>>
>> C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code.
>>
>> --
>> Paulo
>
> A binary blob requirement makes no sense for a standard library.

And yet that has been the way it always worked in the Mesa linage of languages.

Mesa, Modula-2, Modula-3, Ada, Oberon, Object Pascal  ....

>
> Would you like to explain how the proper information hiding support works for generic code in Ada? I'm really curious how that could work in D.

The libraries contain the required metadata for symbol tables and code locations that need to be extracted into the executable/library.

Package definition files contain the minimum information the compiler needs to know to search for the remaining information.

Example,

-- Package header
generic
  type Element_T is private;
package functions is
  procedure Swap (X, Y : in out Element_T);
end functions;

-- Package body
package body functions is
  procedure Swap (X, Y : in out Element_T) is
  begin
    -- implementation
  end Swap;
end functions;

-- importing it
declare
  package functions_Int  is new functions (Int);
  use functions_Int;
  x, y : Int;
begin
  x := 1;
  y := 2;
  Swap(x, y);
end;


Lots of options are possible when the C compiler and linker model aren't being used.

..
Paulo

On 10 December 2014 at 14:16, Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath wrote:
>>
>> On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo  Pinto wrote:
>>>
>>> On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
>>>>
>>>> On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
>>>>>
>>>>> Because you don't really create a template that way but workaround
>>>>> broken function behavior. It is not the usage of empty templates that is bad
>>>>> but the fact that plain functions remain broken => not really a solution.
>>>>
>>>>
>>>> You can compile against phobos sources instead of interface files.
>>>
>>>
>>> This cannot be the solution if D aspires to be used in contexts where binary libraries are used.
>>>
>>> C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code.
>>>
>>> --
>>> Paulo
>>
>>
>> A binary blob requirement makes no sense for a standard library.
>
>
> And yet that has been the way it always worked in the Mesa linage of languages.
>
> Mesa, Modula-2, Modula-3, Ada, Oberon, Object Pascal  ....
>
>>
>> Would you like to explain how the proper information hiding support works for generic code in Ada? I'm really curious how that could work in D.
>
>
> The libraries contain the required metadata for symbol tables and code locations that need to be extracted into the executable/library.
>
> Package definition files contain the minimum information the compiler needs to know to search for the remaining information.
>
> Example,
>
> -- Package header
> generic
>   type Element_T is private;
> package functions is
>   procedure Swap (X, Y : in out Element_T);
> end functions;
>
> -- Package body
> package body functions is
>   procedure Swap (X, Y : in out Element_T) is
>   begin
>     -- implementation
>   end Swap;
> end functions;
>
> -- importing it
> declare
>   package functions_Int  is new functions (Int);
>   use functions_Int;
>   x, y : Int;
> begin
>   x := 1;
>   y := 2;
>   Swap(x, y);
> end;
>
>
> Lots of options are possible when the C compiler and linker model aren't being used.


In D, this should be akin to:

// Package header
module functions;
void Swap(T)(out T x, out T y);

// Package body
module functions;
void Swap(T)(out T x, out T y)
{
  // Implementation
}

// Importing it
import functions : Swap;
void main()
{
  int x = 1;
  int y = 2;
  Swap(x, y);
}

Iain

On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo  Pinto wrote:

>
> Lots of options are possible when the C compiler and linker model aren't being used.
>
> ..
> Paulo

I don't see how symbol table information and relocation meta data is sufficient to produce the correct object code if the template parameters are unknown.

// library
void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }

// my code
foo!(ArcaneType1, DubiousType2)(a, d);

On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via Digitalmars-d wrote:
> On 10 December 2014 at 14:16, Paulo  Pinto via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath wrote:
>>>
>>> On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo  Pinto wrote:
>>>>
>>>> On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
>>>>>
>>>>> On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
>>>>>>
>>>>>> Because you don't really create a template that way but workaround
>>>>>> broken function behavior. It is not the usage of empty templates that is bad
>>>>>> but the fact that plain functions remain broken => not really a solution.
>>>>>
>>>>>
>>>>> You can compile against phobos sources instead of interface files.
>>>>
>>>>
>>>> This cannot be the solution if D aspires to be used in contexts where
>>>> binary libraries are used.
>>>>
>>>> C++ is excused to have template code in headers given the primitive
>>>> tooling, but languages like Ada and Modula-3 support proper information
>>>> hiding for generic code.
>>>>
>>>> --
>>>> Paulo
>>>
>>>
>>> A binary blob requirement makes no sense for a standard library.
>>
>>
>> And yet that has been the way it always worked in the Mesa linage of
>> languages.
>>
>> Mesa, Modula-2, Modula-3, Ada, Oberon, Object Pascal  ....
>>
>>>
>>> Would you like to explain how the proper information hiding support works
>>> for generic code in Ada? I'm really curious how that could work in D.
>>
>>
>> The libraries contain the required metadata for symbol tables and code
>> locations that need to be extracted into the executable/library.
>>
>> Package definition files contain the minimum information the compiler needs
>> to know to search for the remaining information.
>>
>> Example,
>>
>> -- Package header
>> generic
>>   type Element_T is private;
>> package functions is
>>   procedure Swap (X, Y : in out Element_T);
>> end functions;
>>
>> -- Package body
>> package body functions is
>>   procedure Swap (X, Y : in out Element_T) is
>>   begin
>>     -- implementation
>>   end Swap;
>> end functions;
>>
>> -- importing it
>> declare
>>   package functions_Int  is new functions (Int);
>>   use functions_Int;
>>   x, y : Int;
>> begin
>>   x := 1;
>>   y := 2;
>>   Swap(x, y);
>> end;
>>
>>
>> Lots of options are possible when the C compiler and linker model aren't
>> being used.
>
>
> In D, this should be akin to:
>
> // Package header
> module functions;
> void Swap(T)(out T x, out T y);
>
> // Package body
> module functions;
> void Swap(T)(out T x, out T y)
> {
>   // Implementation
> }
>
> // Importing it
> import functions : Swap;
> void main()
> {
>   int x = 1;
>   int y = 2;
>   Swap(x, y);
> }
>
> Iain

But the current object model doesn't support it, right?

At least my understanding is that you need to have the full body visible.

--
Paulo

On Wednesday, 10 December 2014 at 17:19:53 UTC, Tobias Pankrath wrote:
> On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo  Pinto wrote:
>
>>
>> Lots of options are possible when the C compiler and linker model aren't being used.
>>
>> ..
>> Paulo
>
> I don't see how symbol table information and relocation meta data is sufficient to produce the correct object code if the template parameters are unknown.
>
> // library
> void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }
>
> // my code
> foo!(ArcaneType1, DubiousType2)(a, d);


Simple, by dropping C based linker model as I state on my comment.


--
Paulo

On Wed, Dec 10, 2014 at 06:15:48PM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via Digitalmars-d wrote:
[...]
> >In D, this should be akin to:
> >
> >// Package header
> >module functions;
> >void Swap(T)(out T x, out T y);
> >
> >// Package body
> >module functions;
> >void Swap(T)(out T x, out T y)
> >{
> >  // Implementation
> >}
> >
> >// Importing it
> >import functions : Swap;
> >void main()
> >{
> >  int x = 1;
> >  int y = 2;
> >  Swap(x, y);
> >}
> >
> >Iain
> 
> But the current object model doesn't support it, right?
> 
> At least my understanding is that you need to have the full body visible.
[...]

Yeah, the compiler cannot instantiate the template without access to the full body. It *could*, though, if we were to store template body IR in object files, perhaps under specially-dedicated object file sections. It wouldn't prevent reverse-engineering (which is moot anyway when templates are involved), but it *would* work as an "opaque" library interface file.


T

-- 
Food and laptops don't mix.

On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto wrote:
> On Wednesday, 10 December 2014 at 17:19:53 UTC, Tobias Pankrath wrote:
>> On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo  Pinto wrote:
>>
>>>
>>> Lots of options are possible when the C compiler and linker model aren't being used.
>>>
>>> ..
>>> Paulo
>>
>> I don't see how symbol table information and relocation meta data is sufficient to produce the correct object code if the template parameters are unknown.
>>
>> // library
>> void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }
>>
>> // my code
>> foo!(ArcaneType1, DubiousType2)(a, d);
>
>
> Simple, by dropping C based linker model as I state on my comment.
>
>
> --
> Paulo

I don't care for the C based linker model. You'll have to recompile the template, symbol table information and relocation data is just not enough, in any linker model. So you'll need the body of foo and you'll need to compile it at "link time".

What advantages of a hypothetical Pascal inspired D linker model are left now?

If we just want to have binary, because binary, we could share zipped library source and teach dmd how to unzip.