with __pragma__(...): #552

Activity

1. kiwi0fruit

   changed the title [-]with __pragma(...)__:[/-] [+]with __pragma__(...):[/+] on Sep 7, 2018
2. JdeH

   self-assigned this

   on Oct 5, 2018
3. JdeH

   added

   IS: enhancement

   IS: exploratory

   on Oct 5, 2018
4. happy-monk commented on Oct 13, 2018

   

   happy-monk

   on Oct 13, 2018

   Contributor

   More actions

   Do you mind if I try to implement this?
5. JdeH

   added

   STATE: under construction

   on Oct 13, 2018
6. JdeH commented on Oct 13, 2018

   

   JdeH

   on Oct 13, 2018

   Collaborator

   More actions

   @happy-monk

   It would be a nice addition if it doesn't complicate the compiler too much.
   You're welcome to give it a try.
   I've marked it 'under construction' for now.

   Kind regards
   Jacques
7. happy-monk commented on Sep 29, 2019

   

   happy-monk

   on Sep 29, 2019

   Last edited by happy-monk

   Contributor

   More actions

   The with __pragma__ now works in most cases, but with a couple of issues.

   First of all, if you try to nest pragmas of the same kind, you will see rather confusing results. For example:

   with __pragma__('opov'):
       a = b + c
       with __pragma__('opov'):
           x = y + z
       d = e + f
   

   a = b + c and x = y + z will be affected by 'opov', but d = e + f will not.

   This is because with __pragma__ is implemented now by appending/prepending __pragma__('xxx') and __pragma__('noxxx') to the context code. So the nested with will always disable its effect instead of restoring the previous state.

   The same applies to the single-line activation variety of pragmas, because it's implemented in the same way.

   Of course, this is not kind of thing you should see in final/production/etc. code, but it surely will confuse people and get in the way of experimentation with code.

   To solve this some architectural solution is needed. There are several way to handle this, but, I think, the easiest way would be to implement some kind of stack for translator flags and utilise it for with handling and single-line activation. The __pragma__(push) and __pragma__(pop) could also be realised for use with non-context pragmas.
8. JdeH commented on Oct 7, 2019

   

   JdeH

   on Oct 7, 2019

   Last edited by JdeH

   Collaborator

   More actions

   I agree that this behavior may be confusing if you encounter it while experimenting.
   Still I think that the with __pragma__ variant is quite useful.
   The situation reminds me to C/C++ #ifdef #endif macro's that also "cannot count",
   if I remember well, but still are quite useful.
   The same limitation holds for nested comments in many languages.
   So I'd like to include it in the upcoming release, but will pay attention to its limitations in the documentation.

   One probably simple way to lift this limitation for most pragma's would be to use a counter rather than a boolean to maintain their status.
   But currently I do not oversee all consequences (which may be none).
   It may result in some pragma's being nestable and others not, which may be even more confusing, not sure...

   By the way, I don't think I properly understand what you mean by the __pragma__(push) and __pragma__(pop) syntax.
   Would this be a way to handle nested pragma's?
   What exactly would be pushed and popped?
   And how would this pragma deal with nested activation of itself?