Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31786 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-06-24 10:22 -0700 |
| Last post | 2014-06-28 13:52 -0700 |
| Articles | 20 on this page of 116 — 22 participants |
Back to article view | Back to comp.lang.forth
There is no standard Jason Damisch <jasondamisch@yahoo.com> - 2014-06-24 10:22 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-24 12:47 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-24 12:48 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-24 10:05 -1000
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-24 13:19 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-24 10:29 -1000
Re: There is no standard mhx@iae.nl - 2014-06-24 13:33 -0700
Re: There is no standard AKK <akk@nospam.org> - 2014-06-24 22:47 +0200
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-24 15:02 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-24 12:50 -1000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-25 05:22 -0700
Re: There is no standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 13:39 +0000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-25 08:16 -0700
Re: There is no standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:04 +0000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-25 14:45 -0700
Re: There is no standard hughaguilar96@yahoo.com - 2014-06-25 15:16 -0700
Re: There is no standard albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-26 11:47 +0000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 12:22 -0700
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-26 13:03 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 15:06 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-26 15:08 -0700
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 18:47 -0400
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 16:03 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-26 16:25 -0700
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-26 20:21 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 04:53 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 06:56 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 08:30 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 08:45 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 11:01 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 11:14 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 11:20 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 11:43 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 13:12 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 14:10 -0700
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-28 14:24 -0400
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-27 14:08 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-26 17:45 -1000
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-26 15:05 -1000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 05:03 -0700
Re: There is no standard Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-26 09:29 -0500
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 12:46 -0700
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-26 16:10 -0400
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 15:15 -0700
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-26 22:29 -0400
Re: There is no standard Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-27 03:28 -0500
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 08:22 -0700
Re: There is no standard Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-27 10:30 -0500
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 08:52 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 11:13 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 11:29 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 12:32 -0700
Re: There is no standard Jason Damisch <jasondamisch@yahoo.com> - 2014-06-27 12:42 -0700
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-28 15:32 -0400
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-27 13:01 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 13:29 -0700
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-27 16:14 -0400
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-28 02:16 -0700
Re: There is no standard albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-28 12:22 +0000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-28 07:34 -0700
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-28 10:26 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-28 07:18 -1000
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-28 12:35 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-28 11:31 -1000
Re: There is no standard Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-06-29 03:20 +0300
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-28 21:11 -0700
Re: There is no standard albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-29 10:16 +0000
Re: There is no standard albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-29 11:00 +0000
Re: There is no standard mhx@iae.nl - 2014-06-29 05:12 -0700
Re: There is no standard Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-06-29 15:46 +0300
Re: There is no standard stephenXXX@mpeforth.com (Stephen Pelc) - 2014-06-29 14:48 +0000
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-28 18:43 -0400
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-29 05:58 -0700
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-29 06:35 -0700
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-29 11:03 -0400
Re: There is no standard Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-28 12:13 -0500
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-26 20:51 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-27 06:33 -0700
Re: There is no standard Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-27 03:25 -0500
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-28 14:31 -0400
Re: There is no standard Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-29 15:01 +0200
Re: There is no standard Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-29 14:35 -0500
Re: There is no standard Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-30 03:20 +0200
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-28 21:30 -0700
Re: There is no standard albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-29 10:27 +0000
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-25 08:18 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-25 07:47 -1000
Re: There is no standard hughaguilar96@yahoo.com - 2014-06-25 14:48 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-25 15:25 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-25 16:51 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 03:54 -0700
Re: There is no standard "Elizabeth D. Rather" <erather@forth.com> - 2014-06-26 08:06 -1000
Re: There is no standard hughaguilar96@yahoo.com - 2014-06-26 14:08 -0700
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 15:46 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-26 15:54 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-26 15:55 -0700
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-27 00:00 -0400
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 07:06 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-27 07:06 -0700
Re: There is no standard Mark Wills <markwills1970@gmail.com> - 2014-06-27 07:13 -0700
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-30 06:38 -0400
Re: There is no standard bruce.mcfarling@gmail.com - 2014-06-26 12:06 -0700
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-26 16:18 -0400
Re: There is no standard Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-06-26 15:23 -0700
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-26 22:31 -0400
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-24 16:01 -0400
Re: There is no standard Richard Owlett <rowlett@pcnetinc.com> - 2014-06-25 05:04 -0500
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-25 15:44 -0400
Re: There is no standard googlegroups@mailfilter.33mail.com - 2014-06-25 13:52 -0700
Re: There is no standard barrym95838@yahoo.com - 2014-06-26 14:16 -0700
Re: There is no standard m II <C@in.the.hat> - 2014-06-26 19:37 -0600
Re: There is no standard rickman <gnuarm@gmail.com> - 2014-06-26 22:35 -0400
Re: There is no standard Jason Damisch <jasondamisch@yahoo.com> - 2014-06-25 09:47 -0700
Re: There is no standard Roger Levy <roger.levy@gmail.com> - 2014-06-25 10:10 -0700
Re: There is no standard "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:16 -0400
Re: There is no standard BruceMcF <agila61@netscape.net> - 2014-06-28 13:52 -0700
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-06-28 10:26 -0700 |
| Message-ID | <1a6f148f-003c-48e2-b2d1-56cec3a0b053@googlegroups.com> |
| In reply to | #32001 |
On Saturday, June 28, 2014 10:34:39 AM UTC-4, Ilya Tarasov wrote: > Oh, forget that puny CreateFile :) My goal was to demonstrate parameter types used for at least one version of OS and show that c-addr u is not only usable way to represent strings. And we are already found no prohibitions for using OPEN as alternative for OPEN-FILE. The lesser question still remains: why any attempts to use non-standard Forth meets hard and non-compromise position without asking why ever this needs? This is a rhetorical question already :) But treating it as a question about Forth is a category mistake. Its a question about either (1) why the group in question adopts a hard, no-compromise position on using non-standard Forth or (2) why someone perceives the group to be doing so when they do not. The question either refers to (1) the various people who follow clf, in which case its more than a little misleading to call that set of people a group, or (2) some other group of people that it seems likely most people here are unfamiliar with.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-28 07:18 -1000 |
| Message-ID | <UOWdnf7yTOxJZTPOnZ2dnUVZ_t-dnZ2d@supernews.com> |
| In reply to | #31998 |
On 6/28/14 2:22 AM, Albert van der Horst wrote: > In article <fa310258-f087-4c23-9a43-22fa59177ae2@googlegroups.com>, > Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > >> CreateFile accepts pointer to ASCIIZ and returns one parameter, with >> special code for HANDLE if failed. CREATE-FILE accepts c-addr u and >> returns handle and error code. If CREATE-FILE is a wrapper for >> CreateFile, you need to perform an additional actions, and, more >> important, provide an additional documentation and tutorials instead of >> referring to Win API. So you must decide, do you want to provide a set >> of words with similar interface as host OS API functions, or create an >> additional abstraction layer. Both of this solutions has advantages and >> disadvantages, but, in any case, overall architecture must not be >> fragmentary! 'ASCIIZ sucks' is not an argument at all. So what is the >> reasons to ignore more common standards and keeping compatibility with >> old Forth? If you really can list that reasons, it may be useful for the >> better understanding the overall situation. If not, it may be a detailed >> issue to the current standard. > > I've made a Forth for Windows and of course it has a CREATE-FILE, and > it complies with the standard. So you can write programs with it. Of > course it is a wrapper, and it doesn't do what people used to > programming against the API in C expect. Those people are profound > windows experts! No c programmer in his right mind uses CreateFile(), > but he uses the open() of fopen() calls from the c standard library. > So standard c-programs work. ISO Forth programs work. Who needs > CreateFile? > > With my CREATE-FILE Forth programmers who program against the ISO 94 > standard are happy, because standard Forth-programs work. It has been > tested against that standard, which is some guarantee that weird > CreateFile features didn't seep through. If one would report a > deviation from ISO 94, then it becomes a task for the implementor of a > Forth to study (experiment with) the Windows API and fix it, so more > of the standard programs work. The whole point of having the FILES wordset is to provide a way for Forth programs to be portable across *different* OSs that have different protocols for managing such things. If you are happy with writing a Forth program that is explicitly dependent on Windows (or OSX, or ...), for example, writing your OS calls without the FILES wrappers is entirely appropriate. All you have to do is document the dependency, and everyone will be happy. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2014-06-28 12:35 -0700 |
| Message-ID | <8a54e143-5583-41c0-9214-279273e73b16@googlegroups.com> |
| In reply to | #32006 |
> The whole point of having the FILES wordset is to provide a way for > Forth programs to be portable across *different* OSs that have different > protocols for managing such things. If you are happy with writing a I'm understand. Don't you feel it is a time to try to reclaim some Forth positions by inviting a new programmers? If so, may be it is better to write some specialized implementation rather than keeping portability? Programmers familiar with VB, Pascal, C (and derivative languages) may be thankful for such kind of adaptation and Forth may become more likely to use. File IO syntax is not a critical part of Forth, like some another things. Of course, I'm understand I can add another set of words and keep ANS portability. We discuss this already. But I'm asking about plans of committee and related organizations, not about mine. Will you state it is better to keep compatibility with older code than restructure some auxiliary parts of Forth for better chances to encourage interest of wider programmer's auditory?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-28 11:31 -1000 |
| Message-ID | <AcqdnXvSBa7dqTLOnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #32017 |
On 6/28/14 9:35 AM, Ilya Tarasov wrote: >> The whole point of having the FILES wordset is to provide a way for >> Forth programs to be portable across *different* OSs that have different >> protocols for managing such things. If you are happy with writing a > > I'm understand. Don't you feel it is a time to try to reclaim some Forth positions by inviting a new programmers? If so, may be it is better to write some specialized implementation rather than keeping portability? Programmers familiar with VB, Pascal, C (and derivative languages) may be thankful for such kind of adaptation and Forth may become more likely to use. File IO syntax is not a critical part of Forth, like some another things. We do many things to interest new Forth programmers (such as the recent and continuing thread about cheap boards with Forth), but I doubt seriously that changing the file I/0 words would have much influence, since most are implemented in terms of commands appropriate to whatever OS each particular system is implemented on. If the newbie prefers those they're available. > Of course, I'm understand I can add another set of words and keep ANS portability. We discuss this already. But I'm asking about plans of committee and related organizations, not about mine. Will you state it is better to keep compatibility with older code than restructure some auxiliary parts of Forth for better chances to encourage interest of wider programmer's auditory? All language standards (not just Forth) are expected by international standards bodies to maintain compatibility while evolving toward the future. I am sure that the Forth 200x committee (of which I am not a member, although I follow their work with interest) is happy to do things that appeal to new programmers providing they are consistent with basic Forth architecture and don't "break" existing applications. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Hannu Vuolasaho <vuokkosetae@gmail.com> |
|---|---|
| Date | 2014-06-29 03:20 +0300 |
| Message-ID | <lonm44$7h2$1@dont-email.me> |
| In reply to | #32017 |
On 28.06.2014 22:35, Ilya Tarasov wrote: > I'm understand. Don't you feel it is a time to try to reclaim some Forth > positions by inviting a new programmers? If so, may be it is better to > write some specialized implementation rather than keeping portability? > Programmers familiar with VB, Pascal, C (and derivative languages) may > be thankful for such kind of adaptation and Forth may become more likely > to use. File IO syntax is not a critical part of Forth, like some > another things. Another language, another way to write it. First of all Forth's stacks are the hardest thing to understand for a programmer of more popular language. Even when they could see the control flow, understand meaning of the words, their code would be horrible in the begin. 100 lines in one word, non-understandable naming etc. There is also a way how every program language is written. Forth has short words which have good names and stack comments. Even between C and C++ simple null check is different. This is my favourite way of doing it. if( ! ptr) got_null_ptr(); /* C */ if( ptr == nullptr) gotNullPtr(); // C++ So yes. Learning a new programming language is hard. Syntax, semantics and culture. And it is language's job to be easy to use (PHP) and coherent (NOT PHP). What new users want from another programming language is that it solves something more easily than other tools. I ended up using Forth when I needed testbench for my C program so that it had totally different work flow. What would be served if every platform had different words for same tasks? OPEN ( c-addr u -- handle ) or ( c-addr u -- handle ior ) Hard to port, debug and use external code. What is really needed, is to have easy way to use external libraries. Someone writes python module, take Cython, add magic and you have C-library and definition file for forth. Or you find some nice DLL, and throw it to the miracle machine and again you have definitions for it in forth file. OK. I know magic and miracles in this task are impossible. My point is that usually someone has solved part of your problem already. You have to just fit it in. And portable solutions are the way to go. If it is written in another language, you need to study it and learn the language and how it is written. BTW open would be horrible name for a word. Open CD tray, open socket, open file or open sprinkler valve on top of you. Best regards, Hannu Vuolasaho
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-06-28 21:11 -0700 |
| Message-ID | <fd6ac556-9356-4c7a-becc-f690a07783a4@googlegroups.com> |
| In reply to | #32027 |
On Saturday, June 28, 2014 8:20:19 PM UTC-4, Hannu Vuolasaho wrote: > BTW open would be horrible name for a word. Open CD tray, open socket, > open file or open sprinkler valve on top of you. Oh, no, its a wonderful name. Its such a low level thing that you only need it available meaning ``open file'' for a relatively brief period while loading source until you have built something more usable and tailored to your application. And if the source that uses it has loaded the word in opening includes (as its just a small wrapper around an external function call), for sure the open that is there is the file open one.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-29 10:16 +0000 |
| Message-ID | <53afe767$0$15938$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32027 |
In article <lonm44$7h2$1@dont-email.me>, Hannu Vuolasaho <vuokkosetae@gmail.com> wrote: >On 28.06.2014 22:35, Ilya Tarasov wrote: > >> I'm understand. Don't you feel it is a time to try to reclaim some Forth > > positions by inviting a new programmers? If so, may be it is better to > > write some specialized implementation rather than keeping portability? > > Programmers familiar with VB, Pascal, C (and derivative languages) may > > be thankful for such kind of adaptation and Forth may become more likely > > to use. File IO syntax is not a critical part of Forth, like some > > another things. > >Another language, another way to write it. > >First of all Forth's stacks are the hardest thing to understand for a >programmer of more popular language. Even when they could see the >control flow, understand meaning of the words, their code would be >horrible in the begin. 100 lines in one word, non-understandable naming etc. > >There is also a way how every program language is written. Forth has >short words which have good names and stack comments. > >Even between C and C++ simple null check is different. This is my >favourite way of doing it. >if( ! ptr) got_null_ptr(); /* C */ >if( ptr == nullptr) gotNullPtr(); // C++ > >So yes. Learning a new programming language is hard. Syntax, semantics >and culture. And it is language's job to be easy to use (PHP) and >coherent (NOT PHP). What new users want from another programming >language is that it solves something more easily than other tools. I >ended up using Forth when I needed testbench for my C program so that it >had totally different work flow. > >What would be served if every platform had different words for same >tasks? OPEN ( c-addr u -- handle ) or ( c-addr u -- handle ior ) Hard to >port, debug and use external code. > >What is really needed, is to have easy way to use external libraries. >Someone writes python module, take Cython, add magic and you have >C-library and definition file for forth. Or you find some nice DLL, >and throw it to the miracle machine and again you have definitions for >it in forth file. Once I finally bit the bullet, I was surprised how easy it was to make a win32 Forth. Adding a general purpose dll loader that allows a SAVE-SYSTEM (the hardest part) amounts to one bloody screen. The problem with using any dll library is in two things: 1. documentation of the library 2. the use of data structures foreign to Forth, that are found in obscure .h files 3. subsequent use of foreign data structures, e.g. call backs. > >OK. I know magic and miracles in this task are impossible. The miracle machine you're refering to exist! You can throw the c-definitions at some Forths, without having to rework them. They surely will answer > >My point is that usually someone has solved part of your problem >already. You have to just fit it in. And portable solutions are the way >to go. If it is written in another language, you need to study it and >learn the language and how it is written. > >BTW open would be horrible name for a word. Open CD tray, open socket, >open file or open sprinkler valve on top of you. Not in some OO system, that combine OO with name spaces. There i NOT published > >Best regards, >Hannu Vuolasaho -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-29 11:00 +0000 |
| Message-ID | <53aff1ce$0$15878$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32037 |
In article <53afe767$0$15938$e4fe514c@dreader35.news.xs4all.nl>, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >In article <lonm44$7h2$1@dont-email.me>, >Hannu Vuolasaho <vuokkosetae@gmail.com> wrote: >>On 28.06.2014 22:35, Ilya Tarasov wrote: >> >>> I'm understand. Don't you feel it is a time to try to reclaim some Forth >> > positions by inviting a new programmers? If so, may be it is better to >> > write some specialized implementation rather than keeping portability? >> > Programmers familiar with VB, Pascal, C (and derivative languages) may >> > be thankful for such kind of adaptation and Forth may become more likely >> > to use. File IO syntax is not a critical part of Forth, like some >> > another things. >> >>Another language, another way to write it. >> >>First of all Forth's stacks are the hardest thing to understand for a >>programmer of more popular language. Even when they could see the >>control flow, understand meaning of the words, their code would be >>horrible in the begin. 100 lines in one word, non-understandable naming etc. >> >>There is also a way how every program language is written. Forth has >>short words which have good names and stack comments. >> >>Even between C and C++ simple null check is different. This is my >>favourite way of doing it. >>if( ! ptr) got_null_ptr(); /* C */ >>if( ptr == nullptr) gotNullPtr(); // C++ >> >>So yes. Learning a new programming language is hard. Syntax, semantics >>and culture. And it is language's job to be easy to use (PHP) and >>coherent (NOT PHP). What new users want from another programming >>language is that it solves something more easily than other tools. I >>ended up using Forth when I needed testbench for my C program so that it >>had totally different work flow. >> >>What would be served if every platform had different words for same >>tasks? OPEN ( c-addr u -- handle ) or ( c-addr u -- handle ior ) Hard to >>port, debug and use external code. >> >>What is really needed, is to have easy way to use external libraries. >>Someone writes python module, take Cython, add magic and you have >>C-library and definition file for forth. Or you find some nice DLL, >>and throw it to the miracle machine and again you have definitions for >>it in forth file. > >Once I finally bit the bullet, I was surprised how easy it was >to make a win32 Forth. >Adding a general purpose dll loader that allows a SAVE-SYSTEM >(the hardest part) amounts to one bloody screen. > >The problem with using any dll library is in two things: >1. documentation of the library >2. the use of data structures foreign to Forth, that are found >in obscure .h files >3. subsequent use of foreign data structures, e.g. call backs. > >> >>OK. I know magic and miracles in this task are impossible. > >The miracle machine you're refering to exist! You can throw the >c-definitions at some Forths, without having to rework them. >They surely will answer > >> >>My point is that usually someone has solved part of your problem >>already. You have to just fit it in. And portable solutions are the way >>to go. If it is written in another language, you need to study it and >>learn the language and how it is written. >> >>BTW open would be horrible name for a word. Open CD tray, open socket, >>open file or open sprinkler valve on top of you. > >Not in some OO system, that combine OO with name spaces. >There i > >NOT published Indeed this was published by accident. Oops. Please ignore the OO part. The rest is reasonably okay. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-06-29 05:12 -0700 |
| Message-ID | <61b1959c-68ab-4831-9356-7e660d647282@googlegroups.com> |
| In reply to | #32037 |
Albert van der Horst writes Re: There is no standard > In article <lonm44$7h2$1@dont-email.me>, > Hannu Vuolasaho <vuokkosetae@gmail.com> wrote: [..] > OK. I know magic and miracles in this task are impossible. > The miracle machine you're refering to exist! You can throw the > c-definitions at some Forths, without having to rework them. > They surely will answer Well, I wouldn't if you hadn't provoked me. The OP seems to be incredibly misinformed. Even a cursory glance at Win32Forth or gForth brings up evidence of significant progress since the last century. The explanation wouldn't fit on one screen:-) Note that the current 64-bit OS expect parameters in registers AND on the stack, and that integers and floats can be arbitrarily mixed. References may be to functions that are referenced but not present in currently open libraries. Sometimes one encounters reference to objects that look like functions but are actually macros. All 3 major OSs have a slightly different ABI. -- example: loading functions from an arbritrary-precision library. WINDOWS? [IF] Library: libmpfr-4.dll [THEN] LINUX? [IF] Library: libmpfr.so [THEN] DARWIN? [IF] Library: libmpfr.dylib [THEN] -- libmpfr 3.0.x functions (excerpt) Extern: mpfr_set_d int mpfr_set_d (int rop, double r, int n); Extern: mpfr_set_zero void mpfr_set_zero (int rop, int sign); Extern: mpfr_clear void mpfr_clear (a); Extern: mpfr_init2 void mpfr_init2 (a, n); Extern: mpfr_set_str int mpfr_set_str (a, a, n, n); Extern: mpfr_set_si int mpfr_set_si (a, n, n); Extern: mpfr_get_str void* mpfr_get_str (a, a, n, n, a, n); Extern: mpfr_get_si int mpfr_get_si (a, n); Extern: mpfr_get_d double mpfr_get_d (a, n); Extern: mpfr_swap void mpfr_swap (a, a); ... etc. Forth can also pretend to 'know' the type of a parameter but it's too much sugar for me. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Hannu Vuolasaho <vuokkosetae@gmail.com> |
|---|---|
| Date | 2014-06-29 15:46 +0300 |
| Message-ID | <lop1r8$jl7$1@dont-email.me> |
| In reply to | #32042 |
On 29.06.2014 15:12, mhx@iae.nl wrote: > Albert van der Horst writes Re: There is no standard > >> In article <lonm44$7h2$1@dont-email.me>, >> Hannu Vuolasaho <vuokkosetae@gmail.com> wrote: > [..] >> OK. I know magic and miracles in this task are impossible. > >> The miracle machine you're refering to exist! You can throw the >> c-definitions at some Forths, without having to rework them. >> They surely will answer > > Well, I wouldn't if you hadn't provoked me. The OP seems > to be incredibly misinformed. Even a cursory glance at Win32Forth > or gForth brings up evidence of significant progress since the > last century. Yes. calling foo() from library is easy now days. However how much there is more. Preprosessor macros and constants, enumerations and datastructures. They make that part of library->forth hard. It is required to have header file and still those aren't easy to translate. How much compiler has packed or aligned struct isn't displayed in .h file. So my magic and miracles would need header file reader and understanding how the library was compiled. Best regards, Hannu Vuolasaho
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-06-29 14:48 +0000 |
| Message-ID | <53b02600.694935610@news.demon.co.uk> |
| In reply to | #32037 |
On 29 Jun 2014 10:16:07 GMT, albert@spenarnc.xs4all.nl (Albert van der Horst) wrote: >The miracle machine you're refering to exist! You can throw the >c-definitions at some Forths, without having to rework them. >They surely will answer The source code for the Extern: notation of 2012 can be found at: http://soton.mpeforth.com/flag/extern/index.html In this notation, the Forth definition of the Windows SendMessage() API function is: LIBRARY: Kernel32.dll EXTERN: int PASCAL SendMessage( HWND hwnd, DWORD mesg, WPARAM wparam, LPARAM lparam ); When used with libraries designed to be ported, often the only thing that changes across Windows, Mac and Linux is the library name. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-28 18:43 -0400 |
| Message-ID | <longec$8ul$1@dont-email.me> |
| In reply to | #31994 |
On 6/28/2014 5:16 AM, Ilya Tarasov wrote: > пятница, 27 июня 2014 г., 23:14:55 UTC+3 пользователь rickman написал: >> On 6/27/2014 4:28 AM, Andrew Haley wrote: >> >>> Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> >>>>> There is nothing in the standard that requires you to implement counted >> >>>>> strings. I don't know what you mean by "two output numbers for file IO". >> >>>>> When you talk about aligning Forth to the current OS API you show that >> >>>>> you don't fully understand the extent Forth is used in the embedded >> >>>>> world where there is *no* OS many times. >> >>>> >> >>>> Explain this, please: >> >>>> >> >>>> http://pfe.sourceforge.net/pfe-wordsets/file.html >> >>>> ===================================================================== >> >>>> CREATE-FILE( name-ptr name-len open-mode# -- name-file* name-errno# ) >> >>>> ===================================================================== >> >>>> >> >>>> And compare with this: >> >>>> >> >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx >> >>>> >> >>>> ===================================================================== >> >>>> HANDLE WINAPI CreateFile( >> >>>> _In_ LPCTSTR lpFileName, >> >>>> _In_ DWORD dwDesiredAccess, >> >>>> _In_ DWORD dwShareMode, >> >>>> _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes, >> >>>> _In_ DWORD dwCreationDisposition, >> >>>> _In_ DWORD dwFlagsAndAttributes, >> >>>> _In_opt_ HANDLE hTemplateFile >> >>>> ); >> >>>> ===================================================================== >> >>> >> >>> Compare with this: >> >>> >> >>> int open(const char *pathname, int flags, mode_t mode); >> >> >> >> Can you just tell me what your point is? >> >> >> >> -- >> >> >> >> Rick > > CreateFile accepts pointer to ASCIIZ and returns one parameter, with special code for HANDLE if failed. CREATE-FILE accepts c-addr u and returns handle and error code. If CREATE-FILE is a wrapper for CreateFile, you need to perform an additional actions, and, more important, provide an additional documentation and tutorials instead of referring to Win API. So you must decide, do you want to provide a set of words with similar interface as host OS API functions, or create an additional abstraction layer. Both of this solutions has advantages and disadvantages, but, in any case, overall architecture must not be fragmentary! 'ASCIIZ sucks' is not an argument at all. So what is the reasons to ignore more common standards and keeping compatibility with old Forth? If you really can list that reasons, it may be useful for the better understanding the overall situation. If not, it may be a detailed issue to the current standard. That is why I asked in my other reply, "Are you aware that Forth is not Windows?" Even if you only look at the Windows case, is this some huge burden? If you wish to debate the separate issue of using what you call ASCIIZ, I can't see that as a significant issue. I certainly don't see how you referring to it as a "standard" is of any value. A language would not be changed because you can't find a compelling reason to not change it. It would be changed because you found a compelling reason to in fact, make the change. Also, are you aware that ASCIIZ is used in Forth? Just not everywhere and not as part of the standard. That is the point others have tried to make to you. The standard does not in any way limit what you do with your implementation. I use Win32Forth a lot and that implementation supports ASCIIZ along with various conversion words. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2014-06-29 05:58 -0700 |
| Message-ID | <5cd7ee74-5681-4d29-9de4-7c4e58f41979@googlegroups.com> |
| In reply to | #32026 |
> That is why I asked in my other reply, "Are you aware that Forth is not > Windows?" > Even if you only look at the Windows case, is this some huge burden? I'm using both PC and bare metal Forth processor systems. I see no critical problems to change string representation or anything else. It is definitely not a key Forth feature. So I'm free to use counted strings when contacting with peoples with Pascal background, and ASCIIZ with one who familiar with C. > If you wish to debate the separate issue of using what you call ASCIIZ, > I can't see that as a significant issue. No, I don't want to debate at all. It is more important to observe, how much misunderstandings appears after a question about minor detail, that easy to change. If you don't agreed to change some library according to the requirements of another language, you will probably lost you partners experienced with that language. > It would be changed because you found a compelling reason to in fact, > make the change. I've asked about compelling reasons several times before. Of course, it was not a questions about argument formats. In 2009, Forth was at 41st and 48th positions at TIOBE. Now it is in the '51 to 100' group. Is it not a compelling reason to think about overall strategy of Forth development? And please don't think I'm just want to take part in the ANS committee - this is definitely not a great achievement for me :)
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-06-29 06:35 -0700 |
| Message-ID | <0ab631ee-0038-48a5-859c-5491271fca95@googlegroups.com> |
| In reply to | #32044 |
On Sunday, June 29, 2014 8:58:20 AM UTC-4, Ilya Tarasov wrote: > And please don't think I'm just want to take part in the ANS committee - this is definitely not a great achievement for me :) Rest assured that nobody is getting the impression that you have any interest in working to make the situation better by attempting to make a constructive contribution under the RFC/CFV system of the Forth200x/201x process.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-29 11:03 -0400 |
| Message-ID | <lop9rb$ejr$1@dont-email.me> |
| In reply to | #32044 |
On 6/29/2014 8:58 AM, Ilya Tarasov wrote: >> That is why I asked in my other reply, "Are you aware that Forth is not >> Windows?" >> Even if you only look at the Windows case, is this some huge burden? > > I'm using both PC and bare metal Forth processor systems. I see no critical problems to change string representation or anything else. It is definitely not a key Forth feature. So I'm free to use counted strings when contacting with peoples with Pascal background, and ASCIIZ with one who familiar with C. > >> If you wish to debate the separate issue of using what you call ASCIIZ, >> I can't see that as a significant issue. > > No, I don't want to debate at all. It is more important to observe, how much misunderstandings appears after a question about minor detail, that easy to change. If you don't agreed to change some library according to the requirements of another language, you will probably lost you partners experienced with that language. > >> It would be changed because you found a compelling reason to in fact, >> make the change. > > I've asked about compelling reasons several times before. Of course, it was not a questions about argument formats. In 2009, Forth was at 41st and 48th positions at TIOBE. Now it is in the '51 to 100' group. Is it not a compelling reason to think about overall strategy of Forth development? And please don't think I'm just want to take part in the ANS committee - this is definitely not a great achievement for me :) So why are you posting here? You are not making any concrete points and you state you do not wish to contribute to the standards effort. I don't see your points at all. Everything you bring up you immediately step away from as not being worth discussing. I don't agree that any of the points you have made are worth changing to not drive programmers away from the language. I seriously doubt there would be one Java programmer who would convert to Forth if it used zero terminated strings or had one less return value from CREATE-FILE. Programmers work in many languages because they all promise some advantage of automatically fixing some problem that happens in programming. Often the promises are empty, but not in an obvious way. Forth doesn't really promise anything in the same way. Forth just gives you access to a flexibility that lets you be all that you can be. Without training only some programmers can turn that into an advantage. I think even weak programmers can use Forth well, but only by working with better programmers. There being only a small number of Forth programmers available it is likely there just isn't that critical core number to allow Forth to ever take off. I'm not sure I care a lot. One may not be a critical number, but it is a number and is enough for me. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-06-28 12:13 -0500 |
| Message-ID | <moidnYxjmOoAajPOnZ2dnUVZ_tCdnZ2d@supernews.com> |
| In reply to | #31985 |
rickman <gnuarm@gmail.com> wrote: > On 6/27/2014 4:28 AM, Andrew Haley wrote: >> Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >>>> There is nothing in the standard that requires you to implement counted >>>> strings. I don't know what you mean by "two output numbers for file IO". >>>> When you talk about aligning Forth to the current OS API you show that >>>> you don't fully understand the extent Forth is used in the embedded >>>> world where there is *no* OS many times. >>> >>> Explain this, please: >>> >>> http://pfe.sourceforge.net/pfe-wordsets/file.html >>> ===================================================================== >>> CREATE-FILE( name-ptr name-len open-mode# -- name-file* name-errno# ) >>> ===================================================================== >>> >>> And compare with this: >>> >>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx >>> >>> ===================================================================== >>> HANDLE WINAPI CreateFile( >>> _In_ LPCTSTR lpFileName, >>> _In_ DWORD dwDesiredAccess, >>> _In_ DWORD dwShareMode, >>> _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes, >>> _In_ DWORD dwCreationDisposition, >>> _In_ DWORD dwFlagsAndAttributes, >>> _In_opt_ HANDLE hTemplateFile >>> ); >>> ===================================================================== >> >> Compare with this: >> >> int open(const char *pathname, int flags, mode_t mode); > > Can you just tell me what your point is? CREATE-FILE is a fairly simple abstraction over a system call that most operating systems have. The UNIX system call -- simple, clean, and straightforward -- is a good fit to Forth's CREATE-FILE; it's so similar that CREATE-FILE doesn't have much to do. The Windows function is what we'd expect from Microsoft, and is not IMO something to imitate. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-06-26 20:51 -0700 |
| Message-ID | <f67826f8-8393-4ddc-993b-e2f5ff568bdb@googlegroups.com> |
| In reply to | #31884 |
On Thursday, June 26, 2014 3:46:49 PM UTC-4, Ilya Tarasov wrote: > I don't want to mutate Forth at all. Stack calculations and postfix notation are not so terrific and can be explained. > But I cannot explain (and cannot found) the reasons to use 1.23E0 Which, as have been explained, you don't have to ... by the standard, you are free to recognize 1.23 as floating point. You appear to be misreading "shall recognize", which says nothing about what else may be recognized. > stacked vocabularies Any search order specification is going to be a stack implicitly, but there's nothing in Forth94 that requires that be exposed to system users. > Pascal-style strings instead of ASCIIZ Which from Forth94 you don't have to, since it was Forth94 which removed the dependence on counted strings that was common to Forth79 and Forth83 ... if you want to use obsolete 70's style C null-terminated strings, you are free to. > two output numbers for file IO So what this is saying is that in ... CREATE-FILE ( str fam -- fileid ior ) ... you object to having the fileid (one number) and the I/O result value (the second number)? If you struggle to explain the benefit of having the I/O result return on top of the fileid on stack, that suggests you just aren't very good at explaining things. > ... and many other things from '94. Do you have any examples of things you have to have according to Forth94 that are not either fictitious or things that there is no sensible reason to object to?
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2014-06-27 06:33 -0700 |
| Message-ID | <f070f8e1-7774-45c9-b75a-0c2827704e5d@googlegroups.com> |
| In reply to | #31921 |
> > But I cannot explain (and cannot found) the reasons to use 1.23E0 I'm pointed to my note that I cannot _found_ the reasons. This does not means I cannot explain it. But I prefer to use explanation like 'this is obsolete solution and needs to be changed'. Please keep in mind world is much more large than Forth community and peoples around you may have another experience and be qualified in another areas. So, when I told 'I cannot understand', this means not my lack of understanding, but lack of arguments or presentation quality. If you want to blame every programmer, who don't want to use ANS'94 literally, they are probably wants to stop dealing with you.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-06-27 03:25 -0500 |
| Message-ID | <-N6dnWEkBLMPtzDOnZ2dnUVZ_o-dnZ2d@supernews.com> |
| In reply to | #31884 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> That's something of a philosophical issues with Forth, as well as a >> practical one. How much do you want to mutate the language to keep >> these "new users" happy? After all, Forth is different by design: how >> much have you got to change the language to achieve that? How much >> should lisp have changed to accommodate users who can't cope with >> parantheses? Haskell to accommodate users who can't cope with >> currying? > > I don't want to mutate Forth at all. Stack calculations and postfix > notation are not so terrific and can be explained. But I cannot > explain (and cannot found) the reasons to use 1.23E0, stacked > vocabularies, Pascal-style strings instead of ASCIIZ, two output > numbers for file IO and many other things from '94. The thing about Forth is this: not every feature will suit your application, but every single one is there because it proved to be useful in applications. Forth is the ultimate blue-collar langauge, where every design decision was based on application experience. The number format has proved useful for all sorts of things, and that's why it is that way. It's unconventional, but it worked in applications. ASCIIZ sucks, and I explained why, and no language since C has used it AFAIAA. No. What does "two output numbers for file IO?" mean? Stacked vocabularies? I don't know what in the standard this refers to. > Peoples often wants to have this things similar to others languages > and well understand Forth key features. The question is not to add a > new features or libraries in the attempts to be accepted by any > programmer. Minimize the standard requirements, align it to current > OS API and more Forth systems became standard compatible. The standard requirements are already pretty minimal. What alignment to a "current OS API" do you mean? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-28 14:31 -0400 |
| Message-ID | <op.xh6ge9f86zenlw@localhost> |
| In reply to | #31927 |
On Fri, 27 Jun 2014 04:25:54 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > ASCIIZ sucks, and I explained why, and no language since C has > used it AFAIAA. No. Does "no language since C" include or exclude all of C's derivatives? (i.e., "weasel" wording) How many of the high-use modern languages are derived from C? Basically, *all* of them ... (See TIOBE index.) Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web