Error 404 - Not Found
Sorry, but you are looking for something that isn't here.
Yes, I’m aware of most of those links — I was a particular fan of the Lindsey/van der Meulen book and it helped me write a compiler on some informal Algol68 subset languages. I must say I’m personally relieved that W-grammars haven’t caught on for modern languages — they always gave me a headache 🙂
]]>The “official reference” (aka Final Report??) informally uses an english commentary to describe Algol68, but formally uses “Van Wijngaarden grammar” to enforce the syntax AND sematics.
* http://en.wikipedia.org/wiki/Van_Wijngaarden_grammar
In contrast C-lang uses “K&R” (aka the Old Testiment) describe and premote the C programming language, but “under the bonnet” there were many things not described in the”K&R” testiment…
For example: “What _did_ the C operators /\ and \/ do?”
* http://stackoverflow.com/questions/1540886/what-did-the-c-operators-and-do
In both cases (vWG-grammars and PDP-10 C-code) are the ultimate reference, but neither are intended for the novice.
To learn Algol68 the better choice would be to read:
* Chapter 0 of http://www.softwarepreservation.org/projects/ALGOL/book/Lindsey_van_der_Meulen-IItA68-Revised.pdf
* OR “A Tutorial on ALGOL 68”. ANDREW S. TANENBAUM. http://www.timesink.org/cs6373/Algol68.pdf
FYI: there is an informal Algol68@linkedin group one could join to help rediscover this classic language:
* http://www.linkedin.com/groups/Algol68-2333923
And a very good (and easy to use) Algol68 implementation by Marcel can currently be downloaded from: http://jmvdveer.home.xs4all.nl
(Marcel’s A68 implementation is an “interpreter” that will – on the fly (on linux) – generate a “ELF LSB shared object” (when the optimisation option is used)
]]>“such a tool would not work particularly well given there is a wide range of coding styles out there and all sorts of unusual things you can do in C that could not be moved to Swift automatically.”
Yes there are things you *CAN* do in C that couldn’t be moved to swift automatically, but one would assume that the vast majority of well written objective-c code wouldn’t do that too often. Like you could store stuff in C arrays with pointers, but I would hope, most objective-c programmers would choose to use objective-c arrays. That’s why I said it would only convert 95% of code or something.
I don’t know that coding styles would matter too much. After all, the basic model of swift, the class and object model, the way the whole method system works is obviously the same. It’s when you put crufty C-isms into a method you might run into trouble, but I would guess most code doesn’t do that.
“Secondly, there is no point. The objc code is perfectly good and will interoperate with swift just fine.”
Yes it does, but I think most people would feel weird when half their code is in Swift and half in objective-c, always in internal mental conflict about whether now is the time to rewrite that source file or class, or whether to push on a bit longer with the objective-c. If someone writes a convertor, that decision is made easier. Run the convertor over it, if no warnings pop out, happily carry on in Swift. If some warnings pop out, see how much cruft it can’t convert before making a decision whether to push on in objective-c.
]]>“As for rewriting existing libraries? I don’t see any advantage in doing that as a religious movement.”
I do see an advantage, for all the same reasons they introduced the language. Stronger type checking = less bugs and more maintainable. Also, I’d imagine they could start making the APIs better for developers with better parameterised types and a stronger contract in the API. Whenever I’ve gone through some Java code and upgraded everything to the latest version, added full template support, removed warnings (the stronger the typing, the more sensible warnings you can get), I’ve always found bugs hiding, and God knows there are plenty of bugs in Cocoa.
My prediction is they’ll spend a couple of years bedding down swift and sorting out the problems, then they’ll write an automated tool for converting code from one to the other, then they’ll start updating over the span of years a library here and there, which presumably won’t hurt the objective-c folks since it is all 2-way compatible. Then at some point, maybe 6 or 7 years down the track, objective-c will be deprecated. Although, the old Mac C API was certainly supported for a long time. Maybe it even still works(?), but it is painful to use. Look how Apple dumped all the objective-c garbage collection users (OK, there weren’t huge numbers of them, but the ones that were there, got hurt). Presumably if they release a code conversion tool, the pain will be reduced at least.
Anyway, my prediction, it will take a long time to find out.
]]>such a tool would not work particularly well given there is a wide range of coding styles out there and all sorts of unusual things you can do in C that could not be moved to Swift automatically. Secondly, there is no point. The objc code is perfectly good and will interoperate with swift just fine. People will rewrite ObjC code in swift themselves as it makes sense to do so.
]]>from what available facts do you derive that Apple’s intent with Swift is to rewrite vast portions of OSX four the sole purpose of getting rid of C? What you state is not a particularly practical reason to rewrite who knows how many lines of working and 100% debugged source code. If you want to say to me that something like CoreFoundation will be supplanted with a new framework that entirely replaces it with a system that works better and offers more features, then yea…it would make sense to write that in swift.
I’m perfectly well aware that nothing stops ObjC from being used in the kernel. But…why would you? I believe Swift already does the dynamic dispatching and certainly has native native data structures like maps and arrays and such. Why would Swift’s ObjC compatibility be useful in an environment with no legacy ObjC code to deal with? That makes no sense. As I said, I could imagine a new IOKit that uses Swift and replaces the current awkward EC++-based system. There is not just no point to ObjC interoperability in Apple’s current kernel.
]]>IOKit (Kernel Drivers) was written in obj-c before converting to c++ after Apple purchase of NeXT.
WebObjects was rewritten to Java from Obj-C ten years ago. Apple
uses it for all their Stores. All this is perfect candidate for Swift.
Apple has already said c++ support in Swift only will come if you wrap it in obj-c class.
There will be no exception in Swift because Cocoa doesn’t use it.
Cross Platform. Apple doesn’t care about cross platform.
c++ steering committee is talking about adding GUI (Cairo 2D) support as
standard. There is no way Apple will support a third part library
and hook that up to CoreGraphics.
Apple’s intension is to replace C in every area like security, network code where
safety/Security is necessary.
Apple will convert existing code because it helps in dog-fooding and test
for compatibility and long term support of existing software to make
sure there are no surprises later on like fragile base class problem.
Mind total transformation may take 10 years if not 5 years. It depends
on the speed of Swift in the respective domains of C/C++/Obj-C.
Oh and apple have a long way to go before they could change instruction sets without developers affected. They may get there one day, but right now they are nowhere near.
]]>All Swift really does is bring Cocoa programming into the 21st century. It has been woefully behind for years. Ofcourse, its going to be build with the current industry mindset at the heart of its design.
As for rewriting existing libraries? I don’t see any advantage in doing that as a religious movement. If they need to re-architect a library because its design no longer fits their plans, then yea…it would make sense to rewrite it in Swift. However, a wholesale effort to rewrite CF in Swift for the heck of it…replace existing debugged code with brand new code with new bugs wouldn’t be a good decision. However, I could imagine that over time, pieces of a particular library would be added in swift and some components rewritten if they are problematic. It would make sense to provide a new version of IOKit based on Swift since EC++ is a dead project and they use macro-hackery to get around the limitations of EC++. However, I don’t think the ObjC compatibility stuff would make it into the kernel.
I think the bottom line is that they need to finish the language and get it accepted by the cocoa developer community for UI development. Longer term, they need to have quality interoperability with both C and C++ so that we can use Swift where it makes sense and cleanly interface it with code written in other languages where Swift doesn’t make sense (such as cross-platlform code). Yes…that means PROPER exception handling that is interoperable with C++ exception handling. try/catch is not evil. Lazy programmers just don’t want to be bothered with the mundane details of error handling! 😛
]]>so basically not only programmer can prototype code in simd library for the CPU
and share it with GPU and if the CPU has free time the GPU code can
be run on the CPU at the same time.
With Apple starting to design their own GPU. they will strip out all the
OpenGL code from driver/chip and just have OpenCL as the compatibility
portion.
They are also using simd.h as basis for LinearAlgebra library.
]]>