OSNews

renoX wrote:>>>>>>>>>>>>>
What I find very funny is that they haven't chosen to use a C like syntax for the strings for example.

Frankly what's so good about ("text" nl) instead of "textn"..
<<<<<<<<<<<<<<<<<&l t;<<<<<<<

Actually, the syntax for strings *was* mostly taken from C (rather than, say, the Algol-branch of the language tree). You'll note that HLA strings use quotes while HLA characters use apostrophes (unlike Pascal). You'll also note that HLA automatically concatenates two juxtaposed string constants appearing in the source file, just as C does.

Now as to why HLA doesn't support the C escape sequences, well, this isn't necessary in *assembly language*. You can easily specify the numeric character constants and the assembler will automatically embed those constants directly in the output file. For numeric character constants, I chose to use the Delphi/Turbo Pascal notation, specifically "#" followed by a numeric value. For example, an end of line sequence (under Linux) could be specified by #$a, so you could write something like "Hello World" #$a and HLA would automatically concatenate that character code to the end of the string.

As for the phrase << "Hello World" nl >> just note that there is nothing particularly special about the identifier "nl". It's just an identifier declared in the stdio header file. It happens to expand to the sequence <<#$d #$a>> under Windows and <#$a>> under Linux. IOW, it's a platform-idependent way to specify a newline sequence.

Another place where HLA is different than C with respect to strings is putting a quote within a quoted string. Like Pascal, you double up the quotation marks to get a single quote, e.g.,
"He said ""hello world"" to me"

The *nice* thing about the fact that HLA does *not* use C's escape character sequence syntax is that it is much easier to create such strings to pass on to other (C) programs and functions that *do* want to see these escape sequences. That is, if you really want to pass the string "hello worldn" to some other code, including the backslash and the n (without them being converted to a newline), then HLA's string syntax is far cleaner.

Ultimately, though, this is just one of those syntactical things that an HLA user is supposed to learn in order to write HLA code. Syntactically, *no* part of HLA exactly matches some part of any other language. That was never the point of HLA. HLA was designed to make it easy for someone who knows an imperative language such as C/C++/C#/Java or Pascal/Delphi/Kylix/Modula-2/Ada to quickly get up to speed in assembly language. The point wasn't to provide an assembler whose syntax *exactly* matches one of these other HLLs, but to provide statements in the language that have semantics similar to statements in those HLLs. IOW, the goal was to make learning assembly language, after learning an imperative HLL, about as easy as learning a second imperative language. In the classroom setting, it has been quite successfully used for that purpose.

To address the question: <<Frankly what's so good about ("text" nl) instead of "textn"..>>, I would ask

"What so good about [cout << "text" << endl]?"
Different language, different approach is all.


RenoX also wrote:>>>>>>>>>>>>>
Well being heavily derived from a dead language is not a good idea in my book.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<
As others have pointed out, Pascal is hardly dead. Even if it were, the programming language constructs found in the Algol branch of the programming language tree are generally considered to be superior (in terms of readability) than those on the C side.

>>>>>>>>>
Even universities are ditching Pascal and going to Java for teaching computer science, so students won't even know Pascal to help them.
<<<<<<<<<
Simply knowing C or Java isn't going to be sufficient to learn assembly language programming. HLA succeeds as a teaching tool not because of syntactical similarities, but because of *programming paradigm* similarities. A student who has learned how to solve problems using an IF/ELSE or WHILE statement in any of these imperative HLLs will have a pretty good idea how to solve those same types of problems in any other language supporting these statements.

A big problem with (traditional) assembly language is that you don't have these statements available to you. Instead, you have to learn how to synthesize them using comparisons, conditional jumps, and other techniques. There is a steep learning curve a beginning assembly language student faces when moving from a HLL to assembly. The point of a high-level assembler, such as HLA, is to allow students to employ the HLL programming paradigm early on in their education so that they can begin writing code immediately. If they don't know how to use compares and branches, but they do know how to use IFs and WHILEs, then provide them with an assembler that lets them use IFs and WHILEs during the first few weeks of their course (while they master other topics).

Of course, no student should complete an assembly language course thinking that IF and WHILE statements are actually assembly language. Certainly, before the course is over, they need to learn about comparisons and conditional branches. But having those HLL-like statements available for use in the early parts of the course saves the students from having to "learn everything all at once" and allows the instructor to spread out the material over the quarter. IOW, a high-level assembler like HLA allows the student to leverage their existing HLL knowledge early in the course so they don't have to learn everything from scratch before being able to test out ideas in assembly language.

Whether those students know Pascal, C/C++/C#, Java, or any of a couple dozen other imperative programming languages, chances are pretty good they'll know what to do with an IF or WHILE statement, and after taking a few minutes (or even hours) to learn the HLA syntax for these statements, they'll be able to use them. OTOH, changing programming paradigms (e.g., to cmp/Jcc) is a *very* time-consuming process.


Cheers,
Randy Hyde