<siraben>
KipIngram: I should note that SICP doesn't talk too much about efficiency, but in practice, with the right data structures and algorithms, functional programs are usually just as fast as their imperative counterparts for high-level applications
<siraben>
No one is ever going to beat hand written C or assembly, but for instance Haskell performance is comparable to Java
<siraben>
IME performance problems most commonly arise from people abusing linked lists when other data structures would be better replacements
<siraben>
The bible for this is "Purely Functional Data Structures" by Chris Okasaki
<siraben>
KipIngram: I think lecture 1B talks immediately about a semi-formal model about how a machine executes Scheme code
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC1 has joined #forth
<KipIngram>
Yes, that sounds right. I watched the first few minutes of it before taking a break.
<KipIngram>
Doing some reading now. Re-reading a favorite series; The Dresden Files by Jim Butcher.
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
Guest60158 is now known as X-Scale
<KipIngram>
This emphasis on the "wizardry metaphor" in these lectures is amusing. :-)
<KipIngram>
These early lectures are painfully slow...
Zarutian_HTC has joined #forth
Zarutian_HTC1 has quit [Read error: Connection reset by peer]
dave0 has joined #forth
<dave0>
maw
sts-q has quit [Ping timeout: 268 seconds]
<siraben>
KipIngram: heh, 2x speed FTW
sts-q has joined #forth
siraben has joined #forth
siraben has joined #forth
siraben has quit [Changing host]
siraben has quit [Changing host]
gravicappa has joined #forth
lispmacs has joined #forth
<KipIngram>
:-) No kidding.
<KipIngram>
This is funny; near the end of lecture 4, a student asks a question about how (cons 17 24) and (cons 4 3) (for example) can remember that they have different numbers. He's been trying to present all this in such an abstract way - right there it seems like the easiest way in the world to understand it is as it really is - they're two different bits of RAM and one of them has 17 and 24 and the othre has 4 and
<KipIngram>
3. But he seemed unwilling to just slice it open like that - I guess that's too "non-abstract."
<KipIngram>
He's going out of his way to avoid mentioning any real physical implementation aspects.
<siraben>
KipIngram: they will get to real implementation aspects later
<siraben>
I think the ability to hold these things abstractly is important, especially for beginning programmers
<siraben>
of course I think these employees are experienced in other languages of the time, ALGOL, FORTRAN and whatnot
<siraben>
it could easily be upstreamed to nixpkgs as well
andrei-n has joined #forth
tech_exorcist has joined #forth
wineroots has quit [Ping timeout: 245 seconds]
* DKordic
drops 5 Ki B of Forth.
f-a has joined #forth
dave0 has quit [Quit: dave's not here]
jedb has quit [Quit: Leaving]
jedb has joined #forth
tech_exorcist has quit [Remote host closed the connection]
<proteusguy>
KipIngram, re: "Suddenly you don't NEED IF / THEN" this is a big thing to achieve. I use guard statements but otherwise don't use if as a flow control inside a function/word at all.
lispmacs has quit [Read error: Connection reset by peer]
<KipIngram>
proteusguy: Yes, I was fairly happy when I realized what was going on (no IF ... THEN, etc.)
<f-a>
how you do not need them
<KipIngram>
siraben: I don't disagree re: the value of abstraction. I just had to snicker a little at the lengths the fellow went to to avoid giving the obvious answer to the question.
<KipIngram>
f-a: I've incorporated a family of conditional return instructions into my Forth.
<KipIngram>
I replace IF ... THEN by factoring ... into a new word with a conditional return at the very beginning.
<f-a>
what is this word
<KipIngram>
It accomplishes the same control flow and encourages me to factor more completely.
<KipIngram>
Well, I have a whole bunch of them, but if you wanted just one you might call it ?;
<KipIngram>
<flag> ?;
<f-a>
what does 1 ? do
<KipIngram>
I have a whole family, like =; !=; >; 0<; etc
<KipIngram>
It's just a name. question mark, semicolon.
<f-a>
yes but
<KipIngram>
It's meant to imply "possibly return."
<f-a>
what does it do
<KipIngram>
If the flag is true it returns.
<f-a>
return as in C?
<f-a>
I c
<f-a>
thanks
<KipIngram>
Transfers control to the address on the top of the return stack, and pops the return stack.
<KipIngram>
I also have some that do two returns (like 0=;; )
<KipIngram>
The only reason for those is so that I can push the condition return decision down into a lower factor level.
<KipIngram>
So if foo calls bar, I can decide to return from foo from within bar.
<KipIngram>
Pops two return stack items, transfers control to the lower item.
<KipIngram>
This family of words has obviated pretty much all conditional structures.
<KipIngram>
I have a similar family where the action, instead of returning, is to jump back to the start of the current word.
<KipIngram>
That eliminates all normal looping constructs.
<KipIngram>
So a while loop looks like this:
<KipIngram>
: <word> 0=; ... code ... loop ;
<KipIngram>
A do until word would be
<KipIngram>
: <word> ... code ... 0=loop ;
<KipIngram>
As I commented yesterday, all those usual control words just allow us to make a definition longer that ought to be factored instead.
<KipIngram>
siraben: this complete avoidance of physical details just isn't the direction that an electrical engineer's training goes. After all, for us it's ALL ABOUT the implementation.
<KipIngram>
The easy answer to the kids question, without going into too much detail, was just, I thought, "There's not just one cons. All of them are different instances of cons, stored apart from one aother, and ONE WAY OR ANOTHER the "information" about the specific numbers is "im there.""
<KipIngram>
in there
<KipIngram>
f-a: I actually worte a Python script to generate the nasm source code for the whole set of conditional returns, conditional loops, conditional double returns, etc.
<KipIngram>
It just systematically plugged from "list of conditionals" and the list of actions to produce the entire set, which is like order of a hundred primitives.
<DKordic>
KipIngram: Continuations: Generalize any Function with a ""ret"" Parameter. Show me some examples.
phadthai_ has joined #forth
phadthai has quit [Read error: Connection reset by peer]
f-a has quit [Ping timeout: 246 seconds]
f-a has joined #forth
tech_exorcist has joined #forth
proteus-guy has quit [Ping timeout: 252 seconds]
Zarutian_HTC has quit [Ping timeout: 240 seconds]
<siraben>
KipIngram: haha, they really do go into all the hairy details later!
<siraben>
Gerald Sussman is also an electrical engineer
<siraben>
But to answer the question about cons, just imagine two memory cells are being allocated
<siraben>
they point to the first and second arguments respectively
<siraben>
1 cons = 1 allocation
proteus-guy has joined #forth
lispmacs has joined #forth
Zarutian_HTC has joined #forth
<KipIngram>
Sure - exactly.
<KipIngram>
But he carefully avoided saying that.
<KipIngram>
I just thought it was cute.
<KipIngram>
DKordic: I'm not sure I'm following; are you saying, consider that all words offer the possibility of choosing to return, as part of their basic operation?
<KipIngram>
That feels to me like mixing functionalities. In Forth + adds, - subtracts, swap swaps, and 0=; conditionally returns. We're advised not to mingle these things too much.
<KipIngram>
Each word is supposed to have one, completely clear, action.
<lispmacs>
I have a humble project going to control an ad9833 audio frequency synthesizer with FlashForth, if anyone is interested:
<KipIngram>
siraben: I just think it's an interesting contrast with the way I'd approach teaching someone about computing. I'd be inclined to start with digital logic. Gates, flip flops, registers, etc. State machines! Then show how generic decision structures can be built up from that. Processor design. Etc.
<DKordic>
KipIngram: "fix" is called the Paradoxical Combinator, W/Fixed-point_combinator .
<KipIngram>
Number representation. Addition, subtraction, two's complement, etc. etc. etc.
<KipIngram>
Peano arithmetic is so far from what computers actually DO that I'd likely never mention it.
<DKordic>
KipIngram: >> [ dfn ( not P True False ) ( P False True ) ] <<!
<KipIngram>
I'm not able to follow that yet, but I opened that link for review later today. Still too early to take something like that on - it looked fairly abstract.
<KipIngram>
I saw some of the same kind of math that is my current barrier in my own "self education" in physics.
<DKordic>
Show me the if.
<KipIngram>
?
<KipIngram>
What do you mean?
<KipIngram>
You mean how I'd replace an IF THEN?
<KipIngram>
Ok, so if in standard Forth one would do this:
<KipIngram>
: foo ..a.. 0= if ..b.. then ..c.. ;
<KipIngram>
I'd do this:
<DKordic>
Sorry, I meant to say W/Material_conditional .
<KipIngram>
: foo ..a.. bar ..c.. ;
<KipIngram>
: bar 0!=; ..b.. ;
<KipIngram>
Notice the reversal of the condition.
<KipIngram>
bar would be suitably named to imply what it was doing.
<KipIngram>
and its conditionality.
<remexre>
KipIngram: this is actually a tension I noticed TAing for my uni's intro-fp class -- the previous classes had all been explaining things in a machine-oriented way, and a lot of students got tripped up /hard/ by the differences between java/python/c/c++ and ocaml
<DKordic>
>> [ dfn ( eor P Q True False ) ( P ( Q False True ) ( Q True False ) ) ] <<! Looks like a W/Truth_table , doesn't it?
f-a has left #forth [#forth]
<remexre>
which I sorta attribute more to ocaml being taught as "just another PL" instead of "here's some machine-executable math notation", than to "knowing what an allocation is poisoned the students' minds"
<DKordic>
I forgot to mention W/Combinatory_logic .
<remexre>
tbh it'd be really neat to see a curriculum that starts with very low-level and very high-level langs at the same time (Forth+asm and Haskell+Scheme?), and as you progress you sorta meet in the middle, w/ the program finishing with "write a $high_level_lang compiler in $low_level_lang"
gravicappa has quit [Ping timeout: 265 seconds]
<KipIngram>
remexre: Sure - we "shape ourselves" to our training. A hard gear shift is a challenge to even a good student.
<KipIngram>
I'm an EE. I was exposed to logic gates first. I did study FORTRAN before studying assembly, but only one course in it.
<KipIngram>
What REALLY sculpted me, though, was my summer internship after freshman year at General Dynamics. A contractor working there named Ed sort of "took me under his wing" andmentored me. Loaned me books on system software. So I learned that summer how an assembler works, and how a loader works, and how operating systems do the major aspects of what they do, and so on.
<KipIngram>
It became crystal clear to me that everything a computer can actually DO (in hardware) is almost ridiculously simple. And that everything else is just building up from there.
<KipIngram>
It was a real eye-opening time for me, but probably only along a ertain "knowledge front."
<KipIngram>
I think that once you really see how a state machine, the way you learn them in logic course, can manage the resources of a computer, you've uncovered the key mystery. After that there are just "alternative clevernesses."
<KipIngram>
I think where this training could perhaps be better is if they tried to prevent the mental wall between code and data from appearing. Obviously, when you really understand what the thing is doing, you realize that what's code at one moment is data at another. But nonetheless, that dichotomy creeps in, and then it's hard to tear it down again when you start to study something like Lisp.
<KipIngram>
I'll go back to the Peano arithmetic again - when your first training was in things like gates and adders and so forth and so on, the very idea that someone would introduce addition as repeated increment/decrement operations... it's hard to not see it as silly because of its inefficiency.
<KipIngram>
When "we all know" how it really works. :-)
<KipIngram>
I'm really trying to describe my own limitations here, that I'm struggling to overcome - not passing judgement on the course
<KipIngram>
This does point up a shortcoming in the common math training we give youngsters, though. I don't think many kids finishing high school REALLY grasp positional notation in all its beauty.
<KipIngram>
It's seriously just about the most amazing thing ever conceived.
<KipIngram>
We could not be where we are without it.
<KipIngram>
It's then natural to introduce binary arithmetic as the version of positional notation that is practical for computers to use, because of the bi-level nature of the circuitry.
<KipIngram>
Well, I guess spoken and written language itself ranks higher.
<KipIngram>
Since you can't get anything else without that.
<DKordic>
`` To iterate is human, to recurse divine. '' -- L. Peter Deutsch
<DKordic>
KipIngram: That is why You will find "fix" enlightening.
Zarutian_HTC has joined #forth
andrei-n has quit [Quit: Leaving]
andrei-n has joined #forth
<KipIngram>
That presentation linked earlier doesn't make lambda calculus any more clear to me. It still just seems to take simple ideas and render them in some extremely complex way that I can't yet find any sense in.
<KipIngram>
For one thing, it always seems far more complex than whatever conncept it says its representing.
<KipIngram>
I've yet to come across a reference that REALLY EXPLAINS it in clear and concise fashion.
<KipIngram>
For example, it says that "f compose g" is (Lvwx.v(wx))fg where L is the lambda.
<KipIngram>
I look at that and just think, "HUH????"
<KipIngram>
Maybe it's one of those things that will seem obvious once I "get it," but so far that hasn't happened.
<KipIngram>
"LC doesn't burden us with boring and error-prone technical details, such as memory management and instructions sequencing." I find those aspects of a system to be FASCINATING. Not boring.
<KipIngram>
Ok, maybe it just hadn't gotten around to trying to explain it yet. Maybe it considered that other stuff... "motivational." So I'm retracting my judgement temporarily.
mtsd has quit [Ping timeout: 252 seconds]
Croran has joined #forth
andrei-n has quit [Quit: Leaving]
f-a has joined #forth
<KipIngram>
Ok, so so far this seems like it's mostly about simplifying expressions. Is there more to it than that? I think it would help to know what the pot of gold at the end of the rainbow is.
<KipIngram>
I'm referring to lambda calculus here.
<remexre>
idk abt in those lectures in particular, but it's simpler to write down than most other turing-complete formalisms while being fairly mathematician-writable
<remexre>
and perhaps even human-writable :)
tech_exorcist has quit [Quit: tech_exorcist]
<remexre>
and lambda calculus plus macros is more or less a completely practical language
jedb has quit [Quit: Leaving]
jedb has joined #forth
<remexre>
(well, add conses and fixnums to that and you've got lisp)
Croran has quit [Quit: Croran]
tabemann has quit [Remote host closed the connection]