A problem is that gcc supposedly will not detect that the characters
between single quotes are a string and should not be handled by the
coprocessor.
I did not yet research if/how this behavior can be (in fact gcc _can_
compile pascal code !)
-Michael
On 11/16/2013 07:53 AM, Martin Schreiber wrote:
MSElang probably will not support macros.
While I agree that this is sensible, I vote for allowing to optionally
use the standard gnu g preprocessor if the need should occur.
-Michael
On 11/16/2013 09:56 AM, Martin Schreiber wrote:
I think program semantics should be independent of line breaks.
+1
-Michael
--
DreamFactory - Open Source REST JSON Services for HTML5 Native Apps
OAuth, Users, Roles,
On 11/16/2013 02:55 PM, Ivanko B wrote:
what is *=?
???
IMHO it's a good thing that fpc does support +=, -=, *= ...
I think this is a very clear and handsome syntax.
(Another extension I do like about fpc is case of string.)
-Michael
On 11/17/2013 06:46 PM, Martin Schreiber wrote:
Do you have a real example where elseif is much better than nested ifs
I use such indentation:
if a=b then begin
..x := y;
.end else if c = d then begin
..z := w;
.end else if f = g then begin
..s := t;
end;
with that an elseif keyword is not
On 11/15/2013 09:40 PM, Sieghard wrote:
And yet, there are - probabely still just as many - C programmers that
don't trust their compilers a bit.
Including myself. But my way of handling this is doing nice code and
in critical cases after compiling checking the resulting ASM code it the
On 11/15/2013 09:48 PM, Sieghard wrote:
Not even neccessarily. It could be a programmer error, e.g. such that
he forgot to declare a variable volatile,
Right. This just hit me some days ago when porting a program from an
ancient MRI C compiler to a modern gnu compiler. But even here, the
On 11/15/2013 10:17 PM, Sieghard wrote:
You _do_ know that pointer errors make for most of the scurity
problems of software overall, relegating any other errors to distant
follow-up places?
Correct but this is explicit pointer arithmetic (which in fact is very
common for C programmers). For
On 11/15/2013 08:28 PM, Sieghard wrote:
_What_ bit count should it use if you use it within an expression
where operands of different
I already did mention this.
The obvious definition is
- neglect the size of the variable to store the result in
- for constants use the smallest bit count
On 11/18/2013 12:01 PM, Ivanko B wrote: And no CASE for (strangely
discriminated) float
Case of float does not make sens as with float any test on equal does
not make sens.
Of course it does make sense to invent a case testing ranges for float.
But this would be a completely new baby.
On 11/18/2013 12:10 PM, Ivanko B wrote:
I use such indentation:
===
Only the cunny indentation allows to have the code be readable. It's
an workaround :)
I used half-indentation with else because to me it is absolutely
logical (both parts are subsumed below the if block),
On 11/18/2013 12:46 PM, Ivanko B wrote:
Case of float does not make sens as with float any test on equal does
not make sens.
===
? These comparisions works well in IF.
Sadly, It is allowed in if but it does not make any sense and is the
cause of ample problems programming
On 11/18/2013 03:54 PM, Ivanko B wrote:
if Pos (AModifiers [i], 'iI') 0
then Mask := MaskModI
For me, putting then in a new line under if is extremely confusing.
moreover elseif seems to be just a short form of else if (but not
really that much shorter)
-Michael
On 11/15/2013 01:03 AM, Sieghard wrote:
And then, it's a little bit funny to read a statement against source
code optimization from a C programmer, when it is often an expressed
concern by such to keep their source code as optimized for their
compiler as possible...
:-) This seems a
On 11/14/2013 09:49 PM, Sieghard wrote:
For debugging you can define a lower Optimization level.
You can d that, of course. Often, then, the reason for debugging goes away.
Optimization levels are only allowed to affect execution speed and code
size.
If the result of a function is
On 11/14/2013 09:28 PM, Sieghard wrote:
It might not be very neccessary if these types aren't compatible among each
other. Range checking has to be done only on coercion then, i.e. when
assigning a value cast from a - any - different type.
I understand that Martin is (IMHO) correctly assuming
On 11/14/2013 08:12 AM, Martin Schreiber wrote:
I don't like it.
Or with reserved words:
type
boolty = max: 8; //bool8
cardty = 0 to max: 8;//card8
intty = smin to smax: 8; //int8
charty = #max: 8;//char8
floatty = -.max to .max: 64; //flo64
On 11/15/2013 10:06 AM, Martin Schreiber wrote:
How do you suggest one should solve the Pascal with problem that it is
possible that an additional field in the with record can hide already used
names in existing with statements with that record?
+1
IMHO there is no decent way to handle the
On 11/15/2013 02:00 PM, Martin Schreiber wrote:
Why? Do you never work with variant records?
No.
There and with records
generally with is a good aid to structure the code.
Anyway: sorry for not being clear enough. I meant the with keyword for
denoting the record the fields denoted afterward
On 11/15/2013 02:08 PM, Martin Schreiber wrote:
How do you define char8/char16/char32 float32/float64 then if you don't want
to be forced to write the range?
Neither a bit limitation nor a range makes sense for floats.
Bits: you would need to specify a bit count as well for the Mantissa and
On 11/14/2013 09:16 AM, Michael Schnell wrote:
x6: unsigned : 2;
This syntax would allow for
x7: unsigned : 1024;
It would be a nice and consequent to provide arbitrary precision
integer arithmetic :-) .
-Michael
On 11/12/2013 04:45 PM, Martin Schreiber wrote:
with r: rec1 do
I decently hate with due to the ambiguity it imposes: it actively but
temporarily hides other names without notion (nested with's are even
more malicious).
So I _never_ use it
I vote for dropping it :-)
-Michael
On 11/13/2013 12:21 PM, Martin Schreiber wrote:
Never mind. with is very important in order to speed up array of record
addressing and the like.
I disagree.
With is just a way to save some typing.
speeding the runtime execution is up to the compiler optimization (it
might decide to use a
On 11/13/2013 02:27 PM, Martin Schreiber wrote:
therefore int64: 2; is invalid, i
I don't agree that this is sensible, but it's up to you.
how would you define a bitpacked record filed with two bits that is
intended to be handled as a signed integer ?
ty tr = ??;
r : tr;
i: int32
r.x2
On 11/13/2013 02:30 PM, Martin Schreiber wrote:
No. For exactly that purpose we have the with statement.
Haha !
intermediate variables are much more versatile than with (very
useful even for other stuff than for records) and impose much less
ambiguity as they only hide their own name (which
On 11/13/2013 02:37 PM, Martin Schreiber wrote:
There is no with itself in MSElang, there is 'with' ALIAS ':'
REFERENCE 'do' STATEMENTS 'end'
I need to take a closer look.
-Michael
--
DreamFactory - Open Source REST
if Strings are zero based pos() will issue a 0 if he second string
starts with the first one.
Supposedly it will issue -1 if there is no match.
While I do like this behavior, it is very incompatible with any existing
Pascal dialect, where you do if pos() = 0 to check if a string is
contained
On 11/13/2013 05:19 PM, Martin Schreiber wrote:
type
recordty = bitpacked record
x2: -2 to 1;
x3: -2 to 1: 2; //same as above
x4: 0 to 5: 4; //subrange in 4 bits
end;
While I don't like to be forced to calculate the range manually from the
intended bit count, this of
On 11/13/2013 09:33 PM, Sieghard wrote:
You could also decide to make pos take a return variable parameter
for the position, as this would nearly always be neccessary. Its
return value would then be a boolean, indicating whether the substring
was found. You might provide an overloaded
On 11/11/2013 11:03 PM, Sieghard wrote:
t _even_ C has block delimiters ({ and }), because they're
_needed_ by any notation that does _not_ restrict formatting the code.
In fact I _always_ use begin ... end ( or in C } ... { ) with if
and loop instructions (as I do not like the ambiguity
On 11/11/2013 11:00 AM, Ivanko B wrote:
That signedness isn't more than just a old (and not obvious) assumption.
Thus -1 is greater than 1 as the representation of -1 is all bits set ?
-Michael
--
November Webinars for
On 11/12/2013 10:13 AM, Martin Schreiber wrote:
In Pascal (and in MSElang) ';' does not terminate but separate a statement.
Exactly. (Different from C.)
Empty statements are possible -
OK. Thus my (c-influenced) style is acceptable.
-Michael
On 11/10/2013 02:33 PM, Sieghard wrote:
Don't try. There was _never_ a complete implementation of this
language around for all the time being, although the foremost computer
scientists of the time worked on these compilers (way back) then.
Martin does like a decent challenge :-) :-) .
On 11/11/2013 05:35 AM, Ivanko B wrote:
You require theater seat numbers to start at 0 for each row as well?
+1
(If the count of seats is 9 it would start with 00, of course.)
Sine we'll have bit counts etc starting from 0 then it's more
consistent to count everything numeric from 0 as well
On 11/08/2013 11:26 PM, Sieghard wrote:
TYPE
MonthDay = 1..31;
WeekDay = 1..7;
CharBits = 5..9; { for serial interfaces }
Not useful?
IMHO Only really useful if you go on
Type WorkingHours = Array [MonthDay] of Integer;
or similar.
-Michael
On 11/08/2013 05:32 PM, Martin Schreiber wrote:
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64?
So why invent new names instead of using the really well known names
such as uint8_t, int16_t
-Michael
--
On 11/09/2013 08:27 PM, Sieghard wrote:
C-ish type
IMHO C-ish stuff only should be avoided if there is not already a really
decent alternative in well known Pascal dialects.
In fact C-ish naming _should_ be used if the most well known (GNU) C
dialect or the most well known C-Libraries (glibc
On 11/08/2013 07:46 PM, Martin Schreiber wrote:
One probably would write
Register = bitpacked RECORD
Field_1: $..$007f;
Field_2: $..$0003;
Field_3: $..$001f;
Field_4: $..$0001;
Field_5:
On 11/11/2013 10:53 AM, Martin Schreiber wrote:
Because if there is a u for unsigned there must be a s for signed
(orthogonality). But int is already signed (as Sieghard pointed out)
so sint is bad.
While I do see you point, IMHO this is trading strictness vs
readability, and thus a matter of
On 11/11/2013 10:34 AM, Ivanko B wrote:
Why not something like
bitpacked RECORD
Filed_1: integer: 7;
Filed_2: integer: 2;
Filed_3: integer: 5;
Filed_4: integer: 1;
Filed_5: integer: 1;
end
===
For non-2^N ranging.
I don't
On 11/11/2013 12:15 PM, Martin Schreiber wrote:
card32, int32 is based on Pascal types and unambiguous too. cardinal,
integer - recommended type, card, int - size of the CPU registers.
Yep.
As said: mater of taste. So it's up to you.
-Michael
On 11/08/2013 07:00 AM, Martin Schreiber wrote:
Do we need subrange types?
I understand subranges are only useful for defining arrays with same as
index.
But as you want to disallow whatever based arrays, I doubt
array[TSubrange] makes much sense.
In fact a subrange is a special case of an
On 11/08/2013 11:30 AM, Ivanko B wrote:
Ranging for integers may also help to build not yet hardware suported types,
Somewhat similar, but IMHO by far not as useful as Records defining
bit-field variables.
-Michael
--
On 11/06/2013 01:40 PM, Martin Schreiber wrote:
string8, string16 and string32.
string8 is utf-8 encoded, string16 utf-16, string32 ucs4.
This ask for three versions of RTL provided classes like TStringlist
(and in fact TStrings) , so that the user who decides to use one of the
three
On 11/07/2013 09:42 AM, Martin Schreiber wrote:
MSEgui doesn't use tstringlist, there is a tmsestringdatalist
I don't know msegui well enough to see what this exactly means.
Delphi and Lazarus and most programs done with these tools use TStrings
all over the place (including, but not
On 11/07/2013 12:56 PM, Martin Schreiber wrote:
There possibly will be no TStrings in MSElang RTL.
As providing TStrings similar to the different types of same in D7, DXE
and Lazarus/fpc without creating sever ambiguity is close to impossible,
this is OK.
If a user wants to port a program he
On 11/06/2013 11:56 AM, Ivanko B wrote:
Now approx 100% of WWW are utf8, most DB setups are UTF8, most text
editors are UTF8, most LINUX installations are UTF8..
While UTF8 is a perfect code for storing and transport, IMHO it is not
at all perfect for being handled by complex software. Here
(Copied from the FPC mailing list where it had erroneously been posted)
IMHO this theme is complex enough to start another mailing list instead
of discussion it here.
There already has been a (IMHO very interesting) discussion in the
German Lazarus forum that in fact does have an mse
(Copied from the FPC mailing list where it had erroneously been posted)
IMHO this theme is complex enough to start another mailing list instead
of discussion it here.
There already has been a (IMHO very interesting) discussion in the
German Lazarus forum that in fact does have an mse
On 11/06/2013 12:49 PM, Ivanko B wrote:
Sure, provided that all ansistring-like operations are correct for its
surrogates.
Codepoints 2^15 cause a problem with index of a string (as with
codepoints 2^7 in UTF8). This needs to be documented appropriately.
using the index not explicitly but
On 11/06/2013 12:57 PM, Ivanko B wrote:
Probably needs a wider discussion even flaming debates - on
FreePascal.Ru etc...
We are not discussing free Pascal here, so I don't get the meaning of
this ?!?!?
-Michael
--
On 11/06/2013 01:31 PM, Ivanko B wrote:
Which shouldn't be ignored avoided :)
??
Once we contact with aliens (and their alphabets) then UTF8 or UTF16
become only choices.
??
-Michael
--
November
On 11/06/2013 01:40 PM, Martin Schreiber wrote:
On Wednesday 06 November 2013 11:27:58 Michael Schnell wrote:
[...] strings
It is planned to implement bytestring, bytestring[maxlength], string8,
string16 and string32.
string8 is utf-8 encoded, string16 utf-16, string32 ucs4. string8
On 11/06/2013 01:45 PM, Ivanko B wrote:
I vote for adding Syntax for parallel processing
==
It can mainly be useful for parallel-aware languages like Haskell
(which prevents form creating state-machine applications badly
compatible with paralleizing ).
Did you
101 - 154 of 154 matches
Mail list logo
