Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What do forth people think about google go?

6 views
Skip to first unread message

gavino

unread,
Jan 1, 2010, 3:36:16 PM1/1/10
to

John Passaniti

unread,
Jan 2, 2010, 8:06:05 PM1/2/10
to
On Jan 1, 3:36 pm, gavino <gavcom...@gmail.com> wrote:
> http://golang.org/doc/go_lang_faq.html

I think "Issue 9" would be a much cooler name.

billy

unread,
Jan 4, 2010, 1:26:06 AM1/4/10
to
On Jan 1, 12:36 pm, gavino <gavcom...@gmail.com> wrote:
> http://golang.org/doc/go_lang_faq.html

It's cool, but not related to Forth in any particular way.

My first thought was "why didn't they give a little credit to Oberon?"
It's so similar to Oberon it's scary. Total library redesign, of
course, and more of the C syntax, plus a few new features, but
otherwise...

I may learn it one day. Especially if they manage to make it faster
than Python eventually -- that's really, REALLY bad to be slower than
Python. I love Python, use it all the time... But it's really, really
not designed to be fast.

-Wm

Helmar

unread,
Jan 5, 2010, 2:03:11 PM1/5/10
to
On Jan 1, 3:36 pm, gavino <gavcom...@gmail.com> wrote:
> http://golang.org/doc/go_lang_faq.html

It is a moving target. They even sometimes change the syntax in
incompatible ways...
The basic concept is not as bad, as some people want to make it. It is
not "general purpose" and it does not do every useful concept it could
have.
I've made a pet-project with it to learn the language. See
http://code.google.com/p/pdfreader/
Try the "pdserve" program (point your browser to pdserve.html if
you've started it) to see the most useful visual result.

It's btw. very simple to implement a Forth in Go ;)

Regards,
-Helmar

gavino

unread,
Jan 5, 2010, 2:51:58 PM1/5/10
to

ever try stackless python?

gavino

unread,
Jan 5, 2010, 2:52:48 PM1/5/10
to
On Jan 5, 11:03 am, Helmar <hel...@gmail.com> wrote:
> On Jan 1, 3:36 pm, gavino <gavcom...@gmail.com> wrote:
>
> >http://golang.org/doc/go_lang_faq.html
>
> It is a moving target. They even sometimes change the syntax in
> incompatible ways...
> The basic concept is not as bad, as some people want to make it. It is
> not "general purpose" and it does not do every useful concept it could
> have.
> I've made a pet-project with it to learn the language. Seehttp://code.google.com/p/pdfreader/

> Try the "pdserve" program (point your browser to pdserve.html if
> you've started it) to see the most useful visual result.
>
> It's btw. very simple to implement a Forth in Go ;)
>
> Regards,
> -Helmar

btw?

so you prefer forth! when would you use go not forth?

Helmar

unread,
Jan 5, 2010, 3:23:34 PM1/5/10
to
On Jan 5, 2:52 pm, gavino <gavcom...@gmail.com> wrote:

Hi,

> so you prefer forth! when would you use go not forth?

I think if I'd write a server for HTTP, I'd very probably prefer Go.
This works fine with Go and out of the box. It's also nice to have the
slices and compared to C the maps.

-Helmar

Ian Osgood

unread,
Jan 6, 2010, 2:43:04 PM1/6/10
to
On Jan 1, 12:36 pm, gavino <gavcom...@gmail.com> wrote:
> http://golang.org/doc/go_lang_faq.html

It is a fine language for the intended purpose: large scale software
development which requires the efficiency of a compiled language and
the flexibility of a dynamic language. The forces at Google which led
to the creation of Go:

* Ken Thompson and Rob Pike. 'Nuff said. :) Ken has a 40-year itch
to scratch. This is also why Limbo's CSP model of concurrency was
used.

* Steaming piles of legacy C++ that take forever to build due to C's
primitive header file semantics. This motivates the fast compilation
and package semantics.

* Entrenched Python culture. This led to garbage collection, the array
slice features, and choices of built-in maps and other objects.

* The rise of multi-core computers and server farms. Forth should see
the writing on the wall here. I wish more people acknowledged that the
language itself is the right place for the multiprocessing
abstractions. There is too much room to err otherwise.

* Modula-3 and Oberon. co-routines and class libraries.

Ian

Mat

unread,
Jan 8, 2010, 5:54:53 AM1/8/10
to
On 5 Jan., 19:03, Helmar <hel...@gmail.com> wrote:
> On Jan 1, 3:36 pm, gavino <gavcom...@gmail.com> wrote:
> It's btw. very simple to implement a Forth in Go ;)

Hello,

For me, at current I don't see much differences in implementing Forth
with Go to C. The only thing I really miss is a simple preprocessor
but that can be solved otherwise (replicating-switch threading).

One advantage is there simple co-processing concept as language
feature make it easy to implementing some kind parallel processing in
forth although there approach seem not very efficient yet.

And the available compilers other than these GCC based one are a work
in progress at best...

Ciao,
Mat.

Peter Knaggs

unread,
Feb 23, 2010, 6:24:53 AM2/23/10
to Mat
This is actually a poll about how widely the proposal is implemented
and how popular it is among the programmers. It is called a CfV
(call-for-votes) because the process is inspired by the Usenet Rdf/CfV
process.

You find the actual ballot further down (look for "VOTING PROCEDURE"),
after the proposal on which you vote.

PROPOSAL
========

Synonyms

Stephen Pelc, 26 September 2008

20080926 Updated ambiguous conditions.
20060922 Enhanced current practice section.
Fixed some typos.
20060821 First draft.


Rationale
=========

Problem
-------
Various words have been used to generate a new name for an existing
word. This required when porting code and when generating application
wordlists that contain a reference to an existing word, e.g. when
providing limited access to Forth system kernel words.

Especially with native code compiling Forth systems and cross
compilers, these words have not provided full access to the required
behaviour. The behaviour may require carnal knowledge of the
underlying system, which is one reason why SYNONYM should be
standardised.

Current practice
----------------
The proposed form SYNONYM has been in use at MPE with cross compilers
and VFX Forth since 1998. It is also implemented in Win32Forth and
PFE.

Many people have suggested that we stay with words such as AKA, ALIAS
or ALIAS:, usually of the form

' oldname ALIAS newname

This has merit in terms of common practice, but will break code for
several systems. Some systems, e.g. cross compilers, cannot generate
enough information using the xt of a word alone. All surveyed
systems can implement SYNONYM.

Solution
--------
Although many people have objected to parsing words, parsing permits
the host system the most flexibility in implementation and is thus
the preferred solution.

The syntax is:

SYNONYM <newname> <oldname>

where <newname> will behave identically to <oldname>.

Note that <newname> may be the same as <oldname>.


Proposal
========

10.6.2.xxxx SYNONYM synonym FACILITY EXT
( "<spaces>newname" "<spaces>oldname" -- )

For both strings skip leading space delimiters. Parse name
delimited by a space. definition for newname with the semantics
defined below. Newname may be the same as oldname.

newname interpretation: ( i*x -- j*x )
Perform the interpretation semantics of oldname

newname compilation: ( i*x -- j*x )
Perform the compilation semantics of oldname

Ambiguous conditions:
oldname is not found.
IMMEDIATE is used on a word defined by SYNONYM.


Reference Implementation
========================

The implementation of SYNONYM requires carnal knowledge of the host
implementation, which is one reason why it should be standardised.
The implementation below is imperfect and specific to VFX Forth.

: Synonym \ <"new-name"> <"curdef"> --
\ *G Create a new definition which redirects to an existing one.
create immediate
hide ' , reveal
does>
@ state @ 0= over immediate? or
if execute else compile, then
;


VOTING INSTRUCTIONS
===================

Fill out the appropriate ballot(s) below and mail it/them to
<vo...@forth200x.org>. Your vote will be published (including your
name (without email address) and/or the name of your system) on
<http://www.forth200x.org/substitute.html>. You can vote (or change
your vote) at any time, and the results will be published there.

Note that you can be both a system implementor and a programmer, so
you can submit both kinds of ballots.


Ballot for systems

If you maintain several systems, please mention the systems separately
in the ballot. Insert the system name or version between the brackets.
Multiple hits for the same system are possible (if they do not
conflict).

[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.

If you want to provide information on partial implementation, please do
so informally, and I will aggregate this information in some way.


Ballot for programmers

Just mark the statements that are correct for you (e.g., by putting an
"x" between the brackets). If some statements are true for some of your
programs, but not others, please mark the statements for the dominating
class of programs you write.

[ ] I have used (parts of) this proposal in my programs.
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.

If you feel that there is closely related functionality missing from the
proposal (especially if you have used that in your programs), make an
informal comment, and I will collect these, too. Note that the best time
to voice such issues is the RfD stage.

CREDITS

Proponent: Stephen Pelc
Votetaker: Peter Knaggs

--
Peter Knaggs

0 new messages