 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> In a similar was, AMOS BASIC has local variables, named functions and
> procedures, separate compilation, and a whole chock-load of features. In
> fact, so many features that it hardly counts as "BASIC" any more; it's
> more like a brand new language with a superficial resemblance to BASIC...
If I recall correctly, the original BASIC, and the vast majority of
clones for a pretty long time, didn't even have the concept of a function.
They had subroutines (the most typical keyword to jump to one being GOSUB)
which were just slightly fancier GOTO labels.
Every single variable was global, of course. (No such thing as a variable
local to a subroutine.)
And forget about modules and separate source files for subroutines.
The whole program was always in one single file. (Heck, even the concept
of "file" was not really well-defined in the age of punch cards and magnetic
tapes.)
The only control structure other than GOTO was an IF (and you were lucky
if your brand of BASIC supported an ELSE branch.) Anything that couldn't be
done with IF had to be done with GOTO.
And the language was completely untyped, of course. Typically you could
have two types: An integral (usually floating point) and a string. That's
about it. Some variants possibly supported some kind of array or enumeration
structure. Forget about creating your own types or data containers.
Also, originally every single line was numbered. Typically the line numbers
were in increments of 10 so that you could add additional lines between two
existing lines. If you kept adding lines between two existing lines, you
would eventually run out of line numbers and you were stuck, and would have
to start re-numbering lines manually. (The fanciest BASIC editors had a way
of re-numbering the whole program to be once again in increments of 10. Of
course this messed up any numbering scheme you might have had, eg. subroutine
1 starting from line 1000, subroutine 2 starting from line 2000 and so on.
The automatic re-numbering would just make every line number be 10 apart
from each other.)
More modern BASIC variants got rid of mandatory line numbers, and started
supporting named labels as well as actual functions, arrays, dividing the
program into several source files, new control structures, and other fancy
stuff.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25-4-2012 19:58, nemesis wrote:
> Warp escreveu:
>> clipka <ano### [at] anonymousorg> wrote:
>>> So yes: Currying *is* like writing a function that takes fewer
>>> arguments, calling the original one and supplying (unchangeable)
>>> defaults for the missing arguments.
>>
>> I think that the difference is that the new function is not static,
>> but it's generated dynamically. (In other words, what you end up is a
>> new function which fixes some of the parameters of the original function,
>> but the values to which they are fixed is determined at runtime rather
>> than at compile time.)
>>
>> This means, if I understand correctly, that you could for example create
>> such functions in a loop (or, as we are talking about functional
>> languages,
>> in a recursive manner), which is quite difficult to achieve with static,
>> compile-time functions. (I suppose you could try to emulate this in a
>> statically typed language with no lambda functions, but you would need
>> some kind of stack or something where the fixed parameter values are
>> stored.)
>>
>> There are probably even deeper implications.
>
> currying comes from Haskell Curry, the mathematician behind many further
> lambda calculus concepts.
>
> Here's the thing about the lambda calculus, which is at the kernel of
> haskell the language: all the functions are one-argument functions that
> return other one-argument functions. So, multiple argument functions are
> actually just syntatic sugar for convenience. And yes, clearly syntatic
> sugar is a good thing, as any competent C++ template writer can attest.
>
> Surely writing a function and letting the compiler handle all the
> partial applications is much saner than writing yourself functions for
> each possible partial application case. And no, I don't think in haskell
> such functions are dynamically generated. Like I said, the concept of
> one-argument functions is at the very heart of haskell: the compiler
> breaks all functions down into one-argument functions, at compile time.
IIRC in (compilers for) languages like Miranda lambda calculus is first
converted to Combinatory Logic (another branch of mathematics that is
provable equivalent to Lambda Calculus). Where CL is extended to include
many other operators (including the standard mathematical operators like
addition and multiplication) apart from the usual S,K, and I. The
advantage is that CL is more efficient to implement and LC has better
properties as a language to express problems.
> Then again, in languages with default and keyword arguments you do not
> need to worry about that, only to remember the argument names. Argument
> position, names or order, though, can still shoot everyone in the foot.
>
Shooting yourself in the foot is generally less of a problem than the
urge to shoot oneself in the head.
--
tip: do not run in an unknown place when it is too dark to see the
floor, unless you prefer to not use uppercase.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/25/2012 13:01, Warp wrote:
> But what's the advantage in having only one-argument functions?
The same advantage as not having writable code and only having a linear tape
gives to Turing machines. It makes the math easier, is all. You're not
supposed to actually *compute* with it, any more than you're supposed to run
business logic on a TM.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/25/2012 1:07, Invisible wrote:
> C and C++ have function pointers. It's dubious whether functions are "first
> class", but certainly you can pass them as arguments.
Given that the only levels of context in C is "global" and "auto", one could
even argue that a function pointer in C is actually a closure, as it
succeeds in capturing every variable in the scope of the function. ;-)
> C# presumably allows /everything/.
Not sure what that means. You *can* create functions on the fly in C#, so
yeah, I don't think there's much you can't do with enough work.
> Java allows you to use the reflection API to create an object that
> represents a function method, and to invoke that method. Alternatively you
> can use anonymous inner classes. (The fact that this feature even /exists/
> tells you how badly Java programmers want anonymous functions.)
Anonymous inner classes aren't functions. They're classes you instantiate.
> Eiffel? Well, they have "delegates", which are sort-of the same thing.
I'm not sure what's "sort of" about them. You can create a new function,
create a delegate to it, assign it to a variable, send it over a network
connection, and invoke the function.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/25/2012 14:18, Warp wrote:
> If I recall correctly, the original BASIC, and the vast majority of
> clones for a pretty long time, didn't even have the concept of a function.
Correct. Raise your hand if you've written Dartmouth BASIC. _O/
> They had subroutines (the most typical keyword to jump to one being GOSUB)
> which were just slightly fancier GOTO labels.
Yep.
> The only control structure other than GOTO was an IF (and you were lucky
> if your brand of BASIC supported an ELSE branch.) Anything that couldn't be
> done with IF had to be done with GOTO.
No, there was FOR/NEXT. I don't think there was a WHILE. The THEN was a
line number, not a statement.
> And the language was completely untyped, of course. Typically you could
> have two types: An integral (usually floating point) and a string. That's
> about it.
There were strings and integers, yes.
> Some variants possibly supported some kind of array or enumeration
> structure. Forget about creating your own types or data containers.
They all had arrays. Lots of the original 8-bit BASIC interpreters had one
array of integers that basically filled all the extra memory.
> Also, originally every single line was numbered.
Indeed. And this is because there was no defined editor. You could type
lines into BASIC and edit your program using nothing but the interpreter.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/04/2012 10:18 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> In a similar was, AMOS BASIC has local variables, named functions and
>> procedures, separate compilation, and a whole chock-load of features. In
>> fact, so many features that it hardly counts as "BASIC" any more; it's
>> more like a brand new language with a superficial resemblance to BASIC...
>
> If I recall correctly, the original BASIC, and the vast majority of
> clones for a pretty long time, didn't even have
C64 BASIC is the very first programming language I ever learned, when I
was still only 9 years old. (I soon learned many other dialects.)
The language is interpreted, not compiled. "Files" are stored on tape,
so random access is impossible, and splitting a program across several
files would be a pointless endeavour.
There is no text editor. Instead you edit the program using line
numbers. Type in a command and it executes immediately. (So the BASIC
interpreter is also the "operating system" as such.) Type in a line
number followed by a command, and that line is added to the program.
Lines are kept in sorted order, so you can insert between lines
(provided their numbers are not consecutive). For this reason, lines are
invariably numbered in 10s. Enter a line number that already exists, and
the existing line is replaced. Enter a line number with nothing
following it, and the line is deleted. The LIST command shows you the
program listing as it currently exists.
There are three types of variable. Normal variables hold signed
integers. (I have no idea what their range is.) Variable names ending
with "#" hold floating-point values. (Remember, no FPU, so SLOOOW. Also,
64KB of RAM, so these eat memory like candy.) Variable names ending with
"$" hold variable-length text strings. Typically a string cannot be more
than 255 characters. Typically a variable name cannot be more than 30
characters - which is fine. The entire screen is only 40 characters
wide. (A few BASIC implementations allow up to 30 characters, BUT IGNORE
ANYTHING BEYOND 8!)
All variables are global variables.
There are no subroutines. There is only GOTO and GOSUB/RETURN. This is
an UNSTRUCTURED programming language, after all.
You can have multi-dimensional arrays. They all start at index 1. There
are no user-defined data types.
Your flow control constructs are IF/THEN/ELSE, WHILE/LOOP, REPEAT/UNTIL,
and FOR/NEXT. Some dialects allow compound statements on a single line
using ":" as separator. Others demand that you use THEN GOTO if you want
multiple statements.
Almost every dialect had a strange DATA construct. A DATA statement is
followed by a comma-separated list of decimal numbers. The READ
statement fetches the next code into the specified variable. The RESTORE
command resets to the first DATA statement. If you want to write machine
code, you invariably have to write a BASIC program such as
10 FOR X = 1 TO 13
20 READ D
30 POKE (23874+X), D
40 NEXT X
50 DATA 45,84,27,45,95,13,75,65,42,84,13,10,59
This uses the POKE command to copy the stuff in the DATA statements into
a given location in RAM. (Notice how the DATA statements accept only
decimal. In general, BASIC understands nothing else.) This is arguably
the only reason that I know that the op-code for the 6510 "RTS" (return
from subroutine) command is 96 decimal.
To my mind, any language more sophisticated than this is no longer
"BASIC". It is now "a language based on BASIC".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Almost every dialect had a strange DATA construct. A DATA statement is
> followed by a comma-separated list of decimal numbers. The READ
> statement fetches the next code into the specified variable. The RESTORE
> command resets to the first DATA statement. If you want to write machine
> code, you invariably have to write a BASIC program such as
>
> 10 FOR X = 1 TO 13
> 20 READ D
> 30 POKE (23874+X), D
> 40 NEXT X
> 50 DATA 45,84,27,45,95,13,75,65,42,84,13,10,59
Think punch cards.
In the case above, you have 4 cards with your program, one line per
card, and can change the DATA card every time you run the program. So
when your warehouse invetory changes, you can still reuse the "Monthly
report" program deck of cards with this month's deck of DATA cards.
Historical note: this is also the reason for the line numbers. It
allowed the deck to be shuffled (ex: after being dropped on the floor)
and read by the computer without having to bother about the order of the
cards.
Of course, on a cassette or a floppy diskette, there is little risk of
dropping your code on the floor and shuffling the data, so eventually
line numbers disappeared.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> No, there was FOR/NEXT. I don't think there was a WHILE. The THEN was a
> line number, not a statement.
Right.
Oh, and forget about indentation. Most "editors" back then had no such
concept. Following deeply nested loops and conditionals was a task in
itself...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/04/2012 01:14 PM, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> No, there was FOR/NEXT. I don't think there was a WHILE. The THEN was a
>> line number, not a statement.
>
> Right.
>
> Oh, and forget about indentation. Most "editors" back then had no such
> concept. Following deeply nested loops and conditionals was a task in
> itself...
You can't nest IF statements at all.
In every BASIC dialect *I* saw, loop bodies are /automatically/
indented, and you can't turn this off.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/04/2012 01:07 PM, Francois Labreque wrote:
>> Almost every dialect had a strange DATA construct. A DATA statement is
>> followed by a comma-separated list of decimal numbers. The READ
>> statement fetches the next code into the specified variable. The RESTORE
>> command resets to the first DATA statement. If you want to write machine
>> code, you invariably have to write a BASIC program such as
>>
>> 10 FOR X = 1 TO 13
>> 20 READ D
>> 30 POKE (23874+X), D
>> 40 NEXT X
>> 50 DATA 45,84,27,45,95,13,75,65,42,84,13,10,59
>
> Think punch cards.
That's just scary.
But incidentally, most BASIC dialects had a way to read data off tape as
well. Usually a READ$() function, or sometimes you had to play with CMD
(change main device) so that your INPUT and PRINT commands now address a
file rather than the screen...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
