The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce anything. Or is f_float sufficiently different from a normal float?
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
begin
x := %f_float 1.5;
writeln(x);
end.
$ pas zzz
$ link zzz
$ run zzz
1.50000E+00
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce >anything. Or is f_float sufficiently different from a normal float?
In article <v8lpj0$ems$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce
anything. Or is f_float sufficiently different from a normal float?
Just to touch on the Pascal point itself, one of that language's
hallmarks is almost excessive rigidity in how it treats types.
While integer->float conversions are implicit, the opposite is
not. I think that the general rule is that when a type "widens"
conversion is implicitly ok (so in mathematics, when the
integers are a proper subset of the reals, so every integer is
already a real, and implicit conversion from int to real is
intuitive, even though representations on physical computers
aren't quite so neat for implementation reasons), but when types
narrow, as in when going from real to int, one must exercise
more caution.
An old annoyance about Pascal was that the size of an array is
part of it's type, which makes writing functions and procedures
that work across differently sized arrays challenging.
Interesting, this has become du jour again in modern languages,
but those tend to provide access to a `slice` type that provides
a window onto the underly array, and implicitly encodes a
length (and usually a "capacity"). This makes working with
arrays in such languages very convenient.
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce anything. Or is f_float sufficiently different from a normal float?
--scott
On 8/4/2024 8:22 AM, Dan Cross wrote:
An old annoyance about Pascal was that the size of an array is part of
it's type, which makes writing functions and procedures that work
across differently sized arrays challenging.
In original Wirth Pascal. Most implementations has solutions.
Why didn't I do this?
I did think about it, but what about more complicated expression.
x := 1.5 * 1.5;
Is that multiply an IEEE S_float multiply or VAX F_float multiply?
Logically, it would have been an IEEE S_float multiply and then
converted to VAX F_float. I didn't think it was a problem that needed
to be solved.
On Sun, 4 Aug 2024 10:51:20 -0400, Arne Vajhøj wrote:
On 8/4/2024 8:22 AM, Dan Cross wrote:
An old annoyance about Pascal was that the size of an array is part of
it's type, which makes writing functions and procedures that work
across differently sized arrays challenging.
In original Wirth Pascal. Most implementations has solutions.
ISO Pascal added “conformant arrays”, where the array bounds were passed as separate arguments.
I don’t think you ever saw these on the micros, which persisted with their UCSD-Pascal derivatives. But you did on the
bigger machines.
On 8/4/2024 8:22 AM, Dan Cross wrote:
In article <v8lpj0$ems$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce
anything. Or is f_float sufficiently different from a normal float?
Just to touch on the Pascal point itself, one of that language's
hallmarks is almost excessive rigidity in how it treats types.
Ada is even more strict.
While integer->float conversions are implicit, the opposite is
not. I think that the general rule is that when a type "widens"
conversion is implicitly ok (so in mathematics, when the
integers are a proper subset of the reals, so every integer is
already a real, and implicit conversion from int to real is
intuitive, even though representations on physical computers
aren't quite so neat for implementation reasons), but when types
narrow, as in when going from real to int, one must exercise
more caution.
Such a restriction is rather common today.
An old annoyance about Pascal was that the size of an array is
part of it's type, which makes writing functions and procedures
that work across differently sized arrays challenging.
In original Wirth Pascal. Most implementations has solutions.
[snip]
Interesting, this has become du jour again in modern languages,
but those tend to provide access to a `slice` type that provides
a window onto the underly array, and implicitly encodes a
length (and usually a "capacity"). This makes working with
arrays in such languages very convenient.
Different people may have different opinions on what is a modern
language.
But a lot of the widely used static typed languages does not
have any problems with arrays of different lengths as they
are treated as objects.
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:22 AM, Dan Cross wrote:
Interesting, this has become du jour again in modern languages,
but those tend to provide access to a `slice` type that provides
a window onto the underly array, and implicitly encodes a
length (and usually a "capacity"). This makes working with
arrays in such languages very convenient.
Different people may have different opinions on what is a modern
language.
Designed in this century.
But a lot of the widely used static typed languages does not
have any problems with arrays of different lengths as they
are treated as objects.
Like I said, modern languages make this a solved problem.
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
Java arrays are more like the aforementioned slices.
On 8/4/2024 8:09 PM, Dan Cross wrote:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:22 AM, Dan Cross wrote:
Interesting, this has become du jour again in modern languages,
but those tend to provide access to a `slice` type that provides
a window onto the underly array, and implicitly encodes a
length (and usually a "capacity"). This makes working with
arrays in such languages very convenient.
Different people may have different opinions on what is a modern
language.
Designed in this century.
That rules out Java.
But there are still languages like C#, Scala and Kotlin.
But a lot of the widely used static typed languages does not
have any problems with arrays of different lengths as they
are treated as objects.
Like I said, modern languages make this a solved problem.
But C#, Scala and Kotlin also just allows for passing any length
arrays to methods taking an array.
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
Java arrays are more like the aforementioned slices.
I don't think so.
Java does not have anything like slices.
C# does.
C# Span is similar to slices. But C# Span and C# array are far from
the same.
On 8/4/2024 8:09 PM, Dan Cross wrote:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:22 AM, Dan Cross wrote:
In article <v8lpj0$ems$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce >>>>> anything. Or is f_float sufficiently different from a normal float?
Just to touch on the Pascal point itself, one of that language's
hallmarks is almost excessive rigidity in how it treats types.
Ada is even more strict.
Rust even more so.
There may be different definitions of strict.
But my take (apropos arrays) is:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:22 AM, Dan Cross wrote:
In article <v8lpj0$ems$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
In article <v8hn3m$3aviu$1@gwaiyur.mb-net.net>,
Uli Bellgardt <UliBellgardtsSpamSink@online.de> wrote:
The value 1.5 should be an f_float value as well:
$ type zzz.pas
program z(input,output);
var
x : f_float;
This seems very strange to me... Pascal isn't supposed to have such
strong typing, is it? I don't remember ever having to manually coerce >>>> anything. Or is f_float sufficiently different from a normal float?
Just to touch on the Pascal point itself, one of that language's
hallmarks is almost excessive rigidity in how it treats types.
Ada is even more strict.
Rust even more so.
On 8/4/2024 6:19 PM, Lawrence D'Oliveiro wrote:
ISO Pascal added “conformant arrays”, where the array bounds were
passed as separate arguments.
I thought that on VMS this was done by passing an array descriptor and
not by pass extra arguments. dsc$descriptor_a etc..
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
Different people may have different opinions on what is a modern
language.
Designed in this century.
That rules out Java.
On Sun, 4 Aug 2024 10:51:20 -0400, Arne Vajhøj wrote:Yes, the preface to ISO 10206 has lots of project history and why we
On 8/4/2024 8:22 AM, Dan Cross wrote:
An old annoyance about Pascal was that the size of an array is part of
it's type, which makes writing functions and procedures that work
across differently sized arrays challenging.
In original Wirth Pascal. Most implementations has solutions.
ISO Pascal added “conformant arrays”, where the array bounds were passed as separate arguments. I don’t think you ever saw these on the micros, which persisted with their UCSD-Pascal derivatives. But you did on the
bigger machines.
Also I didn’t know before, but there is an official spec for “Extended Pascal”, too: ISO 10206.
On 8/4/2024 8:09 PM, Dan Cross wrote:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:22 AM, Dan Cross wrote:
Interesting, this has become du jour again in modern languages,
but those tend to provide access to a `slice` type that provides
a window onto the underly array, and implicitly encodes a
length (and usually a "capacity"). This makes working with
arrays in such languages very convenient.
Different people may have different opinions on what is a modern
language.
Designed in this century.
That rules out Java.
But there are still languages like C#, Scala and Kotlin.
But a lot of the widely used static typed languages does not
have any problems with arrays of different lengths as they
are treated as objects.
Like I said, modern languages make this a solved problem.
But C#, Scala and Kotlin also just allows for passing any length
arrays to methods taking an array.
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
Java arrays are more like the aforementioned slices.
I don't think so.
Java does not have anything like slices.
C# does.
C# Span is similar to slices. But C# Span and C# array are far from
the same.
Arne
Pay attention that despite being designed (or at least brought to
public) in this century, C# originally lacked slices.
On Sun, 4 Aug 2024 21:00:35 -0400
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:09 PM, Dan Cross wrote:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
Java arrays are more like the aforementioned slices.
I don't think so.
Java does not have anything like slices.
C# does.
C# Span is similar to slices. But C# Span and C# array are far from
the same.
Pay attention that despite being designed (or at least brought to
public) in this century, C# originally lacked slices.
They were added relatively recently, in v. 8.0, and referred in c# docs
as "Indices and ranges".
On Mon, 5 Aug 2024 15:34:49 +0300, Michael S wrote:
Pay attention that despite being designed (or at least brought to
public) in this century, C# originally lacked slices.
The whole C♯/Dotnet thing just seems like a corporate vanity project on
the part of Microsoft, after they had their knuckles rapped by Sun over trying to subvert Java. Microsoft themselves will not use Dotnet for
anything important (e.g. Microsoft Office). Their one time trying to do so (Windows Vista) ended in disaster.
In article <v8p87j$9ptm$3@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:09 PM, Dan Cross wrote:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
Java arrays are more like the aforementioned slices.
I don't think so.
Java does not have anything like slices.
An array in Java is a pointer and a length. A slice is a
pointer and a length.
On 8/5/2024 8:34 AM, Michael S wrote:
On Sun, 4 Aug 2024 21:00:35 -0400
C# Span is similar to slices. But C# Span and C# array are far from
the same.
Pay attention that despite being designed (or at least brought to
public) in this century, C# originally lacked slices.
They were added relatively recently, in v. 8.0, and referred in c# docs
as "Indices and ranges".
I thought it was C# 7.2.
On 8/4/2024 5:53 PM, John Reagan wrote:
Why didn't I do this?
I did think about it, but what about more complicated expression.
x := 1.5 * 1.5;
Is that multiply an IEEE S_float multiply or VAX F_float multiply?
Logically, it would have been an IEEE S_float multiply and then
converted to VAX F_float. I didn't think it was a problem that needed
to be solved.
I was sort of expecting literals to be of the type determined by
suffix and compiler switch and that mixed expressions would be
converted similar to various other mixed expressions.
That was not the case.
Probably not worth spending time on "fixing". It must be
an extremely rare case.
Java does not have anything like slices.
But it looks absolutely horrible!
Dates/times? You have to contend with an API that has accumulated so much legacy cruft, that you are left with an old class where every single
member is deprecated, yet the class itself is still needed in the newer- style calls.
Trying to do select/poll? There’s something like 4 different classes and I don’t know how many methods involved.
On 8/7/2024 5:35 PM, Lawrence D'Oliveiro wrote:
Trying to do select/poll? There’s something like 4 different classes
and I don’t know how many methods involved.
There are several ways to do that in Java:
* java.nio
* Netty
* RxJava
* ...
All of them require a bit of documentation reading.
But so does the same problem in languages like C# and C.
And the typical Java application works at a higher level - it asks some framework to listen at a given port and call some code to process
requests.
On 8/4/2024 9:58 PM, Dan Cross wrote:
In article <v8p87j$9ptm$3@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/4/2024 8:09 PM, Dan Cross wrote:
In article <v8o4h8$2ut3$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
Like:
public class FlexArray {
private static void dump(int[] a) {
for(int v : a) {
System.out.printf(" %d", v);
}
System.out.println();
}
public static void main(String[] args) throws Exception {
int[] a1 = { 1 };
int[] a2 = { 1, 2 };
int[] a3 = { 1, 2, 3 };
dump(a1);
dump(a2);
dump(a3);
}
}
Java arrays are more like the aforementioned slices.
I don't think so.
Java does not have anything like slices.
An array in Java is a pointer and a length. A slice is a
pointer and a length.
An array in Java is an object containing data type, array
length and all the elements.
Which is not the same as a structure containing a
pointer to somewhere in another object and a length.
On 8/7/2024 5:35 PM, Lawrence D'Oliveiro wrote:
Dates/times? You have to contend with an API that has accumulated so much
legacy cruft, that you are left with an old class where every single
member is deprecated, yet the class itself is still needed in the newer-
style calls.
That is also one of Roland's pet peeves.
On 2024-08-07, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/7/2024 5:35 PM, Lawrence D'Oliveiro wrote:
Dates/times? You have to contend with an API that has accumulated so much >>> legacy cruft, that you are left with an old class where every single
member is deprecated, yet the class itself is still needed in the newer- >>> style calls.
That is also one of Roland's pet peeves.
Now try parsing JSON using the supplied builtin Java libraries
on Android. :-)
There is a solution but it is not as clean as elsewhere.
On 8/8/2024 8:13 AM, Simon Clubley wrote:
On 2024-08-07, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/7/2024 5:35 PM, Lawrence D'Oliveiro wrote:
Dates/times? You have to contend with an API that has accumulated so
much
legacy cruft, that you are left with an old class where every single
member is deprecated, yet the class itself is still needed in the
newer-
style calls.
That is also one of Roland's pet peeves.
Now try parsing JSON using the supplied builtin Java libraries
on Android. :-)
There is a solution but it is not as clean as elsewhere.
I would use binding instead of parsing.
I have never done anything on Android, but I would
expect both JSON-B and Jackson to work on Android
JSON-B is:
Jsonb b = JsonbBuilder.create();
X o = b.fromJson(jsonstr, X.class);
Jackson is:
ObjectMapper om = new ObjectMapper();
X o = om.readValue(jsonstr, X.class);
It don't get much easier than that.
You can of course ask why it did not become part of standard
Java SE.
For timeline/random reasons JSON-B became part of Java EE
not Java SE.
On 8/8/2024 8:13 AM, Simon Clubley wrote:
On 2024-08-07, Arne Vajhj <arne@vajhoej.dk> wrote:
On 8/7/2024 5:35 PM, Lawrence D'Oliveiro wrote:
Dates/times? You have to contend with an API that has accumulated so much >>>> legacy cruft, that you are left with an old class where every single
member is deprecated, yet the class itself is still needed in the newer- >>>> style calls.
That is also one of Roland's pet peeves.
Now try parsing JSON using the supplied builtin Java libraries
on Android. :-)
There is a solution but it is not as clean as elsewhere.
I would use binding instead of parsing.
I have never done anything on Android, but I would
expect both JSON-B and Jackson to work on Android
JSON-B is:
Jsonb b = JsonbBuilder.create();
X o = b.fromJson(jsonstr, X.class);
Jackson is:
ObjectMapper om = new ObjectMapper();
X o = om.readValue(jsonstr, X.class);
It don't get much easier than that.
GSON is less than 300 KB. From Google. Widely used (Maven lists over
23000 other software depending on it) so not likely to go away.
On 2024-08-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/8/2024 8:13 AM, Simon Clubley wrote:
On 2024-08-07, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/7/2024 5:35 PM, Lawrence D'Oliveiro wrote:
Dates/times? You have to contend with an API that has accumulated so much >>>>> legacy cruft, that you are left with an old class where every single >>>>> member is deprecated, yet the class itself is still needed in the newer- >>>>> style calls.
That is also one of Roland's pet peeves.
Now try parsing JSON using the supplied builtin Java libraries
on Android. :-)
There is a solution but it is not as clean as elsewhere.
I would use binding instead of parsing.
I have never done anything on Android, but I would
expect both JSON-B and Jackson to work on Android
I like to avoid using third-party libraries when possible.
JSON-B is:
Jsonb b = JsonbBuilder.create();
X o = b.fromJson(jsonstr, X.class);
Jackson is:
ObjectMapper om = new ObjectMapper();
X o = om.readValue(jsonstr, X.class);
It don't get much easier than that.
For comparison, here are the two built-in options available on Android
that I know about:
https://developer.android.com/reference/android/util/JsonReader https://developer.android.com/reference/org/json/package-summary
> GSON is less than 300 KB. From Google. Widely used (Maven lists over
> 23000 other software depending on it) so not likely to go away.
https://killedbygoogle.com/
But:
* with 23000 projects depending on it
* no external dependencies
* no need for huge enhancements (JSON is JSON)
then it seems like a pretty safe bet.
I _was_ mostly being hyperbolic, but the fact remains that big G will cheerfully kill off services with (merely) millions of users.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 437 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 192:58:10 |
| Calls: | 9,135 |
| Calls today: | 2 |
| Files: | 13,432 |
| Messages: | 6,035,344 |