Feature Proposal: Formalise and simplify the programming language

Motivation

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

eg:

%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"}%"}%

%STARTSECTION{"name"}%
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..

Examples

MichaelDaum:

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"}%
%STARTSECTION{"geti"}%%CALC{"$GET(%name%)"}%%ENDSECTION{"geti"}%
---++ use ParametarisedSet to simplify SSP delayed using INCLUDE and verbatim section (atm works only in same topic)

<verbatim>
%STARTSECTION{"seti"}%%CALC{"$SET(%name%, %value%)"}%%ENDSECTION{"seti"}%
%STARTSECTION{"geti"}%%CALC{"$GET(%name%)"}%%ENDSECTION{"geti"}%
</verbatim>
   * 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

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenDowideit - 19 Apr 2012

Discussion

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

Commenting is disabled while not logged in