Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #30165 > unrolled thread
| Started by | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| First post | 2014-05-07 13:06 -0700 |
| Last post | 2014-05-07 20:01 -0700 |
| Articles | 20 on this page of 155 — 23 participants |
Back to article view | Back to comp.lang.forth
gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-07 13:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 13:31 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 00:10 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 23:21 -0700
Re: gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-08 04:07 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 14:21 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 17:36 +0000
Re: gforth too bloated ? dambere@web.de - 2014-05-09 15:01 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 00:05 +0200
Re: gforth too bloated ? Melzzzzz <mel@zzzzz.invalid> - 2014-05-10 00:30 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 09:16 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 03:27 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-09 20:42 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-07 22:32 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 21:06 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-09 04:14 -0500
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 13:42 -0400
Re: gforth too bloated ? Roger Levy <roger.levy@gmail.com> - 2014-05-09 11:48 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:18 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 09:19 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:30 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 13:21 -1000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:16 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:28 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 10:39 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 12:04 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-11 12:10 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 13:11 +0000
Re: gforth too bloated ? Stan Barr <plan.b@dsl.pipex.com> - 2014-05-11 16:17 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 17:10 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 08:34 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 22:12 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:38 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:35 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:29 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 23:37 -0700
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:40 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-12 00:39 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 10:20 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-12 05:10 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-13 09:17 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-13 04:28 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-12 03:19 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-13 16:40 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-13 07:56 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 11:52 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-14 08:15 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:09 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:42 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 17:21 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 10:45 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 12:56 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 12:03 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-14 09:17 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 16:50 +0000
Re: gforth too bloated ? AKK <akk@nospam.org> - 2014-05-14 20:26 +0200
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-14 20:38 +0200
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 20:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 14:22 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-15 17:39 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:03 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:32 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 02:13 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 20:18 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:08 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:28 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:23 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:52 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 09:19 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 11:51 -0500
Re: gforth too bloated ? Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> - 2014-05-17 22:00 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:20 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:54 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 15:51 +0200
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-16 07:59 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:39 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:22 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:11 -0500
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-16 15:43 +0200
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:26 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 03:42 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:19 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-16 17:59 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 13:20 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 14:08 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-18 10:07 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-21 21:37 -0400
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 10:06 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 10:04 +0000
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 15:39 +0200
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-22 13:36 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 11:59 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:11 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 14:48 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 20:27 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-22 02:23 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:51 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:41 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:40 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:16 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 21:09 -0400
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 03:57 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-15 15:50 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 10:07 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:33 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 08:04 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-17 19:03 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:06 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-19 01:38 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 13:38 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:39 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 15:49 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 20:30 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 17:59 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:08 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:07 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:15 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 12:11 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 12:36 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:17 -0700
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-20 16:26 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-20 09:27 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 15:48 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 18:35 +0100
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 03:45 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:28 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 11:56 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 20:54 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:06 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-22 17:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:05 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-23 19:19 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:30 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-22 12:09 -0500
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:22 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:03 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 16:57 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:28 +0200
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 21:56 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 00:21 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:42 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-22 02:15 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:47 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:12 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:24 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 12:00 +0000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-10 13:16 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-10 11:05 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 18:11 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 02:12 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 16:36 +0000
Re: gforth too bloated ? jacko <jackokring@gmail.com> - 2014-05-07 20:01 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-15 15:03 -0700 |
| Message-ID | <7xha4q66nn.fsf@ruckus.brouhaha.com> |
| In reply to | #30404 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
> Well, I started to say better syntax: LOCAL x LOCAL y defined
> globally like VARIABLE x VARIABLE y.
Aside from name collisions, this also doesn't work if the function using
the locals is recursive or reentrant.
> But, I'm not sure how older Forths would handle destroying or freeing
> the variable at the end-of-use, without major internal changes to the
> interpreter. Where is the garbage collection in an interpreted Forth?
For normal Forth locals, the variables are on a stack that's unwound
when the function exits, like in C. That can be either the return stack
or a dedicated locals stack. You'd normally heap-allocate and GC the
locals if you want to support closures (upward funargs), but I don't
think anyone is proposing doing that, or at least standardizing it.
Instead the idea is to only support "downward" quotations/closures.
Anton has a GC package here:
http://www.complang.tuwien.ac.at/forth/garbage-collection.zip
and it might be interesting to use it in connection with closures. But,
most languages get along ok without (upward) closures, typically using
OOP instead.
It occurs to me, maybe a useful form of upward closures can be supported
by simply ALLOT'ing the memory for the locals when the closure is
created. This leaks memory if you have loops making such closures on
the fly, but sometimes it's useful to just have a few permanent closures
in your program, that persist through its execution and don't need to be
GC'd. E.g. suppose your Forth has FLN (natural log) and you want a
few other bases as well. Something like:
: logBase ( f -- xt ) fln 1e fswap f/ { a } [: fln a * :] ;
2e logBase flg CONSTANT flg \ log base 2
10e logBase flog10 CONSTANT flog10 \ log base 10
8e flg f. \ prints 3
Here the "a" in logBase is an upward funarg copied into a permanent
meory cell, with two such cells allocated at the start of the program
(or you could imagine a few more, if you wanted log base 5 or whatever).
"Permanently" allocated locals should probably use a different syntax
than normal locals, though if GC is present they wouldn't have to be
truly permanent.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-15 15:06 -0700 |
| Message-ID | <7xd2fe66ik.fsf@ruckus.brouhaha.com> |
| In reply to | #30405 |
Paul Rubin <no.email@nospam.invalid> writes:
> : logBase ( f -- xt ) fln 1e fswap f/ { a } [: fln a * :] ;
> 2e logBase flg CONSTANT flg \ log base 2
> 10e logBase flog10 CONSTANT flog10 \ log base 10
Meant to say:
: logBase ( f -- xt ) fln 1e fswap f/ { a } [: fln a * :] ;
2e logBase CONSTANT flg \ log base 2
10e logBase CONSTANT flog10 \ log base 10
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-15 15:32 -0700 |
| Message-ID | <7xegzuk700.fsf@ruckus.brouhaha.com> |
| In reply to | #30406 |
Paul Rubin <no.email@nospam.invalid> writes:
> : logBase ( f -- xt ) fln 1e fswap f/ { a } [: fln a * :] ;
> 2e logBase CONSTANT flg \ log base 2
> 10e logBase CONSTANT flog10 \ log base 10
And this doesn't work either--I forgot that you have to say EXECUTE in
order to run an xt. I'll leave an appropriate CREATE wrapper to your
imagination.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-16 02:13 +0200 |
| Message-ID | <ll3l72$mif$1@online.de> |
| In reply to | #30405 |
Paul Rubin wrote: > Anton has a GC package here: > > http://www.complang.tuwien.ac.at/forth/garbage-collection.zip > > and it might be interesting to use it in connection with closures. But, > most languages get along ok without (upward) closures, typically using > OOP instead. Indeed - a frequent usage of closures in Lisp-like language is to implement OOP. Just do OOP directly, no need to do closures as a way to implement it. Actually, the closures that do exist in Forth are implemented using OOP. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-15 20:18 -0700 |
| Message-ID | <7xoayy76nq.fsf@ruckus.brouhaha.com> |
| In reply to | #30408 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Indeed - a frequent usage of closures in Lisp-like language is to implement
> OOP. Just do OOP directly, no need to do closures as a way to implement it.
> Actually, the closures that do exist in Forth are implemented using OOP.
In Lisp it's partly a matter of stylistic preference. The log-base-n
example I tried to post is easier with closures than with a full-blown
class definition and access methods. In Scheme it would be
(define (logBase base)
(let ((a (/ 1 (log base)))) ; log is natural log in scheme
(lambda (x) (* (log x) a))))
(define log2 (logBase 2))
(define log10 (logBase 10))
in Haskell it's even cleaner:
logBase b x = a*log x
where a = 1/log b
log2 = logBase 2
log10 = logBase 10
In Java? I don't want to think about it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-16 04:08 -0500 |
| Message-ID | <_8SdnRVy-7UOSOjOnZ2dnUVZ_tCdnZ2d@supernews.com> |
| In reply to | #30409 |
Paul Rubin <no.email@nospam.invalid> wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Indeed - a frequent usage of closures in Lisp-like language is to implement
>> OOP. Just do OOP directly, no need to do closures as a way to implement it.
>> Actually, the closures that do exist in Forth are implemented using OOP.
>
> In Lisp it's partly a matter of stylistic preference. The log-base-n
> example I tried to post is easier with closures than with a full-blown
> class definition and access methods. In Scheme it would be
>
> (define (logBase base)
> (let ((a (/ 1 (log base)))) ; log is natural log in scheme
> (lambda (x) (* (log x) a))))
>
> (define log2 (logBase 2))
> (define log10 (logBase 10))
>
> in Haskell it's even cleaner:
>
> logBase b x = a*log x
> where a = 1/log b
> log2 = logBase 2
> log10 = logBase 10
>
> In Java? I don't want to think about it.
Heh. Your wish is my command. :-)
It's basically the same, modulo the usual Java type declarations:
DoubleFunction logBase(int base) {
Double a = 1 / Math.log(base);
return x -> a * Math.log(x);
}
DoubleFunction log2 = logBase(2);
DoubleFunction log10 = logBase(10);
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-16 04:28 -0500 |
| Message-ID | <MtKdncutIuzKR-jOnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #30416 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> Indeed - a frequent usage of closures in Lisp-like language is to implement
>>> OOP. Just do OOP directly, no need to do closures as a way to implement it.
>>> Actually, the closures that do exist in Forth are implemented using OOP.
>>
>> In Lisp it's partly a matter of stylistic preference. The log-base-n
>> example I tried to post is easier with closures than with a full-blown
>> class definition and access methods. In Scheme it would be
>>
>> (define (logBase base)
>> (let ((a (/ 1 (log base)))) ; log is natural log in scheme
>> (lambda (x) (* (log x) a))))
>>
>> (define log2 (logBase 2))
>> (define log10 (logBase 10))
>>
>> in Haskell it's even cleaner:
>>
>> logBase b x = a*log x
>> where a = 1/log b
>> log2 = logBase 2
>> log10 = logBase 10
>>
>> In Java? I don't want to think about it.
>
> Heh. Your wish is my command. :-)
>
> It's basically the same, modulo the usual Java type declarations:
>
> DoubleFunction logBase(int base) {
> Double a = 1 / Math.log(base);
> return x -> a * Math.log(x);
> }
>
> DoubleFunction log2 = logBase(2);
> DoubleFunction log10 = logBase(10);
Thinking about it some more, though, why would anyone even bother with
a closure for this? It's really just an object with one method:
public class LogBase {
double a;
LogBase(int base) { a = 1 / Math.log(base); }
double log(double x) { return a * Math.log(x); }
}
LogBase log2 = LogBase(2);
LogBase log10 = LogBase(10);
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-16 09:23 -0700 |
| Message-ID | <7xmwehu1zh.fsf@ruckus.brouhaha.com> |
| In reply to | #30418 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> public class LogBase {
> double a;
> LogBase(int base) { a = 1 / Math.log(base); }
> double log(double x) { return a * Math.log(x); }
> }
Do you still have to put that definition in a separate file, and import
it to anyplace that might use it?
> LogBase log2 = LogBase(2);
> LogBase log10 = LogBase(10);
Now you have to say log2.log(x) instead of log2(x) but I guess that's ok.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-17 07:52 -0500 |
| Message-ID | <8pydneT7k_8YxurOnZ2dnUVZ_oqdnZ2d@supernews.com> |
| In reply to | #30424 |
Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> public class LogBase {
>> double a;
>> LogBase(int base) { a = 1 / Math.log(base); }
>> double log(double x) { return a * Math.log(x); }
>> }
>
> Do you still have to put that definition in a separate file, and import
> it to anyplace that might use it?
If it's public, sure, but Java users generally use an IDE, and there
the operation is simply "create a class." There is no "default"
namesapce, although you can always say something like
import com.redhat.util.*;
in all of your project files, so in practice it doesn't matter.
>> LogBase log2 = LogBase(2);
>> LogBase log10 = LogBase(10);
>
> Now you have to say log2.log(x) instead of log2(x) but I guess
> that's ok.
You always have to do that: only methods may be called, and every
method has an object, so you always have to say which object's log()
method you want. Most pure-OOP languages have this property, although
I think you may be able to invoke an object's default method without
specifying its name in something like BETA.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-17 09:19 -0700 |
| Message-ID | <7xppjcs7ig.fsf@ruckus.brouhaha.com> |
| In reply to | #30434 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Do you still have to put that definition in a separate file, and import >> it to anyplace that might use it? > > If it's public, sure, but Java users generally use an IDE, and there > the operation is simply "create a class." Hmm, maybe the IDE helps... I find the separate file per class as creating huge ongoing clutter when trying to read code. The one-time inconvenience when the class is first created is minor by comparison. >>log2.log(x) instead of log2(x) > ... Most pure-OOP languages have this property, although I think you > may be able to invoke an object's default method Python objects can have a __call__ method so you can just call the object.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-17 11:51 -0500 |
| Message-ID | <PpOdnU7SuNkRDurOnZ2dnUVZ_rqdnZ2d@supernews.com> |
| In reply to | #30438 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Do you still have to put that definition in a separate file, and import >>> it to anyplace that might use it? >> >> If it's public, sure, but Java users generally use an IDE, and there >> the operation is simply "create a class." > > Hmm, maybe the IDE helps... I find the separate file per class as > creating huge ongoing clutter when trying to read code. AFAIK most Java programmers just right-click on an identifier and go to its definition. It makes little difference which file it's in, and there's not much reason for people even to be aware of source files. Import statements are created by the IDE. > The one-time inconvenience when the class is first created is minor > by comparison. The filename rule makes stuff easy to find though, even outside the IDE. I've wished for that a few times with C++! Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> |
|---|---|
| Date | 2014-05-17 22:00 +0200 |
| Message-ID | <5377bfd9$0$2061$426a74cc@news.free.fr> |
| In reply to | #30434 |
Le 17/05/2014 14:52, Andrew Haley a écrit :
> Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> public class LogBase {
>>> double a;
>>> LogBase(int base) { a = 1 / Math.log(base); }
>>> double log(double x) { return a * Math.log(x); }
>>> }
>>
>> Do you still have to put that definition in a separate file, and import
>> it to anyplace that might use it?
>
> If it's public, sure, (...)
If you define it as an inner "static public class" of some other class
(http://docs.oracle.com/javase/tutorial/java/javaOO/innerclasses.html),
it will share a file along with another class. But actually as you said,
in java the number of files isn't an issue.
sam (just passing :) )
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-16 09:20 -0700 |
| Message-ID | <7xr43tu23t.fsf@ruckus.brouhaha.com> |
| In reply to | #30416 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > return x -> a * Math.log(x); Is that a recent addition to Java? Anyway, if even Java now has closures, that definitively establishes them as (at least) a useful alternative to OOP.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-17 07:54 -0500 |
| Message-ID | <8pydnef7k_--werOnZ2dnUVZ_oqdnZ2d@supernews.com> |
| In reply to | #30423 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> return x -> a * Math.log(x); > > Is that a recent addition to Java? Fairly recent, yes. Java 8. > Anyway, if even Java now has closures, that definitively establishes > them as (at least) a useful alternative to OOP. It's still OOP, or it wouldn't be possible in Java: a Function is (conceptually, at least) an Object with a single method. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-16 15:51 +0200 |
| Message-ID | <ll555p$cgv$1@online.de> |
| In reply to | #30409 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Indeed - a frequent usage of closures in Lisp-like language is to >> implement >> OOP. Just do OOP directly, no need to do closures as a way to implement >> it. Actually, the closures that do exist in Forth are implemented using >> OOP. > > In Lisp it's partly a matter of stylistic preference. The log-base-n > example I tried to post is easier with closures than with a full-blown > class definition and access methods. In Scheme it would be > > (define (logBase base) > (let ((a (/ 1 (log base)))) ; log is natural log in scheme > (lambda (x) (* (log x) a)))) > > (define log2 (logBase 2)) > (define log10 (logBase 10)) > > in Haskell it's even cleaner: > > logBase b x = a*log x > where a = 1/log b > log2 = logBase 2 > log10 = logBase 10 > > In Java? I don't want to think about it. Forth (you tried it, and failed): : logbase ( rbase -- ) create fln 1/f f, does> ( r -- log[r] ) fln f@ f* ; 2e logbase flb 10e logbase flg The Haskell solution looks more like math, but the Forth solution is pretty close in what it does. No need for OOP, closures or such things in Forth. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-05-16 07:59 +0200 |
| Message-ID | <85ha4qxnzp.fsf@junk.nocrew.org> |
| In reply to | #30408 |
Bernd Paysan wrote: > a frequent usage of closures in Lisp-like language is to implement > OOP. Just do OOP directly, no need to do closures as a way to > implement it. I haven't checked thouroughly, but I believe most serious Lisp implementations do indeed implement OOP directly. Using closures to implement OOP would probably only be for 1) toy Lisps, or 2) academic exercises.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-16 13:39 +0000 |
| Message-ID | <2014May16.153957@mips.complang.tuwien.ac.at> |
| In reply to | #30405 |
Paul Rubin <no.email@nospam.invalid> writes:
>It occurs to me, maybe a useful form of upward closures can be supported
>by simply ALLOT'ing the memory for the locals when the closure is
>created. This leaks memory if you have loops making such closures on
>the fly, but sometimes it's useful to just have a few permanent closures
>in your program, that persist through its execution and don't need to be
>GC'd. E.g. suppose your Forth has FLN (natural log) and you want a
>few other bases as well. Something like:
>
>: logBase ( f -- xt ) fln 1e fswap f/ { a } [: fln a * :] ;
> 2e logBase flg CONSTANT flg \ log base 2
>10e logBase flog10 CONSTANT flog10 \ log base 10
>
>8e flg f. \ prints 3
Forth already supports this kind of thing with CREATE DOES>
: log-base ( r "name" -- )
\ environmental dependency on sane alignment by CREATE
create 1e fswap fln f/ f,
does> ( r1 -- r2 )
fln f@ f* ;
2e log-base fld
10e log-base flog
Or alternatively with :":
: log-base ( r "name" -- )
1e fswap fln f/
: ]] fln fliteral f* ; [[ ;
2e log-base fld
10e log-base flog
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-16 01:22 -0700 |
| Message-ID | <cd6d8a4c-8315-4a97-82e2-63ac7a921775@googlegroups.com> |
| In reply to | #30404 |
On Thursday, 15 May 2014 22:39:40 UTC+1, Rod Pemberton wrote:
> It would also mean that the braces { } delimit the parameter list.
> I'm assuming that older, non-optimizing Forths will just define a
> temporary variable with the address location for the item on the
> stack.
Offsets into the stack, in order to support locals in recursive functions.
> But, I'm not sure how older Forths would handle destroying
> or freeing the variable at the end-of-use, without major internal
> changes to the interpreter. Where is the garbage collection in an
> interpreted Forth? ...
>
It's not necessary. The locals are allocated on a stack (some systems use a dedicated locals stack, like mine, and others use the return stack. The space is allocated at run-time, at the start of the word, and de-allocated when the word exits.
>
> I can also see the braces syntax being a slight implementation issue
> for older Forths too. The { brace would need to be some type of
> looping word to fetch the name of each local to be defined.
I've already implemented this (in high-level Forth) in my Forth-83 ITC Forth. See http://turboforth.net/locals.htm - there's a full break-down of how it works. Turns out it's insanely easy to implement. Well, easy with a dedicated locals stack. Implementing on the return stack is much trickier. If your looping words (DO et al) use the return stack (most do) then locals on the return stack become tricky. The index into the locals on the return stack would change with each loop. This would have to be managed at compile time. Not impossible. Just trickier. I chose the easy way out and just implemented a new stack. It's all high level Forth and would probably compile just fine on your system.
One thing to note: My implementation doesn't add the names of the locals to the Forth dictionary. In fact it doesn't add them to any dictionary at all. It's not necessary. There's no reason to manipulate the dictionary in any way to implement locals (so don't think in terms of CREATE or HEADER or anything like that).
All you have to do is hash the names of the locals in some way when then are defined (i.e. in LOCALS| , and store those hashes in a table on the heap. LOCALS| loops and exits when it sees a single | .
FIND is re-vectored. During compiliation of the defintion being compiled, FIND searches the dictionary/vocab as normal. If the word that you're searching for is NOT found, then you hash the word, then go search the locals table. If you find it, then its offset in that table has a direct relationship to the offset into the locals/return stack at run-time.
Simple. See my page for a breakdown if it's something that interests you. I demonstrated to a couple of guys here in the office how you can add local variables to the language *by writing the implementation yourself* and I think it's fair to say it absolutely blew their brains out.
>
> I'd say that if locals of any form are widely adopted, it should
> definately improve optimizing Forths and help with conversion of
> Forth to C. But, I'm uncertain as to how difficult or easy it
> would be to implement this within an interpreted Forth. Currently,
> I think it would have some issues as mentioned above (looping,
> garbage collection). I.e., this seems to be a feature that
> preferences modern Forths.
>
I'm not expert on modern optimising Forths by any means, but I suspect you're right. I think one issue at the moment is that a lot of Forth system favour saving the top of the data stack in registers, rather than locals. Consequently, including locals in your Forth definition can actually slow things down, as extra register traffic results - not enough registers.
There seems to be a certain snobbery towards locals in the Forth world. Like you're some sort of pussy if you revert to the use of locals. My view is, if it saves a load of performance hitting stackrobatics (at least on my simple Forth system) *or* makes my code easier to understand, I'll use them. I think they're a great addition to the language.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-16 04:11 -0500 |
| Message-ID | <_8SdnRRy-7W4S-jOnZ2dnUVZ_tCdnZ2d@supernews.com> |
| In reply to | #30412 |
Mark Wills <markwills1970@gmail.com> wrote: > I demonstrated to a couple of guys here in the office how you can > add local variables to the language *by writing the implementation > yourself* and I think it's fair to say it absolutely blew their > brains out. Well, yes, and that's really the point. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-05-16 15:43 +0200 |
| Message-ID | <5r0dxn3kderx$.1b96y2w0legdo$.dlg@40tude.net> |
| In reply to | #30412 |
Op Fri, 16 May 2014 01:22:34 -0700 (PDT) schreef Mark Wills: <snip a perfect explanation> > FIND is re-vectored. During compiliation of the defintion being compiled, > FIND searches the dictionary/vocab as normal. If the word that you're > searching for is NOT found, then you hash the word, then go search the > locals table. If you find it, then its offset in that table has a direct > relationship to the offset into the locals/return stack at run-time. You have to look for locals FIRST, then the rest. This way there are no name collisions. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web