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

Feature request: result variables in {EX} statements #81

Open
RieksJ opened this issue Jan 15, 2019 · 1 comment
Open

Feature request: result variables in {EX} statements #81

RieksJ opened this issue Jan 15, 2019 · 1 comment
Assignees

Comments

@RieksJ
Copy link
Contributor

RieksJ commented Jan 15, 2019

Currently, we use the text _NEW in violation statements to refer to the atom that was created by the InsAtom function. This way of working prevents one from creating multiple atoms in a single VIOLATION statement and create a link between such atoms.

More general, we see the need for (user-defined) functions where the result is to become an atom in a pair that is to be InsPaired in some relation. An example might be the computation of a hash over an OBJECT.

This ticket suggests syntax and semantics for this, as follows, that extends the {EX} syntax, which currently is {EX} <function>;<arg1>;<arg2>; ... ;<argn>, to the following:

{EX} _$<varname> = <function>;<arg1>;<arg2>; ... ;<argn>

where <varname> is an arbitrary text (consisting of alphanumeric characters) representing the variable in which function will leave its result. The scope of <varname> is the VIOLATION statement in which it is used. Here is an example of what a VIOLATION might look like in which two atoms of type SomeConcept are created and linked in the relation scPair [ SomeConcept * SomeConcept ] [SYM]

VIOLATION (TXT "{EX} _$newSC1 = InsAtom;SomeConcept"
          ,TXT "{EX} _$newSC2 = InsAtom;SomeConcept
          ,TXT "{EX} InsPair;scPair;SomeConcept;_$newSC1;SomeConcept;_$newSC2
          ,TXT "{EX} InsPair;scPair;SomeConcept;_$newSC2;SomeConcept;_$newSC1
          )

The reason for keeping _ in this proposal is that it reduces the likelihood of ambiguous interpretation of texts in which $ appears (similar to why we sometimes use _; as separator). Specification of the _; separator remains as it is now, i.e. it should be specified immediately behind the {EX} (as in {EX}_;.

@hanjoosten
Copy link
Member

Related to AmpersandTarski/Ampersand#800

@Michiel-s Michiel-s transferred this issue from AmpersandTarski/Ampersand Nov 13, 2021
Michiel-s pushed a commit that referenced this issue Jul 9, 2023
alignment fix for atomic object components
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

3 participants