"Abstract Types" in the Rathaxes type system

[Louis Opter]

Since December we define Rathaxes types differently: you don't directly
write the type (often a structure) that will be generated anymore.

Instead, you just define fields and the compiler will generate a
structure around them for you. You don't have any control on the name of
the structure being generated.

This works fine and is actually very cool because it allows us to push
this ref/scalar system and solve our pointer/non-pointer ambiguities in
the language.

However, it makes it impossible to define what I'm calling "Abstract
Types". "Abstract Types" are the Rathaxes types I define to interface
with the Kernel types, here is a small example:

template type Ethernet::AbstractDevice()
{
decl data_types()
{
struct net_device data;
}

chunk LKM::includes()
{
#include <linux/netdevice.h>
}

map
{
}
}

This was cool until December, I could type "${Ethernet::AbstractDevice}"
and that would expand to "struct net_device".

But with the new type system this now expands in something like:
"rtxType_Ethernet_AbstractDevice" -which is actually a structure with a
single struct net_device field- and is not compatible, whatsoever, with
the Kernel APIs. So, we have to do this:

${MyAbstractType} *var;
kernel_api_function(&var->data);

This &var->data is actually a nop, but it's confusing and hard to
understand.

Another way is to do a cast:

${MyAbstractType} *var;
kernel_api_function((struct kernel_type *)var);

Which is, I believe, more intuitive and coherent with how you would
initialize the var pointer here, with a return value from the kernel
(i.e: with a cast into ${MyAbstractType} *). But, at the same time, it's
more verbose and more error prone (since you bypass type checking from
the C compiler).

Either way, I think both notations suck, and afaik David agrees too. I
think we need something else to define "Abstract Types" (btw, if anybody
disagrees with this "Abstract Type" term, let me know).

The intuitive solution seems to add a qualifer or something to tell the
compiler to not encapsulate the type in a generated structure. But that
seems to easy. And I wonder how it would be compatible with the
ref/scalar system.

--
Louis Opter

[Louis Opter]

On Mar 23, 2013, at 7:06 PM, Louis Opter <kale...@kalessin.fr> wrote:

> The intuitive solution seems to add a qualifer or something to tell the
> compiler to not encapsulate the type in a generated structure. But that
> seems to easy. And I wonder how it would be compatible with the
> ref/scalar system.

I'd like to add a quick note about what the qualifier could be (I think
"abstract" is too abstract…).

"extern" comes to my mind, I think it kinda fits the use-case here and
would be sort-of intuitive for anybody who did a little bit of C++.

But David and I are afraid that this could create confusion with C/C++
at some point.

"direct type", "native type" or "kernel type" might be better
alternatives.

--
Louis Opter

[Lionel Auroux]

After reading your complain, I think we just miss the point in the abstraction of type in rathaxes.

Rathaxes type must provide abstraction of target language type (here C).

But our poor type handling in Cnorm and then in rathaxes make kernel type mapping difficult and inefficient.

Describe this abstraction in subsystem interface (RTI) with 'type' statement attribute/method seems to be good.

As I see, your big problem is in the mapping of this interface type into a concrete type in C.

Before encapsulate things into a mangled type container with the decl statement, it could be judicious to just revise our requirement.

I think sometimes you just need to alias the rathaxes type directly to a C type, sometimes you don't.

Your example is for me the typical use case of an aliasing feature.

Let me redefine our keywords.

* in RTI:

- type statement allow to describe a type statement

-- attribute allow to access scalar element of this aggregate

-- method as in OOP

?? Could a type contains many decl statement? I don't think so. or I forgot. so, why we need to say it in the RTI?

* in BLT:

- the concrete part of the type should be only of two kinds : decl or alias

- decl as usual to compose a new type from different part of target language/systems

- alias as you show us. because our rathaxes abstraction is directly feed by the target system thru a C type.

Of course, for all kinds of type we have ref/scalar artefacts.

Does these new requirements fit your coding experience?

--
Cordialement,
Lionel Auroux

[David Pineau]

2013/3/25 Lionel Auroux <lionel...@gmail.com>:

> After reading your complain, I think we just miss the point in the
> abstraction of type in rathaxes.
>
> Rathaxes type must provide abstraction of target language type (here C).
> But our poor type handling in Cnorm and then in rathaxes make kernel type
> mapping difficult and inefficient.
>
> Describe this abstraction in subsystem interface (RTI) with 'type' statement
> attribute/method seems to be good.
>
> As I see, your big problem is in the mapping of this interface type into a
> concrete type in C.
>
> Before encapsulate things into a mangled type container with the decl
> statement, it could be judicious to just revise our requirement.
>
> I think sometimes you just need to alias the rathaxes type directly to a C
> type, sometimes you don't.
>
> Your example is for me the typical use case of an aliasing feature.
>
> Let me redefine our keywords.
>
> * in RTI:
> - type statement allow to describe a type statement
> -- attribute allow to access scalar element of this aggregate
> -- method as in OOP
>
> ?? Could a type contains many decl statement? I don't think so. or I forgot.
> so, why we need to say it in the RTI?

No, only one decl statement can is valid within both RTI and BLT files.

The reason why we must explicit it is as always a decision issue:
Since we want our language to be flexible, and defined by the interfaces,
this is the only way to enforce WHERE the decl will be weaved in the
generated code.

>
> * in BLT:
> - the concrete part of the type should be only of two kinds : decl or alias
> - decl as usual to compose a new type from different part of target
> language/systems
> - alias as you show us. because our rathaxes abstraction is directly feed by
> the target system thru a C type.
>
> Of course, for all kinds of type we have ref/scalar artefacts.
>
> Does these new requirements fit your coding experience?

This seems similar to what Louis proposed, with the difference that it
may integrate better inside the current rathaxes language :)

>
> --
> Cordialement,
> Lionel Auroux
>
> --
> --
> ML Rathaxes
> www.rathaxes.org
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Rathaxes Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rathaxes-deve...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
David Pineau,
Developer R&D at Scality

[Lionel Auroux]

2013/3/25 Lionel Auroux <lionel...@gmail.com>

Just a complement of my post for be correctly understood...

It's not in the interface than we know if a type will be implemented directly into a system C type or not.

So I prefer to write it in the template part.

When I wrote : "Could a type contains many decl statement?".  I  remember that decl was initially wrote as a chunk.

So we need to specify the target pointcut. This could be explicitly written.

I didn't show alias/decl syntax:

RTI:

XXX

interface Ethernet
{

      provided type AbstractDevice
      {

      target LKM::data_types(); // better than decl

      chunk LKM::includes();
      attribute Builtin::symbol  netdev;

      }

}

XXX

BLT:

with OS=Linux

template type Ethernet::AbstractDevice()
{

   alias struct net_device;

   chunk LKM::includes()

  { #include <linux/netdevice.h> }

   map
   {

      netdev : ${self}->ndev;

   }

}

with OS=Foobar

template type Ethernet::AbstractDevice()
{

   decl
   {

      __u16  id;

      __u8     magic;

      caddr    netd;

   }

   chunk LKM::includes()

   { /*nothing*/}

   map
   {

      netdev : ${self}->netd;

    }

}

--
Cordialement,
Lionel Auroux

[David Pineau]

2013/3/25 Lionel Auroux <lionel...@gmail.com>:

I'm not convinced by the "target" replacing the "decl". To me, it
makes it loose its meaning semantic-wise. Right, the target is where
we want the decl to be injected... But it has no relation whatsoever
about the fact that we want to declare what our type actually is.

Apart from that, I agree with your proposal for the decl/alias
alternatives within a BLT file. I think this matches our use-case and
will solve the issue at hand.

[Lionel Auroux]

2013/3/25 David Pineau <dav.p...@gmail.com>

ok if we continue to use decl in the RTI, I prefer decl and declalias as keyword.

declalias is better than alias, it's easier to understand that it's related to the decl in the RTI.

 

Apart from that, I agree with your proposal for the decl/alias
alternatives within a BLT file. I think this matches our use-case and
will solve the issue at hand.

It's seems easier to implement too...

 

--
David Pineau,
Developer R&D at Scality

--
--
ML Rathaxes
www.rathaxes.org

---
You received this message because you are subscribed to the Google Groups "Rathaxes Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rathaxes-deve...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Cordialement,
Lionel Auroux

[David Pineau]

yup :)

Louis will soon put up a report for the WE, i will explain my next
objectives before we start the python rewrite of the compiler :)