💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Исчисление параметров.

Текст оператора BEGIN процедуры сохраняется в состоянии выполнения как значение процедурного идентификатора. Этот текст может содержать ссылки на формальные параметры. Предположим на момент, что переменные с таким же идентификатором, что и формальные параметры используются как фактические параметры при вызове оператора процедуры. Тогда определение для простых процедур может дать верный результат. Например:

PROGRAM Sample(INPUT, OUTPUT);

VAR

Vin: CHAR;

PROCEDURE Bump(VAR Vin: CHAR);

BEGIN {Bump}

IF Vin = ‘A’

THEN

Vin: = ‘B’
END; {Bump}

BEGIN {Sample}

Vin: = ’Q’;

Bump(Vin)

END. {Sample}

PROCEDURE Bump … END (s)

= s È {< †Bump†, †BEGIN IF Vin = ‘A’ THEN Vin: = ‘B’ END†> }

т.е. простое определение даст

Bump(Vin) (s) = s(Bump) (s) = BEGIN IF Vin = ‘A’ THEN Vin: = ‘B’ END (s)

что является корректным значением.

Когда функция частного значения вычисляется отдельно, только исходя из декларации, идентификаторы параметров появляются в результатах. В процедуре Bump

IF Vin = ‘A’ THEN Vin: = ‘B’ = (Vin = ‘A’ -> Vin: = ‘B’) | ()

идентификатор Vin является параметром функции значения, в математическом смысле.

Формальные и фактические параметры не всегда являются одним и тем же, но такое определение могло бы работать, когда при использовании значения текста процедуры он будет иметь фактические параметры, вставленные вместо формальных. То есть, если в приведенном выше примере вызов процедурного оператора выглядел бы как

Bumo(DiffV)

где фактический параметр DiffV предположительно соответственно объявлен как CHAR, тогда значение могло быть получено вставкой DiffV везде в тексте Bump, где встречаетcя Vin. Таким образом,

Bumo(DiffV) = BEGIN IF DiffV = ‘A’ THEN DiffV: = ‘B’ END

В общем случае, если P – идентификатор процедуры, и его объявление имеет формальный параметр X, тогда для фактического параметра Y, определим

P (Y) (s) = s (P) _{X< -Y} (s)

где X < - Y означает, что внутри s(P) каждое вхождение X заменяется на Y. Обобщение до более чем одного параметра очевидно: идентификатор каждого фактического параметра заменяет соответствующий идентификатор формального параметра.

Значение оператора процедуры Bump также может быть получено из параметризованного условного присваивания заменой формального параметра на фактический. Т.е.

Bump(DiffV) = (Vin = ‘A’ -> Vin: = ‘B’) _{Vin < -DiffV} | ()

= (DiffV = ‘A’ -> DiffV: = ‘B’) | ()

Но тут есть неуловимый изъян при выполнении подстановки в общем случае. Может так случиться, что путаница в идентификаторах может дать неправильное значение. Например, программа

PROGRAM Alias(INPUT, OUTPUT);

VAR

One, Two: CHAR;

PROCEDURE SwitchThese2(VAR V1, V2, Temp: CHAR);

{ V1, V2, Temp: = V2, V1, V1 }

BEGIN { SwitchThese2}

Temp: = V1;

V1: = V2;

V2: = Temp

END; {SwitchThese2}

BEGIN {Alias }

SwitchThese2(One, Two, Two);

END. {Alias}

имеет

SwitchThese2(One, Two, Two) = Two: = One; One: = Two, Two: = Two; = (Two: = One)

Но замена в условном присваивании полученного из раздела объявлений дает неправильный результат.

(Two, Two, One): = (Two, One: = One, Two)

Сложность с именами параметров называется «Алиасинг», потому что один фактический идентификатор имеет два формальных имени, в пример Two имеет два различных имени V2 и Temp.

Если происходит Алиасинг и параметризованное определение дает неверные результаты, обычно это значит, что процедура была написана не очень аккуратно и она выдает непредусмотренный результат.

В вышеприведенном примере программист, возможно, не рассмотрел случай, когда временная переменная была та же, что и одна из тех, значения которых обменивались. Он не предусмотрел другую и не предупредил потенциальных пользователей. Комментарии вида

{Фактические параметры должны быть различными идетификаторами}

могли бы быть полезными.

Без алиасинга, можно безопасно вычислить функцию частного значения процедуры и подставить фактические параметры в результат. Когда это случается, тем не менее, определение может быть использовано напрямую, копируя фактический параметр до вычисления функции частного значения.