HiLang 2.4.6
dotnet add package HiLang --version 2.4.6
NuGet\Install-Package HiLang -Version 2.4.6
<PackageReference Include="HiLang" Version="2.4.6" />
<PackageVersion Include="HiLang" Version="2.4.6" />
<PackageReference Include="HiLang" />
paket add HiLang --version 2.4.6
#r "nuget: HiLang, 2.4.6"
#:package HiLang@2.4.6
#addin nuget:?package=HiLang&version=2.4.6
#tool nuget:?package=HiLang&version=2.4.6
HiLang
HiLang is a minimal high-level language to describe the schema of a domain, taking inspiration from protobuf (.proto models) for hierarchical structures and SQL DML for entities, relations and views.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. net5.0-windows was computed. net6.0 was computed. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 was computed. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
.NET Core | netcoreapp2.0 was computed. netcoreapp2.1 was computed. netcoreapp2.2 was computed. netcoreapp3.0 was computed. netcoreapp3.1 was computed. |
.NET Standard | netstandard2.0 is compatible. netstandard2.1 was computed. |
.NET Framework | net461 was computed. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
MonoAndroid | monoandroid was computed. |
MonoMac | monomac was computed. |
MonoTouch | monotouch was computed. |
Tizen | tizen40 was computed. tizen60 was computed. |
Xamarin.iOS | xamarinios was computed. |
Xamarin.Mac | xamarinmac was computed. |
Xamarin.TVOS | xamarintvos was computed. |
Xamarin.WatchOS | xamarinwatchos was computed. |
-
.NETStandard 2.0
- FSharp.Core (>= 9.0.303)
- FsLexYacc (>= 11.3.0)
- FsLexYacc.Runtime (>= 11.3.0)
- Microsoft.CodeAnalysis.CSharp (>= 4.14.0)
- Nerdbank.GitVersioning (>= 3.7.115)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on HiLang:
Package | Downloads |
---|---|
Hiperspace.SQL
# Hiperspace.SQL Hiperspace.SQL is a full SQL query engine for Hiperspace, supporting the full range of joins, aggregations, and subqueries. Hiperspace.SQL provides the same query functionality as a .NET client can use with LINQ queries, but without the need to write code in C#/F# Hiperspace fully supports point-in-time "time travel" queries that are not possible with Python Data-Frames or DuckDB ## Features - Hiperspace.SQL is not limited to queries of columns within a table, but supports the full navigation of properties of Hiperspace elements - Where a column is a complex object it is returned as a JSON object - Executing a batch of SQL statements return columnar data frames (dictionary of column-name and array of values) - Explain SQL returns the execution plan, detailing the SetSPaces accessed and keys used for search (Key, Index, Scan) - The Parquet method returns a Parquet file that can be used with any Apache Parquet library, or added to DuckDB OLAP store |
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last Updated |
---|---|---|
2.4.6 | 0 | 9/23/2025 |
2.4.4 | 230 | 8/7/2025 |
2.4.2 | 109 | 7/28/2025 |
2.4.0 | 150 | 7/10/2025 |
2.3.8 | 140 | 7/1/2025 |
2.3.7 | 159 | 6/18/2025 |
2.3.4 | 151 | 6/5/2025 |
2.2.2 | 166 | 5/5/2025 |
2.2.1 | 207 | 4/14/2025 |
2.2.0 | 114 | 3/29/2025 |
2.1.9 | 216 | 3/5/2025 |
2.1.6 | 126 | 2/15/2025 |
2.1.0 | 127 | 1/24/2025 |
2.0.0 | 96 | 1/14/2025 |
1.3.9 | 146 | 11/15/2024 |
1.3.0 | 130 | 10/5/2024 |
1.2.18 | 171 | 9/15/2024 |
1.2.16 | 155 | 9/7/2024 |
1.2.15 | 141 | 9/1/2024 |
1.2.11 | 119 | 8/6/2024 |
1.2.9 | 121 | 7/26/2024 |
1.2.8 | 153 | 7/19/2024 |
1.2.6 | 132 | 7/15/2024 |
1.2.4 | 150 | 7/4/2024 |
1.2.0 | 158 | 5/30/2024 |
1.1.37 | 145 | 5/11/2024 |
1.1.34 | 138 | 4/22/2024 |
1.1.30 | 149 | 3/24/2024 |
1.1.26 | 153 | 3/14/2024 |
1.1.23 | 164 | 2/26/2024 |
1.1.22 | 158 | 2/16/2024 |
1.1.21 | 211 | 1/11/2024 |
1.1.19 | 185 | 1/1/2024 |
1.1.17 | 161 | 12/23/2023 |
1.1.11 | 166 | 12/16/2023 |
1.1.10 | 172 | 12/6/2023 |
1.1.7 | 168 | 11/30/2023 |
1.1.5 | 162 | 11/21/2023 |
1.0.14-prerelease | 213 | 8/6/2023 |
https://www.cepheis.com/hiperspace/20250923
## Overview
This release introduces three new features for references to views, the `Any` polymorphic union type and `Get<TEntity>(string sid)` function. Together they provide the `Hiperspace.DB` functionality to combine any number of Hiperspaces in a single Graph view without duplication or copying.
-----
### View References
Views in Hiperspace are generated to combine all *entities, segments, aspects and views* that can be projected as the view, but also provide an additional role for sub-types and complex associations.
All references in `Hiperspace` can be navigated to either *elements* key or an index that matches the predicate used to reference it. The [last release](https://www.cepheis.com/hiperspace/20250807) completed the optimization of view access to parts, this release adds indexing to efficiently access view items with criteria other than the key.
#### Indexed views
Consider the example of a Trading problem where **Trades** are booked in a **Book**, but each trade type {Fixed Income, Forex, Equity} can have specific properties for the product traded. When the view is referenced by a member other than the key (*Book in this example*), an index is created to efficiently access the set of matching values.
```
view Banking.Trade (Id : String) {Book : Banking.Book};
entity Banking.FI.Trade : Banking.Trade = Banking.Trade();
entity Banking.FX.Trade : Banking.Trade = Banking.Trade();
entity Banking.EQ.Trade : Banking.Trade = Banking.Trade();
entity Banking.Book (Id : String) [Trades : Banking.Trade (Book = this)];
```
`Trades : Trade (Book = this)`selects the set of Trade that have a reference to `this` Book. This access causes an index to be created in the view `Trade` that is inherited by each implementation.
#### Sub type
[image]Sites/hiperspace/diagrams/trade.svg[/image]
This [UML](https://en.wikipedia.org/wiki/Unified_Modeling_Language) diagram represents the logical view of the `.hilang` schema above. When a relational database is used, one of three strategies are normally followed:
* **Direct**: Each entity {Trade, FI_Trade, FX_Trade, EQ_Trade} is mapped separately, and joined as needed
* **Down** denormalization: Properties of the parent are duplicated in each of the sub-types and with context specific joining
* **Up** denormalization: Properties of each sub-type are added to the base type (optionally with *aliases* for duplicate names)
Hiperspace does not need denormalization the elements because types can inherit from a base type. The code `entity FX_Trade : Trade = Trade;` states that the *entity* **FX_Trade** *inherits*(:) from **Trade** *and can be viewed*(=) as a **Trade**
In the example above, each sub-type will be queried in parallel using the index on the **Book** reference
##### Modelled as Aspect
The schema could also have been modelled using *aspect* rather than *realization*, depending on business requirement, e.g.
* *Convertible* where final exchange is either equity or cash
* *Hybrid* where cashflow is calculated from either from a yield-curve or equity price
* *Participation* where the equity price uses FX exchange rates
[image]Sites/hiperspace/diagrams/trade2.svg[/image]
```
entity Banking.Trade (Id : String) {Book : Banking.Book}
[FI : Banking.FI.Trade, FX : Banking.FX.Trade, EQ : Banking.EQ.Trade];
aspect Banking.FI.Trade;
aspect Banking.FX.Trade;
aspect Banking.EQ.Trade;
entity Banking.Book (Id : String) [Trades : Banking.Trade (Book = this)];
```
**Aspects** *appear* to be properties of the *owning* entity, so the choice has minimal impact on usage ( `Banking.FI.Trade { YieldCurve = ... }` vs `Banking.Trade { FI = new Banking.FI.Trade { YieldCurve = ...}}`)
#### Segment / Aspect reference
Segments and Aspects are *owned* by the `entity, segment, aspect` that references them as an extension. They appear (*to users *) as a set property for segments, and value property for aspects, with the `owner` added *transparently* when a value is assigned.
[image]Sites/hiperspace/diagrams/segment.svg[/image]
```
entity Customer [Accounts : Has];
segment Has (Account : Account);
entity Account [HasCustomer : Has (Account = this)];
```
`HiLang` translates the segment `Has` into an element `CustomerHas` (adding the key `owner : Customer`), and the segment `Has` is transformed into a *view* that `CustomerHas` provides. If there are no other implementations of `Has` (*e.g. for a sub-account of Account*) the view is *pruned* and not generated.
In this example `Has` is referenced by `Account` to provide a link from `Account` to `Customer` using the `HasCustomerIndex`. As a `segment`/`aspect` can be applied to any stored element, `Has` view includes the key `owner : Any` which in this case can be *cast* to `Customer`.
-----
### Any
The new type `Any` has been introduced to support `segment`/`aspect` views, and can be converted to any of the domain types like a `union` in F#. Unlike `object`, `Any` can be serialized and used anywhere in the schema, when a generic reference is required. `Any` is code generated by `HiLang` to include a constructor for the each of the domain types, together will *cast* operators to convert to each of the domain types. Elements also include a *cast* operator to convert to an `Any` when assigned.
`Any` uses constructors and conversion operators to behave like a base type for any domain element `Any value = customer` *will use Customer’s operator Any function*, `Customer? value = any` *will use Any’s operator Customer function* to return the value or `null`. Explicit cast functions are crerted for each *element* that could be stored.. for the *Customer* type it includes
* **Customer()** : cast the Any to a customer or null
* **CustomerAsync()** : async function to return the value (*especially usefull for WebAssembly where network read may be required*)
`Any` includes the functions
* `Type AnyType()`to inspect the content of the `Any` class for match/switch statement
* `bool Is<T>()` : returns true if the content of the `Any` is of type `T`
* `T? As<T>()` : returns the value of the `Any` cast to the type `T`
* `Task<T?> AsAsync<T>()` : returns the value of the `Any` cast to the type `T` using an async network call if necassary
-----
### Get(string sid)
`SubSpace` provides an `object? Get (string sid)` function that can be used to get an element in Hiperspace without knowing the type, just using the stringified key of the element. This function is now obsolete and has been replaced by `TEntity Get<TEntity>(string sid)` that allows the desired type to be retrieved.
This method was added for `Hiperspace.DB` that includes `GraphSpace` to aggregate `Node`/`Edge`/`HiperEdge` across domains. For `GraphSpace` it is necessary to call `Get()` with the `SKey` of a `Node` and then cast to `Node` which was not possible with `object` because *elements* do not need be viewable as a `Node`. `GraphSpace` uses `Get<Node>(skey)` for the lookup.