Great if that works for you! In any case, the constraint on types comes from
the fact that the only way to construct an HCons is with the cons function
(because the h and t fields are private) and the only two exported overloads
only allow valid constructions
Ok, we can extract with overloading - put we still can't put a constraint on
types.
> Uh? I just proposed a solution that implements HLists. Is there anything
> missing?
You really did implement it, we just can't access the generics(like in my
original 2. implementation). Back to square one.
> In any case, I think that in Nim a more idiomatic solutions would to use
> tuples i
Uh? I just proposed a solution that implements HLists. Is there anything
missing?
In any case, I think that in Nim a more idiomatic solutions would to use tuples
instead, which are of course isomoprhic. One cannot used recursion with tuples,
but that can be easily circumvented with macros.
Yes, and those lists would be typesafe too. We could implement HLists
flawlessly in Nim if it'd have either of these feature groups:
* pattern matching + nominal virtual abstractions("interfaces", but we only
have structural ones by concepts)
* pattern matching + existential types
* existe
Yes, since the list is heterogeneous, the type changes according to the various
parameters. It is very similar to a tuple - as explained in the blog post I
linked - but it behaves like a list in certain respects and this helps in
writing generic procedures that would otherwise require a macro
Hmm, means that it will construct a new type (maybe anonymous tuple?) for each
of initiations?
I can't see much of advantage of it though, hmm, anyone care to elaborate?
(Should I create a new thread instead?)
@alehander42 What @trtt is trying to implement is called an HList, and is a
common construction in, say, Haskell or Scala.
This is an [example of implementation in
Scala]([https://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-scala-part-6a-heterogeneous-list%C2%A0basics/)](https:/
@trtt Here it is
# hlist.nim
type
HNil* = object
HCons*[H, T] = ref object
h: H
t: T
HList = HNil or HCons
let hNil* = HNil()
proc cons*[H; T: HList](hd: H; tl:T): auto =
HCons[H, T](h: hd, t: tl)
template `<>
@trtt please, write your example in another language where the type system
accepts it: this way we can more easily show the same
See:
type
HNil = object
HCons[H, T] = ref object
head: H
tail: T
let hNil = HNil()
proc cons[H; T](hd: H; tl: HCons): auto =
HCons[H, T](head: hd, tail: tl)
proc cons[H](hd: H; tl: HNil): auto =
HCons[H, void](head: hd
I am on my phone now, I will try to give an example tomorrow
No, you don't need parameters there, you can leave them unspecified. HCons is
just the existential type HCons[H, T] for some H and T
It's not going to except that. This is what I'm thinking about:
type
HListKind* = enum hkNil, hkCons
HList[H, T] = ref object of RootObj
case kind*: HListKind
of hkCons:
head: H
tail: T
of hkNil:
discard
let hN
If I'd want to limit the 2nd parameter of cons to HConses I'd need to tell it
what kind of HCons it should expect and that comes with a 3rd type parameter -
this would clash with HNil. Maybe if we'd add variants to denote HNil...
If you want to prevent T to be anything other than HNil or HCons, just make the
constructor private and expose two overloads of cons
@alehander42: implicit conversions can't detect heterogeneous types.
@mratsim: I can have strongly typed heterogeneous lists, but maybe not in nim.
I already presented my issue and how much heterogeneity I need. I also told you
that T needs to be a concept.
@andrea: yes, it's a limitation of ni
> Nope, T is a fixed generic type. It doesn't mean anything and it's definitely
> not heterogeneous. It's not going to work like that, I tried it.
Let me emphasize what @mratsim mentioned, **" change T to be a variant or use
polymorphism."**
And no, you hadn't tried it. Nothing in your example
@trtt, change T to be a variant or use polymorphism.
You can't have strong compile-time type safety with heterogeneous list, that
just doesn't work. i.e. if you want to get a list [(int8, Packed), (int64,
Packed), (string, Packed)], you can't.
So as I asked earlier, can you be more clear at whi
@trtt did you read the converters part of the manual? You can have a sum
type(variant) and to write in your array stuff like 2 "4" [2] and it would be
automatically converted to the same sum type (but different kind). I think this
is a more Nim solution: I wouldn't want to construct a special li
@trtt Ok, I have a version that works
type
HNil = object
HCons*[H, T] = ref object
head*: H
tail*: T
let hNil = HNil()
proc cons*[H; T](hd: H; tl:T): auto =
HCons[H, T](head: hd, tail: tl)
let l = cons("hi", cons(2, hNil))
Nope, T is a fixed generic type. It doesn't mean anything and it's definitely
not heterogeneous. It's not going to work like that, I tried it.
It also doesn't need to be a structure.
"# add any possible heterogeneous values you defined" \- we're already over
variants - we're trying to make the
@trtt I agree that the code I posted is not working. But I am convinced that it
**should** work, and the fact that is not working is a bug of Nim. It is true
that a generic T does not have fields like head and tail. On the other hand,
all concrete types T which are ever used in specializing that
Incorrect, @mratsim definitely put generic in there, meant, the type T that you
should make it variant or heterogeneous.
Also considering with your example about @[messageType, messageId, rpc_method,
arguments]
It should have a structure like this
type
MyHeterogeneousVals =
You gave the HgCells in HgPacks a fix data type - because of this, it's not
heterogeneous anymore. You shouldn't remove the concept because it should be a
constraint on the types at the procedures.
I think you need to define at which level your list is heterogeneous.
If you have a seq[T] with T being a runtime type, you have to use type erasure,
either through object variants or through inheritance.
Here is your example fixed. Now you can just transform the Packet type into an
object vari
@mashingan no, 'msgpack-nim' is a dead project, the author is waiting for nim
1.0. 'msgp4nim' is probably just an experiment - it can't do what I want and
it's also failing for basic cases(I started to use this first but I experienced
a lot of issues). The two other projects are based on msgpack
@trtt, I've covered heterogeneous containers and how to do type erasure in
reply to @kcvinu threads here:
* [Is there any untyped list datatype in
Nim](https://forum.nim-lang.org/t/4233#26367)
* [Need help for a generic object
field](https://forum.nim-lang.org/t/4406#27516)
@trtt You can add such a constraint with `T: HList` if you want. It seems not
to work very well now, maybe I will try to figure out why.
But there is another point which is important. You **do not** lose the generic
type information if you don't specify T. This is because the type checking and
The available packages don't answer your problem?
[https://nimble.directory/search?query=msgpack](https://nimble.directory/search?query=msgpack)
@andrea your HList/hkCons's tail has type T which means you can't be sure that
it's a HCons - you'll lose the generic type information too and can't apply
type inference anymore.
@mratsim my lists are always heterogeneous
@alehander42 let me explain the problem:
I'm trying to create a flexible
If your list is not heterogeneous, you can just implement it like in
[nimfp](https://github.com/vegansk/nimfp/blob/master/src/fp/list.nim#L10-L20)
type
ListNodeKind = enum
lnkNil, lnkCons
List*[T] = ref object
## List ADT
case kind: ListNodeKind
Also, you can use converters:
[https://nim-lang.org/docs/manual.html#converters](https://nim-lang.org/docs/manual.html#converters)
I'd do
type
HList[T] = ref object
case kind: HListKind:
of HNil: discard
of HCons: head: T; tail: HList[T] # on two lines in real code
HValue = ref object
case kind: HValueKind:
of HInt: i: int
of HString: text: st
@trtt Apart from using solutions for pattern matching such as gara, you can
iterate recursively over HLists and use if/case statements
This is how I would write a barebone HList, but for some reason the recursive
printAll does not seem to work
type
HListKind = enum hkNil, hkC
My last 2 "solutions" don't work either because for the first one I'd need a
proper nominal abstraction feature(or how to store a concept in a seq when the
elements can be different) and for the second one I'd need existential types(or
how to tell the that a seq can hold a HeterogenCell with any
Interesting problem!
Variants _are_ basically sum types in Nim.
Yeah, I was wondering similar things for some projects.
I am not sure what are you using hlists for, is it an AST. To represent an AST
you don't really need anything more complicated than data types(variants) in
Nim: HList.Cons ca
without PM.
I ditched heterogen lists and I'm investigating 2 possible solutions: 1. using
concepts and implicits conversions(matching things at addition etc.) 2. using
normal seq with a "heterogen cell" which holds the data and the handler - this
one only needs overloaded procedures or concepts to work.
Do you need just to be able to have nil and cons, or do you need to store
various values inside? In the second case, you can use variants indeed: they
are similar to data types from Haskell. If you're writing an interpreter, this
is what you need usually: represent all the possible values with d
This is perfect example case for [object
variant](https://nim-lang.org/docs/manual.html#types-object-variants)
That's great! Thanks!
> if Nim would have pattern matching
[https://github.com/alehander42/gara](https://github.com/alehander42/gara)
That would be useful too if Nim would have pattern matching...
The usual answer is json
[https://nim-lang.org/docs/json.html](https://nim-lang.org/docs/json.html)
Hi,
> How to implement heterogen lists in nim? In FP languages we've access to
> better pattern matching and sum types but in nim I can't reproduce them
> properly. I've tried it two different ways:
1\. this one fails because it can't infer the type of any
46 matches
Mail list logo
