SYNTAX ERROR (change nameclass on assignment) in APL - syntax-error

When I try to assign to a name in Dyalog APL, I get one of these error messages:
SYNTAX ERROR: Can't change nameclass on assignment
SYNTAX ERROR: Invalid modified assignment, or an attempt was made to change nameclass on assignment
What exactly does it mean to "change nameclass on assignment", why isn't it allowed, and how can I work around this issue?

What exactly does it mean to "change nameclass on assignment"?
APL distinguishes between syntactic roles, and each role is identified by a number. The ⎕NC function takes one or more names, and returns their Name Class, for example 2 for variable and 3 for function, 4 for operator, and 9 for ref.
As per the assignment documentation:
Re-Assignment
A name that already exists may be assigned a new value if the assignment will not alter its name class, or will change it from 2 to 9 or vice versa. The table of permitted re-assignments is as follows:
Ref
Variable
Function
Operator
Ref
Yes
Yes
Variable
Yes
Yes
Function
Yes
Yes
Operator
Yes
Yes
Why isn't it allowed?
The prohibition against certain re-assignments is necessary to disambiguate when an augmented assignment is performed, or when the value of an assignment is used (whatever is on the right of the assignment arrow is returned as result). For example:
Plus←+
a←100
a Plus←10
a
110
Double←{2×⍵}
Double b←10
20
Without this restriction, it would be impossible to distinguish these cases from parallel assignment:
c d←10
c
10
d
10
How can I work around this issue?
Reusing a name for something entirely different is probably a bad idea in production code, and adoption of a strict naming convention (e.g. mine) is recommended. However, when experimenting in an interactive session (REPL), simply removing the definition of an existing name, opens up its usage for all purposes. The ⎕EX (expunge) system function and the )ERASE system command both do this:
a←10
a←+
SYNTAX ERROR: Can't change nameclass on assignment
a←+
∧
⎕EX'a'
a←+
a←10
SYNTAX ERROR: Invalid modified assignment, or an attempt was made to change nameclass on assignment
a←10
∧
)erase a
a←10

Related

Number of formal parameters is larger than the number of actual parameters

So when I try to compile (activate), the compiler throws this error message:
Different number of parameters in FORM and PERFORM (routine:
CALL_CALCULATE_TAX_ITEM, number of formal parameters: 7, number of
actual parameters: 6)
It refers to the line 169 in the include LJ_1B_NFE_INF3B, where there is this statement:
PERFORM call_calculate_tax_item
USING
ls_rbkpv
ls_drseg
ls_j_lbaa
ls_lfa1
ls_xmlpo
abap_true
CHANGING
et_bapiret2[].
Here is the form code:
FORM call_calculate_tax_item
USING ls_rbkpv TYPE mrm_rbkpv
ls_drseg TYPE mmcr_drseg
ls_j_1baa TYPE j_1baa
ls_lfa1 TYPE lfa1
ls_xmlpo TYPE ty_xmlpo_ext "1843823
lv_get_conditions TYPE flag "2142110
CHANGING et_bapiret2 TYPE bapirettab.
So, it's obvious that there are 7 parameters both in PERFORM and FORM, why does the compiler say that there are only 6 actual parameters?
Thanks and sorry for broken English.
Usually such problems result from a not fully implemented SAP Note or not activating all the changes made by the note at the very same time.
In your case I see that either SAP Note 2142110 is not fully implemented or some of the changes resulting from the implementation of it have not been activated.

Rules for barewords

Barewords can be used at the left hand side of Pair declarations (this is not documented yet, I'm addressing this issue right now, but I want to get everything right). However, I have not found what is and what's not going to be considered a bareword key anywhere.
This seems to work
say (foo'bar-baz => 3); # OUTPUT: «foo'bar-baz => 3␤»
This does not
say (foo-3 => 3); # OUTPUT: «(exit code 1) ===SORRY!=== Error while compiling /tmp/jorTNuKH9V␤Undeclared routine:␤ foo used at line 1␤␤»
So it apparently follows the same syntax as the ordinary identifiers. Is that correct? Am I missing something here?
There are no barewords in Perl 6 in the sense that they exist in Perl 5, and the term isn't used in Perl 6 at all.
There are two cases that we might call a "bare identifier":
An identifier immediately followed by zero or more horizontal whitespace characters (\h*), followed by the characters =>. This takes the identifier on the left as a pair key, and the term parsed after the => as a pair value. This is an entirely syntactic decision; the existence of, for example, a sub or type with that identifier will not have any influence.
An identifier followed by whitespace (or some other statement separator or terminator). If there is already a type of that name, then it is compiled into a reference to the type object. Otherwise, it will always be taken as a sub call. If no sub declaration of that name exists yet, it will be considered a call to a post-declared sub, and an error produced at CHECK-time if a sub with that name isn't later declared.
These two cases are only related in the sense that they are both cases of terms in the Perl 6 grammar, and that they both look to parse an identifier, which follow the standard rules linked in the question. Which wins is determined by Longest Token Matching semantics; the restriction that there may only be horizontal whitespace between the identifier and => exists to make sure that the identifier, whitespace, and => will together be counted as the declarative prefix, and so case 1 will always win over case 2.

How to tell if an identifier is being assigned or referenced? (FLEX/BISON)

So, I'm writing a language using flex/bison and I'm having difficulty with implementing identifiers, specifically when it comes to knowing when you're looking at an assignment or a reference,
for example:
1) A = 1+2
2) B + C (where B and C have already been assigned values)
Example one I can work out by returning an ID token from flex to bison, and just following a grammar that recognizes that 1+2 is an integer expression, putting A into the symbol table, and setting its value.
examples two and three are more difficult for me because: after going through my lexer, what's being returned in ex.2 to bison is "ID PLUS ID" -> I have a grammar that recognizes arithmetic expressions for numerical values, like INT PLUS INT (which would produce an INT), or DOUBLE MINUS INT (which would produce a DOUBLE). if I have "ID PLUS ID", how do I know what type the return value is?
Here's the best idea that I've come up with so far: When tokenizing, every time an ID comes up, I search for its value and type in the symbol table and switch out the ID token with its respective information; for example: while tokenizing, I come across B, which has a regex that matches it as being an ID. I look in my symbol table and see that it has a value of 51.2 and is a DOUBLE. So instead of returning ID, with a value of B to bison, I'm returning DOUBLE with a value of 51.2
I have two different solutions that contradict each other. Here's why: if I want to assign a value to an ID, I would say to my compiler A = 5. In this situation, if I'm using my previously described solution, What I'm going to get after everything is tokenized might be, INT ASGN INT, or STRING ASGN INT, etc... So, in this case, I would use the former solution, as opposed to the latter.
My question would be: what kind of logical device do I use to help my compiler know which solution to use?
NOTE: I didn't think it necessary to post source code to describe my conundrum, but I will if anyone could use it effectively as a reference to help me understand their input on this topic.
Thank you.
The usual way is to have a yacc/bison rule like:
expr: ID { $$ = lookupId($1); }
where the the lookupId function looks up a symbol in the symbol table and returns its type and value (or type and storage location if you're writing a compiler rather than a strict interpreter). Then, your other expr rules don't need to care whether their operands come from constants or symbols or other expressions:
expr: expr '+' expr { $$ = DoAddition($1, $3); }
The function DoAddition takes the types and values (or locations) for its two operands and either adds them, producing a result, or produces code to do the addition at run time.
If possible redesign your language so that the situation is unambiguous. This is why even Javascript has var.
Otherwise you're going to need to disambiguate via semantic rules, for example that the first use of an identifier is its declaration. I don't see what the problem is with your case (2): just generate the appropriate code. If B and C haven't been used yet, a value-reading use like this should be illegal, but that involves you in control flow analysis if taken to the Nth degree of accuracy, so you might prefer to assume initial values of zero.
In any case you can see that it's fundamentally a language design problem rather than a coding problem.

Fortran 95: open statement, status variable: unknown vs. replace

I would like to know what is the different between this statement:
open(unit=11,file="something.TXT",status="unknown"), which is Fortran's default status (i.e., the previous statement is the same as open(unit=11,file="something.TXT")
and this statement:
open(unit=11,file="something.TXT",status="replace")
I have the impression that the unknown status behave exactly as I would expect with replace: if the file doesn't exist, it creates it. If it does exist, then it replaces it.
The Fortran standard lays down that the interpretation of status='unknown' is processor-dependent. That is, your impression is subtly incorrect.
In the draft of the 1995 standard I have at hand this is explained in section 9.3.4.2.
In the draft of the 2003 standard I have at hand this is explained in section 9.4.5.15.

ColdFusion structkey starting with number

Why does this fail:
<CFIF isdefined("URL.3dfile")>...</CFIF>
with following message:
Parameter 1 of function IsDefined, which is now URL.3dfile, must be a syntactically valid variable name.
and this won't:
<CFIF structkeyexists(URL,"3dfile")>...</CFIF>
Is the way it get's parsed not much the same? And .. are variables starting with numbers invalid or aren't they?
Seybsen - variables names should not begin with a number. This is likely a legacy of older non-java version of CF Where a variable was not part of an object.
However, in the java world everything IS an object. This leads to a syntactical nuance. If you are using variable names in dotted notation your var name will likely throw an error. But use it in other ways and it will succeed.
So this sort of syntax works
url['33foo']
But setting a variable name directly - 33foo = true - will not work.
Here's a post with a full explanation.
http://www.coldfusionmuse.com/index.cfm/2005/9/8/isdefined%20vs%20structkeyexists