How do i read in pascal a string and an integer in the same line like the C's scanf("%s %d", str, &n); version?
I am sorry, but I am pretty sure there is no way. You must read them separated.
Pascal does not have an equivilent of C's ...scanf() functions. You will have to either find a third-party implementation, write your own implementation, or just parse the string directly.
If from stdin:
read(s); read(i);
If not, then you are out of luck for Borland's Pascal variants. Free Pascal (2.4+) inherited a variant
from Apple(Standard Pascal derivative) variants that takes input from a string:
readstr(inputstr,s,i);
IIRC this is an Extended Pascal standard procedure that is commonly implemented by standard Pascal variants too, since it is basically a variant of the standard Pascal readln from input.
Related
Does Rust provide a way to decode a single character (unicode-scalar-value to be exact) from a &[u8], which may be multiple bytes, returning a single USV?
Something like GLib's g_utf8_get_char & g_utf8_next_char:
// Example of what glib's functions might look like once ported to Rust.
let i = 0;
while i < slice.len() {
let unicode_char = g_utf8_get_char(&slice[i..]);
// do something with the unicode character
funcion(unicode_char);
// move onto the next.
i += g_utf8_next_char(&slice[i..]);
}
Short of porting parts of the GLib API to Rust, does Rust provide a way to do this, besides some trial & error calls to from_utf8 which stop once the second character is reached?
See GLib's code.
No, there is no such functionality publicly exposed in the Rust standard library as of Rust 1.14.
And neither should there be. Rust doesn't believe in a gigantic standard library. Crates are trivial to use and prevent people from rewriting code. Many people have an incorrect opinion (yeah, that's right: an opinion is incorrect) that using dependencies makes their program weaker.
Anything put in the standard library has to be maintained forever. There are zero plans for a Rust 2.0 that would break backwards compatibility. Python is the normal example here, with a multitude of "get data from a URL" parts of the standard library that are all redundant and deprecated now. The Python maintainers have to waste time keeping those working, instead of advancing the language.
Third-party crates allow things to be created, evolve, and die without burdening the entire language.
You can convert a byte slice (&[u8]) into a string slice (&str) by using str::from_utf8 (note that this validates that the whole byte slice is valid UTF-8). You can then use the chars() iterator on the string slice to iterate on each character (char) in the string.
I have a pascal program which is compiled using Sun pascal 2.1, and I want to compile it by fpc now, but I got in some trouble. Reset procedure is used in that program but
Sun Pascal's reset: reset(file,filename), where filename is a string(See Sun Pascal 3.0.2 Reference Manual);
while FPC's reset:
procedure Reset(
var f: file;
l: LongInt
);(http://www.freepascal.org/docs-html/rtl/system/reset.html), so I got "incompatible type" error.
In my case, reset's 2nd parameter is an array of char, is it OK to just change it to reset(file, sizeof(array)), or should I choose anther compiler, like gpc, in which I found the 2nd parameter of reset is also string.
Start here:
http://wiki.freepascal.org/File_Handling_In_Pascal
But I second the motion to use more modern ways with streams and/or Stringlists.
An alternatives is Modern Pascal's CLI (www.ModernPascal.com). I wrote it to migrate Apple Pascal, and old Turbo Pascal to work on modern platforms. I support 99% of the older syntax, along with Web, dBase, etc. (I port legacy solutions to Linux, Mac, etc. this way).
In Pascal it is possible to declare union types:
AnimalType = (Dog, Cat);
Animal = record
name: string;
case myType: AnimalType of
Dog: (weight: Integer);
Cat: (age: Integer);
end;
However, it is easy to violate the contract of case:
var
a: Animal;
begin
a.name := 'Kittie';
a.myType := Cat;
a.weight := 10; // There is no weight for cats!
writeln(a.age); // Prints 10
end.
There is a semantic error in this example, but the compiler typechecks it successfully. Also, there is no error at the runtime.
So, does the case block exist only for the documentation purposes?
The short answer to your question is, "no case blocks in variant records are not there only for documentation purposes". I say this because although the Pascal implementation you are using did not detect the fact that the program as accessing an inactive variant, other implementation do detect this error.
The long answer to your question is as follows.
Many people who are just learning Pascal don't realize that there are two major flavours of the Pascal language. There is ISO 7185 Standard Pascal (or just Standard Pascal for short) and there is Turbo/Borland Pascal (the most popular variant). So let me give you two answers to your question "So, does the case block exist only for the documentation purposes"?
The Standard Pascal Answer
Standard Pascal defines an error as "A violation by a program of the requirements of this International Standard that a processor is permitted to leave undetected". So yes, the program you have given does contain an error and yes the processor (i.e. Pascal implementation) you are using does not detect it, but other implementation will detect it, so no the case block in variant records actually has a functional purpose.
The Turbo/Borland Answer
As far as the Turbo/Borland Pascal flavours go, I don't know if none of them will detect this error, but even if none of them do, it's probably better to think of this as an error that they do not detect rather than as something for documentation purposes only. Saying something is for documentation purposes only, sounds to me like saying it was never intended to be functional.
A union makes it possible to give a variable multiple types. In your example, weight and age are stored at the same location in memory.
If you want a 'typesafe union', you should use inheritance.
I'm teaching myself Pascal and thought mixing Pascal with Japanese sounded like a really good idea the other day, but it appears Pascal only accepts Japanese characters some of the time, and I don't really know why it accepts them at all. Is there something I need to include to allow writing in Japanese with Free Pascal?
You don't mention which Pascal, and you don't describe acceptance. As identifier or literals in source code, on standard input, as literal?
Delphi D2009 and higher support unicode identifiers in their utf8 sources.
Free Pascal hasn't implemented this yet. It does allow utf8 source encoding though, and thus unicode literals.
The use of symbol literals is not immediately clear from what I've read up on Scala. Would anyone care to share some real world uses?
Is there a particular Java idiom being covered by symbol literals? What languages have similar constructs? I'm coming from a Python background and not sure there's anything analogous in that language.
What would motivate me to use 'HelloWorld vs "HelloWorld"?
Thanks
In Java terms, symbols are interned strings. This means, for example, that reference equality comparison (eq in Scala and == in Java) gives the same result as normal equality comparison (== in Scala and equals in Java): 'abcd eq 'abcd will return true, while "abcd" eq "abcd" might not, depending on JVM's whims (well, it should for literals, but not for strings created dynamically in general).
Other languages which use symbols are Lisp (which uses 'abcd like Scala), Ruby (:abcd), Erlang and Prolog (abcd; they are called atoms instead of symbols).
I would use a symbol when I don't care about the structure of a string and use it purely as a name for something. For example, if I have a database table representing CDs, which includes a column named "price", I don't care that the second character in "price" is "r", or about concatenating column names; so a database library in Scala could reasonably use symbols for table and column names.
If you have plain strings representing say method names in code, that perhaps get passed around, you're not quite conveying things appropriately. This is sort of the Data/Code boundary issue, it's not always easy to the draw the line, but if we were to say that in that example those method names are more code than they are data, then we want something to clearly identify that.
A Symbol Literal comes into play where it clearly differentiates just any old string data with a construct being used in the code. It's just really there where you want to indicate, this isn't just some string data, but in fact in some way part of the code. The idea being things like your IDE would highlight it differently, and given the tooling, you could refactor on those, rather than doing text search/replace.
This link discusses it fairly well.
Note: Symbols will be deprecated and then removed in Scala 3 (dotty).
Reference: http://dotty.epfl.ch/docs/reference/dropped-features/symlits.html
Because of this, I personally recommend not using Symbols anymore (at least in new scala code). As the dotty documentation states:
Symbol literals are no longer supported
it is recommended to use a plain string literal [...] instead
Python mantains an internal global table of "interned strings" with the names of all variables, functions, modules, etc. With this table, the interpreter can make faster searchs and optimizations. You can force this process with the intern function (sys.intern in python3).
Also, Java and Scala automatically use "interned strings" for faster searchs. With scala, you can use the intern method to force the intern of a string, but this process don't works with all strings. Symbols benefit from being guaranteed to be interned, so a single reference equality check is both sufficient to prove equality or inequality.