T
Tech07
Richard said:
In retrospect? Are you ignoring the previous posts? Or history? (rhetorical
questions).
In retrospect? Are you ignoring the previous posts? Or history? (rhetorical
questions).
T
Tech07
Flash said:
Do tell! How can I use errno correctly in a multi-threaded program?
U
user923005
In such programs, it is stored in thread local storage. The
definition in these cases is not a static integer at all. For
instance:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include>grepcarl
errno e*.h
errno.h ( 2): *errno.h - system wide error numbers (set by
system calls)
errno.h ( 20): #ifndef _INC_ERRNO
errno.h ( 21): #define _INC_ERRNO
errno.h ( 29): /* declare reference to errno */
errno.h ( 31): #ifndef _CRT_ERRNO_DEFINED
errno.h ( 32): #define _CRT_ERRNO_DEFINED
errno.h ( 33): _CRTIMP extern int * __cdecl _errno(void);
errno.h ( 34): #define errno (*_errno())
errno.h ( 36): errno_t __cdecl _set_errno(_In_ int _Value);
errno.h ( 37): errno_t __cdecl _get_errno(_Out_ int *
_Value);
errno.h ( 100): #endif /* _INC_ERRNO */
Since the C language does not define threads (and any solution to this
issue will be inherently non-portable since C itself does not define
it), it's not terribly topical anyway. Certainly
would be more on target.
F
Flash Gordon
user923005 said:
<snip>
glibc on Linux does clever stuff as well...
Indeed, where they can talk about various synchronisation and locking
mechanisms, mutexes etc, all of which could be used if an implementation
was so poor quality that it provided threads (as an extension) but not a
thread safe errno.
C
Colonel Harlan Sanders
What a tool.
You've attached the name "Nilges" proudly to thousands of posts on
Usenet and God knows how many forums.
With these you have made the name a synonym for "frothing lunatic" or
just "kook". If posts on Usenet can harm the reputation of your
family, you are the one answerable for this.
Not to mention any relatives of Benedict de Spinoza who has had his
name shat on by your poisonous verbiage; and more painful for a
philosopher, your frequent descents into threats of violence (as above
cited) when your arguments are found wanting.
But fortunately, the longer and more nutty your posts get, the fewer
can bear to read them, and I think nobody at all, even those you
purport to defend, can take you seriously.
I realize it is rather pointless to tell you this, I'm sure hundreds
of people have made similar points in the past, so mea culpa for
feeding the troll (cue "troll == Jew" idiocy).
N
NevilleDNZ
Algol68 tries to treat BOOL and INT as two different types
of data. For example BOOL has the NOT,AND,OR operators, whereas
INT has it's own ,-,*,/ operators. Any mixing causes a compile
time triggers syntax error forcing the programmer to reconsider
what s/he is trying to achieve.
Below is a short program to demonstrate the relationship
and conversions between the distinct types BYTES, []CHAR, INT,
BITS and []BOOL.
Enjoy
Neville Dempsey
--
For Algol68-user mailinglist with archives & subscription follow:
https://lists.sourceforge.net/lists/listinfo/algol68-user
To download Linux's Algol68 Compiler, Interpreter & Runtime:
http://sourceforge.net/projects/algol68/
BEGIN
# BEGIN BOOL b; b := 1 END can be achieved as: #
BOOL b; b := 1 NE 0;
# Here is the Algol68's BITS/BYTES heirachy:
BYTES <=> []CHAR <=1=> INT <=> BITS <=> []BOOL #
# BITS are to []BOOL as BYTES are to []CHAR! #
# Declarations: #
BYTES bytesx;
[bytes width]CHAR acharx;
INT intx;
BITS bitsx;
[bits width]BOOL aboolx;
# Note: all of the above (aboolx, bitsx,
word, acharx, bytes) store the
equivalent info of one native machine
word. In particular BITS and BYTES
are exactly one native machine word,
in size which (in 1968) sometimes
means 6 lots (ELEMs) of 6 BIT
CHARacters, a total of 36 BITS!
c.f.: REAL PROGRAMMER THINK IN UPPERCASE! #
# initialize the BOOL array to an ASCII "!" (0x21) #
bytesx := bytespack("!");
# from BYTES to []BOOL is more natural as 2 coercions are in place #
acharx := bytesx;
intx := ABS acharx[1]; # Only 1 BYTE! #
bitsx := BIN intx;
aboolx := bitsx;
print((aboolx, new line)) ;
# prints: FFFFFFFFFFFFFFFFFFFFFFFFFFTFFFFT #
# here is how to the reverse conversion could be done #
bitsx := bitspack(aboolx);
intx := ABS bitsx;
acharx[1] := REPR intx; # Only 1 BYTE! #
bytesx := bytespack(acharx);
print((1 ELEM bytesx, new line)) # print 1st BYTE #
# prints: "!" #
END
N
Nick Keighley
very sane. It's C that's the oddity (or rather low level language)
here.
all well and good
I was just suprised it was a *syntax* error. Obviously Algol-68's
syntax was great deal tougher than most (even most modern) languages.
C for instance calls errors like this "constraint errors"
thanks. I think.
<snip>
--
10.3. Transput declarations
{ "So it does!" said Pooh, "It goes in!"
"So it does!" said Piglet, "And it comes out!"
"Doesn't it?" said Eeyore, "It goes in and out like
anything,"
Winnie-the-Pooh, A.A. Milne.}
From "Revised Report on the Algorithmic Language ALGOL 68"
N
NevilleDNZ
It happens at compile time.... I've always called compile
time errors "syntax errors"... maybe I am wrong calling them
syntax errors as the word "syntax" seems to suggest the
sentence structure is wrong. Maybe this is better called a
"semantic error"?
None-the-less, detecting these kinds of errors at compile time
is a real bonus (detection prior to mission lanuch). C allows
a certain amount of semantic checking, but is a rather too
gregarious in its usage of "int". Python is further gregarious
with many other things, including procedure arguments.
Wishlist: It would be nice if in python one could "opt in"
to "_compile-time_" semantic checking.
Compare the following programs and resulting output:
$ cat moon_landing.a68
PROC hms = (INT h,m,s)INT: (h*60+m)*60+s;
PROC VOID launch, translunar injection, csm lm docking, lunar orbit
insertion,
csm lm separation, lunar landing, begin eva, first step on surface;
PROC mission time = INT: SKIP;
PROC sleep = (INT duration)VOID: SKIP;
DO
IF mission time = hms(00,00,00) THEN launch
ELIF mission time = hms(02,44,16) THEN translunar injection
ELIF mission time = hms(03,24,03) THEN csm lm docking
ELIF mission time = hms(75,49,50) THEN lunar orbit insertion
ELIF mission time = hms(100,39,53) THEN csm lm separation
ELIF mission time = hms(102,45,40) THEN initiate lunar landing("The
eagle has landed")
ELIF mission time = hms(109,07,33) THEN begin eva
ELIF mission time = hms(109,24,15) THEN first step on surface("One
small step for ~ man"); done
FI;
sleep(1)
OD;
done: ~
$ a68g moon_landing.a68
13 ELIF mission time = hms(102,45,40) THEN initiate lunar landing
("The eagle has landed")
1
a68g: syntax error: 1: VOID construct must yield a routine, row or
structured value (detected in conditional-clause starting at "IF" in
line 8).
15 ELIF mission time = hms(109,24,15) THEN first step on surface
("One small step for ~ man"); done
1
a68g: syntax error: 1: VOID construct must yield a routine, row or
structured value (detected in conditional-clause starting at "IF" in
line 8).
Programmer must now reconsider what they were trying to achieve.
$ cat moon_landing.py
import time
def hms(h,m,s): return (h*60+m)*60+s
launch=translunar_injection=csm_lm_docking=lunar_orbit_insertion=\
csm_lm_separation=lunar_landing=begin_eva=first_step_on_surface=lambda:None
start_mission=time.time()
def mission_time(): return int(time.time() - start_mission)
while True:
print mission_time()
if mission_time() == hms(00,00,00): launch()
elif mission_time() == hms(02,44,16): translunar_injection()
elif mission_time() == hms(03,24,03): csm_lm_docking()
elif mission_time() == hms(75,49,50): lunar_orbit_insertion()
elif mission_time() == hms(100,39,53): csm_lm_separation()
elif mission_time() == hms(102,45,40): initiate_lunar_landing("The
eagle has landed")
elif mission_time() == hms(109,07,33): begin_eva()
elif mission_time() == hms(109,24,15): first_step_on_surface("One
small step for ~ man"); break
time.sleep(1)
$ python moon_landing.py
102 hours later....
Traceback (most recent call last):
File "moon_landing.a68", line 37, in ?
elif mission_time() == hms(102,45,40): initiate_lunar_landing("The
eagle has landed")
TypeError: <lambda>() takes no arguments (1 given)
Neil must now reconsider what he was trying to achieve.
The point would be that if the programmer follows certain semantics,
then the compiler/interpreter should cooperate and make use of these
semantics as early as possible, esp prior to program being run, rather
then during a critical part of a mission.
enjoy
N
C
Chris Dollin
NevilleDNZ said:
Algol-68 is defined by a two-level grammar which is powerful enough
to do type-checking as well as sentence structure, so type errors
/are/ syntax errors in that case.
However, this approach to language definition has not become popular,
and it seems to be more usual to define the long-range checks of
programming languages -- the sorts of things that type-checking
in a statically-checked language is -- separately from the syntactic
structure and indeed relying on it.
The checks can be defined formally or informally; that's a separate
issue.
--
"I'm far too ditzy to grasp the subtleties of mockery." Raven,
/Questionable Content/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
N
Nick Keighley
Algol-68 was jolly clever
possibly influenced by the fact that the Algol-68 specification was
unreadable by anyone with an IQ of less than Alan Turing
sample:
********
7.1. Independence of properties
{The following syntax determines whether two properties (i.e., two
'PROP's), such as those corresponding to REAL x and INT x, may or may
not be enveloped by the same 'LAYER'.}
7.1.1. Syntax
A) PREF :: procedure yielding ; REF to.
B) NONPREF :: PLAIN ; STOWED ; procedure with PARAMETERS yielding
MOID ; UNITED ; void.
C) *PREFSETY :: PREF PREFSETY ; EMPTY.
{PROP :: DEC ; LAB ; FIELD.
QUALITY :: MODE ; MOID TALLY ; DYADIC ; label ; MODE field.
TAX :: TAG ; TAB ; TAD ; TAM.
TAO :: TAD ; TAM.}
*******
It *is* quoted out of context. But Algol-68's syntax representation
is a far tougher cookie than BNF.
R
Richard Tobin
Chris Dollin said:
The issue of whether van Wijngaarden grammars clarify or obscure
syntax descriptions is a matter of current debate: what is certain
is that up to now they haven't inspired any new kinds of parsing
mechanisms which can use their undoubted powers of expression.
[Bornat, 1979]
As far as I know, they still haven't.
And of course, you wouldn't want a compiler that when faced with
a type error just said "syntax error"
-- Richard
N
NevilleDNZ
What I can describe with Algol68 - when compared to C -
is that C will let you "do (most) anything", whereas
Algol68 is a tad grumpy.
Indeed Algol68 grumbles like an old professor leaving
you pondering what who is wrong, so then you drag
out a dictionary (eg. deproceduring, dereferencing,
uniting, widening, rowing, voiding, shortening,
lengthening etc) 10 minutes later you realise that Algol
68 isn't being recalcitrant (like Pascal) and indeed
Algol 68 spotted a bug.
On the other hand C might core dump (and python might
give you a TypeError) at 120 hours into the mission
leaving you guessing what went wrong.
Another observation when refactoring Algol68 code
is you do have - again - to put up with that grumpy
old professor, but it is worth it. Kind of like using
a version of "lint" on steroids as a mandated part of
the compiler.
If Algol68 testiness means compiler writers study must
vW-grammar, then I am all for mandating vW-grammar to
compiler writers, leaving us programmers the easy
job of using the resulting language as a tool.
In the Algol 68 Report this was called "Security":
Security was one of 4 key requirements:
1. Completeness and clarity of design,
2. Orthogonal design,
3. Security,
4. Efficiency:
* Static mode checking
* Mode-independent parsing
* Independent compilation
* Loop optimization
* Representations - in minimal & larger character sets
C99 and gcc has the some of the aspect of "Security",
in particular argument checking. Maybe others??
IMHO
NevilleD
C
Chris Dollin
Richard said:
I have that book!
And of course, you wouldn't want a compiler that when faced with
a type error just said "syntax error"
It's much better to exhibit two page-long type expressions and mention
that they're not compatible!
(Quick, guess which programming language I'm referring to.)
--
"He was thinking about an immortal man who flew - James Blish
from star to star faster than light." /They Shall Have Stars/
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
D
Dik T. Winter
In order to get such things as a syntax error requires more than a simple
grammar. Note that in Algol 68 the following is also a syntax error:
'begin' 'int' i; a 'end'
Replacing a by i makes it a correct program, but the lack of declaration
of a makes it a syntax error.
In principle the syntax for Algol 68 was not tougher, but the way it was
stated was new (a 2-level grammar) and not readily understood by many.
One advantage of this is that the semantics sections in the report are
actually quite small because it is the syntax that in most cases defines
how things are done.
D
Dik T. Winter
About:
'begin' 'bool' b; b := 1 'end'
No, in Algol 68 it really is a syntax error. The grammar can not produce
the program above.
'begin' 'bool' b; b := 1 'end'
No, in Algol 68 it really is a syntax error. The grammar can not produce
the program above.
R
Richard Tobin
[/QUOTE]
Why am I not surprised...
Something ML-derived, I expect. Or possibly XML Schemas.
-- Richard
P
Phil Carmody
What are pragmats? Pragmas and pragmata I could parse.
Phil
Phil
M
Martien Verbruggen
Pragmats are compiler directives in ALGOL.
Martien
N
Nick Keighley
Why am I not surprised...
Something ML-derived, I expect. Or possibly XML Schemas.[/QUOTE]
C++ can produce some pretty nasty diagnostics
P
Phil Carmody
Martien Verbruggen said:
Well, as you can probably tell, I never knew that. Many thanks.
Phil