Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #25242 > unrolled thread
| Started by | Ian van Breda <igvb@btopenworld.com> |
|---|---|
| First post | 2013-08-16 11:59 +0100 |
| Last post | 2013-08-23 17:37 +1000 |
| Articles | 20 on this page of 88 — 16 participants |
Back to article view | Back to comp.lang.forth
LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-16 11:59 +0100
Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 12:31 +0100
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:31 +0000
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 21:50 +0200
Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-17 08:51 +0000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-18 20:10 +0100
Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-18 23:32 +0200
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-18 15:47 -0700
Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-19 15:10 +0100
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 09:46 +0000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-22 20:15 +0100
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 07:17 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 14:18 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 10:25 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 15:39 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 11:26 -0500
Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-20 11:25 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 10:05 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-21 14:38 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 11:48 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-21 16:50 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:18 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-22 12:33 +0000
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-22 15:26 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:25 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:24 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:12 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 01:22 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 02:56 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 01:49 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:52 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 08:10 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:00 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 13:46 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 03:01 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-24 03:24 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 12:51 -0500
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-25 11:44 -0700
Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:42 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:24 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 11:50 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 08:13 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 13:55 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:05 -0500
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-24 10:36 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 13:05 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 22:44 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 04:29 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 20:15 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 15:51 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 23:27 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-26 03:19 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-26 20:38 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-27 11:52 -0500
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-28 03:52 +0200
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-28 11:55 -0500
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-26 11:36 +0000
Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-21 10:36 -0700
Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-21 17:22 +0000
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:34 -0500
Re: LOCALS| and {: mhx@iae.nl - 2013-08-21 23:05 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 03:15 -0500
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-22 14:49 -0700
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:07 +0200
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-26 20:51 -0700
Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-27 15:55 +0200
Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 10:22 -0700
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-27 17:33 +0000
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-27 23:02 +0000
Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 22:02 -0700
Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-27 11:08 -0700
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-27 21:16 -0700
Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:56 +0000
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 20:10 +0000
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:49 +0000
Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-20 07:14 +0000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-21 10:28 +0100
Re: LOCALS| and {: "Elizabeth D. Rather" <erather@forth.com> - 2013-08-18 10:04 -1000
Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-19 20:08 +0100
Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:54 +0000
Re: LOCALS| and {: Mark Wills <markrobertwills@yahoo.co.uk> - 2013-08-20 02:19 -0700
Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 04:37 -0500
Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-17 13:58 +0200
Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-17 18:49 -0700
Re: LOCALS| and {: "Ed" <invalid@invalid.com> - 2013-08-23 17:37 +1000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2013-08-30 02:42 +0000 |
| Message-ID | <kvp0qf$o5s$1@dont-email.me> |
| In reply to | #25374 |
Paul Rubin wrote: > > So you could call a function either with > > struct threeints foo = (a, b, c); > > function foo; > > or > > function(a, b, c); > > That is approximately what Haskell does. Maybe also Ruby. Ruby: func 2, 3, 4 func( 2, 3, 4) > > > or of course > > function(.x=a, .y=b, .z=c); > > That is called "keyword arguments" and is available in a lot of dynamic > languages like Python and (much earlier) Lisp. It doesn't sound > feasible in C because of the need to hair up the linker if calling like > that across modules. Maybe something like it could be done with C++ > templates. > > > (a, b) = (b, a); is swapping a and b > > That is Haskell and Python etc. Ruby: a, b = b, a
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-22 12:24 -0500 |
| Message-ID | <b86dnTs5_vPU1IvPnZ2dnUVZ_uWdnZ2d@supernews.com> |
| In reply to | #25363 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>In Smalltalk, though, you wouldn't have such a problem. >>You'd say: >> >>CreateFont >> withnHeight: h >> withnWidth: w >> withnEscapement: 0 >> withnOrientation: 0 >> withfnWeight: 0 >> withfdwItalic: flag0 >> withfdwUnderline: flag1 >> withfdwStrikeOut: flag2 >> withfdwCharSet: DEFAULT_CHARSET >> withfdwOutputPrecision: OUT_TT_PRECIS >> withfdwClipPrecision: CLIP_DEFAULT >> withfdwQuality: ANTIALIASED_QUALITY >> withfdwPitchAndFamily: family >> >>Surely this is the sort of thing to emulate, rather than C's dumb list. > > There is no accounting for tastes. Anyway, that's easy to emulate, > e.g., in Forth: > > h \ withnHeight > w \ withnWidth > 0 \ withnEscapement > 0 \ withnOrientation > 0 \ withfnWeight > flag0 \ withfdwItalic > flag1 \ withfdwUnderline > flag2 \ withfdwStrikeOut > DEFAULT_CHARSET \ withfdwCharSet > OUT_TT_PRECIS \ withfdwOutputPrecision > CLIP_DEFAULT \ withfdwClipPrecision > ANTIALIASED_QUALITY \ withfdwQuality > family \ withfdwPitchAndFamily > CreateFont But that's not the same thing at all: the things after \ are just comments. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-08-23 11:50 +0000 |
| Message-ID | <2013Aug23.135056@mips.complang.tuwien.ac.at> |
| In reply to | #25365 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>In Smalltalk, though, you wouldn't have such a problem.
>>>You'd say:
>>>
>>>CreateFont
>>> withnHeight: h
>>> withnWidth: w
>>> withnEscapement: 0
>>> withnOrientation: 0
>>> withfnWeight: 0
>>> withfdwItalic: flag0
>>> withfdwUnderline: flag1
>>> withfdwStrikeOut: flag2
>>> withfdwCharSet: DEFAULT_CHARSET
>>> withfdwOutputPrecision: OUT_TT_PRECIS
>>> withfdwClipPrecision: CLIP_DEFAULT
>>> withfdwQuality: ANTIALIASED_QUALITY
>>> withfdwPitchAndFamily: family
>>>
>>>Surely this is the sort of thing to emulate, rather than C's dumb list.
>>
>> There is no accounting for tastes. Anyway, that's easy to emulate,
>> e.g., in Forth:
>>
>> h \ withnHeight
>> w \ withnWidth
>> 0 \ withnEscapement
>> 0 \ withnOrientation
>> 0 \ withfnWeight
>> flag0 \ withfdwItalic
>> flag1 \ withfdwUnderline
>> flag2 \ withfdwStrikeOut
>> DEFAULT_CHARSET \ withfdwCharSet
>> OUT_TT_PRECIS \ withfdwOutputPrecision
>> CLIP_DEFAULT \ withfdwClipPrecision
>> ANTIALIASED_QUALITY \ withfdwQuality
>> family \ withfdwPitchAndFamily
>> CreateFont
>
>But that's not the same thing at all:
It's obviously not the same thing. One is Smalltalk, the other is
Forth.
> the things after \ are just comments.
Yes. So what?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-23 08:13 -0500 |
| Message-ID | <CbednaEkhcuN_YrPnZ2dnUVZ_jmdnZ2d@supernews.com> |
| In reply to | #25376 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>In Smalltalk, though, you wouldn't have such a problem. >>>>You'd say: >>>> >>>>CreateFont >>>> withnHeight: h >>>> withnWidth: w >>>> withnEscapement: 0 >>>> withnOrientation: 0 >>>> withfnWeight: 0 >>>> withfdwItalic: flag0 >>>> withfdwUnderline: flag1 >>>> withfdwStrikeOut: flag2 >>>> withfdwCharSet: DEFAULT_CHARSET >>>> withfdwOutputPrecision: OUT_TT_PRECIS >>>> withfdwClipPrecision: CLIP_DEFAULT >>>> withfdwQuality: ANTIALIASED_QUALITY >>>> withfdwPitchAndFamily: family >>>> >>>>Surely this is the sort of thing to emulate, rather than C's dumb list. >>> >>> There is no accounting for tastes. Anyway, that's easy to emulate, >>> e.g., in Forth: >>> >>> h \ withnHeight >>> w \ withnWidth >>> 0 \ withnEscapement >>> 0 \ withnOrientation >>> 0 \ withfnWeight >>> flag0 \ withfdwItalic >>> flag1 \ withfdwUnderline >>> flag2 \ withfdwStrikeOut >>> DEFAULT_CHARSET \ withfdwCharSet >>> OUT_TT_PRECIS \ withfdwOutputPrecision >>> CLIP_DEFAULT \ withfdwClipPrecision >>> ANTIALIASED_QUALITY \ withfdwQuality >>> family \ withfdwPitchAndFamily >>> CreateFont >> >>But that's not the same thing at all: > > It's obviously not the same thing. One is Smalltalk, the other is > Forth. > >> the things after \ are just comments. > > Yes. So what? The point of keyword notation is to make life easier for the programmer. With your "solution", if you exchange two lines, or if you miss one out, badness will result. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-08-23 13:55 +0000 |
| Message-ID | <2013Aug23.155504@mips.complang.tuwien.ac.at> |
| In reply to | #25378 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> h \ withnHeight
>>>> w \ withnWidth
>>>> 0 \ withnEscapement
>>>> 0 \ withnOrientation
>>>> 0 \ withfnWeight
>>>> flag0 \ withfdwItalic
>>>> flag1 \ withfdwUnderline
>>>> flag2 \ withfdwStrikeOut
>>>> DEFAULT_CHARSET \ withfdwCharSet
>>>> OUT_TT_PRECIS \ withfdwOutputPrecision
>>>> CLIP_DEFAULT \ withfdwClipPrecision
>>>> ANTIALIASED_QUALITY \ withfdwQuality
>>>> family \ withfdwPitchAndFamily
>>>> CreateFont
>>>
>>>But that's not the same thing at all:
>>
>> It's obviously not the same thing. One is Smalltalk, the other is
>> Forth.
>>
>>> the things after \ are just comments.
>>
>> Yes. So what?
>
>The point of keyword notation is to make life easier for the
>programmer. With your "solution", if you exchange two lines, or if
>you miss one out, badness will result.
Yes, it's Forth. Simplicity, not error checking.
Of course, if you like to ensure that the "with..." words all occur
and occur in the right order, it's relatively easy to define them that
way. Of course, if you post such a thing, there sure is someone here
who will write that it's unnecessary complexity.
Anyway, Forth has an advantage for this kind of stuff: It supports
returning multiple data, and that could be used for such calls as
follows:
size \ withnHeight withnWidth
0 \ withnEscapement
0 \ withnOrientation
0 \ withfnWeight
plain \ withfdwItalic withfdwUnderline withfdwStrikeOut
DEFAULT_CHARSET \ withfdwCharSet
rendering-default \ withfdwOutputPrecision withfdwClipPrecision withfdwQuality
family \ withfdwPitchAndFamily
CreateFont
and already it's quite a bit less forbidding.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-23 13:05 -0500 |
| Message-ID | <mf2dnZjBaKzLOYrPnZ2dnUVZ_rmdnZ2d@supernews.com> |
| In reply to | #25379 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> h \ withnHeight >>>>> w \ withnWidth >>>>> 0 \ withnEscapement >>>>> 0 \ withnOrientation >>>>> 0 \ withfnWeight >>>>> flag0 \ withfdwItalic >>>>> flag1 \ withfdwUnderline >>>>> flag2 \ withfdwStrikeOut >>>>> DEFAULT_CHARSET \ withfdwCharSet >>>>> OUT_TT_PRECIS \ withfdwOutputPrecision >>>>> CLIP_DEFAULT \ withfdwClipPrecision >>>>> ANTIALIASED_QUALITY \ withfdwQuality >>>>> family \ withfdwPitchAndFamily >>>>> CreateFont >>>> >>>>But that's not the same thing at all: >>> >>> It's obviously not the same thing. One is Smalltalk, the other is >>> Forth. >>> >>>> the things after \ are just comments. >>> >>> Yes. So what? >> >>The point of keyword notation is to make life easier for the >>programmer. With your "solution", if you exchange two lines, or if >>you miss one out, badness will result. > > Yes, it's Forth. Simplicity, not error checking. Sure, but in this case the process is extremely error-prone because of the long list of arguments. I wonder what the probability of getting it right the first time is. > Of course, if you like to ensure that the "with..." words all occur > and occur in the right order, it's relatively easy to define them that > way. Of course, if you post such a thing, there sure is someone here > who will write that it's unnecessary complexity. It's my turn to say "So what?" In this case, the likelihood of getting it wrong is to high that the usual solution is inadequate. > Anyway, Forth has an advantage for this kind of stuff: It supports > returning multiple data, and that could be used for such calls as > follows: > > size \ withnHeight withnWidth > 0 \ withnEscapement > 0 \ withnOrientation > 0 \ withfnWeight > plain \ withfdwItalic withfdwUnderline withfdwStrikeOut > DEFAULT_CHARSET \ withfdwCharSet > rendering-default \ withfdwOutputPrecision withfdwClipPrecision withfdwQuality > family \ withfdwPitchAndFamily > CreateFont > > and already it's quite a bit less forbidding. True., that's a start. But the indirect version that makes a struct with named fields is more like the right answer. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-08-24 10:36 +0000 |
| Message-ID | <2013Aug24.123652@mips.complang.tuwien.ac.at> |
| In reply to | #25382 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> h \ withnHeight
>>>>>> w \ withnWidth
>>>>>> 0 \ withnEscapement
>>>>>> 0 \ withnOrientation
>>>>>> 0 \ withfnWeight
>>>>>> flag0 \ withfdwItalic
>>>>>> flag1 \ withfdwUnderline
>>>>>> flag2 \ withfdwStrikeOut
>>>>>> DEFAULT_CHARSET \ withfdwCharSet
>>>>>> OUT_TT_PRECIS \ withfdwOutputPrecision
>>>>>> CLIP_DEFAULT \ withfdwClipPrecision
>>>>>> ANTIALIASED_QUALITY \ withfdwQuality
>>>>>> family \ withfdwPitchAndFamily
>>>>>> CreateFont
>>>>>
>>>>>But that's not the same thing at all:
>>>>
>>>> It's obviously not the same thing. One is Smalltalk, the other is
>>>> Forth.
>>>>
>>>>> the things after \ are just comments.
>>>>
>>>> Yes. So what?
>>>
>>>The point of keyword notation is to make life easier for the
>>>programmer. With your "solution", if you exchange two lines, or if
>>>you miss one out, badness will result.
>>
>> Yes, it's Forth. Simplicity, not error checking.
>
>Sure, but in this case the process is extremely error-prone because of
>the long list of arguments. I wonder what the probability of getting
>it right the first time is.
Sounds like what a believer in static type checking says about Forth.
But my experience is that the probability of getting Forth code right
the first time is surprisingly high (certainly higher than what I see
when I use C or Java), and the main reason is that I know that there
is no safety net in Forth, so I program extra careful (another reason
is the complexity of C and Java).
For this particular issue, producing a template like
\ withnHeight
\ withnWidth
\ withnEscapement
\ withnOrientation
\ withfnWeight
\ withfdwItalic
\ withfdwUnderline
\ withfdwStrikeOut
\ withfdwCharSet
\ withfdwOutputPrecision
\ withfdwClipPrecision
\ withfdwQuality
\ withfdwPitchAndFamily
CreateFont
should help keeping the error rate low.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-24 13:05 -0500 |
| Message-ID | <N9OdnS6GHqVAaIXPnZ2dnUVZ_v2dnZ2d@supernews.com> |
| In reply to | #25388 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>>> h \ withnHeight >>>>>>> w \ withnWidth >>>>>>> 0 \ withnEscapement >>>>>>> 0 \ withnOrientation >>>>>>> 0 \ withfnWeight >>>>>>> flag0 \ withfdwItalic >>>>>>> flag1 \ withfdwUnderline >>>>>>> flag2 \ withfdwStrikeOut >>>>>>> DEFAULT_CHARSET \ withfdwCharSet >>>>>>> OUT_TT_PRECIS \ withfdwOutputPrecision >>>>>>> CLIP_DEFAULT \ withfdwClipPrecision >>>>>>> ANTIALIASED_QUALITY \ withfdwQuality >>>>>>> family \ withfdwPitchAndFamily >>>>>>> CreateFont >>>>>> >>>>>>But that's not the same thing at all: >>>>> >>>>> It's obviously not the same thing. One is Smalltalk, the other is >>>>> Forth. >>>>> >>>>>> the things after \ are just comments. >>>>> >>>>> Yes. So what? >>>> >>>>The point of keyword notation is to make life easier for the >>>>programmer. With your "solution", if you exchange two lines, or if >>>>you miss one out, badness will result. >>> >>> Yes, it's Forth. Simplicity, not error checking. > >>Sure, but in this case the process is extremely error-prone because of >>the long list of arguments. I wonder what the probability of getting >>it right the first time is. > > Sounds like what a believer in static type checking says about Forth. Probably, but that doesn't make it wrong. However, I'm not sure that static type checking solves this problem because many of the args are compatible with type integer. > But my experience is that the probability of getting Forth code right > the first time is surprisingly high (certainly higher than what I see > when I use C or Java), and the main reason is that I know that there > is no safety net in Forth, so I program extra careful (another reason > is the complexity of C and Java). > > For this particular issue, producing a template like > > \ withnHeight > \ withnWidth > \ withnEscapement > \ withnOrientation > \ withfnWeight > \ withfdwItalic > \ withfdwUnderline > \ withfdwStrikeOut > \ withfdwCharSet > \ withfdwOutputPrecision > \ withfdwClipPrecision > \ withfdwQuality > \ withfdwPitchAndFamily > CreateFont > > should help keeping the error rate low. It'll help. But please remember where we came in: the suggestion was that local variables help with Windows calls with lots of arguments. I don't believe that locals really help at all: what's needed is named arguments. And this can be done simply and easily by passing a struct that is filled in with the named arguments. No language extension required, just a better interface design. The same is true of Forth - Forth calls as well. A dozen args on the stack is a sure sign that the interface design is messed up. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-08-24 22:44 +0200 |
| Message-ID | <kvb607$ojv$1@online.de> |
| In reply to | #25390 |
Andrew Haley wrote:
> It'll help. But please remember where we came in: the suggestion was
> that local variables help with Windows calls with lots of arguments.
> I don't believe that locals really help at all: what's needed is named
> arguments. And this can be done simply and easily by passing a struct
> that is filled in with the named arguments. No language extension
> required, just a better interface design.
Yes. The local variables help, because you'll have too many arguments, and
you have to reorder them. But when you have named arguments (pass a
struct), you can just store the argument as you go along into that struct.
IMHO this also solves the problem of a stable foreign function interface
without generating code at run-time. For each function, you generate some
code that converts the pointer to a structure call into the ABI call, and
preceed that function with this code. That adds a little bloat, but not
much. Add a label with a name that is not possible in C (e.g. containing a
parenthesis followed by single-letter abbreviations of fundamental types,
in+out).
Generating the structures out of the interface description is pretty easy to
do, all you need to know are the sizes and the alignment restrictions of the
elements; if you go for natural alignment on most platforms, you don't need
to think about it.
Example: Let's say you have the following function:
void setxy(int x, int y)
{
a=x;
b=y;
}
and you compile it on x86_64 to
setxy(II)V:
movl 4(%rdi),%esi
movl (%rdi),%edi
setxy:
movl %edi, a(%rip)
movl %esi, b(%rip)
ret
If you think that C is moribund, to let it die, you need to enable easy
migration away from C. As during the migration period, people will still
have legacies in C, easy calling into C is a must, and the shared library
should contain all necessary informations.
Compare this to Java and the JNI interface: There, you actually have such a
thing.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-25 04:29 -0500 |
| Message-ID | <6OadnYPUPrj_U4TPnZ2dnUVZ_rKdnZ2d@supernews.com> |
| In reply to | #25392 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > > If you think that C is moribund, to let it die, you need to enable easy > migration away from C. And I'm sure that I said that I think that C is not, as I had previously thought, moribund. > As during the migration period, people will still have legacies in > C, easy calling into C is a must, and the shared library should > contain all necessary informations. Why? The headers are where this stuff goes. So use them. > Compare this to Java and the JNI interface: There, you actually have > such a thing. Sure, but a Java .class file has almost everything that's in the source file except the comments. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-08-25 20:15 +0200 |
| Message-ID | <kvdhjb$d1o$1@online.de> |
| In reply to | #25393 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> As during the migration period, people will still have legacies in >> C, easy calling into C is a must, and the shared library should >> contain all necessary informations. > > Why? The headers are where this stuff goes. So use them. We do use them (with Swig and libcc), but overall, it is an awfully bloated approach. If C is intended as system programming language, it fails to do that job. >> Compare this to Java and the JNI interface: There, you actually have >> such a thing. > > Sure, but a Java .class file has almost everything that's in the > source file except the comments. Yes, but that's simply necessary for the purpose. If you want to have a binary container that's intended to be interfaced to, you have to add information about how to interface it, in a way that is fairly easy to parse (and this is exactly what the Java .class file contains!). C is not the be all and end all of languages, even if it is not as moribund as you originally thought. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-25 15:51 -0500 |
| Message-ID | <kfSdnen8E8Sp84fPnZ2dnUVZ_qKdnZ2d@supernews.com> |
| In reply to | #25394 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> As during the migration period, people will still have legacies in >>> C, easy calling into C is a must, and the shared library should >>> contain all necessary informations. >> >> Why? The headers are where this stuff goes. So use them. > > We do use them (with Swig and libcc), but overall, it is an awfully > bloated approach. Well, yes. It's old. But it works well enough. >>> Compare this to Java and the JNI interface: There, you actually have >>> such a thing. >> >> Sure, but a Java .class file has almost everything that's in the >> source file except the comments. > > Yes, but that's simply necessary for the purpose. If you want to > have a binary container that's intended to be interfaced to, you > have to add information about how to interface it, in a way that is > fairly easy to parse (and this is exactly what the Java .class file > contains!). C is not the be all and end all of languages, even if > it is not as moribund as you originally thought. Sure, but what's your point? Does anyone think that C is the be all and end all of programming languages? Does this have anything to do with Forth, or anything else we're talking about? I'm sure either of us could come up with dozens of ways of improving C and many other programming languages. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-08-25 23:27 +0200 |
| Message-ID | <kvdsr7$pum$1@online.de> |
| In reply to | #25398 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> We do use them (with Swig and libcc), but overall, it is an awfully >> bloated approach. > > Well, yes. It's old. But it works well enough. I don't think so. Installing Swig with a work-in-progress patch from Gerald Wodni is something that pretty much does only work for two people now (me and Gerald), and using the C compiler to compile the actual binding is quite limiting, too. I don't actually want to force the user to install GCC if I distribute Gforth! >> Yes, but that's simply necessary for the purpose. If you want to >> have a binary container that's intended to be interfaced to, you >> have to add information about how to interface it, in a way that is >> fairly easy to parse (and this is exactly what the Java .class file >> contains!). C is not the be all and end all of languages, even if >> it is not as moribund as you originally thought. > > Sure, but what's your point? Does anyone think that C is the be all > and end all of programming languages? Yes. Especially the GCC team appears to do so. It's also like saying "use the headers to extract the interface informations." To understand the headers, you need a significant part of the C parser. > Does this have anything to do > with Forth, or anything else we're talking about? I'm sure either of > us could come up with dozens of ways of improving C and many other > programming languages. The typical case I'm dealing with C is when using libraries. If I compare the effort to deal with C libraries e.g. to the effort to deal with Java classes through JNI, I clearly see that there is a huge need for improving C. If people would only write self-containing apps in C, and not release reusable components called libraries, there would be no point in improving. A number of popular modern languages are interactive, and creating C bindings to all of them is pretty much a nuisance. That's because C libraries lack essential information, and the essential information is the interface description. Yes, it's in the header file. In a mostly useless format for anything but the C compiler itself or something with similar complexity. The easiest targets to write bindings for C are pretty ancient like x86. Back in those days, the C calling convention was essentially to create a structure on the stack (with chars and shorts promoted to int). That's easy. Still, the information about the number of parameters and their type is not in the library. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-26 03:19 -0500 |
| Message-ID | <poadnb5zNv0JkobPnZ2dnUVZ_hmdnZ2d@supernews.com> |
| In reply to | #25399 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > > If people would only write self-containing apps in C, and not > release reusable components called libraries, there would be no > point in improving. A number of popular modern languages are > interactive, and creating C bindings to all of them is pretty much a > nuisance. That's because C libraries lack essential information, > and the essential information is the interface description. That's right: they're only really designed to be called from C code. It's a pain in Java too, because you have to write bindings for everything. But surely fixing this doesn't require changes to C itself, but a tool to generate the bindings. But I'm not sure that even the C compiler really has enough information to generate high-quality bindings. It would still need to human input to convert, say, C strings to language strings. Also, the compiler only only sees int*; it doesn't know that's a pointer to an array. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-08-26 20:38 +0200 |
| Message-ID | <kvg7b5$clb$1@online.de> |
| In reply to | #25409 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> >> If people would only write self-containing apps in C, and not >> release reusable components called libraries, there would be no >> point in improving. A number of popular modern languages are >> interactive, and creating C bindings to all of them is pretty much a >> nuisance. That's because C libraries lack essential information, >> and the essential information is the interface description. > > That's right: they're only really designed to be called from C code. > It's a pain in Java too, because you have to write bindings for > everything. Indeed. > But surely fixing this doesn't require changes to C itself, but a tool > to generate the bindings. Oh, please, forget about this concept of long tool chains. The languages that have been recently made are much more interactive, and thus Forth-like in nature. Just embed the necessary information about how to call a function into the shared library in a way that is easy to parse. > But I'm not sure that even the C compiler > really has enough information to generate high-quality bindings. It > would still need to human input to convert, say, C strings to language > strings. Also, the compiler only only sees int*; it doesn't know > that's a pointer to an array. Yes, the string/array/pointer situation is really a problem; the C language lacks an addr+len style interface for passing strings and arrays (compare e.g. to Go, which has that). In any case: C strings are one of the worst misguided "inventions" of this language. They force to create a copy of a string... This can only be topped by the JNI bindings: To create a Java string e.g. from Forth, you need *two* copies. First, the C string, and then of course the Java String object is another copy of the data. One copy is unavoidable, as Forth stores strings in addr+len and UTF-8 format, and Java stores them as array of integers. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-27 11:52 -0500 |
| Message-ID | <D42dnePLuIvbRIHPnZ2dnUVZ_g2dnZ2d@supernews.com> |
| In reply to | #25419 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> >>> If people would only write self-containing apps in C, and not >>> release reusable components called libraries, there would be no >>> point in improving. A number of popular modern languages are >>> interactive, and creating C bindings to all of them is pretty much a >>> nuisance. That's because C libraries lack essential information, >>> and the essential information is the interface description. >> >> That's right: they're only really designed to be called from C code. >> It's a pain in Java too, because you have to write bindings for >> everything. > > Indeed. > >> But surely fixing this doesn't require changes to C itself, but a tool >> to generate the bindings. > > Oh, please, forget about this concept of long tool chains. The > languages that have been recently made are much more interactive, > and thus Forth-like in nature. Just embed the necessary information > about how to call a function into the shared library in a way that > is easy to parse. So why bother with C? You're fighting C's essential nature. It seems that C is everything you don't want, so rather than use something else that does what you want, you want to change C. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-08-28 03:52 +0200 |
| Message-ID | <kvjl48$6ga$1@online.de> |
| In reply to | #25428 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Oh, please, forget about this concept of long tool chains. The >> languages that have been recently made are much more interactive, >> and thus Forth-like in nature. Just embed the necessary information >> about how to call a function into the shared library in a way that >> is easy to parse. > > So why bother with C? You're fighting C's essential nature. It seems > that C is everything you don't want, so rather than use something else > that does what you want, you want to change C. The problem I have with this approach is that C is everywhere, and I absolutely have to interface with C (and, on Android, even Java), because all system libraries are written in C (except on Android, where it is a mix of C, C++, and Java; which is actually easier than just C after you got over the initial hurdle that you now need another interface to another language, because Java is so much better to interface with). If you want to write system libraries, please use a language which makes sense for writing system libraries. Apparently, C isn't making sense (if you don't see C as the appropriate language to write applications, which is now common sense), so it needs changing. Best in a way that doesn't break code. You have to remember: If you write a system library, you don't write for yourself. It's "nine times the effort", as Fred Brooks argues. Some of that effort needs to go into the compiler and the binary format, and Java is pretty well designed in this aspect. If you think that the mission of C is just being another language for lone wolf programming, then you are missing the point of C. That's what C was designed for: systems and system libraries (though with a 1970 mindest). The language to write the fastest benchmarks in is called Fortran, and the language for lone wolf programming is called Forth. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-08-28 11:55 -0500 |
| Message-ID | <OIudnUU19JEBtoPPnZ2dnUVZ_rCdnZ2d@supernews.com> |
| In reply to | #25441 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Oh, please, forget about this concept of long tool chains. The >>> languages that have been recently made are much more interactive, >>> and thus Forth-like in nature. Just embed the necessary information >>> about how to call a function into the shared library in a way that >>> is easy to parse. >> >> So why bother with C? You're fighting C's essential nature. It seems >> that C is everything you don't want, so rather than use something else >> that does what you want, you want to change C. > > The problem I have with this approach is that C is everywhere, and I > absolutely have to interface with C (and, on Android, even Java), > because all system libraries are written in C (except on Android, > where it is a mix of C, C++, and Java; which is actually easier than > just C after you got over the initial hurdle that you now need > another interface to another language, because Java is so much > better to interface with). > > If you want to write system libraries, please use a language which > makes sense for writing system libraries. Apparently, C isn't > making sense (if you don't see C as the appropriate language to > write applications, which is now common sense), so it needs > changing. Best in a way that doesn't break code. So, you have a job to do if you want to persuade people to make that change. It's an interesting idea, but a lot of work. > You have to remember: If you write a system library, you don't write > for yourself. It's "nine times the effort", as Fred Brooks argues. > Some of that effort needs to go into the compiler and the binary > format, and Java is pretty well designed in this aspect. > > If you think that the mission of C is just being another language > for lone wolf programming, then you are missing the point of C. Eh? Of course you are. Why would I think that? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-08-26 11:36 +0000 |
| Message-ID | <521b3dd7$0$3208$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #25393 |
In article <6OadnYPUPrj_U4TPnZ2dnUVZ_rKdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> wrote: >> >> If you think that C is moribund, to let it die, you need to enable easy >> migration away from C. > >And I'm sure that I said that I think that C is not, as I had >previously thought, moribund. > >> As during the migration period, people will still have legacies in >> C, easy calling into C is a must, and the shared library should >> contain all necessary informations. > >Why? The headers are where this stuff goes. So use them. > >> Compare this to Java and the JNI interface: There, you actually have >> such a thing. > >Sure, but a Java .class file has almost everything that's in the >source file except the comments. As has an gcc object file that is compiled with debug information. So what? > >Andrew. -- 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 | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2013-08-28 22:27 -0400 |
| Message-ID | <2bct19pl580nevrksdqmp8e9mdcapuhtpi@4ax.com> |
| In reply to | #25393 |
On Sun, 25 Aug 2013 04:29:06 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: <snip> > > Compare this to Java and the JNI interface: There, you actually have > > [interface information] > > Sure, but a Java .class file has almost everything that's in the > source file except the comments. > Not necessarily. You have the names and types of class member variables, and the names, return types, parameter types, and declared Exceptions for methods. And the names of base classes and interfaces. Local variable names and types, and parameter names, are optional; they can be omitted by the compiler, or stripped afterward. Same for line-number mappings, but those only matter if you care about exact source layout. You also may not have the declared scope of local variables, but you can reconstruct the effective scope which is good enough. (To be pedantic, even with line-number mappings you don't have source *columns* and indentation, but that's a triviality.) Also if there's dead code in the source the compiler usually omits it from the .class file.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web