Google releases new programing language.
Don McKenzie
Google releases new programing language.
http://golang.org/
http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
and for your viewing pleasure:
http://www.youtube.com/watch?v=rKnDgT73v8s
a one hour youtube video!
Cheers Don...
--
Don McKenzie
Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
Web Camera Page: http://www.dontronics.com/webcam
No More Damn Spam: http://www.dontronics.com/spam
Rich Webb
>
>Google releases new programing language.
>http://golang.org/
>
>http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>
>and for your viewing pleasure:
>http://www.youtube.com/watch?v=rKnDgT73v8s
>a one hour youtube video!
Looks interesting, in the sed->awk->Perl tradition perhaps.
But "goroutines"? Somebody should be flogged...
--
Rich Webb Norfolk, VA
Rob Gaddi
>
> Google releases new programing language.
> http://golang.org/
>
> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>
> and for your viewing pleasure:
> http://www.youtube.com/watch?v=rKnDgT73v8s
> a one hour youtube video!
>
>
> Cheers Don...
>
Looks a lot like Python, but with a compiler instead of an
interpreter. *shrug*
--
Rob Gaddi, Highland Technology
Email address is currently out of order
Grant Edwards
>> Google releases new programing language.
>> http://golang.org/
> Looks a lot like Python, but with a compiler instead of an
> interpreter. *shrug*
To me, it looks a lot more like C/Java than it looks like
Python:
* whitespace isn't significant
* curly-braces as block delimiters
* semicolons to separate statements
When it comes to semantics rather than looks, it still doesn't
seem all that similar to Python. In general, the object/type
system doesn't seem to be comparable (Go has no inheritence).
Go also has no exceptions or any practical error-handling
facilities.
All in all, I was pretty underwheled.
--
Grant Edwards grante Yow! I have the power to
at HALT PRODUCTION on all
visi.com TEENAGE SEX COMEDIES!!
Bob
gootines?
They got into trouble as soon as they named it "go"
Bob
David Brown
>
> Google releases new programing language.
> http://golang.org/
>
> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>
> and for your viewing pleasure:
> http://www.youtube.com/watch?v=rKnDgT73v8s
> a one hour youtube video!
>
This is comp.arch.embedded - where's the compilers for non-x86 targets?
I suppose that gccgo could be re-targeted, if the run-time library is
not too difficult to port.
From a very quick glance, it looks like some good points:
Source in utf-8 with utf-8 support throughout (not a big deal for
embedded systems, but great for "big" systems);
Proper modules and namespaces;
Useful standard libraries;
Inferred strong typing;
Mandatory braces in for, if and switch statements;
Proper arrays that are distinct from pointers;
Maps (like Python dicts or Perl hashes);
Support for processes and communication;
Explicitly sized integers;
and some bad points:
Separate compiler and linker steps (you'd think they would have learned
from the "success" of gcc's link-time optimisation project);
Much of the ugliness from C, with a good dose of its own (though less
than C++ templates);
Currently limited to x86 and amd64.
Rich Webb
A quite decent review by MarkCC over at Good Math, Bad Math
<http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php>
Mark qualifies as One Smart Cookie and he has had some time to play with
the language since he works at Google. Short version: ... nah, read the
original; it's not too long and has useful insights.
The best, though, was from commentator James H G Redekop: "I get this
feeling they picked the name so that when they put out the next version
of the language, they can call it Go2 and make Dijkstra jokes."
Grant Edwards
> When it comes to semantics rather than looks, it still doesn't
> seem all that similar to Python.
[...]
One big difference between Python and Go that I forgto to
mention is that go is statically typed while Python is
dynamically typed. That's a pretty fundamental difference.
I use Python every day, and I really don't see where the
comparison to Python comes from. To me it looks more like
cleaned up Java or C with garbage collection.
--
Grant Edwards grante Yow! What a COINCIDENCE!
at I'm an authorized "SNOOTS
visi.com OF THE STARS" dealer!!
geoff
Can't it print simple words ? Lazzo may be interested....
geoff
-jg
> Google releases new programing language.http://golang.org/
>
> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>
> and for your viewing pleasure:http://www.youtube.com/watch?v=rKnDgT73v8s
> a one hour youtube video!
>
> Cheers Don...
Interesting, but missing was a For each,
which is a rather glaring omission on something that hopes to improve
what is already out there ?
No examples, and no EXE sizes listed
( it does create standalone EXEs, right ? )
I also liked Microsoft's ASMl language... on the topic of research-lab-
languages...
-jg
krel
> Currently limited to x86 and amd64.
Well they specifically mention that an incomplete port to ARM exists so
I guess it is not too far away.
-jg
>
> Interesting, but missing was a For each,
> which is a rather glaring omission on something that hopes to improve
> what is already out there ?
Looking at the examples in the link above, I see
range might do this
for c := range self.chars {...
- but their keyword list omitted mention of this under for..
Seems a confusing use of = and := ?
Are there rules to that, or does either work ?
-jg
Andrew Reilly
> Seems a confusing use of = and := ?
> Are there rules to that, or does either work ?
There are rules. := is short-hand for variable declaration, typing *and*
initial assignment. = is just assignment. If you're keen on syntactic
sugar, it seems like a fairly well-thought-out way to avoid quite a lot
of boilerplate.
Don't forget the multiple result mechanism: I think that might go quite a
way towards making up for the lack of exceptions. Not a fan of
exceptions myself. The multiple returns means that one donesn't have to
pass results back through a reference argument just to get the error code
(common C idiom), or designate a range of result values as "errors".
--
Andrew
son of a bitch
>
> Google releases new programing language.
> http://golang.org/
>
> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>
> and for your viewing pleasure:
> http://www.youtube.com/watch?v=rKnDgT73v8s
> a one hour youtube video!
>
>
> Cheers Don...
>
>
>
Great, there seems to be world wide shortage of
Computer Programming Languages.
But kinda just looks like Microsoft + Borland + C + Pascal + Perl
Dirk Zabel
>
> Don't forget the multiple result mechanism: I think that might go quite a
> way towards making up for the lack of exceptions. Not a fan of
> exceptions myself. The multiple returns means that one donesn't have to
> pass results back through a reference argument just to get the error code
> (common C idiom), or designate a range of result values as "errors".
>
-- Dirk
malcolm
>
> Great, there seems to be world wide shortage of
> Computer Programming Languages.
:)
> But kinda just looks like Microsoft + Borland + C + Pascal + Perl
Yes, which could make it a good teaching tool ?
Anyone tried the IDE ? (it does have one, right?)
-jg
malcolm
> On Thu, 12 Nov 2009 14:13:45 -0800, -jg wrote:
> > Seems a confusing use of = and := ?
> > Are there rules to that, or does either work ?
>
> There are rules. := is short-hand for variable declaration, typing *and*
> initial assignment. = is just assignment. If you're keen on syntactic
> sugar, it seems like a fairly well-thought-out way to avoid quite a lot
> of boilerplate.
Ah, yes, that's nifty...
> Don't forget the multiple result mechanism: I think that might go quite a
> way towards making up for the lack of exceptions. Not a fan of
> exceptions myself. The multiple returns means that one donesn't have to
> pass results back through a reference argument just to get the error code
> (common C idiom), or designate a range of result values as "errors".
Yes, noticed that - a nice idea.
-jg
David Brown
It's a *programming language*. Why would a programming language have an
IDE?
Perhaps what you are trying to ask is whether there are syntax
highlighting setups available for commonly used IDEs such as Eclipse,
KDevelope, (x)emacs, etc.
And maybe you are also asking about the state of the debugger - does it
have one, is it based on gdb, or does it "speak" gdb and can thus be
used with existing gdb front-ends?
I don't know the answer to either of these, but it helps to ask the
right questions.
keithr
>
> Google releases new programing language.
> http://golang.org/
>
> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>
> and for your viewing pleasure:
> http://www.youtube.com/watch?v=rKnDgT73v8s
> a one hour youtube video!
>
>
> Cheers Don...
>
<sarcasm>
We really needed another one.
</sarcasm>
David Segall
>malcolm wrote:
>> On Nov 13, 11:29 am, son of a bitch <bitchin_2...@yahoo.com> wrote:
>>> Great, there seems to be world wide shortage of
>>> Computer Programming Languages.
>>
>> :)
>>
>>> But kinda just looks like Microsoft + Borland + C + Pascal + Perl
>>
>> Yes, which could make it a good teaching tool ?
>>
>> Anyone tried the IDE ? (it does have one, right?)
>>
>
>It's a *programming language*. Why would a programming language have an
>IDE?
Where have you been? I think an Integrated Development Environment is
now essential for system development in any language. The poster is
right to expect one or more that supports Go. It is difficult to list
the features that you should expect from an IDE without knowing the
programming language but Sun have a (Java oriented) list of features
to look for in an IDE here -
<http://java.sun.com/developer/technicalArticles/tools/intro.html>.
>
>Perhaps what you are trying to ask is whether there are syntax
>highlighting setups available for commonly used IDEs such as Eclipse,
>KDevelope, (x)emacs, etc.
>
>And maybe you are also asking about the state of the debugger - does it
>have one, is it based on gdb, or does it "speak" gdb and can thus be
>used with existing gdb front-ends?
>
>I don't know the answer to either of these, but it helps to ask the
>right questions.
He asked one of the right questions. Most text editors can do syntax
highlighting. Using a separate front end to gdb is hardly
"integrated".
David Brown
> David Brown <da...@westcontrol.removethisbit.com> wrote:
>
>> malcolm wrote:
>>> On Nov 13, 11:29 am, son of a bitch <bitchin_2...@yahoo.com> wrote:
>>>> Great, there seems to be world wide shortage of
>>>> Computer Programming Languages.
>>> :)
>>>
>>>> But kinda just looks like Microsoft + Borland + C + Pascal + Perl
>>> Yes, which could make it a good teaching tool ?
>>>
>>> Anyone tried the IDE ? (it does have one, right?)
>>>
>> It's a *programming language*. Why would a programming language have an
>> IDE?
>
> Where have you been? I think an Integrated Development Environment is
> now essential for system development in any language. The poster is
It's a matter of choice. I use a dozen different C compilers with
almost as many target processors, plus several other programming
languages. The last thing I need with a new compiler or new language is
a new IDE to go with it.
There are three ways to work when programming:
1) You can use an IDE that came with your compiler + tools
2) You can use a generic IDE with whatever compiler and tools you want
3) You can use a simpler editor with command line tools
Using a compiler/toolchain specific IDE is fine if you do most of your
work using it, or if it has a great deal of added value (such as a
graphics design system for guis, or RAD tools, or whatever). It's also
great if you want a simple "all-in-one" system and don't want to think
about your tools. But typically, these IDEs are limited and inflexible,
and every one is different - making your job a lot harder if you work
with more than one toolchain or language.
Generic IDEs like Eclipse are a better choice for many uses. You get a
powerful editor, project management, source code versioning control,
build management, debugging, etc. Language-specific syntax
highlighting, refactoring, etc., is done by plugins or syntax
highlighting files. If your development process fits standard models
neatly, you can use built-in build management, otherwise the IDE will
call external "make" tools.
Some people (including me) prefer a simpler editor and use command-line
tools such as explicitly running "make" commands. I find that gives me
the fastest and most flexible development process, and gives me a fairly
consistent environment for my different toolchains.
No sane toolchain vendor would make a new IDE unless they have very
specific requirements, or overwhelmingly many special features. In
commercial toolchain development, the trend is towards Eclipse for new
IDEs - many vendors are even dropping their existing IDEs and moving to
Eclipse in newer versions. You can expect that sooner or later an
Eclipse plugin for "go" will turn up, as well as an emacs mode and, if
the language becomes popular, plugins and syntax highlighter files for
other common IDEs and editors.
> right to expect one or more that supports Go. It is difficult to list
> the features that you should expect from an IDE without knowing the
> programming language but Sun have a (Java oriented) list of features
> to look for in an IDE here -
> <http://java.sun.com/developer/technicalArticles/tools/intro.html>.
>
A few of these features are programming language specific, but most are
very general - and are providing by generic IDEs.
I am not saying you should not use, or want to use, an IDE for "go".
I'm just saying that you should not expect a compiler toolchain vendor
to provide a specific IDE - it is far from necessary for using the
language, and would be a big waste of effort.
Antoon
"David Brown" <david...@hesbynett.removethisbit.no> schreef in bericht
news:2qOdndYsI8cL8WHX...@lyse.net...
> Don McKenzie wrote:
> >
> > Google releases new programing language.
> > http://golang.org/
> >
> > http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
> >
> > and for your viewing pleasure:
> > http://www.youtube.com/watch?v=rKnDgT73v8s
> > a one hour youtube video!
> >
>
> This is comp.arch.embedded - where's the compilers for non-x86 targets?
> I suppose that gccgo could be re-targeted, if the run-time library is
> not too difficult to port.
>
> From a very quick glance, it looks like some good points:
>
> Source in utf-8 with utf-8 support throughout (not a big deal for
> embedded systems, but great for "big" systems);
>
The deifference between a Public function and a private function is
determined by the first character of the name. But when using UTF-8
how does it tell the difference for say Japanese names?
Antoon
-jg
Integrated Development environment, and Integrated Debug Environment -
many use the former to mean 'an editor'.
A syntax highlighting editor, is a very small amount of work, and the
language should be able to be added to most good editors, quite
easily.
However, good DEBUG is very different, and if someone wants a NEW
language to take off, it had BETTER be easy to get up to speed on.
Simple really.
Good debug is rather hard to simply bolt-on-later.
Look around at some of the smarter systems out there :
Microsoft have free tools, with very good (seamless)integration of key
parts
* Syntax editor
* Data inspector, including find declaration
* Variable watch
* Breakpoints
Same with Lazarus - A wide choice of languages, all
with usable systems. (not stone soup)
Data inspection and variable watch, are rather tightly linked to the
language definition, and the compiler and object files itself.
So, that task really needs to be done by whoever wants the language
to be widely used - if you want it done quickly, and right.
Sure, start with something that already works on another language,
but there are enough new features in Go, that a lot of detail work is
needed.
Of course, if their only target is the depths of research labs, and
those happy with the command line....
-jg
terryc
> It's a matter of choice. I use a dozen different C compilers with
> almost as many target processors, plus several other programming
> languages. The last thing I need with a new compiler or new language is
> a new IDE to go with it.
What do you mean by and IDE, aka what functions does it need to have?
Several editors do bracket matching, keyword highlighting, etc.
Is that enough?>
krel
>>> Perhaps what you are trying to ask is whether there are syntax
>>> highlighting setups available for commonly used IDEs such as Eclipse,
>>> KDevelope, (x)emacs, etc.
>>> And maybe you are also asking about the state of the debugger - does
>>> it have one, is it based on gdb, or does it "speak" gdb and can thus
>>> be used with existing gdb front-ends?
If you download the Go source code you can already find syntax
highlighting scripts for vim, emacs and xcode in the /misc directory.
René König
http://code.google.com/p/go/issues/detail?id=9&colspec=ID
David Segall
>David Segall wrote:
>> David Brown <da...@westcontrol.removethisbit.com> wrote:
>>
>>> malcolm wrote:
>>>> On Nov 13, 11:29 am, son of a bitch <bitchin_2...@yahoo.com> wrote:
>>>>
>>>> Anyone tried the IDE ? (it does have one, right?)
>>>>
>>> It's a *programming language*. Why would a programming language have an
>>> IDE?
>>
>> Where have you been? I think an Integrated Development Environment is
>> now essential for system development in any language. The poster is
>
>It's a matter of choice.
Agreed. I responded to your post only because I thought your sentence
below implied that the poster asked the "wrong" question and I happen
to prefer the posters choice to yours.
Bob Larter
> On 2009-11-12, Grant Edwards <inv...@invalid.invalid> wrote:
>
>> When it comes to semantics rather than looks, it still doesn't
>> seem all that similar to Python.
> [...]
>
> One big difference between Python and Go that I forgto to
> mention is that go is statically typed while Python is
> dynamically typed. That's a pretty fundamental difference.
>
> I use Python every day, and I really don't see where the
> comparison to Python comes from. To me it looks more like
> cleaned up Java or C with garbage collection.
That's my take on it too. What really impressed me was the great
concurrency stuff.
--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
Bob Larter
> Don McKenzie wrote:
>>
>> Google releases new programing language.
>> http://golang.org/
>>
>> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>>
>> and for your viewing pleasure:
>> http://www.youtube.com/watch?v=rKnDgT73v8s
>> a one hour youtube video!
>>
>
> This is comp.arch.embedded - where's the compilers for non-x86 targets?
It supports ARM as well as x86.
-jg
> If you look at Go, you should look at Go! as well:http://code.google.com/p/go/issues/detail?id=9&colspec=ID
:)
Oh Dear, OOps....!
Guess they did not use the Google search engine, did they!! Red faces
all round.
So, Sounds like 'Goo', or 'Goog', or 'ogle' might have to be 'new
name' candidates - or they could simply throw some money at the
problem...., but that would not go
down as well with their target.
-jg
David Brown
> David Brown wrote:
>> Don McKenzie wrote:
>>>
>>> Google releases new programing language.
>>> http://golang.org/
>>>
>>> http://tech.yahoo.com/news/infoworld/20091110/tc_infoworld/99864
>>>
>>> and for your viewing pleasure:
>>> http://www.youtube.com/watch?v=rKnDgT73v8s
>>> a one hour youtube video!
>>>
>>
>> This is comp.arch.embedded - where's the compilers for non-x86 targets?
>
> It supports ARM as well as x86.
>
I noticed that as a minor point deeper inside the documentation - the
front pages don't mention it.
Obviously Google have worked on compilers targeting the cpus they are
interested in. But if it is going to be of interest to
comp.arch.embedded, it there must be compilers targeting the cpus /we/
are interested in. x86 and amd64 barely register here, and pure ARM is
not much better. If and when there are ports for ARM Thumb, Cortex,
PPC, Coldfire, MIPs, AVR, 8051, msp430, etc., etc., then c.a.e. can get
excited.
David Brown
You'd have to ask someone who wants to program with Japanese function names.
I don't really see much benefit from being able to use non-ASCII
characters in function or variable names. But then, I program in
English (and even if I occasionally use Norwegian words in names, it's
easy to transliterate for programming purposes). Where I do see utf-8
as potentially useful is in strings, and possibly in comments and inline
source code documentation.
I'm not a fan of having something as small as the capitalization of a
name affecting something as important as the visibility of a function.
David Brown
> David Brown <da...@westcontrol.removethisbit.com> wrote:
>
>> David Segall wrote:
>>> David Brown <da...@westcontrol.removethisbit.com> wrote:
>>>
>>>> malcolm wrote:
>>>>> On Nov 13, 11:29 am, son of a bitch <bitchin_2...@yahoo.com> wrote:
>>>>>
>>>>> Anyone tried the IDE ? (it does have one, right?)
>>>>>
>>>> It's a *programming language*. Why would a programming language have an
>>>> IDE?
>>> Where have you been? I think an Integrated Development Environment is
>>> now essential for system development in any language. The poster is
>> It's a matter of choice.
>
> Agreed. I responded to your post only because I thought your sentence
> below implied that the poster asked the "wrong" question and I happen
> to prefer the posters choice to yours.
You are being overly polite - I didn't /imply/ that he asked the wrong
questions, I /said/ he asked the wrong questions! But on reading my own
post, it was unreasonable of me to word it that strongly - rather, I
should have said he could have asked /better/ questions, that are more
likely to have positive answers and that discuss tools that are more
useful to the language's target audience.
Nobody
> I'm not a fan of having something as small as the capitalization of a
> name affecting something as important as the visibility of a function.
This isn't without precedent. E.g. Prolog uses upper-case for variables
and lower-case for atoms, Haskell uses upper-case for constructors,
lower-case for variables (and symbols for infix operators).
Other languages may lack rules but have conventions, e.g. Java
conventionally uses upper-case for class names, lower-case for everything
else (variables, parameters, members, methods, packages), and this
convention seems to be uniformly followed.
One advantage of using case is that it can make a language context-free
rather than context-sensitive, as you can distinguish between different
kinds of identifier without having to keep track of which identifiers are
in scope and with which kind.
David Brown
> On Sun, 15 Nov 2009 11:41:00 +0100, David Brown wrote:
>
>> I'm not a fan of having something as small as the capitalization of a
>> name affecting something as important as the visibility of a function.
>
> This isn't without precedent. E.g. Prolog uses upper-case for variables
> and lower-case for atoms, Haskell uses upper-case for constructors,
> lower-case for variables (and symbols for infix operators).
>
In these cases, it's slightly different in that you are talking about
different parts of the language. A particularly bad thing about forcing
a convention like this to determine public or private access is that it
is something you will often want to change during the development of a
program. It is far from uncommon that you want a particular variable to
be private to a module, class, block or whatever, yet sometimes you want
to "cheat" and peak at it during testing and debugging. With C, that
means removing the "static" in the declaration, and adding an "extern"
declaration in your temporary test/debug code. With a language like
Pascal, it means adding it temporarily to your "interface" section.
With Go, it means doing a search and replace to change the small letter
into a capital letter - a far more intrusive and inconvenient operation.
> Other languages may lack rules but have conventions, e.g. Java
> conventionally uses upper-case for class names, lower-case for everything
> else (variables, parameters, members, methods, packages), and this
> convention seems to be uniformly followed.
>
Conventions are fine, and have can be very beneficial. But they are
just conventions - if they are not appropriate for the code you are
writing, you don't have to follow them. But even such capitalization
conventions are enforced as rules, I still do not think it is an
appropriate way to determine such an important aspect of the code. A
clear and unambiguous keyword such as "public" is much better, IMHO (and
this is all about personal opinion). It is much clearer to read, and
easier to spot by eye or to search for with an editor.
> One advantage of using case is that it can make a language context-free
> rather than context-sensitive, as you can distinguish between different
> kinds of identifier without having to keep track of which identifiers are
> in scope and with which kind.
>
That is certainly a benefit. But no language is context free - you are
only making it slightly less context sensitive, and I can't see that it
is worth the cost.
Grant Edwards
There's a gcc frontend for Go, so doesn't that cover Cortex,
ARM Thumb, PPC, Coldfire, MIPS, AVR, SPARC, IBM z-series, H8,
SH, MSP430, and so on?
--
Grant
-jg
>
> There's a gcc frontend for Go, so doesn't that cover Cortex,
> ARM Thumb, PPC, Coldfire, MIPS, AVR, SPARC, IBM z-series, H8,
> SH, MSP430, and so on?
Depends what you mean by 'cover'.
If that means can create 'hello world', yes, but the serious weakness
of a hop that includes gcc, is the debug info no longer reaches back
to the users source code.
Any polished debug environment needs source level Step, and full
variable watch, in the native structures.
-jg
Boudewijn Dijkstra
<newsnine...@woa.com.au>:
You're talking about editor features. An IDE provides (or should provide)
project management, toolchain calling and debug support as well.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
David Brown
> On Nov 16, 9:36 am, Grant Edwards <inva...@invalid.invalid> wrote:
>> There's a gcc frontend for Go, so doesn't that cover Cortex,
>> ARM Thumb, PPC, Coldfire, MIPS, AVR, SPARC, IBM z-series, H8,
>> SH, MSP430, and so on?
>
The gcc front end is certainly a good start. gcc has numerous
front-ends (C, C++, Fortran, Ada, Objective C, and various other
out-of-tree languages), a middle-end, and a range of back-ends
(something like 30+ in-treee). However, gcc is not nearly as modular as
it appears - there are interconnections between front-end parts and
back-end parts that mess things up. In particular, you can't just take
the "go" front-end and configure and compile for the AVR back-end - it's
quite possible that the "go" front-end makes demands of the back-end,
such as insisting on it being 32-bit. As another example, avr-gcc is
missing some features in its C++ support (though some would say that
having only limited RTTI and exceptions support is a good thing...),
partly because of missing front-end, back-end interaction.
Even when minimal requirements are met, there is then the quality of the
code. Again as an easy example, the avr backend can generate quite
reasonable 32-bit code - but if the front-end language insists on using
32-bit all the time, the final generated avr code will be terrible even
if it is technically correct.
Then there are the libraries - although I believe that much of the "go"
libraries is written in C, there are still porting issues.
So a gcc front-end for "go" is a big step towards portability, but there
are still more steps ahead.
> Depends what you mean by 'cover'.
> If that means can create 'hello world', yes, but the serious weakness
> of a hop that includes gcc, is the debug info no longer reaches back
> to the users source code.
> Any polished debug environment needs source level Step, and full
> variable watch, in the native structures.
>
I think this is a bit mixed up. Having a gcc front-end means that you
/can/ get debug information all the way through. I believe you are
thinking of a a C pre-processor (like "cfront") that generates C code
and is then compiled. If that were the case, using C as an intermediary
language, then most debug information is typically lost.
Of course, having a gcc front-end does not guarantee that you do get
good debug information - it depends on the quality of the debug
information generated by the gcc "go" front-end, on how well that fits
with gdb (or other elf debuggers), and how well the actual debugger
software works.
Andrew Reilly
> Op Sat, 14 Nov 2009 00:26:04 +0100 schreef terryc
> <newsnine...@woa.com.au>:
>> On Fri, 13 Nov 2009 14:13:03 +0100, David Brown wrote:
>>
>>> It's a matter of choice. I use a dozen different C compilers with
>>> almost as many target processors, plus several other programming
>>> languages. The last thing I need with a new compiler or new language
>>> is a new IDE to go with it.
>>
>> What do you mean by and IDE, aka what functions does it need to have?
>> Several editors do bracket matching, keyword highlighting, etc. Is that
>> enough?>
>
> You're talking about editor features. An IDE provides (or should
> provide) project management, toolchain calling and debug support as
> well.
Don't forget command line argument obfuscation. That seems to be very
important. That, and include paths. Impenetrable.
Cheers,
--
Andrew
Nobody
>> One advantage of using case is that it can make a language context-free
>> rather than context-sensitive, as you can distinguish between different
>> kinds of identifier without having to keep track of which identifiers are
>> in scope and with which kind.
>
> That is certainly a benefit. But no language is context free - you are
> only making it slightly less context sensitive, and I can't see that it
> is worth the cost.
There's a benefit to being able to *parse* a language using a context-free
grammar. This allows text editors to perform highlighting,
auto-completion, etc without having to track identifiers (which
isn't always possible; editors have to be able to work with incomplete
code).
David Brown
That is certainly true - it is not easy for an editor to use different
syntax highlighting for C functions and variables, for example.
Context-free, or close to context-free, makes this a lot easier. It
also makes compilation easier and faster (which was one of the goals of
"go"). However, I'd prefer the editor to have to work harder rather
than me - I would parse the difference between "public foo" and "private
foo" faster than the difference between "Foo" and "foo". I can always
buy a faster computer, and a better parser only needs to be written
once, but it's hard to upgrade the human brain...
Jasen Betts
> On Nov 16, 9:36 am, Grant Edwards <inva...@invalid.invalid> wrote:
>>
>> There's a gcc frontend for Go, so doesn't that cover Cortex,
>> ARM Thumb, PPC, Coldfire, MIPS, AVR, SPARC, IBM z-series, H8,
>> SH, MSP430, and so on?
>
> Depends what you mean by 'cover'.
> If that means can create 'hello world', yes, but the serious weakness
> of a hop that includes gcc, is the debug info no longer reaches back
> to the users source code.
is go so badly broken that it doesn't use the "#line" preprocessor
directive to enable source level debugging? or are you making shit up?
Bob Larter
> I think this is a bit mixed up. Having a gcc front-end means that you
> /can/ get debug information all the way through. I believe you are
> thinking of a a C pre-processor (like "cfront") that generates C code
> and is then compiled. If that were the case, using C as an intermediary
> language, then most debug information is typically lost.
If you check the doc's, they mention that the GCC frontend generates C
code, which is all you get for debugging.
David Brown
> David Brown wrote:
>> I think this is a bit mixed up. Having a gcc front-end means that you
>> /can/ get debug information all the way through. I believe you are
>> thinking of a a C pre-processor (like "cfront") that generates C code
>> and is then compiled. If that were the case, using C as an
>> intermediary language, then most debug information is typically lost.
>
> If you check the doc's, they mention that the GCC frontend generates C
> code, which is all you get for debugging.
>
I haven't read the docs, so I'll take your word for it. But if that's
the case, then it is not a gcc frontend - it's a pre-processor
generating C as an intermediary language. That's fair enough - there
are several compiler tools that do that, and it's a quick way to make a
fairly portable tool. But the terminology they have used on the website
is at best misleading.
Sylvia Else
> Don't forget the multiple result mechanism:
Of course not. It's a nice symmetry. Previously one could only get
confused about the order the parameters. Now scope for confusion about
the order of results has been added.
Sylvia.
Marco
> I haven't read the docs, so I'll take your word for it. But if that's
> the case, then it is not a gcc frontend - it's a pre-processor
> generating C as an intermediary language.
I disagree with your use of the term "pre-processor" it can still be
a full compiler that generates C code. A pre-processor doesn't do type
checking, semantics, etc. very important for embedded code.
David Brown
Do you have a suggestion for a better term? You are certainly correct
that the compile-go-to-C program has more compiler features than the
traditional C pre-processor, but less than a traditional compiler.
Nobody
How much of the original structure is retained in the C code?
GHC's C output isn't noticeably higher-level than its assembler output, so
I'd call it a compiler whether it's generating C or assembler.
OTOH, if the Go compiler's C code preserves much of the structure of its
input (along the lines of CFront or f2c), I'd call it a translator.
David Brown
> On Sun, 22 Nov 2009 18:25:45 +0100, David Brown wrote:
>
>>>> I haven't read the docs, so I'll take your word for it. But if that's
>>>> the case, then it is not a gcc frontend - it's a pre-processor
>>>> generating C as an intermediary language.
>>> I disagree with your use of the term "pre-processor" it can still be
>>> a full compiler that generates C code. A pre-processor doesn't do type
>>> checking, semantics, etc. very important for embedded code.
>>>
>> Do you have a suggestion for a better term? You are certainly correct
>> that the compile-go-to-C program has more compiler features than the
>> traditional C pre-processor, but less than a traditional compiler.
>
> How much of the original structure is retained in the C code?
>
No idea.
> GHC's C output isn't noticeably higher-level than its assembler output, so
> I'd call it a compiler whether it's generating C or assembler.
>
> OTOH, if the Go compiler's C code preserves much of the structure of its
> input (along the lines of CFront or f2c), I'd call it a translator.
>
That sounds reasonable enough to me. Since I can't answer your
question, however, I can't tell which is the most appropriate. Maybe if
I keep quiet, someone who has actually tried the software can give us an
answer!
Marco
<david.br...@hesbynett.removethisbit.no> wrote:
> Marcowrote:
came across:
A "source-to-source compiler" is a type of compiler that takes a high
level language as its input and outputs a high level language.