[swift-dev] Implementing New Syntax in Swift

[Seth Friedman]

Changing the subject of this thread since it's now an entirely different
question than what I originally asked. Hopefully this will result in better
visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri at gmail.com> wrote:

> Thanks Jordan!
>
> Here's a specific flow I'm interested in understanding. Note that this is
> just a wild example that would help me better understand parts of the
> compiler I'm interested in rather than any sort of proposal for the
> language.
>
> Let's say I have a type called SuperInt that has some cool integer
> operations that would be applicable and useful to everyone writing Swift.
> It's a given that this makes sense to be in the Swift language, and people
> are going to be using it so often that it makes sense to create a new
> literal syntax for this type. I'd like users to be able to instantiate a
> SuperInt with the following:
>
> let superIntExample = %^100^%
>
> Crazy syntax for a crazy example, but I wanted to make sure it's not
> something that's already in Swift. In this example, my SuperInt would be
> instantiated with a value of 100.
>
> I'd like to know the parts of the Swift compiler I would need to
> understand and change to implement this new type with its new syntax.
>
> I really this question requires a lengthy answer, but I think it would
> make a great start to a Swift internals manual (which I agree with you
> would be a fantastic idea).
>
> Anyone's help would be much appreciated!
>
> Thanks,
> Seth
> On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose at apple.com> wrote:
>
>> Hi, Seth. Sorry for not getting back to you sooner! I don't think we have
>> anything exactly like this, but there's *sort* of a sequence diagram in
>> Chris and Joe's talk at the LLVM conference, "Swift's High-Level IR
>> <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks something like this:
>>
>> 1. Parsing
>> 2. Semantic analysis, including type-checking
>> 3. SIL generation
>> 4. Mandatory SIL passes
>> 5. SIL optimization
>> 6. LLVM IR generation
>> 7. LLVM optimization
>> 8. LLVM output (usually including machine code generation and writing to
>> a .o file)
>>
>> …with the last two handled pretty much completely by LLVM
>> <http://llvm.org> itself, and not customized by Swift.
>>
>> We probably ought to have something like Clang's "Internals
>> <http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
>> better), which lays out the major concepts in each library. As it is we
>> have various concepts that are documented very well, either in docs/ or in
>> header comments, and others which are just arcane knowledge in the heads of
>> the implementers. This is not a good thing.
>>
>> The "Contributing <https://swift.org/contributing/>" page on the website
>> lists a handful of ways to get involved; another one we're still bringing
>> up is issues with the "StarterBug" label in JIRA. These are intended to be
>> bugs that a newcomer could use as a goal-oriented way to learn about one
>> part of the project.
>>
>> Of course, we're happy to answer any specific questions you might have
>> (and this list is probably the right place for them). It's the general ones
>> that are hard. :-)
>>
>> Jordan
>>
>> On Dec 16, 2015, at 2:36, Seth Friedman <sethfri at gmail.com> wrote:
>>
>> Thanks Jordan!
>>
>> Another question if anyone has some time: I'm really interested in
>> contributing to the project, but given that I don't have a ton of
>> experience with compilers, I'm having a really hard time following the flow
>> of the program. I understand that the high level flow is lexing, parsing,
>> sema, and building the AST. However, tracing through the actual functions
>> in the compiler prove much more difficult due to the amount of
>> indirection/metaprogramming.
>>
>> Are there any sort of sequence diagrams that I haven't found yet? If
>> anyone could let me know of any good resources you know of, that would be
>> great. I'm sure this would also be of use to people in my boat that want to
>> help but don't know how to start.
>>
>> Thanks,
>> Seth
>>
>> On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose at apple.com> wrote:
>>
>>> Hi, Seth. I think you're getting Clang / swift-clang mixed up with
>>> swiftc / swift. Clang is not the Swift compiler; the Swift compiler lives
>>> in the "swift" repo. Swift depends on Clang for its interoperation with C
>>> and Objective-C.
>>>
>>> A *lot* of the compiler encodes information about Optional, but most of
>>> it stems from ASTContext.h and ASTContext.cpp, which has dedicated
>>> entrypoints for getting Optional, Optional.None, and Optional.Some.
>>>
>>> Hope this helps,
>>> Jordan
>>>
>>> On Dec 8, 2015, at 17:59 , Seth Friedman via swift-dev <
>>> swift-dev at swift.org> wrote:
>>>
>>> Hi all,
>>>
>>> In Optional.swift in the stdlib, there's a comment that says "The
>>> compiler has special knowledge of Optional<Wrapped>, including the fact
>>> that it is an enum with cases named 'None' and 'Some'."
>>>
>>> What I'm trying to understand is: If I wanted to implement the optional
>>> type from scratch, what would be the process I would go through? I've
>>> scoured the swift-clang project and can't seem to find any reference to
>>> optionals or even Swift explicitly. I discovered nullability attributes and
>>> am hypothesizing that an expression of something like "Type?" is somehow
>>> mapped to an attribute, but I'm really just stumbling around in the dark.
>>>
>>> In terms of what I've tried, I've gone through a lot of the source in
>>> the swift-clang lib/Basic and lib/AST directories, and I've read through
>>> the "Clang CFE Internals Manual" on the Clang website.
>>>
>>> Help is much appreciated!
>>>
>>> Thanks in advance,
>>> Seth
>>>
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160111/984eb617/attachment.html>