Gotcha. Thanks. It seems like swift is close enough to Basic that if you can learn Basic you can learn Swift, no? Seems like a lot of effort to do the transpiler, but maybe you have a good reason to not want to work in Swift?
I have a very good reason I want to work in Swiftā¦ because I have basically (pun) given up on Xojoā¦ And if this project succeedsā¦ Then I can freely write anything I want for macOS and/or iOS and not have to deal with any of the types of issues that Xojo has suffered from lately. If it doesnāt work, its MY fault, and I can fix itā¦
Not to mention, even being 64, I still love to learn new thingsā¦ and this has been a learning experience to be sure.
Todays project is to replicate all the filedialogs (Open, Save etc) in Swift with syntax as close to Xojo as possibleā¦ If you havenāt already, take a look at the 13 tutorials I have already posted here regarding Swift. These dialogs will possibly be the next one
Sorry, my question was why do you NOT want to work in Swift? That is to say, why go through the trouble of creating a transpiler when you can just code in Swift?
Three reasons
- Because I am comfortable with Xojo, it gives me a way to learn more about Swift , by replicated functionality of one language in another
- Others may benefit by being able to create macOS/iOS/ATV applications by leveraging what they already know thus shortening the learning curve involved
- because I can
2 Likes
Itās a āmountainā thing.
Why do you climb mountains? Because they are there.
2 Likes
Decided to work on this some moreā¦ I used it to help translate my Xojo version of Markdown to Swift, and it did 90% of the work, but with like 500 errors. Iāve updated the translator and currently it translates the same Xojo code with only 180 errors, and most of those are due to my use of PAIRS, and a few places with Swift is more strict in datatypes. Also places where a corresponding Swift function has a slightly different name than the Xojo counterpartā¦
1 Like
Beer !
1 Like
Updateā¦ Morpho was able to take 2088 lines of code cut directly from an Xojo project (my Markdown) and translated it directly to 2204 corresponding lines of Swift code with only 24 anomolies.
Most of which related to the use of the āpairā datatype (which is not a native Swift construct), the use of the Xojo Dictionary (Swift dictionary syntax isnāt directly convertable)
There are 5 errors where the Xojo INSERT statement has reversed arguments from Swift, and 2 related to datatype casting. The translator can (and will) be modified to handle those.
Leaving at best 14 lines of code out of 2204 that would have to be manually adjustedā¦ meaning in this particular case it was over 99% accurate in the translation.
One caveat is ultimately the translated code may need to rely on specific function libraries I have previously created. The translator inserts stub functions to aid in the compilation.
However, all of those libraries were published on this website under my 12 part Swift tutorial a few months back
If anyone wants to take this for a spin let me know. It does require that XCode is installed, runs only on a Mac, and for the most part is assuming Xojo API1 (or generic BASIC code)
I would like to see how it handles other developers āBASICā code, so I can add the approparite features/functions to become a more complete solution
Dave, Iād love to give it a whirl.
I tried your earlier Morpho and and it gives me insights into the differences in Swift (still on the steep but rapid learning curve) and ended up re-writing the few methods I experimented with.
Dates are an issue but looks like thereās a great library for that.
Not sure, but I think itās best to rewrite as I go anyway from a leraning and experience POV. I remember creating a VFP library in RB when I started with that to provide some comfort in the big move, and things like trim(string) and string.trim() (I can never decide which is best) seem more user=friendly than string.trimmingCharacters(in: .whitespacesAndNewlines)
Anyway, thanks for sharing and if I can help then I will.
If I remember I published a Swift Date library that uses Xojo syntax including SQLDATE/TIME etc.
The String library I posted, has TRIM(s) and s.TRIM() both as well as every other String function I could think of
Iām experimenting with creating an analog for the PAIR datatype (it will use <-> instead of : , as : is reserved in Swift)ā¦ that and the INSERT anomoly I mentioned aboveā¦ once I fix those Iāll post an updated version on my server,
cool, I use pairs a lot for parameter passing. getting tuples from functions will be a time-saver and reduce reliance on other variables being in scope (or global) or creating classes for simple stuff. So far, Swift looks great but still have to verify database performance, especially if I decide to use an ORM layer (with Vapor for server-side stuff). Seems promising but still much to discover. Re dates, I use Julian a lot for simple date compare - donāt have to I guess but itās been invaluable and simple. My primary apps are all payroll related, so loads of dates, fiscal start, end for different countries, days between, timestamps, timezones (UTC to local) etc. - all great fun.
I havenāt seen your Swift articles - noob on this forumā¦
Updateā¦ Morpho was able to take 2088 lines of code cut directly from an Xojo project (my Markdown) and translated it directly to 2204 corresponding lines of Swift code with only 12 anomalies across only 10 lines of the codeā¦ giving it a 99.5% accuracy rate (WAY more than I hoped for)
All of which related to the use of the āpairā datatype (which is not a native Swift construct) and the use of the Xojo Dictionary (Swift dictionary syntax isnāt directly convertible)
It was able to detect all the warnings (type casting etc), and āfixā the Swift code properly.
After I clean up a few things, I will post an updated version for anyone to attempt to ābreakā
Okā¦ here is the latest version of 
Morpho - BASIC to Swiftā¢ translator
www.rdsisemore.com/Morpho.app.zip
It is a macOS application, it has been signed, but not nortorized
Just type (or copy/paste) your BASIC code into the left pane, and hit translate.
If there are any errors, the will show in the right pane (it might take a few minutes depending on how complex your code is). It DOES use your desktopā¦ and will leave a file called TRANSLATED.SWIFT which will contain the best effort at translation. This can then be used in an Xcode project.
NOTE : as mentioned above, it might require you also include one or more of the libraries published in my tutorial to get a fully operational project.
I realize that it does not yet translate 100%, but I will be enhancing it as I run into real world situations, and would appreciate any feedback (with examples) so that the translation can be as complete as possible.
This application is FREE to use, as is of course the translated results.
The translation engine source code (100% Swift) is not currently available for release.
1 Like
FYIā¦ I threw some more āreal worldā code at Morpho this morning, and it needs some more workā¦
Not sure how I am going to handle a situation like this
FUNCTION xyz(key as String,assigns x as integer)
XYZ("Fred")=3
somehow has to become
func xyz(key as String, x as integer)
xyz("Fred",3)
as Swift has no analog for āassignā ā¦ Another current issue is 2D arraysā¦ Swift has Array of Array, but the resulting syntax is much differentā¦
was just studying that - x would be an inout parameter, called using &x
func xyz(_ key: String, _ x: inout Int)
and call using
var x: Int = 123
xyz("keyvalue", &x)
hope thatās rightā¦havenāt got to arrays yet
Noā¦ X doesnāt need to be an inoutā¦ as it is āassignedā, it is read only. inout is the equivalent of BYREF
rats, misinterpreted assigns and assumed byrefā¦steep hill this swift
No worriesā¦ there are a few things that I wished Swift hadā¦ and ASSIGNS is one of them
my translator handles most (but not all) scenarios when using BYREF, the ones it doesnāt handle completely will be easily identified by Xcode
and then you get someone that wants to do
foo( byref assigns s as string )
or something truly screwy (but legal)