Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REQ] Rework logic syntax #31

Open
mhatzl opened this issue Jun 3, 2023 · 5 comments
Open

[REQ] Rework logic syntax #31

mhatzl opened this issue Jun 3, 2023 · 5 comments

Comments

@mhatzl
Copy link
Contributor

mhatzl commented Jun 3, 2023

The current logic syntax has this strange interplay between parameters and body content.
Instead, it would be better to encapsulate Unimarkup content if used as parameter.
e.g.

{$macro my_macro(param1: heading := [[# Default heading]]): heading := [[
	{$param1} in some section
]]}

{$macro add_one(param1: int): int := param1 + 1}

{$if my_value = 1 [[
	Content One
]] else if my_value = 2 [[
	Content Two
]] else [[
	Content {$my_value}
]]}
@mhatzl
Copy link
Contributor Author

mhatzl commented Aug 19, 2023

There should also be no differentiation between memorables and macros.
Meaning both should start with {$.

@mhatzl
Copy link
Contributor Author

mhatzl commented Aug 19, 2023

If a macro is called, it should also be either using named parameters, or positional parameters.
Mixing them just creates very complex rules and hard to read content.

@mhatzl
Copy link
Contributor Author

mhatzl commented Aug 19, 2023

The return type of a macro should be set after a -> arrow, because it resembles similarity to functions.
Functions in scientific fields are often described using a x b -> c, with c being the result.

It also helps to better separate the return type from parameters, and Rust has a similar syntax.

Example:

{$macro my_macro(param1: int) -> int :=
  param1 + 2
}

@mhatzl
Copy link
Contributor Author

mhatzl commented Aug 19, 2023

Because Unimarkup syntax is now only considered inside [[ ]], it is possible to use { } for scoping and not be taken as attribute blocks. This makes it easier to create if/else-statements that have no Unimarkup content.

Example:

{$if my_value = 1 {
  my_value += 1
} else if my_value = 2 {
  my_value += 2
} else {	
  my_value := 1
}}

Note: Commets should still work inside non-Unimarkup logic context using ;;

It should be possible to set [[ ]] directly instead of { } to prevent unneeded scoping.

If possible, it should not be required to use ; to separate statements.
In this case it should also not be allowed at all to prevent style conflicts.

@mhatzl
Copy link
Contributor Author

mhatzl commented Aug 19, 2023

Maybe instead of [[ ]], using {[ ]} would make it possible to use { } if no markup is set, and otherwise use {[ ]}.
{[ ]} is also better to differentiate from text blocks/boxes. because brackets are surrounded by curly braces.

Maybe even enforce that no space is between bracket and curly braces?
Feedback about readability is needed here.

Example:

{$macro my_macro(param1: heading := [[# Default heading]]) -> heading {[
  {$param1} in some section
]}}

{$macro add_one(param1: int) -> int {
  param1 + 1
}}

{$if my_value = 1 {[
  Content One
]} else if my_value = 2 {[
  Content Two
]} else {[
  Content {$my_value}
]}}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant