Rewrite BASIC language today?
jj
if any, consistent with the meaning of the acronym? I am thinking about the
physical limitations and the pressures to make the language like some of
it's
now little used competitors.
For example, I have always wondered why those "doit" instructions -
FOR/RETURN/
DO/WHILE etc are not all part of one instruction with several parameters.
Some of the differences between different BASICS are surely unnecessary and
not
consistent with the original basis for it's creation.
Perhaps sales of BASIC are not to or for beginners anymore? Perhaps the
"educational" factor
once used to sell the language is not of much interest?
Has modern BASIC evolved into a development language for experts?
jj
Tom Lake
"jj" <in...@amd.com> wrote in message news:fug623$le2$1...@aioe.org...
> Hi, if BASIC were to be written today, what changes would you have made,
> if any, consistent with the meaning of the acronym? I am thinking about the
> physical limitations and the pressures to make the language like some of
> it's
> now little used competitors.
>
> For example, I have always wondered why those "doit" instructions -
> FOR/RETURN/
> DO/WHILE etc are not all part of one instruction with several parameters.
You should really read the book, Back to BASIC by Kemeny and Kurtz,
the authors of the original BASIC. There's a good reason for having separate
keywords in a teaching language.
>
> Some of the differences between different BASICS are surely unnecessary and
> not
> consistent with the original basis for it's creation.
How true! Again, read Back to BASIC. It's the story of why BASIC was created
and how "Street BASIC" corrupted the original vision of the language.
>
> Perhaps sales of BASIC are not to or for beginners anymore? Perhaps the
> "educational" factor
> once used to sell the language is not of much interest?
True BASIC is doing very well in the elementary educational world.
>
> Has modern BASIC evolved into a development language for experts?
It's sickening for a BASIC programmer to see what C programmers have done
in the name of BASIC. I sometimes wish Dartmouth had copyrighted the name
BASIC and kept stricter control over it.
Tom Lake
ArarghMai...@not.at.arargh.com
wrote:
<snip>
>It's sickening for a BASIC programmer to see what C programmers have done
>in the name of BASIC.
Just curious as to what you might be referring to?
>I sometimes wish Dartmouth had copyrighted the name
>BASIC and kept stricter control over it.
I have been an assembler and Basic programmer since I got started.
Several assorted versions of each. :-)
I can't really read a C program well, It's easier to feed it thru the
compiler and read the assembly output.
--
ArarghMail804 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Tom Lake
<ArarghMai...@NOT.AT.Arargh.com> wrote in message
news:dnbq045hsosllvap1...@4ax.com...
> On Mon, 21 Apr 2008 08:24:21 -0400, "Tom Lake" <tl...@twcny.rr.com>
> wrote:
>
> <snip>
>>It's sickening for a BASIC programmer to see what C programmers have done
>>in the name of BASIC.
> Just curious as to what you might be referring to?
Look at many versions of "BASIC" around such as FreeBASIC. They've added
pointers,
unions, function overloading and enumeration to mention a few things. Maybe
even
heap management in a few variations! These are all contrary to the original
intent of
BASIC. Kemeny and Kurtz didn't even want the user to know that there's an
internal
difference in the way integers and floating-point numbers are stored! The
details of
the underlying computer should be inaccessible to the BASIC programmer. The
computer on which BASIC is running should be irrelevant.
Tom Lake
ArarghMai...@not.at.arargh.com
wrote:
><ArarghMai...@NOT.AT.Arargh.com> wrote in message
>news:dnbq045hsosllvap1...@4ax.com...
>> On Mon, 21 Apr 2008 08:24:21 -0400, "Tom Lake" <tl...@twcny.rr.com>
>> <snip>
>>>It's sickening for a BASIC programmer to see what C programmers have done
>>>in the name of BASIC.
>> Just curious as to what you might be referring to?
>
>Look at many versions of "BASIC" around such as FreeBASIC. They've added
>pointers,
>unions, function overloading and enumeration to mention a few things. Maybe
>even
>heap management in a few variations! These are all contrary to the original
>intent of
>BASIC. Kemeny and Kurtz didn't even want the user to know that there's an
>internal
>difference in the way integers and floating-point numbers are stored! The
>details of
>the underlying computer should be inaccessible to the BASIC programmer.
Hmm, I see what you mean. But dropping all the extras makes it pretty
useless except for Beginners. And slow. Maybe the answer is to come
up with a new name for an expanded language whose beginnings started
with BASIC. Any ideas?
>The computer on which BASIC is running should be irrelevant.
Data interchange could get interesting in that case. Everything would
have to be stored in text files, but then you get character set
differences,
Derek
> <ArarghMail804NOS...@NOT.AT.Arargh.com> wrote in message
Agreed. The point of BASIC is to be problem-oriented, not machine-
oriented. Additions should hide the way that the machine works, not
expose it.
Cheers
Derek
ne...@rtrussell.co.uk
> Perhaps sales of BASIC are not to or for beginners anymore? Perhaps
> the "educational" factor once used to sell the language is not of
> much interest?
That's certainly not true of BBC BASIC, which started off life both as
a 'beginners' and an 'educational' language (way back in 1981) and
very much still fulfils those roles today.
> Has modern BASIC evolved into a development language for experts?
As has been alluded to, that has happened to some BASICs *at the cost
of* their suitability for beginners. Personally I deprecate that. On
the other hand I disagree with those who think BASIC shouldn't evolve
at all; as an 'educational' language it needs to reflect some of the
developments in programming techniques that have taken place over the
last 30 years.
I have been privileged to have been involved with BBC BASIC from its
earliest beginnings, and to have overseen (and recently been
responsible for) its development. In bringing it 'up to date' in the
last few years I have tried very hard to be sensitive to its original
aims. Some 'modern' features have been added, but (hopefully) not at
the expense of what BASIC originally stood for.
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Auric__
> On Mon, 21 Apr 2008 22:12:32 -0400, "Tom Lake" <tl...@twcny.rr.com>
> wrote:
>><ArarghMai...@NOT.AT.Arargh.com> wrote in message
>>news:dnbq045hsosllvap1...@4ax.com...
>>> On Mon, 21 Apr 2008 08:24:21 -0400, "Tom Lake"
>>> <tl...@twcny.rr.com> <snip>
>>>>It's sickening for a BASIC programmer to see what C programmers
>>>>have done in the name of BASIC.
>>> Just curious as to what you might be referring to?
>>
>>Look at many versions of "BASIC" around such as FreeBASIC. They've
>>added pointers,
>>unions, function overloading and enumeration to mention a few
>>things. Maybe even
>>heap management in a few variations! These are all contrary to the
>>original intent of
>>BASIC. Kemeny and Kurtz didn't even want the user to know that
>>there's an internal
>>difference in the way integers and floating-point numbers are
>>stored! The details of
>>the underlying computer should be inaccessible to the BASIC
>>programmer.
>
> Hmm, I see what you mean. But dropping all the extras makes it
> pretty useless except for Beginners.
...which was what Kemeny & Kurtz had in mind, wasn't it?
> And slow. Maybe the answer
> is to come up with a new name for an expanded language whose
> beginnings started with BASIC. Any ideas?
I think perhaps the OP had in mind existing languages which call
themselves *BASIC* which are only superficially similar to the
original. Things like XBasic, or anything from MS. (Actually, maybe
MS's VARIANT data type was close to something K&K wanted in the first
place... a data type that could hold *anything*, and the programmer
doesn't have to think about the contents, just *uses* it.)
>>The computer on which BASIC is running should be irrelevant.
> Data interchange could get interesting in that case. Everything
> would have to be stored in text files, but then you get character
> set differences,
That would drive me nuts. Probably push me away from the language
entirely.
--
A bug can make your DOS session run off into the bushes
and not come back.
-- Jeff Duntemann
Tom Lake
<ArarghMai...@NOT.AT.Arargh.com> wrote in message
news:pvlq04ttv1bg0de56...@4ax.com...
>>The computer on which BASIC is running should be irrelevant.
> Data interchange could get interesting in that case. Everything would
> have to be stored in text files, but then you get character set
> differences,
Not everything. Remember, BASIC is only supposed to have two
data types: Real numbers and strings. The ANSI committee (of which
Tom Kurtz was a member) defined BASIC's real number format to
be IEEE floating-point. Strings are ASCII characters. You could transfer
numbers and words between all versions of BASIC that way without the
user ever being aware of what goes on "under the covers"
Tom Lake
ne...@rtrussell.co.uk
> Remember, BASIC is only supposed to have two data types:
> Real numbers and strings.
ANSI BASIC may have only real numbers and strings but many other
BASICs have more data types (most have integer data types, or at least
variant types that may be integer). BASIC in 2008 isn't "a" language,
it's a set of more-or-less incompatible dialects. You can't say it is
"supposed" to have any particular characteristic.
> The ANSI committee (of which Tom Kurtz was a member) defined
> BASIC's real number format to be IEEE floating-point. Strings
> are ASCII characters. You could transfer numbers and words
> between all versions of BASIC that way
What about the "versions of BASIC" developed before there was such a
thing as IEEE floating point, i.e. prior to 1985? For example BBC
BASIC (1981) uses a 40-bit floating-point format (although BBC BASIC
for Windows can optionally use IEEE 64-bit floats).
ArarghMai...@not.at.arargh.com
<not.m...@email.address> wrote:
<snip>
>>
>> Hmm, I see what you mean. But dropping all the extras makes it
>> pretty useless except for Beginners.
>
>...which was what Kemeny & Kurtz had in mind, wasn't it?
>
>> And slow. Maybe the answer
>> is to come up with a new name for an expanded language whose
>> beginnings started with BASIC. Any ideas?
>
>I think perhaps the OP had in mind existing languages which call
>themselves *BASIC* which are only superficially similar to the
>original. Things like XBasic, or anything from MS. (Actually, maybe
>MS's VARIANT data type was close to something K&K wanted in the first
>place... a data type that could hold *anything*, and the programmer
>doesn't have to think about the contents, just *uses* it.)
Well, yes for a system neutral version, a VARIANT data type makes
sense(, except for speed issues). It would even make more sense if
for numbers if it used the smallest or maybe the natural machine sized
integer initially and at each overflow move up to the next size as
needed.
>>>The computer on which BASIC is running should be irrelevant.
>> Data interchange could get interesting in that case. Everything
>> would have to be stored in text files, but then you get character
>> set differences,
>
>That would drive me nuts. Probably push me away from the language
>entirely.
Yes, back to cards. :-)
ArarghMai...@not.at.arargh.com
wrote:
>
I meant things like ASCII vs ECBDIC.
Of course, if you defined the interchange character set as ASCII, then
the problem goes away.
Phred
>On Apr 22, 6:46=A0pm, "Tom Lake" <tl...@twcny.rr.com> wrote:
>> Remember, BASIC is only supposed to have two data types:
>> Real numbers and strings.
>
>ANSI BASIC may have only real numbers and strings but many other
>BASICs have more data types (most have integer data types, or at least
>variant types that may be integer). BASIC in 2008 isn't "a" language,
>it's a set of more-or-less incompatible dialects. You can't say it is
>"supposed" to have any particular characteristic.
Bit like UNIX & Linux really.
(Er... Excuse me, just remembered an urgent appointment. :-)
>> The ANSI committee (of which Tom Kurtz was a member) defined
>> BASIC's real number format to be IEEE floating-point. =A0Strings
>> are ASCII characters. You could transfer numbers and words
>> between all versions of BASIC that way
>
>What about the "versions of BASIC" developed before there was such a
>thing as IEEE floating point, i.e. prior to 1985? For example BBC
>BASIC (1981) uses a 40-bit floating-point format (although BBC BASIC
>for Windows can optionally use IEEE 64-bit floats).
Cheers, Phred.
--
ppnerk...@THISyahoo.com.INVALID
Tom Lake
<ne...@rtrussell.co.uk> wrote in message
news:e3c1aad5-64df-4742...@x41g2000hsb.googlegroups.com...
> On Apr 22, 6:46 pm, "Tom Lake" <tl...@twcny.rr.com> wrote:
>> Remember, BASIC is only supposed to have two data types:
>> Real numbers and strings.
>
> ANSI BASIC may have only real numbers and strings but many other
> BASICs have more data types (most have integer data types, or at least
> variant types that may be integer). BASIC in 2008 isn't "a" language,
> it's a set of more-or-less incompatible dialects.
That's exactly what's wrong, in my opinion and the opinion of the creators
of BASIC (see Back to BASIC). BASIC should have been controlled right from
the start. We wouldn't have had all the incompatible versions then.
You can't say it is
> "supposed" to have any particular characteristic.
Sure I can. What BASIC is supposed to be is defined by its creators,
Dartmouth College Regents and the ANSI/ISO committee. Any BASIC which
is substantially different shouldn't be called BASIC. It may be a great
language but BASIC, it ain't.
Tom Lake
ne...@rtrussell.co.uk
> That's exactly what's wrong, in my opinion and the opinion of
> the creators of BASIC (see Back to BASIC). BASIC should have
> been controlled right from the start. We wouldn't have had all
> the incompatible versions then.
Many people might agree with you about what "should have been", but it
isn't and never will be. You can speculate as much as you like about
how things might have been different, but it has little relevance to
the BASIC(s) of today.
> > You can't say it is
> > "supposed" to have any particular characteristic.
> Sure I can. What BASIC is supposed to be is defined by its
> creators, Dartmouth College Regents and the ANSI/ISO committee.
You might, I suppose, argue that BASICs developed after the ANSI
standard was published should have taken more notice of it, but who
can blame them for thinking the cat was already out of the bag? In
the case of those BASICs that existed before 1987 - obviously I'm
particularly thinking of BBC BASIC - the (full) ANSI standard is
completely irrelevant.
> Any BASIC which is substantially different shouldn't be called
> BASIC. It may be a great language but BASIC, it ain't.
It seems to me that you're trying to turn the clock back and rewrite
history. Sorry, it ain't going to happen!
Adam
http://www.yourgriefmatters.com/neworleansgrief.html
Successful Grief Recovery means giving up the hope
for a different or better yesterday.
http://www.ecotao.com/holism/chaosintro.htm
"You don't see something until you have
the right metaphor to let you perceive it."
(Shaw, "echoing Thomas S. Kuhn" in Gleick, 1988).
Adam
** Posted from http://www.teranews.com **
rhnlogic
> <n...@rtrussell.co.uk> wrote in message
>
> news:e3c1aad5-64df-4742...@x41g2000hsb.googlegroups.com...
>
> > On Apr 22, 6:46 pm, "Tom Lake" <tl...@twcny.rr.com> wrote:
> >> Remember, BASIC is only supposed to have two data types:
> >> Real numbers and strings.
>
> > ANSI BASIC may have only real numbers and strings but many other
> > BASICs have more data types (most have integer data types, or at least
> > variant types that may be integer). BASIC in 2008 isn't "a" language,
> > it's a set of more-or-less incompatible dialects.
>
> That's exactly what's wrong, in my opinion and the opinion of the creators
> of BASIC (see Back to BASIC). BASIC should have been controlled right from
> the start. We wouldn't have had all the incompatible versions then.
Oh right. Like ADA. Rigorous specification as thick as
a phone book. Required something like a DOD certification
before you could release a compiler. Thus ADA is so much
more popular than BASIC... Not.
What made BASIC popular was that it could be both implemented
and used by non-experts without really reading the manual
carefully.
IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M
Chipmunk Basic: http://www.nicholson.com/rhn/basic
rhnlogic
> Dartmouth College Regents and the ANSI/ISO committee. Any BASIC which
> is substantially different shouldn't be called BASIC. It may be a great
> language but BASIC, it ain't.
Popular usage of the word would say the opposite. The
weird variant that the creators and ANSI committee produced
was not what was commonly referred to when most people talked
about programming in BASIC, so that minor sub-variant is
the one that should take some derivative name ("True Basic"),
as opposed to being called "Basic".
The Apple, Commodore, Radio Shack, Timex, BBC and MS/PC
versions were far more commonly the referents of the word.
IMHO. YMMV.
ca...@libertybasic.com
Microsoft derived BASICs really became the defacto standard. It
amazes me when people ask me if I'm ever going to make Liberty BASIC
more ANSI compliant. I have made a few QBASIC compatibility tweaks
here and there. I think that's reasonable.
I do agree with Tom that BASIC should be as simple as possible.
Liberty BASIC only has numeric and string variables. Special types
are only introduced by necessity when interfacing with external
libraries.
BASIC needs to be simple. Adding C or Java features is a mistake for
the most part. There is value in keeping things out of the language.
-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com
ne...@rtrussell.co.uk
wrote:
> BASIC needs to be simple.
Certainly it must be possible to use BASIC in a simple way, but it
doesn't follow that adding some more powerful features that *can* be
used but *need not* be is a bad thing. It seems to me that one test
of a good BASIC is not only that is it well suited to the complete
beginner (an essential requirement) but also that it doesn't 'run out
of steam' when somebody wants to progress to more advanced techniques.
> Adding C or Java features is a mistake for the most part.
> There is value in keeping things out of the language.
Can you give an example of something which you feel should be
deliberately 'kept out of' the language, and explain why? Is this the
reason why Liberty Basic can't (without the support of a 'helper' DLL)
access COM automation objects or C++ methods, which has always struck
me as a significant limitation?
ca...@libertybasic.com
wrote:
> On Apr 25, 9:23 pm, "ca...@libertybasic.com" <ca...@libertybasic.com>
> wrote:
>
> > BASIC needs to be simple.
>
> Certainly it must be possible to use BASIC in a simple way, but it
> doesn't follow that adding some more powerful features that *can* be
> used but *need not* be is a bad thing. It seems to me that one test
> of a good BASIC is not only that is it well suited to the complete
> beginner (an essential requirement) but also that it doesn't 'run out
> of steam' when somebody wants to progress to more advanced techniques.
The trouble comes with trying to reconcile the "suited to the complete
beginner" part with the "doesn't run out of steam" part. Once you
cross a certain level of "feature busy-ness" in order to satisfy the
latter then remaining suitable for the beginner becomes difficult.
What kinds of advanced techniques are you talking about? If advanced
techniques simply means that BASIC should be able to do what C and
Java can do then I suggest that (just maybe) C or Java may be more
appropriate for the task at hand. Or I guess you can just use a
version of BASIC that has a gazillion things added to it. That's
fine. Use whatever tools you like, of course. ;-)
> > Adding C or Java features is a mistake for the most part.
> > There is value in keeping things out of the language.
>
> Can you give an example of something which you feel should be
> deliberately 'kept out of' the language, and explain why? Is this the
> reason why Liberty Basic can't (without the support of a 'helper' DLL)
> access COM automation objects or C++ methods, which has always struck
> me as a significant limitation?
Well, there are so many things to keep out of a language. I'm not
saying that one feature or another isn't perfectly good for something,
but that doesn't mean that you should add every 'good' feature on its
own merit. I'm of the belief that the larger a language gets, the
harder it is to master. In some ways Liberty BASIC is already too
big, and I don't doubt that it will get bigger. Sometimes when people
ask for new features I add them, but usually I don't. Imagine what a
big pile of stuff it would be if I added everything people asked
for. ;-)
As for COM support, I don't really get many requests for that.
Perhaps you do? I may add that to LB5, but I'm not actually planning
to at this time. I suspect we really are marketing to different
niches. We most certainly are if you compare BBC BASIC to Run BASIC.
http://www.runbasic.com
Cheers!
-Carl Gundel, author of Liberty BASIC (and Run BASIC)
http://www.libertybasic.com
jj
HOW about INC and DEC?
Instead of LET variable = variable + (or -) number.
It doesn't alter the capabilities but some might claim that it makes the
listings
more readable.
Of course there may be an upper limit to how many commands make perfection.
Some BASICs might have more string commands like UPPER and LOWER, yet
some might claim that is going too far, making too many instructions.
What I am thinking is what makes a perfect BASIC?
I would suggest one which enables an easy learning curve, a reasonable
capability,
and listings that can commonly be shared a amongst a community without the
need
of an expert translation.
Too much to expect?
jj
Gordon Rahman
I would say:
- keep it simple sunshine
- the listings should be fully readable with Notebloc !
- open a microsoft window like you would open any device in BASIC.
- construct graphic possibilities like for the former COMMODORE 64 (sprites)
- don't compete against C++ or Visual BASIC for speed or complexity. Don't
mimic them.
- take the BASIC keywords from the TANDY, APPLE, MSX machines
- use PASCAL block programming
- give it away free
- make it possible to use linenumber programs as well.
- call it JustBASIC ........ oops it already is there!!!!!!
so further more
- give it hardware abbility like port reading
- open and use any DLL you like with it
- keep it small and easy to learn.
- make it shareware
-call it Liberty BASIC ........ oops it's done before .... it exists
already!!!!!
See you at LB ;)
Gordon
"jj" <in...@amd.com> schreef in bericht news:fug623$le2$1...@aioe.org...
Gordon Rahman
>
> HOW about INC and DEC?
> Instead of LET variable = variable + (or -) number.
> It doesn't alter the capabilities but some might claim that it makes the
> listings more readable.
Do you mean leaving the optional LET out?
What's the need of INC or ++
I learned BASIC: A = A + 1
> What I am thinking is what makes a perfect BASIC?
> I would suggest one which enables an easy learning curve, a reasonable
> capability and listings that can commonly be shared amongst a community
> without the need of an expert translation.
Ok, no A% and B# and so on. No lot's of separate listings containing procs
and functions,
but just everything in one listing.
Do you mean you should be able to read the listing fully with any
wordprocessor?
No need to install the language first? Yeah...
Do you wish to read them like we could read those listings from magazines
like
BYTE or CREATIVE?
> Too much to expect?
No, this is what the consumer wants. Try Just BASIC or Liberty BASIC.
Gordon.
jj
"Gordon Rahman" <gra...@planet.nl> wrote in message
news:48132540$0$6028$9a62...@news.kpnplanet.nl...
...............
> What's the need of INC or ++
RE:"++"
There is no need to introduce a failing of another language to prove
your point. I am asking for your opinion rather than stating mine.
e.g Would a listing look clearer if those A=A+1 and similar were relpaced
by INC A, DEC B, or INC A,2 or DEC A,3 etc.
Does it in any way help to make a BASIC listing more language-like rather
than a
mathematical proof?
> Do you mean you should be able to read the listing fully with any
> wordprocessor?
Not really. Only if it moves the language nearer to potential beginners who
might
otherwise be put off.
> Do you wish to read them like we could read those listings from magazines
> like
> BYTE or CREATIVE?
I wasn't quite thinking this, but I can remember some BASIC listings which
were a poor advert for their useage.
Each BASIC language variant would seem to have a community of users and a
common source for
listings or files containing listings. If these are hard to understand and
cannot easily be used and
modified, because they contain specialised "tweaks" and other non-standard
inclusions, then
this would go against the idea of BASIC.
My reason for the subject title.
jj
ne...@rtrussell.co.uk
> What's the need of INC or ++
It's primarily a performance issue. In a compiled language it's
unlikely to make much difference since A = A + 1, A += 1 and A++ will
probably all be converted to the same output (whether machine code or
some machine-independent bytecode). In an interpreted language like
Liberty Basic or BBC BASIC (please let's not get into arguments here -
LB is an interpreted language from the point of view of this
discussion) A += 1 is quite likely to be faster than A = A + 1 because
there's only one variable 'lookup' rather than two.
> No lot's of separate listings containing procs and functions,
> but just everything in one listing.
So you think huge monolithic programs are preferable to small programs
calling library routines? Might I suggest that you're way out of
touch on this one; most people would say the opposite is the case.
ca...@libertybasic.com
> > What's the need of INC or ++
>
> RE:"++"
> There is no need to introduce a failing of another language to prove
> your point. I am asking for your opinion rather than stating mine.
>
> e.g Would a listing look clearer if those A=A+1 and similar were relpaced
> by INC A, DEC B, or INC A,2 or DEC A,3 etc.
>
> Does it in any way help to make a BASIC listing more language-like rather
> than a
> mathematical proof?
Certainly INC and DEC are an interesting example. On the pro side
these are very simple additions, especially if you don't have use
extended form INC var, value. On the con side they add noise to the
language that is unnecessary. The expression a = a + 1 is extremely
simple and relies on core language syntax that the programmer uses for
other things. No new syntax is necessary so why do we need INC or
DEC?
If you are going to add a new feature to the language, it should be a
big win.
Some thoughts about addiing a new feature:
-It should look like BASIC so that the language doesn't become a hodge
podge of syntax
-It should be high level and easy to understand
-It should add capability that isn't already there (does INC?)
-If should be useful to most programmers (80/20 rule)
If a new feature causes a change in coding style that results in a
program that is not recognizably written in BASIC, then is that
program still written in BASIC? There is a sometimes blurry line that
gets crossed when doing programming language work. I know I've
tripped over that line myself. It is challenging to extend a language
while preserving what is essential about that language. No doubt
about it. Once you've added new features to a language it can be hard
to take them out.
-Carl Gundel, author of Liberty BASIC
Gordon Rahman
INC reminds me of LDIR.
LoaD the HL registers and Immediately Repeate Incrementing the Accumulator
until C register is SetFlag
Your talking assembly.
BASIC was made for the Non technicians like me.
I still have some of those BYTES magazines. Yeah, still trying to figure out
what those programmers did.
But at least I can read them. Some listings of today contain only tokens and
other mysterious things. I won't
save these "modern" listings for the comming 20 years, trying to read them.
BASIC should be easy and simple but good enough to (fully) discover Windows.
Maybe BASIC can inspire the young generation as it did with mine.
There is no need for speed. There is no need for OOP if that means that more
people
can work on one same large program. BASIC was there for educational and
recreational reasons too.
So for the individual excitement.
You know what boosted Liberty BASIC? It was easy enough to write books about
it. Some schools
started teaching Liberty BASIC. I'm giving a 24 parts "workshop" on
Programming Windows
with LibertyBASIC. And I'm no teacher at all.
Gordon.
ne...@rtrussell.co.uk
wrote:
> The trouble comes with trying to reconcile the "suited to the complete
> beginner" part with the "doesn't run out of steam" part. Once you
> cross a certain level of "feature busy-ness" in order to satisfy the
> latter then remaining suitable for the beginner becomes difficult.
I really can't see why that should be the case. If the beginner
doesn't need to use those 'advanced' features, and they are documented
in such a way as not to impair his understanding, then he can write
his 'simple' programs without them. When he eventually progresses to
a stage of wanting or needing them, they are there.
The mistake Microsoft made in VB (etc.) was to add 'advanced' features
in such a way that they *do* get in the way of understanding by a
beginner, but that isn't the only way to go about it.
> What kinds of advanced techniques are you talking about? If advanced
> techniques simply means that BASIC should be able to do what C and
> Java can do then I suggest that (just maybe) C or Java may be more
> appropriate for the task at hand.
I don't buy into the idea that there comes a point where you have to
abandon BASIC and move to a more 'advanced' language. Yes, there can
be good reasons to use C or Java but the absence of sufficiently
'advanced' facilities in BASIC shouldn't be one of them.
> I'm of the belief that the larger a language gets, the
> harder it is to master. In some ways Liberty BASIC is already too
> big, and I don't doubt that it will get bigger.
I'm absolutely with you there! BBC BASIC for Windows' run-time engine
is less than 82 Kbytes, including all the EXE file overhead. A self-
contained 'compiled' BBC BASIC program will frequently be under 100
Kbytes. What are the approximately equivalent figures for Liberty
Basic?
> As for COM support, I don't really get many requests for that.
> Perhaps you do?
I don't get "requests" for it because BBC BASIC for Windows already
supports it! Interestingly, it required *no additions to the language
whatever* to provide support for calling C++ methods and COM objects,
even though I considered neither of those when I originally specified
the language. They were possible because of a feature that all
versions of BBC BASIC have (indirection) and because I've always
supported calling API functions by address as well as by name.
The ability to access the Windows API is an important feature of both
Liberty Basic and BBC BASIC, and both can easily access the old 'C-
style' flat APIs (although, notably, LB cannot call functions exported
only by ordinal, such as PickIconDlg). However the more modern
Windows APIs (e.g. GDI+, OLE, COM, DirectX etc.) all use a C++ style
interface and I considered it important that BBC BASIC can access
those too. I'm a little surprised you don't feel the same about LB.
> I suspect we really are marketing to different niches. We most
> certainly are if you compare BBC BASIC to Run BASIC.
I would agree that Run Basic is targeted to a different niche, but
I've always considered BBC BASIC and Liberty Basic to be competing for
much the same market.
Gordon Rahman
Hi Richard,
I'll tell you my secret.
When I look at the Visual BASIC listings, I can't figure out what they do.
In the same dir I find several small listings. So I can't translate or
convert any of those listings.
The users of BASIC don't write huge monolithic programs. Do you?
My larges one (16 MB zip with BMP's) was made by just programming a piece a
time and appending it.
But I never see those listings that you suggest.
Of cource if I was working on Symphony at Microsoft, than I would need a
team and teamwork.
We found out that most Liberty BASIC programmers are individual types.
The second most asked question at LB is to have one single listing. Most
newbies want to
even place there BMP's in the same listing.
Gordon
Adam
>- the listings should be fully readable with Notebloc !
What is Notebloc?
http://www.google.com/search?q=Notebloc+editor
Results 1 - 9 of 9 for Notebloc editor.
Text displayed with the first hit:
In school they taught us how to make HTML
documents on the notebloc/notepad
Is Notebloc another name for Notepad, or is it a separate program?
If it is a separate program, where is it available?
Thanks,
ca...@libertybasic.com
wrote:
> On Apr 26, 5:33 am, "ca...@libertybasic.com" <ca...@libertybasic.com>
> wrote:
>
> > The trouble comes with trying to reconcile the "suited to the complete
> > beginner" part with the "doesn't run out of steam" part. Once you
> > cross a certain level of "feature busy-ness" in order to satisfy the
> > latter then remaining suitable for the beginner becomes difficult.
>
> I really can't see why that should be the case. If the beginner
> doesn't need to use those 'advanced' features, and they are documented
> in such a way as not to impair his understanding, then he can write
> his 'simple' programs without them. When he eventually progresses to
> a stage of wanting or needing them, they are there.
When a new user looks at included examples or visits a forum on the
web and sees code that exercises the more complicated and noisy
features of a programming language, the advanced features can scare
away the novice. It does happen.
> The mistake Microsoft made in VB (etc.) was to add 'advanced' features
> in such a way that they *do* get in the way of understanding by a
> beginner, but that isn't the only way to go about it.
And more and more so with each release of VB, but that's a trap we all
need to keep clear of.
> > What kinds of advanced techniques are you talking about? If advanced
> > techniques simply means that BASIC should be able to do what C and
> > Java can do then I suggest that (just maybe) C or Java may be more
> > appropriate for the task at hand.
>
> I don't buy into the idea that there comes a point where you have to
> abandon BASIC and move to a more 'advanced' language. Yes, there can
> be good reasons to use C or Java but the absence of sufficiently
> 'advanced' facilities in BASIC shouldn't be one of them.
I didn't mean to say that people should abandon BASIC, but if you want
to do things that BASIC isn't designed to do easily, then another
language may be the right choice.
> > I'm of the belief that the larger a language gets, the
> > harder it is to master. In some ways Liberty BASIC is already too
> > big, and I don't doubt that it will get bigger.
>
> I'm absolutely with you there! BBC BASIC for Windows' run-time engine
> is less than 82 Kbytes, including all the EXE file overhead. A self-
> contained 'compiled' BBC BASIC program will frequently be under 100
> Kbytes. What are the approximately equivalent figures for Liberty
> Basic?
I wasn't talking about the size of the runtime support, and you know
it. Besides, this is a thread about language, not implementation.
> > As for COM support, I don't really get many requests for that.
> > Perhaps you do?
>
> I don't get "requests" for it because BBC BASIC for Windows already
> supports it! Interestingly, it required *no additions to the language
> whatever* to provide support for calling C++ methods and COM objects,
> even though I considered neither of those when I originally specified
> the language. They were possible because of a feature that all
> versions of BBC BASIC have (indirection) and because I've always
> supported calling API functions by address as well as by name.
>
> The ability to access the Windows API is an important feature of both
> Liberty Basic and BBC BASIC, and both can easily access the old 'C-
> style' flat APIs (although, notably, LB cannot call functions exported
> only by ordinal, such as PickIconDlg). However the more modern
> Windows APIs (e.g. GDI+, OLE, COM, DirectX etc.) all use a C++ style
> interface and I considered it important that BBC BASIC can access
> those too. I'm a little surprised you don't feel the same about LB.
Why are you surprised? There are compromises to make on all sorts of
levels. BBC BASIC and Liberty BASIC are really very different in
their design, implementation, and purpose.
> > I suspect we really are marketing to different niches. We most
> > certainly are if you compare BBC BASIC to Run BASIC.
>
> I would agree that Run Basic is targeted to a different niche, but
> I've always considered BBC BASIC and Liberty Basic to be competing for
> much the same market.
No, I really don't think so. Liberty BASIC is simpler than other
BASICs for a very deliberate reason. There are a lot of books out
there that teach Liberty BASIC (or its free cousin Just BASIC). I
never once asked the authors or publishers to promote LB. They seem
to have come to the conclusion on their own that it is the right BASIC
for the end user.
-Carl Gundel, author of Liberty BASIC
Gordon Rahman
I do mean "notebook". Anyway the program that you get with XP.
Mine is Dutch so we call it "kladblok".
Sorry.
Gordon
"Adam" <n...@spam.net> schreef in bericht
news:5ng61459i9cg4v26j...@4ax.com...
ne...@rtrussell.co.uk
> The users of BASIC don't write huge monolithic programs. Do you?
They sometimes write huge programs, yes. The biggest program written
in BBC BASIC that I'm aware of is a commercial ePoS (electronic Point
of Sale) application, the (tokenized) BASIC code for which totals just
over 1.5 Megabytes (over 41,000 lines)! Fortunately it's written in a
modular fashion, so you don't have to load all that into the editor at
once.
> Most newbies want to even place there BMP's in the same listing.
Newbies make strange requests! Fortunately they (usually) eventually
learn that there are better ways to do things.
ne...@rtrussell.co.uk
wrote:
> When a new user looks at included examples or visits a forum on the
> web and sees code that exercises the more complicated and noisy
> features of a programming language, the advanced features can scare
> away the novice. It does happen.
That is very true. I do think some people are, unfortunately, put off
BBC BASIC by what they see in some of the 'clever' code posted on
forums etc. They shouldn't be, and if they knew anything at all about
why BBC BASIC was developed in the first place they wouldn't be. LB
isn't immune to the problem: some of the Windows API examples can be
pretty intimidating.
> I wasn't talking about the size of the runtime support, and you know
> it. Besides, this is a thread about language, not implementation.
OK, choose another measure then. BBC BASIC has 138 keywords (reserved
words); how many does Liberty Basic have? By any criterion, I don't
think you can call BBC BASIC a 'bloated' language.
> BBC BASIC and Liberty BASIC are really very different in
> their design, implementation, and purpose.
Do you really think so? I would (in all honesty) have said their
"design" and "purpose" were very similar. Liberty Basic is
(practically) the only BASIC I am comfortable using apart from BBC
BASIC, and one reason is their similarity in user interface and
general capabilities.
> They seem to have come to the conclusion on their own that it is
> the right BASIC for the end user.
A perfectly reasonable conclusion, especially in a part of the world
that has virtually never heard of BBC BASIC. In those countries where
the BBC Micro was popular in the 1980s (principally the UK,
Australasia and parts of Europe) BBC BASIC holds that same position.
ca...@libertybasic.com
wrote:
> On Apr 26, 5:34 pm, "ca...@libertybasic.com" <ca...@libertybasic.com>
> wrote:
>
> > When a new user looks at included examples or visits a forum on the
> > web and sees code that exercises the more complicated and noisy
> > features of a programming language, the advanced features can scare
> > away the novice. It does happen.
>
> That is very true. I do think some people are, unfortunately, put off
> BBC BASIC by what they see in some of the 'clever' code posted on
> forums etc. They shouldn't be, and if they knew anything at all about
> why BBC BASIC was developed in the first place they wouldn't be. LB
> isn't immune to the problem: some of the Windows API examples can be
> pretty intimidating.
Interfacing with external libraries is unavoidably technical. Anyway
I was only trying to make an argument for keeping things simple. I
wasn't pointing to any languages in particular.
> > I wasn't talking about the size of the runtime support, and you know
> > it. Besides, this is a thread about language, not implementation.
>
> OK, choose another measure then. BBC BASIC has 138 keywords (reserved
> words); how many does Liberty Basic have?
147
> By any criterion, I don't think you can call BBC BASIC a 'bloated' language.
When did I say BBC BASIC is bloated?
ne...@rtrussell.co.uk
wrote:
> When did I say BBC BASIC is bloated?
You didn't. I was responding to your comment that "In some ways
Liberty BASIC is already too
big", the implication being (as I read it) that size was one reason
for not adding features like support for C++ APIs. My point was that
providing such support (which BBC BASIC for Windows does) is possible
without bloating the language.
A fairly fundamental difference between the two dialects is that BBC
BASIC contains just one keyword for accessing Windows; support for
dialog boxes, controls, menus, toolbars etc. is not built into the
language itself but is provided by libraries. In contrast LB has much
of this functionality built into the language. I suspect the origins
of this difference in approach are historical: Liberty Basic
presumably never went through a phase of having to fit in a 16 Kbyte
ROM!
Stephen J. Rush
> so further more
> - give it hardware abbility like port reading - open and use any DLL you
> like with it
If it's going to run on a modern multitasking operating system,
unrestricted access to the hardware is a Bad Thing. Suppose my program
wants to grab the printer port, but another job happens to be printing?
What if I try to use two DLLs that have different parameter-passing
conventions? If I pass an integer to a routine that expects a pointer,
the best I can expect is for my program to abort. The worst depends on
how good the operating system is about enforcing memory protection. Any
of the POSIX family will probably just kill the offending process, but
Windows could do anything from the BSOD to allowing silent corruption of
another program's data.
I favor implementations that allow a beginner to use a subset, but have
resources that he can pick up later. FreeBASIC, for example, will let
you use most of the old Dartmouth conventions: line numbers, global
variables, GOSUB/RETURN subroutines. It does (unless you use a compiler
switch to set QBasic mode) require you to declare your variables, but
that's a good habit to get into from the beginning. Of course, FreeBASIC
is far from simple internally. It's GPL'd freeware, so I downloaded the
source tree. A lot of it, though written to complie itself, isn't
immediately recognizable as BASIC.
rhnlogic
> I favor implementations that allow a beginner to use a subset, but have
> resources that he can pick up later. FreeBASIC, for example, will let
> you use most of the old Dartmouth conventions: line numbers, global
> variables, GOSUB/RETURN subroutines. It does (unless you use a compiler
> switch to set QBasic mode) require you to declare your variables,
That's very close to my philosophy for Chipmunk Basic.
A beginner should be able to type in and immediately run
a simple and easy-to-learn subset the language, perhaps right
out of a 30 year old book or kid's magazine article on
learning about computers and programming, and without having
to do any special configuration or limited mode setup beyond
simply launching Chipmunk Basic.
Chipmunk Basic: http://www.nicholson.com/rhn/basic
10 print "Hello World"
20 goto 10
run
ne...@rtrussell.co.uk
> On Apr 26, 4:17 pm, "Stephen J. Rush" <sjr...@comcast.net> wrote:
> > I favor implementations that allow a beginner to use a subset, but have
> > resources that he can pick up later.
>
And mine too for BBC BASIC for Windows. It's not as though I had any
choice in the matter: to be called BBC BASIC it still has to run those
old 1980s programs written for the original 8-bit 6502 implementation
in a 16K ROM. All the 'modern' additions have been made in such a way
that compatibility with the original is not compromised (well,
hardly).
> A beginner should be able to type in and immediately run
> a simple and easy-to-learn subset the language, perhaps right
> out of a 30 year old book or kid's magazine article on
> learning about computers and programming, and without having
> to do any special configuration or limited mode setup
Absolutely. I regularly receive thanks from people who have
'downgraded' from Visual Basic or PowerBasic to BBC BASIC and, despite
having to put up with a somewhat slower execution speed, are grateful
for the immediacy of an interpreted language.
I see no great difficulty reconciling:
10 PRINT "Hello world!"
20 GOTO 10
with accessing a modern C++ style (OLE) Windows API:
DIM IPicture{QueryInterface%, AddRef%, Release%, get_Handle%, \
\ get_hPal%, get_Type%, get_Width%, get_Height%, \
\ Render%, set_hPal%, get_CurDC%, SelectPicture%, \
\ get_KeepOriginalFormat%, put_KeepOriginalFormat%, \
\ PictureChanged%, SaveAsFile%, get_Attributes%}
!(^IPicture{}+4) = !gpPicture%
SYS IPicture.get_Width%, gpPicture%, ^PictureWidth%
SYS IPicture.get_Height%, gpPicture%, ^PictureHeight%
Gordon Rahman
"Stephen J. Rush" <sjr...@comcast.net> schreef in bericht
news:xeGdndaCZMCTJY7V...@comcast.com...
> On Sat, 26 Apr 2008 14:38:32 +0200, Gordon Rahman wrote:
>
>
> If it's going to run on a modern multitasking operating system,
> unrestricted access to the hardware is a Bad Thing. Suppose my program
> wants to grab the printer port, but another job happens to be printing?
>
This problem is solved. I know a Windows BASIC computerlanguage that
already does this things. The programmer is in charge.
>
> What if I try to use two DLLs that have different parameter-passing
> conventions? If I pass an integer to a routine that expects a pointer,
> the best I can expect is for my program to abort.
>
This problem is solved. I know a Windows BASIC computerlanguage that
already does this things. The programmer is in charge.
>
> I favor implementations that allow a beginner to use a subset, but have
> resources that he can pick up later.
I agree. I know a Windows BASIC computerlanguage that
already does this things. The programmer is in charge.
Gordon.
Gordon Rahman
"rhnlogic" <rhnl...@yahoo.com> schreef in bericht
news:9c938440-8cc3-485a...@1g2000prg.googlegroups.com...
> On Apr 26, 4:17 pm, "Stephen J. Rush" <sjr...@comcast.net> wrote:
> A beginner should be able to type in and immediately run
> a simple and easy-to-learn subset the language, perhaps right
> out of a 30 year old book or kid's magazine article on
> learning about computers and programming, and without having
> to do any special configuration or limited mode setup beyond
> simply launching Chipmunk Basic.
>
>
> 10 print "Hello World"
> 20 goto 10
> run
>
I guess it's even easier. You don't need to install anything.
Simply go to the RunBASIC.com website and there you go.
Just type it in and run it.
And if you want to program and save your listing, then I would
suggest you to use a language where you can type
notice "Hello World"
to get a Windows messagebox showing your message.
Gordon
ne...@rtrussell.co.uk
> This problem is solved. I know a Windows BASIC computerlanguage that
> already does this things. The programmer is in charge.
> This problem is solved. I know a Windows BASIC computerlanguage that
> already does this things. The programmer is in charge.
> And if you want to program and save your listing, then I would
> suggest you to use a language where you can type
> notice "Hello World"
It really isn't helpful to suggest that Liberty Basic doesn't suffer
from problems. Liberty Basic has many shortcomings; as does BBC
BASIC. I have strenuously avoided making any claims that BBC BASIC is
"better" than Liberty Basic; they each have their strengths and
weaknesses. One reason why I have made an effort to understand and
use Liberty Basic is, perhaps strangely, so I can learn by comparison
more about BBC BASIC!
Incidentally, to display a message box in BBC BASIC you do:
SYS "MessageBox", 0, "Hello world!", 0, 0
Gordon Rahman
<ne...@rtrussell.co.uk> schreef in bericht
news:8e9135ca-e95f-4790...@34g2000hsh.googlegroups.com...
>One reason why I have made an effort to understand and
>use Liberty Basic is, perhaps strangely, so I can learn by comparison
>more about BBC BASIC!
>
>Incidentally, to display a message box in BBC BASIC you do:
>
>SYS "MessageBox", 0, "Hello world!", 0, 0
>
The Microsoft Windows function to open a Messagebox "MessageBoxA", is
situated in the
USER32.DLL This DLL you can find in your windows system32 directory,
so in Liberty BASIC you can use it like so:
CallDLL #user32, "MessageBoxA",_
hWnd As uLong,_
"Hello world" As Ptr,_
title$ As Ptr,_
wType As uLong,_
r As Long
Calling a function in a DLL (a MS DLL in this case) works according to the
rules
that Microsoft demands. I'm not that good yet in Windows, but I chose LB
because I can learn how Microsoft constructed their Windows (there are more
then 54
different MessageBoxen).
I decided to used the native Liberty BASIC keyword notice:
notice "Hello world!"
Gordon.
ArarghMai...@not.at.arargh.com
<gra...@planet.nl> wrote:
><ne...@rtrussell.co.uk> schreef in bericht
>news:8e9135ca-e95f-4790...@34g2000hsh.googlegroups.com...
>
>>One reason why I have made an effort to understand and
>>use Liberty Basic is, perhaps strangely, so I can learn by comparison
>>more about BBC BASIC!
>>
>>Incidentally, to display a message box in BBC BASIC you do:
>>
>>SYS "MessageBox", 0, "Hello world!", 0, 0
>>
<snip>
> Liberty BASIC sample
>
>CallDLL #user32, "MessageBoxA",_
> hWnd As uLong,_
> "Hello world" As Ptr,_
> title$ As Ptr,_
> wType As uLong,_
> r As Long
<snip>
For comparison, in BCET with this declare, either of these work:
-- sample --
DECLARE FUNCTION MessageBox Lib "User32" StdCall _
ALIAS "MessageBoxA" (BYVAL Handle AS LONG, _
BYVAL Message AS string, _
BYVAL Heading AS string, _
BYVAL Style AS LONG) AS LONG
Handle = 0
m$ = "Hello, World!"
h$ = "From a Compiled Basic Program"
Style = MbAbortRetryIgnore OR MbIconExclamation
R = MessageBox(Handle, m$, h$, Style)
R = MessageBox(Handle, "Hello, World!", _
"From a Compiled Basic Program", Style)
-- end sample --
I actually haven't tested this for the last few releases, but it used
to work. :-)
You could also DECLARE it as a SUB and ignore the return code.
--
ArarghMail804 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
ne...@rtrussell.co.uk
> For comparison, in BCET with this declare, either of these work:
So can you, and if so how, call a 'modern' (e.g. OLE) API with a C++
interface, such as the IPicture::get_Width function I listed the BBC
BASIC code for earlier? The IPicture COM interface is really useful
for loading GIF and JPEG images, and has been present ever since
Windows 95.
ArarghMai...@not.at.arargh.com
>On Apr 28, 6:42 am, ArarghMail804NOS...@NOT.AT.Arargh.com wrote:
>> For comparison, in BCET with this declare, either of these work:
>
>So can you, and if so how, call a 'modern' (e.g. OLE) API with a C++
>interface, such as the IPicture::get_Width function I listed the BBC
>BASIC code for earlier? The IPicture COM interface is really useful
>for loading GIF and JPEG images, and has been present ever since
>Windows 95.
>
This?
> DIM IPicture{QueryInterface%, AddRef%, Release%, get_Handle%, \
> \ get_hPal%, get_Type%, get_Width%, get_Height%, \
> \ Render%, set_hPal%, get_CurDC%, SelectPicture%, \
> \ get_KeepOriginalFormat%, put_KeepOriginalFormat%, \
> \ PictureChanged%, SaveAsFile%, get_Attributes%}
>
> !(^IPicture{}+4) = !gpPicture%
>
> SYS IPicture.get_Width%, gpPicture%, ^PictureWidth%
> SYS IPicture.get_Height%, gpPicture%, ^PictureHeight%
Possibly. I presume that the %'s refer to 32-bit things, not 16-bit.
I also presume that the "get_Width" entry point is 24 bytes past
"IPicture" or thereabouts. Have to figure that out.
oicdl.h shows this for get_Width:
HRESULT ( STDMETHODCALLTYPE __RPC_FAR *get_Width )(
IPicture __RPC_FAR * This,
/* [out] */ OLE_XSIZE_HIMETRIC __RPC_FAR *pWidth);
So, the DECLARE for get_Width would look something like:
DECLARE FUNCTION IPicture_get_Width ALIAS "IPicture+24" _
LIB "???" cdecl (BYVAL gpPicture AS LONG, _
PictureWidth AS LONG) AS LONG
and the call:
Rc = IPicture.get_Height(gpPicture, PictureHeigh)
Assuming all my guesses are correct, and the funky ALIAS works, and I
knew the DLL name and calling convention(cdecl, StdCall ...), this
should work.
You could use "IPicture.get_Width" for "IPicture_get_Width", but
currently that would get some boring warnings about period used not in
conjunction with TYPE elements.
Generally speaking, if you can write the DECLARE, BCET can call it.
The only thing I currently know won't work, is passing a small
structure in a register as one or more of the Console routines
expects. I don't remember which one just now. Maybe it was
SetConsoleCursorPosition? There are workarounds for that, though.
BTW, what does
!(^IPicture{}+4) = !gpPicture%
mean?
ne...@rtrussell.co.uk
> I presume that the %'s refer to 32-bit things, not 16-bit.
> I also presume that the "get_Width" entry point is 24 bytes past
> "IPicture" or thereabouts.
Yes, correct on both counts.
> BTW, what does
> !(^IPicture{}+4) = !gpPicture%
> mean?
The ! is equivalent to C's * (indirection) operator, and ^ is
equivalent to C's & (address-of) operator. What it is doing is
modifying the address of the IPicture structure, so that instead of
pointing to memory allocated by BASIC it's pointing to the COM
interface's Vtable. It's really only a cheat that allows you to use
IPicture.get_Width rather than IPicture!24, so not fundamental to
accessing the COM interface.
Tom Lake
<ne...@rtrussell.co.uk> wrote in message
news:31393d52-f8e6-4148...@w7g2000hsa.googlegroups.com...
On Apr 28, 1:38 pm, ArarghMail804NOS...@NOT.AT.Arargh.com wrote:
> I presume that the %'s refer to 32-bit things, not 16-bit.
> I also presume that the "get_Width" entry point is 24 bytes past
> "IPicture" or thereabouts.
Yes, correct on both counts.
> BTW, what does
> !(^IPicture{}+4) = !gpPicture%
> mean?
The ! is equivalent to C's * (indirection) operator, and ^ is
equivalent to C's & (address-of) operator. What it is doing is
modifying the address of the IPicture structure, so that instead of
pointing to memory allocated by BASIC it's pointing to the COM
interface's Vtable. It's really only a cheat that allows you to use
IPicture.get_Width rather than IPicture!24, so not fundamental to
accessing the COM interface.
Now THAT syntax is definitely not keeping with the spirit of BASIC!
Tom Lake
Adam
Amen!
Address-of and indirection are "system functions", like VARPTR. Why
not use words instead of single-character symbols for these functions?
It saves keystrokes when typing statements, but it seems to sacrifice
readability for the reduction in typing.
It allows the statement to be shorter, but brevity doesn't seem to be
a major goal in dialects which specify subroutines with the syntax:
SUB name(byref x as int, byref y as int, byref x as int)
Maybe OBJ32_ADDR for "object address"? That would give three clues
economically (both when composing the program and when reading it):
1. The argument must be an object
2. The result is a 32-bit (unsigned?) integer
3. The function returns a memory address
Having OBJ16_, OBJ32_, and OBJ64_ forms could nip some foreseeable
platform-incompatibility problems in the bud.
If a BASIC dialect has integers of various lengths, the programmer may
have to know (and specify) what kind of variable to use with the
"^"=address-of operator. Providing a clue in the keyword could save a
lot of debugging time.
IIRC, ANSI BASIC uses single-character symbols only for math
operators, string concatenation, certain logical operators, and a
REMark prefix.
I don't recall whether "?"="print" is part of ANSI BASIC.
Gordon Rahman
snip>>
>>
>>Now THAT syntax is definitely not keeping with the spirit of BASIC!
>
> Amen!
>
Gordon
ne...@rtrussell.co.uk
> >Now THAT syntax is definitely not keeping with the spirit
> >of BASIC!
> Amen!
I tend to agree. Welcome to the wonderful world of BBC BASIC!
> Address-of and indirection are "system functions", like
> VARPTR. Why not use words instead of single-character symbols
> for these functions?
I presume for brevity. You'd really have to ask Acorn because the
indirection operators (? and !) in BBC BASIC descend, I think, from
their earlier Atom BASIC. They were not asked for by the BBC so you
can't hold me responsible!
Having said that, and with hindsight, the indirection operators are
some of the most powerful features of BBC BASIC and - along with the
embedded assembler - are what make so many things possible that
wouldn't otherwise be.
You can consider BBC BASIC to have some of C's low-level capabilities
(after all, C also uses single character operators for indirection and
address-of) which bring with them both power and danger!
H-Man
> Hi, if BASIC were to be written today, what changes would you have made,
> if any, consistent with the meaning of the acronym? I am thinking about the
> physical limitations and the pressures to make the language like some of
> it's
> now little used competitors.
>
> For example, I have always wondered why those "doit" instructions -
> FOR/RETURN/
> DO/WHILE etc are not all part of one instruction with several parameters.
>
> Some of the differences between different BASICS are surely unnecessary and
> not
> consistent with the original basis for it's creation.
>
> Perhaps sales of BASIC are not to or for beginners anymore? Perhaps the
> "educational" factor
> once used to sell the language is not of much interest?
>
> Has modern BASIC evolved into a development language for experts?
>
> jj
This is a really interesting thread. Personally it doesn't really matter to
me if all BASICs conforms to a standard or not. It is, I think, important
that there is a standard to use as a starting point, but to be honest, a
basic BASIC is more or less useless to me. Currently I use PureBasic which
has pretty much anything I need right now, and whatever it doesn't have, I
can create on my own. The learning curve was reasonably short for me,
unlike pascal, C, C+, C++, Java, even .NET stuff. Mileage may vary, but for
me, getting the job done is far more important than is it standard. The
additional power available in PureBasic is occasionally very welcome. Like
LB the visual designer is a very useful RAD bonus as well.
This is just opinion, but part of what makes a language useful to me as a
developer, is what tools does it come with.
--
HK
rhnlogic
> This is a really interesting thread. Personally it doesn't really matter to
> me if all BASICs conforms to a standard or not. It is, I think, important
> that there is a standard to use as a starting point, but to be honest, a
> basic BASIC is more or less useless to me.
That's excellent. Given a choice between features for
power-users and features for beginners, the originating
philosophy of the Basic programming language is best served
by not including power-user features if they would in the
least be in the way of or confusing to beginners.
Even though most programming languages are close enough
to Turing-complete for it to be a temptation, trying to
make a single language useful for everybody can end in a
language closer to useless for everybody.
IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M
Chipmunk Basic: http://www.nicholson.com/rhn/basic
H-Man
In the end I could care less if they call it "basic" or "basic like", makes
me no nevermind, so long as it fits my needs. It's completely wonderful and
exciting that we have so many options available to us, n o matter what it's
called!
--
HK
ArarghMai...@not.at.arargh.com
>On Apr 28, 1:38 pm, ArarghMail804NOS...@NOT.AT.Arargh.com wrote:
>> I presume that the %'s refer to 32-bit things, not 16-bit.
>> I also presume that the "get_Width" entry point is 24 bytes past
>> "IPicture" or thereabouts.
>
>Yes, correct on both counts.
>
>> BTW, what does
>> !(^IPicture{}+4) = !gpPicture%
>> mean?
>
>The ! is equivalent to C's * (indirection) operator, and ^ is
>equivalent to C's & (address-of) operator. What it is doing is
>modifying the address of the IPicture structure, so that instead of
>pointing to memory allocated by BASIC it's pointing to the COM
>interface's Vtable. It's really only a cheat that allows you to use
>IPicture.get_Width rather than IPicture!24, so not fundamental to
>accessing the COM interface.
>
OK. I have never actually ever called a COM interface routine. Would
the reference to "IPicture" be an actual routine entry point or a
pointer to a Vtable? Or something else? If not an actual entry
point, then the DECLARE I wrote won't work. I would have to run a
sample thru a C++ compiler to see what kind of code it generates.
Assuming the result is even readable. :-)
Tom Lake
"rhnlogic" <rhnl...@yahoo.com> wrote in message
news:afab050c-eb76-48a3...@l28g2000prd.googlegroups.com...
> That's excellent. Given a choice between features for
> power-users and features for beginners, the originating
> philosophy of the Basic programming language is best served
> by not including power-user features if they would in the
> least be in the way of or confusing to beginners.
Exactly the point I was trying (not too eloquently) to make.
I may have sounded like I don't want BASIC to evolve or grow.
That's not the case at all! The foremost question developers
should ask themselves when contemplating a new feature
is whether or not that feature will make life easier or harder
for beginners. Actually, developers shouldn't even be
participating in this thread since y'all are programming
geniuses (and no, I'm not being facetious!) and probably don't
even remember what it was like to be totally clueless about
what a programming language is and what it does.
BASIC certainly was NOT written for guys (and Alyce Watson)
like you to use! 8^)
Tom Lake
ne...@rtrussell.co.uk
> Actually, developers shouldn't even be
> participating in this thread since y'all are programming
> geniuses (and no, I'm not being facetious!) and probably don't
> even remember what it was like to be totally clueless about
> what a programming language is and what it does.
Before becoming a 'developer' I was closely involved with the BBC's
Computer Literacy Project in selecting Acorn as a supplier and in
specifying BBC BASIC. My (and the BBC's) concerns for the language at
that point were precisely the ones you espouse: suitability for
beginners and encouragement of good programming skills. Inclusion of
'power' features for the sophisticated programmer came about partly
through Acorn's input and (much) later on when I developed BBC BASIC
for Windows. None of those features make life harder for beginners.
So, I genuinely believe that because of its background and history BBC
BASIC really can claim to be an exception to the rule: it is *both*
well suited to the complete beginner *and* useful for virtually
anybody and for virtually any application.
jj
How about the average length of keywords? They must have been shortened to
fit in the tiny memories available. Was it good fortune that, say ABS, is
the
correct balance between economy and verbosity? Perhaps ABSOLUTE?
I favour the abbreviations, (not those awful single character symbols
though)
but then I am not the beginner I was.
jj
Tom Lake
"jj" <in...@amd.com> wrote in message news:fv7587$boh$1...@aioe.org...
> How about the average length of keywords? They must have been shortened to
> fit in the tiny memories available. Was it good fortune that, say ABS, is
> the
> correct balance between economy and verbosity? Perhaps ABSOLUTE?
No, the original BASIC ran on a GE mainframe and had adequate core
(Known as RAM to you kids!) to run without chopping off the function names.
Tom Lake
rhnlogic
> "jj" <in...@amd.com> wrote in messagenews:fv7587$boh$1...@aioe.org...
> > How about the average length of keywords? They must have been shortened to
> > fit in the tiny memories available. Was it good fortune that, say ABS, is
> > the
> > correct balance between economy and verbosity? Perhaps ABSOLUTE?
The 3 letter function names are long enough for most people
to guess the full name, and without have to memorize a table
of punctuation abuse.
> No, the original BASIC ran on a GE mainframe and had adequate core
> (Known as RAM to you kids!) to run without chopping off the function names.
Mainframe and "adequate core" are relative terms. A GE-235
mainframe, on which BASIC was developed, had 8 to 16
kilowords of core memory (with 2.5 8-bit bytes per 20-bit
word, or 20 to 40 kBytes total, less than the amount of
cache memory on some of today's ARM cell phone processors)
and had a memory cycle time of 167 kHz.
Note again that the units above are kilowords (not mega or
giga) and kiloHertz (not MHz or GHz).
GE-235 Brochure here:
http://archive.computerhistory.org/resources/text/GE/GE.235.1964.102646091.pdf
A GE-235 does look like it took up a room about the size of
a volleyball court though.
Derek
On thing I would like to add to BASIC is comprehensive string pattern
matching. I first found out how useful this was when I was exposed to
SNOBOL4, a language which, like BASIC was intended for use by
humanities scholars who had never thought of touching a computer as
much as for scientists familiar with mathematics. This concept proved
so useful that it has been used in many languages, AWK and PERL being
two of the better known examples. It's the big item that I would like
to see added to BASIC.
Cheers
Derek
ArarghMai...@not.at.arargh.com
wrote:
<snip>
>On thing I would like to add to BASIC is comprehensive string pattern
>matching. I first found out how useful this was when I was exposed to
>SNOBOL4, a language which, like BASIC was intended for use by
>humanities scholars who had never thought of touching a computer as
>much as for scientists familiar with mathematics. This concept proved
>so useful that it has been used in many languages, AWK and PERL being
>two of the better known examples. It's the big item that I would like
>to see added to BASIC.
Something like need not be added as part of the language, but could
implemented as a callable SUB or FUNCTION.
I played around with SNOBOL way, way back in the early 70s, on a TSO
system, but never really learned much about it. Playing some 'Doctor'
program. :-) Maybe it's time to dig into it.
Tom Lake
"rhnlogic" <rhnl...@yahoo.com> wrote in message
news:dd145050-6655-4c0e...@y18g2000pre.googlegroups.com...
> On Apr 29, 9:54 am, "Tom Lake" <tl...@twcny.rr.com> wrote:
>> No, the original BASIC ran on a GE mainframe and had adequate core
>> (Known as RAM to you kids!) to run without chopping off the function
>> names.
>
> Mainframe and "adequate core" are relative terms. A GE-235
> mainframe, on which BASIC was developed, had 8 to 16
> kilowords of core memory (with 2.5 8-bit bytes per 20-bit
> word, or 20 to 40 kBytes total, less than the amount of
> cache memory on some of today's ARM cell phone processors)
> and had a memory cycle time of 167 kHz.
That's true but the 16 KW was plenty for the original BASIC.
That just shows how bloated current OSes have become!
There was a second GE communications computer connected
that was dedicated to I/O processing and that system could
handle dozens of simultaneous users even as small as it is by
today's standards. It was an exciting time in Phoenix and
Schenectady where the GE plants were!
Tom Lake
MC PRTK
> On Tue, 22 Apr 2008 15:36:03 +0000 (UTC), "Auric__"
> <not.m...@email.address> wrote:
>
> <snip>
>>>
>>> Hmm, I see what you mean. But dropping all the extras makes it
>>> pretty useless except for Beginners.
>>
>>...which was what Kemeny & Kurtz had in mind, wasn't it?
>>
>>> And slow. Maybe the answer
>>> is to come up with a new name for an expanded language whose
>>> beginnings started with BASIC. Any ideas?
>>
>>I think perhaps the OP had in mind existing languages which call
>>themselves *BASIC* which are only superficially similar to the
>>original. Things like XBasic, or anything from MS. (Actually, maybe
>>MS's VARIANT data type was close to something K&K wanted in the first
>>place... a data type that could hold *anything*, and the programmer
>>doesn't have to think about the contents, just *uses* it.)
> Well, yes for a system neutral version, a VARIANT data type makes
> sense(, except for speed issues). It would even make more sense if
> for numbers if it used the smallest or maybe the natural machine sized
> integer initially and at each overflow move up to the next size as
> needed.
>
>>>>The computer on which BASIC is running should be irrelevant.
>>> Data interchange could get interesting in that case. Everything
>>> would have to be stored in text files, but then you get character
>>> set differences,
>>
>>That would drive me nuts. Probably push me away from the language
>>entirely.
> Yes, back to cards. :-)
Well, speaking as a complete newbie, who tries a little bit of programming
on good ol' GWBASIC, i guess i'll hav to try programming in C to know if
its better. As for the topic, I think BASIC, especially Microsoft versions
like GWBASIC n QuickBasic are pretty much good. But I think BASIC needs
some hardware control options, like controlling COM n USB ports,maybe more
screen controls, like 640x480 n 800x600 graphics, RGB colors etc.
--
With Great Power Comes Great Responsibility.
(Ben Railley in Spiderman)
ArarghMai...@not.at.arargh.com
<prtk.un...@gmail.com> wrote:
<snip>
>
>Well, speaking as a complete newbie, who tries a little bit of programming
>on good ol' GWBASIC, i guess i'll hav to try programming in C to know if
>its better. As for the topic, I think BASIC, especially Microsoft versions
>like GWBASIC n QuickBasic are pretty much good.
Yes, especially for when they were written.
>But I think BASIC needs
>some hardware control options, like controlling COM n USB ports,maybe more
>screen controls, like 640x480 n 800x600 graphics, RGB colors etc.
I don't.
What support there is, is there because the underlying OS, DOS in this
case, didn't provide enough.
IMO, hardware support should have been handled via IOCTLs to an open
channel, not specicaized statements.
So, instead of:
OPEN "COMn: optlist1 optlist2" [FOR mode] AS [#]filenum% [LEN=reclen%]
you would have:
OPEN "COMn" [FOR mode] AS [#]filenum% [LEN=reclen%]
and
IOCTL [#]filenumber%, string$
Where string$ has the "optlist1 optlist2" info.
That way, support for ANY device can be provided, and not require
BASIC to modified for each and every device that someone wants to use.
--
ArarghMail805 at [drop the 'http://www.' from ->] http://www.arargh.com
rhnlogic
> On Sun, 11 May 2008 01:38:25 +0530, MC PRTK
>
>
> <snip>
>
> >Well, speaking as a complete newbie, who tries a little bit of programming
> >on good ol' GWBASIC, i guess i'll hav to try programming in C to know if
> >its better. As for the topic, I think BASIC, especially Microsoft versions
> >like GWBASIC n QuickBasic are pretty much good.
>
> Yes, especially for when they were written.
>
> >But I think BASIC needs
> >some hardware control options, like controlling COM n USB ports,maybe more
> >screen controls, like 640x480 n 800x600 graphics, RGB colors etc.
>
> I don't.
>
> What support there is, is there because the underlying OS, DOS in this
> case, didn't provide enough.
>
> IMO, hardware support should have been handled via IOCTLs to an open
> channel, not specicaized statements.
Completely useless for the target audience, Beginners,
who know and should have to know nothing about IOCTLs
and such. What there should be are just simple and
almost obvious commands, such as
PRINT for printing on the ASR-33 teletype,
Beep and Sound for computers with speakers,
maybe Spin Left and Spin Right for computers with propellers.
Of course, that's neither extensible nor portable; but other
languages are better architected for those purposes; no need
to make Basic as unusable for Beginners by adding the flaws
of those other languages.
IMHO. YMMV.
--
rhn A.T. nicholson d.0.t C-o-M
ArarghMai...@not.at.arargh.com
<rhnl...@yahoo.com> wrote:
<snip>
>
>Completely useless for the target audience, Beginners,
>who know and should have to know nothing about IOCTLs
>and such. What there should be are just simple and
>almost obvious commands, such as
>PRINT for printing on the ASR-33 teletype,
>Beep and Sound for computers with speakers,
>maybe Spin Left and Spin Right for computers with propellers.
I have no problem with statements like PRINT, LOCATE, COLOR, CLS,
BEEP, SOUND, INPUT and maybe even LPRINT (which I don't support in
BCET). Those could be considered to be basic I/O statements. (Pun
intended) :-)
My problem is with having to support a multitude of various oddball
serial ports, USB ports, parallel ports, . . .
And just look at all the various adapters that are supported by the
SCREEN statement - 6 in PDS, 8 in QBasic. I just think it would have
been better if those were handled by drivers, and not in Basic.
>Of course, that's neither extensible nor portable; but other
>languages are better architected for those purposes; no need
>to make Basic as unusable for Beginners by adding the flaws
>of those other languages.
And another question might be: How often to beginners actually use any
I/O except for the keyboard, display and printer? And data files, of
course.