Re: [OT] PostLisp, a language experiment
From: Ed Beroset (beroset_at_mindspring.com)
Date: 03/14/05
- Next message: Jacek Generowicz: "Re: Python becoming less Lisp-like"
- Previous message: astrobe_at_netcourrier.com: "Re: PostLisp, a language experiment"
- In reply to: Duane Rettig: "Re: [OT] PostLisp, a language experiment"
- Next in thread: Stephen Pelc: "Re: [OT] PostLisp, a language experiment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 14 Mar 2005 12:52:07 GMT
Duane Rettig wrote:
> Ed Beroset <beroset@mindspring.com> writes:
>
>>that the question doesn't make literal sense, but that it's not clear
>>why anyone would want to do that.
>
> Indeed. Why would one want to write buggy code? Let's move on.
> Do you think I'm saying that?
No, of course not! It was just an example intended to convey the
strangeness of your actual question (from a Forth programmer's point of
view) and nothing more. Your actual question, as I understood it, was
"how do I write long definitions in Forth?" If I've misunderstood you,
please let me know.
>>One presumption about why one MIGHT want to do that was to gain
>>presumed efficiency, hence the nature of the replies that you received.
>
> In the Lisp world, we tend to look down on efficiency-as-excuse-for-
> bugginess.
I think that's a pretty common attitude among programmers in any
language, and I think it's a good one.
> Of course, there are areas where we desire to compete
> with C efficiency, where in order to do so we must model the
> hardware-modulo effect (i.e. where adding 1 to the most-positive
> machine-integer mysteriously results in the most-negative
> machine-integer) but for the most part we try to analyze types
> to prove that overflowing to different representations are not
> necessary.
That makes sense.
>>So this leads me to ask, what advantage do you find in writing long
>>definitions? In other words, why would one want long definitions
>>instead of compounds of shorter ones? I find that I tend to use the
>>latter method in Lisp, and C and many other languages so that the code
>>is easier to understand and maintain; I haven't encountered a
>>compelling need to write long definitions.
>
> Lexical proximity and modularity.
Let's make sure I understand you correctly. I think what you're saying
is that one advantage to writing long definitions is that with a long
definition, the programmer is reading in just one place to figure out
what's going on instead of jumping all over in the source code. Is that
a fair paraphrase?
>>>Correct. But there are times when a large function can indeed be used
>>>without any loss of readability. Table-based code is one such example;
>>>in Lisp a case statement might even span many pages, but to break it
>>>up would not necessarily increase the readability or any reusability.
>>
>>My Lisp is extremely rusty, but it strikes me that a large case
>>statement would tend to have short, repetitive actions for each
>>case.
>
> Not necessarily, but even if it always did, how do you reconcile
> a 1000-entry case statement into a "short" definition?
It would be a short definition which processes a 1000-entry data
structure containing test, action tuples. :-)
> That is, you wouldn't have extremely long actions for each case.
>
>>Just as in Forth, you'd break things up into named function.
>
>
> And how do you describe the function/word that contains the actual
> case statement? Is it short?
Probably. It's easy to add CASE statement semantics to Forth, and some
use it. I don't tend to. If it's short (three or four possibilities)
I'll probably just use IF, and if it's long, I'd probably use a vectored
approach.
> (Of course, we'd have to assume that
> there would exist a case type of construct in the first place; Elizabeth
> Rather has suggested a particular implementation, but is such an
> implementation even likely in the Forth world?)
Very! It's what I thought of, too, and Ms. Rather and I are probably on
opposite ends of the Forth programming competency spectrum! (She's on
the "extremely competent" end, just to be clear.)
>>>>As various of us have said, the length of the name(s) is irrelevant
>>>>except in source.
>>>
>>>We're talking precisely and only about source. Since there are
>>
>>>apparently no runtime checks for stack mismatches, they are not caught
>>>or introduced at compile-time, but instead they become directly dependent
>>>on source only.
>>
>>That's correct, and since they're in source only, this leads directly
>>to the maxim of keeping definitions short, with the understanding that
>>the relevant implication isn't the number of characters typed in but
>>the complexity and number of stack items for each definition.
>
> Right. I think we're actually getting somewhere. Perhaps if you
> were to analyze precisely what you mean by "short" and "long",
> you would conclude that such measurement is really a qualitaative
> measurement about the amount of complexity in the stack
> interaactions. Possible?
Yes, and I'd accept that as a better and more concise definition than
"short" vs. "long" in this context. In fact, as others have mentioned,
excessive stack manipulations are usually a sign that something is
"long" and needs to be factored into multiple "short" definitions.
>>>Yes, but even this gets away from my question about what to do with these
>>>pesky stack mismatches.
>>
>>The obvious answer is "avoid them!" The other respondents have been
>>trying to give a more detailed and useful answer, but it boils down to
>>just that.
>
> Heh :-) I actually do avoid them. It's been 1984 since my last
> Forth program :-)
It's like the old joke:
Patient: "Doctor, it hurts when I do this."
Doctor: "Then don't do that."
;-)
>>machine interpretation. In other words, a Forth program reads those
>>comments and can product documentation from them. I don't know if he
>>uses such a tool, but it would certainly be possible to chain stack
>>comments together to check for stack mismatches.
>
> Yes, I also avoid these in the same way...
>
> I like my code to document itself. Why? Because documentation always
> becomes out-of-date - nobody has the perfection of discipline to always
> change the docmentation when the function/word is changed.
I do the same thing with my assembly language code, my Java code, my C++
code, my C code, my Perl code ... etc. Interestingly, two of those
languages (Perl and Java) have documentation generation features more or
less built into the language specification. Apparently, you and I
aren't the only people who think it's important!
>>He probably doesn't have or use such a tool because the idiomatic use
>>of the stack is such a basic part of Forth. It would be like writing
>>a Lisp program to track the use of car and cdr and make sure that the
>>correct one was used each time. It might be possible, but it would be
>>useless to any experienced Lisp programmer.
>
> On the contrary; we use these tools all the time (though not to check,
> but to actually generate).
That's a very different thing. As someone (Bernd Paysan?) already
mentioned, the checking tool would be like training wheels on a bicycle.
Code generation would be more like building a bicycle factory. (I'm
starting to hurt myself with these poor analogies -- your indulgence is
requested!)
> functions that combine a "c" with any numbers of "a" and "d" followed
> finally by "r" (as in cadr, cadadr, etc) to follow down the nodes of
> trees or other list structures; we often use macros to decide what the
> correct branch in the tree is at a particular point, given a higher-level
> specification.
That's somewhat similar in philosophy, if not mechanics, to how a Forth
programmer would probably name things. That is, words that do similar
things are given similar names.
> Yes, of course; I know the Forth of the 80s, but I don't know what
> tools people are using to enhance their productivity in Forth
> nowadays, and hence my questioning.
It's funny; I only know the Lisp of the 80s. Just to forwarn you, my
opinions on this matter are going to be of limited use because I don't
do that much programming in Forth. More experienced people here
(Elizabeth Rather, Bernd Paysan, Anton Ertl, Paul Bennett and others)
can give you a much better view into that question than I could. I'm
more of an apprentice Forth user; those people are master Forth
builders. I only stepped in to try to provide translation services. :-)
> Note that I'm also not trying
> to "convert" you to Lisp use, but I am trying to get you to think
> about how your productivity can be increased, given that you like
> to stay in Forth.
You'd be surprised, then. I have some things I want to add to Macsyma,
which I am happily running on my PDA, and of course the language there
is Lisp. (However, I also have Forth on the same PDA). My motto is
"use the right tool for the job" and because I'm a naturally lazy
fellow, I like to have a lot of tools available!
Ed
- Next message: Jacek Generowicz: "Re: Python becoming less Lisp-like"
- Previous message: astrobe_at_netcourrier.com: "Re: PostLisp, a language experiment"
- In reply to: Duane Rettig: "Re: [OT] PostLisp, a language experiment"
- Next in thread: Stephen Pelc: "Re: [OT] PostLisp, a language experiment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
