Adlandırılmış tipler

TL;DR

• Bir adlandırılmış tip, component'lerin input_type ve output_type bildirimlerinden referansladığı, kayıtlı bir pipelang tipidir — Image, BoundingBox, AudioFrame, Tensor ve platformun type catalog'undaki diğer girdiler.
• Adlandırılmış tipler, platformun alan-biçimli veri için paylaşılan kelime dağarcığıdır. Aynı Image, her görüntü işleyen component için aynı tanıma çözümlenir; aynı BoundingBox, her dedektör için aynı tanıma çözümlenir. Adlandırılmış tip, dil ilkelleriyle her component'in contract'ı arasında yer alır.
• Tip sistemi, iki vertex birbirine bağlandığında bir adlandırılmış tipi çözümler: eşleşen bir ad ve eşleşen bir yapısal biçim kenarın yerleşmesini sağlar; başka her şey, operasyon kaydedilmeden önce, connect çağrısında reddedilir.
• Adlandırılmış tip catalog'u, workspace kullanıcıları için salt okunurdur. Ona ppl type list / get / print / tree ile göz at; adları component.yml'den referansla. catalog'un kendisi platform tarafından küratörlenir.
• Adlandırılmış tipler, tip dilinin geri kalanıyla birleşir. bounding box'ların bir listesi [BoundingBox]'tır; isteğe bağlı bir görüntü Maybe<Image>'dır; her ikisini de taşıyan bir record {img: Image, boxes: [BoundingBox]}'tır. Yapısal kurucular dilde yaşar; adlandırılmış tipler catalog'da yaşar; ikisi de herhangi bir bildirimde birlikte çalışır.

Adlandırılmış tipler neden ayrı bir kavram olarak var

Bir adlandırılmış tip, tekrar eden bir alan biçimine tek bir kanonik ad veren tek bir catalog girdisidir, böylece bu adı referans veren her component aynı tanıma çözümlenir. Dilin atom tipleri (Int64, Double, String, Bool) ve bileşik kurucuları (lists, tuples, records, unions) — ki bunlar herhangi bir biçimi zaten yapısal olarak ifade edebilir — ile birlikte var olur.

Yapısal ifade edilebilirlik ile paylaşılan kimlik farklı şeylerdir. Bir görüntü, yapısal olarak atom tiplerinden ve bir Bytes yükünden oluşan bir record'tur — piksel boyutları, piksel biçimi ve kodlanmış verisi. Her görüntü işleyen component bu record'un kendi kopyasını bildirseydi, yapısal olarak özdeş iki record, aynı tür değeri tanımladıklarına dair hiçbir sinyal taşımazdı ve tip sistemi ad eşleştirmeyi kullanılamaz olarak değerlendirip yalnızca yapısal karşılaştırmaya geri dönerdi. Bir adlandırılmış tip, yapısal karşılaştırmanın sağlayamayacağı paylaşılan kimliği sunar.

Image, platformun tipli bir görüntü değeri için kanonik adıdır: width ve height'ı, piksel format'ı ve kodlanmış data'sı, her görüntü işleyen component'in referansladığı tek bir adlandırılmış tip olarak paketlenmiştir. Bir vertex input_type: Image bildirdiğinde, tip sistemi onu o tanıma çözümler ve output_type: Image bildiren herhangi bir vertex ona bağlanabilir. Paylaşılan ad, iki ucun yapılarını yeniden belirtmeden birleşmesini sağlayan şeydir.

Aynısı AudioFrame (bir data tensor'ı artı bir sample_rate), Tensor<t> (bir shape artı eleman data'sı, eleman tipiyle parametrelendirilmiş), BoundingBox (algılanan bir class artı bir rectangle), Landmark (bir point artı bir confidence) ve catalog'un geri kalanı için de geçerlidir. Her biri component yazarları arasında bir contract'tır: belirli bir adı yayan bir component, o adın biçimini o adın anlamıyla üretir. catalog bu contract'ları tutar.

Zihinsel model

  component author                   backend author
  ┌──────────────────────────────┐   ┌────────────────────────┐
  │ component.yml:               │   │ ppl backend connect    │
  │   input_type:  Image         │◀─▶│   --from-vertex 1 …    │
  │   output_type: [BoundingBox] │   │   --to-vertex   2 …    │
  └──────────────────────────────┘   └────────────────────────┘
                 │                                │
                 │ resolves via                   │
                 ▼                                ▼
  ┌───────────────────────────────────────────────────────────┐
  │ named-types catalog (per remote)                          │
  │   Image       := { ... }                                  │
  │   BoundingBox  := { ... }                                 │
  │   AudioFrame   := { ... }                                 │
  └───────────────────────────────────────────────────────────┘

component yazarı manifest'e bir ad yazar; backend yazarı iki vertex'i birbirine bağlar; tip sistemi her iki ucu catalog'a karşı çözümler ve bağlantıyı doğrular. catalog, adlara component'ler arasında anlam veren şeydir — tip sistemini yapıları tek başına karşılaştırmaya bırakmak yerine her adı tek bir tanıma çözümler.

Adlandırılmış tiplerin atom ve bileşik tiplerle nasıl birleştiği için Tipler'e, ve adların component manifest'lerinde nerede göründüğü için Components'e bakın.

Adlandırılmış tipler tip dilinin geri kalanıyla nasıl birleşir

Bu çerçeveyi „bu adlandırılmış tipi bir list / tuple / record içine sarabilir miyim" diye merak ettiğinde her zaman kullan.

Evet. Adlandırılmış tipler, tip dilinde birinci sınıf değerlerdir; bir tipin görünebileceği her yerde bir adlandırılmış tip de görünebilir — [BoundingBox], tıpkı [Int64]'ün tam sayıların bir listesi olması gibi, algılamaların bir listesidir. Birleştirme kuralları, iç tip atom, bileşik veya adlandırılmış olsun aynıdır ve bir adlandırılmış tipi sarmak onun semantik garantilerinden hiçbirini kaybetmez. Tipler, üç kategorinin nasıl birleştiğini ve tip denetleyicisinin bir kenarı doğrularken birleştirilmiş yapıyı nasıl dolaştığını ele alır.

catalog nasıl küratörlenir

Bu çerçeveyi „kendi adlandırılmış tipimi ekleyebilir miyim" diye ilk kez merak ettiğinde kullan.

Adlandırılmış tip catalog'u, bir workspace kullanıcısının bakış açısından salt okunurdur. workspace kullanıcılarına sunulan fiiller list, get, print ve tree'dir — hepsi sorgudur. Kullanıcı yüzeyinde create yolu yoktur; catalog platform tarafından küratörlenir ve girdiler ayrı bir süreçle eklenir.

Bu kısıtlama, adlandırılmış tiplerin paylaşılan contract'lar olmasından kaynaklanır. catalog'a Image eklemek, gelecekteki her görüntü işleyen component'i o biçime bağlar; onu sonradan değiştirmek, önceki tanımı referans veren her component'i bozar. catalog'u kullanıcıların kendi girdilerini tanımlamasına izin vermek yerine merkezi olarak küratörlemek, her tanımı onu referans veren Component'ler arasında tutarlı tutan şeydir.

Henüz bir adlandırılmış tipi olmayan bir biçim için, biçim kararlı hale gelene dek bir bileşik tip kullan (bir record, bir tuple, atom tiplerinden bir list). Yapısal tipler manifest'te satır içidir, catalog girdileri gerektirmez ve tip sistemi onları adlandırılmış tiplerle aynı şekilde işler — component'ler arasında paylaşılan bir ad taşımazlar. Bir biçim bir adı hak edecek kadar yaygın şekilde tekrar ettiğinde, platformun bunun için sunduğu süreç aracılığıyla catalog'a eklenmesini öner.

catalog'a göz atma

Bunu, hangi adların var olduğunu veya bunlardan birinin yapısal olarak ne olduğunu bilmen gerektiğinde kullan.

Sorgu fiilleri „bana bu catalog hakkında bilgi ver"in dört biçimini kapsar:

ppl type list                          # everythingCopyppl type list --query Frame            # substring filterCopyppl type get AudioFrame                # canonical definitionCopyppl type get AudioFrame --recursive    # plus every transitive dependencyCopyppl type print AudioFrame              # pipelang source suitable for piping into a .type fileCopyppl type tree AudioFrame               # structural AST showing how the type is builtCopyppl type tree AudioFrame --depth 2     # cap the expansion depthCopy

Doğru fiil soruya bağlıdır. list keşif içindir; get kanonik tanım içindir; print tanımı bir dosyaya aktarmak içindir; tree yapısal kompozisyonu anlamak içindir (özellikle iki vertex bağlanamadığında ve kullanıcının biçimlerin tam olarak nerede ayrıştığını görmesi gerektiğinde yararlıdır).

catalog remote başınadır: remote'lar (production, staging, on-premise) arasında geçiş yapmak aynı adı farklı tanımlara çözümleyebilir. Bu kasıtlıdır; remote'ların bağımsız tip kayıtları vardır, çünkü platformun küratörlenen kümesi zaman içinde ve ortam başına evrilir.

connect çağrısı bir adlandırılmış tipi reddettiğinde

Bu çerçeveyi ppl backend connect bir kenarı „type mismatch" hatasıyla ilk kez reddettiğinde kullan.

Adlandırılmış tip connect başarısızlıklarının en yaygın biçimleri:

• Farklı adlar — bir vertex AudioFrame yayar, diğeri Tensor bekler. Adlar eşleşmez, bu yüzden kenar reddedilir. Çözüm genellikle aralarında bir dönüşümdür (veya, dönüşüm yoksa, bir dönüştürücü component).
• Bildirim sapması — her iki vertex de Image'ı referanslar, ama iki component release'i onu farklı yapısal sarmalayıcılar veya argümanlarla bildirir. Çözüm, genellikle component'lerden birini bildirimi eşleşen bir release'e yükselterek iki ucu hizalamaktır.
• Sarmalama uyuşmazlığı — bir taraf Image yayar, diğeri [Image] bekler. Aynı adlandırılmış tip, farklı yapısal sarmalayıcı. Çözüm, kardinaliteyi köprüleyen bir dönüşüm component'idir.
• Yerel gölge — çalışma dizininin component yapılandırmasındaki bir .type dosyası, remote tanımı farklı bir biçimle gölgeliyor. Çözüm, temiz bir dizinden çözümlemek veya yerel .type'ı catalog'a uyacak şekilde güncellemektir.

Her iki uçta ppl type tree <name>, yapıların neden uyuşmadığını anlamak için doğru tanı aracıdır. Tipi yapraklarına kadar genişletir, böylece ayrışma noktası görünür olur.

Bunun yeri

Adlandırılmış tipler, platformun alan-biçimli veri için paylaşılan kelime dağarcığıdır. Dil ilkelleriyle (yapısal olarak paylaşılan ama alan anlamı taşımayan) component'lerin tipli contract'ları (anlam taşıyan ama birleşmek için paylaşılan adlara ihtiyaç duyan) arasında yer alırlar. catalog tanımları tutar; merkezi küratörlük onları tutarlı tutar; catalog'u kullanıcılar için salt okunur tutmak, bir kerelik tanımların çoğalmasını önler. Adlar gerçek tipler olduğundan, tip denetleyicisi onları katı şekilde uygular — Image, graf'taki her tel boyunca, yapısal bir benzerine değil, asla yalnızca bir görsel benzerine değil, Image'a bağlanır.

Sonuç olarak, bir component'in görüntüsünün başka birininkiyle aynı tür değer olup olmadığı, kullanıcının doğrulamasına bırakılmak yerine, tip denetleyicisi tarafından paylaşılan addan çözümlenir.

İlgili

• Tipler — atom, bileşik ve adlandırılmış tipler birlikte.
• Components — input_type / output_type'ın adlandırılmış tipleri nerede referansladığı.
• Backend operasyonları — connect, iki vertex arasında adlandırılmış tipleri çözümleyen fiildir.
• Tip sözdizimi referansı — adlandırılmış tiplerin birleştiği tam pipelang grameri.
• Solutions — paylaşılan kelime dağarcığının ürünler-arası kompozisyonu nasıl desteklediği.