Feature Proposal: Formalise and simplify the programming language


My incorrect assumption that I could do local valiables ala UseOfSetInsideIncludedSections and UseOfSetInsideIncludedSectionsTranscluded, and then developments like ParameterizedVariables and PreferenceValuesInDifferentContexts and

All make me think we need to consolidate things into a language, rather than solving the little impedances.

75% of this formalisation is documentation - it has not kept pace with the additions of the last 6-10 years.

the other 25% is to complete missing corners, and find places we've forgotten - including:
  1. PreferenceValuesInDifferentContexts
  2. SettingAndGettingVariablesUsingMacros
  3. dealing with the mess of UseOfSetInsideIncludedSections, UseOfLocalInsideIncludedSections, UseOfSetInsideIncludedSectionsTranscluded and UseOfSetInsideIncludedSectionsTranscluded
  4. DeprecateTheTmplLanguage

Description and Documentation

enhance INCLUDE & SECTIONS into functions

I want local variables to allow me to do both defaulting and calculations before rendering a result from a SECTION.

using the * Set and * Local syntax could work, but doing so makes a mess (both functionally and rendering-wise).

using the PreferenceSettings method is better, but fails to allow us to re-use a result

Option1: add 'core' parameters to SECTION declarations

so what if we use the STARTSECTION and ENDSECTION macro's to do pre and post result evaluation

%STARTSECTION{"name" LOCALVAR="%IF{"$WIKINAME ='guest'" then="hide" else="I don't know"}%"}%
this is the 'return' value using %LOCALVAR%
more stuff, and then another use of %LOCALVAR%
%STOPSECTION{"name" SOMETHING="%CALC{$SET('someresult', %LOCALVAR%)}%"}%

(I'm using CALC as I don't want to block based on SettingAndGettingVariablesUsingMacros - if that can be implemented...)

I'd like to go further - somehow making an included SECTION's topic scope be similar to a class - somehow allowing us to have a topic local scope that all the SECTIONs in the topic could share

Option2: levarage Preference Parameters and scope based accessors.

PreferenceValuesInDifferentContexts might allow us to do soemthingl like:

the topic where the 'function' is called:
%NAMEFUNCTION{scope="FunctionDefinitionTopic" OTHERINPUT="%SEARCH{.... format="$topic" separator=","}%"}%

(FunctionDefinitionTopic) the topic where the function is defined:
   * Set NAMEFUNCTION = %INCLUDE{"%WEB%.%TOPIC%" section="name" LOCALVAR="%IF{"$WIKINAME ='guest'" then="hide" else="I don't know"}%" OTHERINPUT="%OTHERINPUT{default="somevalue"}%"}%

this is the 'return' value using %LOCALVAR%
more stuff, and then another use of %LOCALVAR%
later we use %OTHERINPUT% too %CALC{$SET('someresult', %LOCALVAR%)}%
Then we use %OTHERINPUT% again - perhaps as a parameter to another FUNCTION! 
%SUMMARYFUNCTION{scope="FunctionDefinitionTopic" OTHERINPUT="%OTHERINPUT%"}%
%STOPSECTION{"name" }%

(again - %SET and %CALC are similarish)

The neat thing about this, is that the SEARCH in OTHERINPUT would be evaluated once even though its used at least 3 times (we don't know how complicated SUMMARYFUNCTION is...) whereas the LOCALVAR IF (if i understand Preferences correctly) will be called multiple times..



Use ParametarisedSet to simplify SSP delayed using INCLUDE and verbatim section (atm works only in same topic)

%STARTSECTION{"seti"}%%CALC{"$SET(%name%, %value%)"}%%ENDSECTION{"seti"}%
---++ use ParametarisedSet to simplify SSP delayed using INCLUDE and verbatim section (atm works only in same topic)

%STARTSECTION{"seti"}%%CALC{"$SET(%name%, %value%)"}%%ENDSECTION{"seti"}%
   * Set SETI = %INCLUDE{"%TOPIC%" section="seti" name="%DEFAULT%" value="%value%"}%
   * Set GETI = %INCLUDE{"%TOPIC%" section="geti" name="%DEFAULT%"}%

   * simple = %GETI{"pseti"}%
   * simple+1 = %SETI{"pseti" value="1"}% = %GETI{"pseti"}%
   * simple+1 = %SETI{"pseti" value="2"}% = %GETI{"pseti"}%
   * simple+1 = %SETI{"pseti" value="3"}% = %GETI{"pseti"}%
  • simple =
  • simple+1 = = 1
  • simple+1 = = 2
  • simple+1 = = 3




-- Contributors: SvenDowideit - 19 Apr 2012


ok - I'm slowly working on this - any feedback I'll try to address and hack into things as i go

On of the reasons why I'm playing with this, is that imo we have too many almost overlapping rush job syntaxes that almost but not quite do the same thing - parameatrised perfs, INCLUDE sections, TMPL language, SpreadSheet, etc that I wonder if we can replace all that complexity with on simpler more fully defined approach

(and then define legacy implementations to support the existing base)

-- SvenDowideit - 20 Apr 2012

Everything is already there to implement local variables

Have a look at Foswiki::Prefs:Stack. It allows to restore a stack as it was at some former point in time. That's what normal programming languages do: they call some restoreStack() to revert any %SET inside the local scope.

So %INCLUDE could do that implicitly.

Only thing required is some means to actually set variables: that's why I proposed %SET in SettingAndGettingVariablesUsingMacros

Variables set via %SET are already local to an %INCLUDEd section. See the tests at SettingAndGettingVariablesUsingMacros.

-- MichaelDaum - 20 Apr 2012

implementation is the easy bit - whats hard is improving and consolidating the language.

-- SvenDowideit - 20 Apr 2012

local scope is not the entire reason that I started exploring this - There's more.

right now, we have a non-transcludable way to avoid repeating ourselves - putting expressions into the default of parmaretarised preferences. This thus does not carry forward to INCLUDE or TMPL based applications. Local scope %SET's or *Set's is one way, another is to extend the parametarised defaulting to SECTION definitions

we also don't have a way to import a group of settings - for example, the 12 settings that need to be cut&pasted from PatternSkin themes to the SitePreferences topic - unmaintainable - if we fix something by adding a new setting to the theme, the upgrading admin has no idea they need to do something - so something like INCLUDE{"" import="settings" or import="sections" ....

-- SvenDowideit - 22 Apr 2012

Topic revision: r8 - 22 Apr 2012, SvenDowideit
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy