Re: use of backward single quote in procedure names, was: DST (summer time) offset

In message <4f81a8f28bsteve@xxxxxxxxxxxxxxx>
"Ste (news)" <steve@xxxxxxxxxxxxxxx> wrote:

In article <87b3a0814f.tigger@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
Nick Roberts <tigger@xxxxxxxxxxxxxxxxxxxxx> wrote:
In message <4f809736c8steve@xxxxxxxxxxxxxxx>
"Ste (news)" <steve@xxxxxxxxxxxxxxx> wrote:

In article <391e8e804f.tigger@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
Nick Roberts <tigger@xxxxxxxxxxxxxxxxxxxxx> wrote:
But you said above that there are syntax checkers for BASIC.
You either use them (hence "waiting for syntax checker after
each and every bleedin' revision: snore.") or you don't, in
which case you can't claim the benefit for them.

Exactly my point

Your point is that you want it both ways?

No. My point was the bit following the semicolon.

; if that sort of thing catches mistakes that you make (I don't
find they are the sorts of thing I do wrong)

Ah, you found it.

You don't make typographical errors, misspell a variable name, etc?
Wow. I've never encountered a perfect typist before.

I can find those errors just as quickly by running something.

This can simply not be true in the general case. If you have mistyped
something in a procedure that is only invoked in the terminal part of a
program, after you have to go through many interactions with the user,
that mistyping could only be found with a lot of effort.

If I type something wrong in C, I only find out when I get around to
compiling it. If I type something wrong in BASIC, I only find out
when I run it - and the bit I'm working on is normally arranged to be
the thing I run first.

As I say above, that is just not achievable all the time. But a
compiler will find it whether it is the first statement of a program or
one that only executes after a lot of pre-processing.

These aren't the class of fault that makes any significant difference
to development time, IMO, even if it's reasonably common. Chasing
down memory corruption or stale pointers is the sort of thing that
takes a while.

I agree with that statement, but primarily because (with a compiler)
all the syntactic issues are trivial. They are anything but trivial if
you actually ave to execute the statement before finding out that there
is a typo in it.

Now, I admit to writing certain classes of thing in BASIC and other
classes of thing in C so direct comparison is difficult. But the
metric isn't: BASIC is fine for simple stuff but C is better for
complex stuff. There's more to it than that.

Now show the code you would need for (say) Font_ScanString.

I tell you what, why don't you show me the C for it? Assuming you're
not using any libraries. Hold on, you were going to use OSLib weren't
you?

Actually, no, I wasn't. I was just going to use the headers that come
with every C/C++ package.

Perhaps another example, from BookMaker:

typedef struct __bk { int order;
int flags;
char *BookName;
char *SrcFileName;
ObjectId submenu;
struct __bk *parent;
struct __bk *emailParent;
QUEUE addresses; } BOOK_STR;

typedef BOOK_STR *BOOK;

typedef struct {
char *alias;
char *dlistFile;
} EMAIL_DETAILS_TYPE;

typedef struct {
char *username;
char *password;
char *listflags;
char *siteselect;
char *siteupload;
char *proxyname;
} FTP_DETAILS_TYPE;

typedef struct {
int portNumber;
char *portName;
char *termChar;
char *command;
char *scriptfile;
} TELNET_DETAILS_TYPE;

typedef union {
EMAIL_DETAILS_TYPE email;
FTP_DETAILS_TYPE ftp;
TELNET_DETAILS_TYPE telnet;
} ADDRESS_DETAILS_TYPE;

typedef struct {
int order;
int appflags;
char *title;
char *address;
QUEUE comments;
BOOK child;
BOOK parent;
int flags;
ADDRESS_DETAILS_TYPE details;
} ADDRESS_STR;

typedef ADDRESS_STR *ADDRESS;

How would your pseudo-structure in BASIC handle that? In particular,
how would you handle the union, and the separation of fields in the
various members of the union? Please note, I'm not saying it's
impossible, but the sheer complexity of having to work out all the
offsets yourself, work out how big the various types of block have to
be, etc predicates against it. In C, all of this stuff _just works_,
with no effort from the programmer.

And what happens when you changfe the definition of a structure? In C,
yet again, it just works. In BASIC, you've got to chase down the
definition and manually update one or more of the offsets, and the size
of the block.
In that case, I'll use some BASIC library which does the same.
Of course you can. But it doesn't come "for free",

http://www.7thsoftware.com/software.html

There it is. And it's free, in the same sense as OSLib or any other
thing that gets you beyond the standard C libraries.

Actually, I don't use anything other than the standard C libraries or
libraries that I have written for myself. I got too pissed off with the
"my library is better than your library" wars of a few years ago.

I'm sure some "standard" set of BASIC libraries could be distributed
in !Boot if anyone cared so that everyone gets them "for free" (in
the sense you probably intended).

The point is, however, that they are _not_ so distributed. So they
aren't free - users have to find them.

"malloc" works on every C compiler I will ever encounter (and as I
use 3 different compilers regularly that is not a trivial benefit).

Right, so now you're off on the portability crusade? Get back on
topic (RISC OS group, RISC OS language discussion) and I'll bother to
answer.

A portability _crusade_? I make one mention of the generality of C, and
you read this as a crusade?


Yes, and every library in BASIC suffers from BASIC's scoping rules,
which means that for functions that need variables with a lifetime
greater than one invocation there are global variables hanging
around to get in the way.

If that were a problem, then extern symbols would be a major headache
for C programming (e.g. function names). Clearly, they aren't because
of that magical thing called "giving identifiers a unique name".

Drivel. In C, you know what you are getting, as they are defined to be
global. In BASIC libraries, you don't, as a lot of inter-procedure
communication is achieved by side-effects. To do the same in C, you use
module-static variables which can't be accessed outside the module.

It seems to me that if anyone is on a crusade, it's you. You seem to be
saying that C offes no benefits whatsoever over BASIC. If that really
is your pov, then there is absolutely no point in us continuing.

When I write a GUI app in BASIC, I'll have a library for each window,
one for each menu and one for each functional unit (e.g. some
specific functional component). I never have problems divorcing these
from each other or problems separating out the namespaces.

But you were proposing standard libraries for BASIC in the same way
there are standard libraries for C. That means that third parties get
to use these libraries, and must be aware of every global variable (and
in a lot of cases, every global variable) that are used, because BASIC's
variable scoping makes them visible to the remainder of the program.

Clearly, if you work for NASA and have people submitting their parts
of a 10 GB source code project from lots of different timezones over
a two year period, you have to be rather more careful. But I'm
talking about writing stuff for RISC OS.

You mean like BookMaker, Rename, KISS, etc? Each of those has been
developed over more than 10 years.

And just as a matter of interest, why shouldn't one try to make a
program as robust under RISC OS as one can? Why should one acceptporer
standards on RISC OS than one would demand on (say) Windows or Linux?
It doesn't need to be safety critical to be worth doing right (or at
least, reasonably right).

Everyone's always comparing writing a whole BASIC program from
scratch with no libraries against using C and OSLib. Talk about
bases loaded.

No, just a recognition that BASIC scoping rules mean that proper
packaging isn't possible.

Frankly, I don't care how you define "proper". Perfectly adequate and
fully functional are sufficient for me.

While in BASIC you get woefully inadequate and a dependency on global
variables.

Very probably true. I suspect that your claim that your
pseudo-structures in BASIC are as powerful as the real thing is
coloured by never having had to write packages that have extremely
complex nested structures.

Let's be clear now: I haven't been trying to say BASIC's
pseudo-structures are as good as C.

So why did you make such a fuss over it when I said that BASIC didn't
have them?
If you manage to see past the red mist

No red mist. As I said, you are the one who seems to be in denial.

and read my previous posts on
this thread, I've said in no uncertain terms that BASIC needs
structures.

What I _am_ saying, however, is that all of those pointless noddy
arguments that people make about how crap BASIC is for interfacting
with SWIs, etc, because you have to do:

foo%?1 = !a% - b%?6 AND zz%!44

are a load of tosh because only someone who hasn't the slightest clue
would be writing BASIC like that.

I have never said anything like that. I have only said that BASIC does
not provide the tools that make programming as simple as it can be, and
that those who insist that they are unnecessary are (willfully or from
ignorance) underestimating the benefit that they offer.

You can replace magic numbers with named variables and wrap the SWI
call in a procedure or function and put the whole collection of
related stuff into a library.


So let's summarise from your list of BASIC gripes:

1. is interpreted, and hence comparatively slow

Not relevant; horses for courses. Hence the proliferation of
other
interpreted languages in the modern world of software engineering.

Who says it isn't relevant? Do you have detailed knowledge of the
internals of all of my programs, to the extent that you can know with
certainty that (say) BookMaker would be as quick as it is if it were
written in BASIC?

Because I wrote it, I can guarantee that PlayKISS and MakeKISS would
not be acceptably fast in BASIC, because I had to rewrite chunks of
them several times in C to achieve an acceptable performance.
Ironically, the one bit that would run at the same speed in BASIC is
the bit where I had to resort to assembler because C wasn't fast
enough.

But in any case, I have already stated that my complaint against BASIC
as far as performance is qualified by the fact that for a lot of
purposes, BASIC is fast enough. But you then are left with the issue
that you either need to program in 2 languages - BASIC when it is fast
enough, or something else (such as C) when it isn't - or you program in
the language that will consistently be fast enough.

2. has no pre-run-time syntax checking

Correct. That's how interpreted languages work. BASIC does have
syntax
checkers if that is important to you.

3. has no pre-run-time variable name checking

See 2.

4. has no pre-run-time type cast checking

See 2. Note: it barely has types at all so even at run time you
are
offered little protection, but that also gives a degree
flexibility.

In C, you have both protection (by default) and the ability to override
it where necessary.

and add a few new points you've raised:

5. isn't portable

Correct. I don't care if I'm writing a RISC OS GUI application.
When I'm
writing a USB device driver, then I won't use BASIC.

Actually, I didn't explicitly say that it wasn't portable. What I said
was that malloc existed on every version of C, which is different.

I've actually only written a couple of programs that I wanted to run
both under Windows or Linux at work and RISC OS at home. However, I
have to write programs in both places. Having to use a different syntax
with different rules in the two places would be a pain. It's not
portability (the ability to run the same program) that is important in
this context, it's the ability to use the same language.

6. doesn't give you proper packaging because of scoping rules

Again, things would have to get pretty big and complex before
that became
an insoluable problem in BASIC, but at that point, you'd probably
have
more pressing concerns (like it's not fast enough).

Again, both BookMaker and the KISS suite would be difficult (for which
read: so complex that I wouldn't even consider trying) without lexical
scoping and static variables.

--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.
.

Relevant Pages

  • Re: wrong print
    ... you must be using non-standard libraries. ... int max_line_len = 1024; char **Amm,**Pss; ... char* readline; void scandir; ... Before posting for the first time to a group ALWAYS read the FAQ ...
    (comp.lang.c)
  • Re: question about memcpy()
    ... In Studio 6 project, it works fine. ... typedef struct _new_params ... unsigned char addr; ... MAC_ADDR resp; ...
    (microsoft.public.vc.mfc)
  • Re: use of backward single quote in procedure names, was: DST (summer time) offset
    ... I admit to writing certain classes of thing in BASIC and other classes ... that gets you beyond the standard C libraries. ... RISC OS language discussion) and I'll bother to answer. ... has no pre-run-time syntax checking ...
    (comp.sys.acorn.programmer)
  • Re: How would you marshal this?
    ... added to the member of type char* ... public tEXTERNAL_NUMERIC Discount; ... IntPtr quantityPtr = IntPtr.Zero; ...
    (microsoft.public.dotnet.framework.interop)
  • Re: string compare
    ... I am using custom string structures in a project. ... short int length; ... char data; ...
    (comp.lang.c)