Hi Chris
I am a bit slow to respond, please read inline, thanks.
> On 1 Oct 2016, at 01:47, Chris Lattner <clatt...@apple.com> wrote:
>
> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution
> <swift-evolution@swift.org> wrote:
>> Is it possible to have best of (these completely different) both worlds?
>
> Yes, of course it is.
> Your email spends a lot of words
Does it?
> trying to form a false dichotomy.
Well, sorry, thank you. but No, I don’t think so:
I am merely describing the advantages and
disadvantages of static programming languages.
It doesn’t mean it should be one or the other, just observing.
Just thinking about the future in years, not in weeks.
Even so, I still like Swift.
> Swift can definitely have both awesome dynamic features while still having
> performance, predictability and safety.
Yes, I take it that it is possible to implement these.
Currently it is not possible to do meta programming in Swift, that is, create
arbitrary functions, properties and new classes
during run time. hypothetical along the lines as if it were so:
// Warning! hypothetical as yet not compilable coding follows:
let Monolith: Class?
var classdefstring = "parentclass: SpaceObject;" +
"var l = 9.0; var h = 4.0; var w = 1.0; " +
"var color = " + defaultMonolithColorStr +
";func volume() -> Double { return l * w * h} “ +
aStringWithAdditionalComponentDefinitions
func defMonolithClass()
{
do // try to define a class, NOT an instance.
{
try Monolith = Meta.defineClass(classdefstring)
}
catch Meta.classDefinitionError
{
// handle a possible class definition error
// e.g. syntax errors. symbols not found etc.
}
catch Meta.creationConflict
{
// class cannot be defined or redefined when instances of Monolith
exist.
// necessary?
}
do // dynamically add components to the Monolith
{
try Meta.addPropertyTo( Monolith,"mass", 3.4)
try Meta.addPropertyTo( Monolith,"physics", PhysicsBody)
try Meta.addFunctionTo( Monolith, someFunctionDefinitionString)
}
catch Meta.ClassExtenderError
{
// handle the error
}
catch Meta.creationConflict
{
// class definition cannot be altered when instances of Monolith
exist.
// necessary?
}
}
defMonolithClass()
// Make an instance of the dynamically generated class
public let mn = Monolith()
let vol = mn.volume
// One can remove after usage, normally ARC should take care of that.
// unless one would wish to reinstate/redefine Monolith again.
mn = nil // remove instance
Monolith = nil // should throw an error when instances of Monolith are
still around.
defMonolithClass() // again, possibly with other definition strings
// Of course ARC should remove dynamic class defs automagically when no
longer
// needed.
There could be overloads of defining classes etc. using other methods than
string wise declaration..
Of course, Meta… for defining structs and other components could be made in a
similar fashion.
I’d guess that it might be very hard and complicated to implement meta
creation similar to the above?
Probably needed the app to interact many times with a compiler present on the
target OS/device? -
thereby making small pluggable “bricks”
Just brainstorming here: I know nearly nothing of compiler construction.
>
>> Would it be possible in Swift to have facilities to generate objects
>> dynamically at runtime? and, if desirable, how can such be implemented?
>
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection <https://github.com/Zewo/Reflection>
Very complex code (to me, hard to read) . As far as I can see, it’s a clever
hack but vulnerable because
depending completely on the underlying memory occupation and layout of an
existing class definition?
Totally new classes/structs etc. cannot be defined with it?
(like in the above hypothetical class def example)
>
> I’m sure it isn’t ideal, but it proves that it can be done. When we have
> bandwidth to reevaluate this area from first principles, I’m sure we can make
> improvements on it.
Yeah, I guess it can be done, that would be great!
>
> I will grant you that Smalltalk is a beautiful language in its simplicity,
> but for that simplicity it makes many tradeoffs that we’re not willing to
> make.
The only tradeoffs I can think of so far are:
- Run time speed. in spite of precompiled methods etc Smalltalk is not so
fast as compiled statical
programming language executables. However, the VMs are getting much better/
faster
these days. Dedicated hardware (processors) would really help too.
- Total freedom, but to me personally this is not a tradeoff at all…
- what else?
> We are willing to make the internal implementation of Swift complex if that
> means that we get a beautiful model for programmers -
> one that preserves the virtues of safety-by-default,
Safety by default? to some extend, yes. However, my experience with many
programming
languages is, that it almost doesn’t matter how much effort is given
to make a PL save. I am still traumatised by many [some words removed here]
source code through all the years I had to work with
(of course only others are writing baaaaaaad code, naturally, I myself am
perfect :o)
> predictability, performance, and joy-to-develop-in.
Yes, I enjoy working with Swift very much as well, thank you (and others) for
creating this language.
>
> The meme of “Swift can never (or will never) support dynamic features” is
> tired, and also wildly inaccurate.
That was a bit overcharged from me. I had that impression, being not too
broadly informed in this meta stuff.
Met vriendelijke groeten, kind regards, one of your colleagues/friends from
another time :o)
TedvG
>
> -Chris
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
