RE: Updated Messaging Chapter

Sounds reasonable.
And to be consistent, message_manager would also be mentioned in Messaging chapter, since it is specific to messaging.

So, any such "special-purpose" pre-defined type would be mentioned in the relevant chapter, dedicated to that topic.

Regardless, we may also add a general "predefined types summary" section, that will list them all.

Thanks,
Yuri.



-----Original Message-----
From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com] 
Sent: Monday, May 19, 2014 10:25
To: Yuri Tsoglin; stefan@amiq.com
Cc: cristian@amiq.com; ieee1647@eda.org; Hannes Froehlich
Subject: RE: Updated Messaging Chapter

Hi,

There is no reason why we cannot add an extra chapter if required to the LRM, if it makes understanding the LRM easier.

The Annexes are additional information to expand on the core LRM, and are not strictly necessary to define the language - they define implementation more instead.

rf_manager - this is mentioned in 31.2.8 of the LRM. It seems a more natural place for it, grouping everything for the Reflection API within the reflection chapter, than having one small part elsewhere?

Cheers,

Darren

-----Original Message-----
From: Yuri Tsoglin [mailto:yurit@cadence.com] 
Sent: Sunday, May 18, 2014 6:29 PM
To: stefan@amiq.com
Cc: Galpin Darren (IFGB ATV MCD SIP CV); cristian@amiq.com; ieee1647@eda.org; Hannes Froehlich
Subject: RE: Updated Messaging Chapter

Hi Stefan,

I just sent you a separate mail with some rework of the section attached.

As for your questions (which are actually more general than just about Messaging chapter), here are my comments:

*) Where should the recording_config section be included: under Messages -OR- under Predefined Types chapter? I would opt for the second.
[Yuri] It seems that currently we do not have a general Predefined Types chapter in LRM. Actually, it might be a good idea to add one. There are a few other (than messages) places where some predefined types are mentioned (e.g. rf_manager for reflection, packing for packing, etc.).
In any case, I think they should be distinguished from "core" data types (such as int, string, etc.).
I don't know if it's not too late to decide about this change now. Darren et al, what do you say?

*) Where should the any_unit/any_struct messaging API sit: under the Messages chapter -OR- under the any_unit/any_struct dedicated chapter?  
I would opt for the second.
[Yuri] I tend to agree, but again - there might be other similar places in LRM. If we decide to put them under a dedicated chapter, we should do it for all (and not just messages).

*) Should predefined types (eg message_manager, recording_config) be part of a library called std_e library, and somehow a separate section of the language standard?
std_e library would be a set of header files to assure the compatibility.
[Yuri] There is no notion of "header files" in e. Conceptually, we can talk about "e packages" instead of "libraries". Every explicitly named type in e belongs to some package, and predefined core types (such as int, string, etc.) belong to the predefined package "e_core".
It seems that currently "e_core" is only mentioned in Annex and not in the main chapters. Maybe we should improve that.
Regarding other pre-defined types (e.g. message_manager or rf_manager) - it sounds like a topic for a separate consideration. Each type clearly must belong to some package, and it should be mentioned in LRM (and currently it doesn't seem to be the case), but the questions are:
- Will that be "e_core" package (probably not) or another predefined package?
- Will they all belong to the same package (e.g. "std_e" as you suggested), or there should be several predefined packages (one for messages, one for reflection, and so on) ?

Thanks,
Yuri.



-----Original Message-----
From: stefan@amiq.com [mailto:stefan@amiq.com] 
Sent: Monday, April 28, 2014 16:42
To: Yuri Tsoglin
Cc: darren.galpin@infineon.com; cristian@amiq.com; ieee1647@eda.org; Hannes Froehlich
Subject: Updated Messaging Chapter


Hello Yuri,

       I attach the document containing changes I made to Messages chapter so you can merge it with the changes you already did. It is mostly the SDM Actions section that is new.

       Since Messages are related to transaction recording, I started writing 3 new sections that I will send out as separate documents:
- recording_config API (section 19.6.1, e LRM): can be inserted under the Messages chapter or as a section of a predefined types chapter
- any_unit messaging API (section 19.6.2, e LRM): can be included under any_unit predefined API
- any_struct messaging API (section 19.6.3, e LRM): can be included under any_struct predefined API

       There are a number of questions that pop-up:
*) Where should the recording_config section be included: under Messages -OR- under Predefined Types chapter? I would opt for the second.

*) Where should the any_unit/any_struct messaging API sit: under the Messages chapter -OR- under the any_unit/any_struct dedicated chapter?  
I would opt for the second.

*) Should predefined types (eg message_manager, recording_config) be part of a library called std_e library, and somehow a separate section of the language standard?
std_e library would be a set of header files to assure the compatibility.

*) Yuri: do you want me to send you also a clean version of the documents (eg without changes tracking)? Is the current formatting good enough? .

Kind Regards,
Stefan.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.