Nice, it's easier to read the Voynich manuscript.
@treeform, that's the way it's usually done, but the idea is to prevent
redundant naming for those entities that represent the same. If either the
labels or the field names can be duplicated, then the code from then forward is
cleaner and less cryptic.
Here how it works in Pascal, for the 1D, 2
Exactly, that was the RFC I read, I was looking for it as a post.
Thanks @araq, how about allowing that pragma {.fieldChecks: on|off.} in the
prog header, so that it would only affect its own scope?
Thanks @solo989 for pointing it up, that cleared some of my doubts about what
to uncheck.
Thanks @mashingan. My intention is to bring up a point (that popped up in an
earlier post that I can't find) in which @araq and others that I can't
remember, were talking about flexing out the restrictions, to allow duplication
of either field labels or field names, when used in the case discrim
It starts to make sense when you think about it.
1) The operator div and mod have to be consistent with each other in such a way
that: if d = a div b, and m = a mod b, then a = d*b + m.
2) By the other hand, div needs to be consistent with the sign in a division,
so if d = a div b and only one
This is a case in which it would be desirable that some fields in object
variants could share the name and hence, its value. In the following example,
my first two attempts: Coordinates_1 and Coordinates_2, were typed intuitively,
but failed to compile one after another due to the restrictions i
It sounds reasonable that the discriminator of an object variant should be kept
invariable to keep the object's data structure safe; I found, however, some
scenarios in which it can be done. One way was to use the compiler directive
--fieldChecks:off. I also attempted the same, but using the pra
Not sure if this helps, but here an example:
The Complex type (at the Standard Math/complex pure library) used to be a
tuple, and was upgraded to a generic object. There are two possible
representations of a complex number: rectangular and polar. The library and
most functions are based on the
Congrats for 1.0 milestone. I'm glad to see that the Complex type is not a
tuple any longer but an object and allows generics like the Rational type. That
makes more sense now. Great job.
I'm learning some features of the language, and I don't understand why in the
Standard Library, the Complex type would be defined as a tuple, when the
Rational type is defined as an object and allows generics? Shouldn't there be
some sort of consistency in the ways these libraries are implemente
I had Issue #1 reported by jyelon, where F5 would not compile ending with
"Process terminated with exit code 1". I verified my PATH variable and it
looked ok. I resolved the issue by running Aporia as Administrator. I also
modified the Aporia Shortcut properties to Run as Administrator by defaul
That's it, gedit also maps it the same way. GTK issue. The double quotes show
different there too when I change the keyboard setting. Thanks.
I have a US Keyboard in my laptop, but configured as "United
States-International" in Windows 10 to allow some Spanish characters that I
need to use. Under this setup, the way to type characters such as á é í ó or ú,
is by clicking the quote and the vowel in sequence, which produces just the
ac
15 matches
Mail list logo
