micro has quit [Remote host closed the connection]
micro has joined #ocaml
kristjansson has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristjansson has joined #ocaml
waleee has quit [Ping timeout: 255 seconds]
<discocaml>
<speeddart> is bytes guaranteed to be 8 bits per byte?
<discocaml>
<._null._> In most contexts, yes
<discocaml>
<speeddart> ok cool, i am attempting to store a chess board and i want to use a byte per tile if possible so i dont waste memory with an int
<discocaml>
<struktured> Are you still using natural ocaml types to represent board state?
<discocaml>
<._null._> How do you plan on using bytes ? They're not really easily accessible in OCaml
<discocaml>
<speeddart> hmm, I thought it had array index access
<discocaml>
<speeddart> I could just use int array if not
<discocaml>
<speeddart> i doubt it will matter that much
<discocaml>
<._null._> What type would byte be, `byte` is not a built-in type
<discocaml>
<._null._> What type would byte be ? `byte` is not a built-in type
<discocaml>
<speeddart> fair enough
<discocaml>
<speeddart> i can use int array, it probably will not matter
<discocaml>
<speeddart> not unless I can do it in a way that works dynamically. i am going to add custom piece functionality in the future - the piece types are not known at compile time.
<discocaml>
<._null._> Their equivalent would be `char`, but they don't support arithmetic and they're really made for ASCII
<discocaml>
<speeddart> I don't think I'll need arithmetic
<discocaml>
<speeddart> I was told a char is also 32 bits at runtime - not sure if that is accurate or not
<discocaml>
<struktured> There's also some bit packing libraries out there if you need them
<discocaml>
<._null._> a char is a pointer to an 8-bit thing. A string is a pointer to a byte array (packed)
<discocaml>
<speeddart> gotcha
<discocaml>
<._null._> Wait I'm wrong, a char is an 8-bit thing (no pointer)
<discocaml>
<speeddart> does an int use a pointer too? i have heard ocaml does some special 31 bit thing with ints but im not entirely sure
<discocaml>
<._null._> Usually 63 if you're on a semi-recent machine, but yes one bit is taken
<discocaml>
<speeddart> tbh - i think im over thinking this
<discocaml>
<speeddart> I will use an int array
<discocaml>
<speeddart> If it is the word size of the computer it might even be better for perf who knows. i optimize later if issue
<discocaml>
<._null._> If you model a chess board, wouldn't it really be a `piece array` (or even `array array` for matrix indexing) ?
<discocaml>
<speeddart> `type piece = int` yeah
<discocaml>
<speeddart> I'
<discocaml>
<speeddart> I'll use a formula for matrix indexing
<discocaml>
<._null._> Why use the full int when you can make your own type
<discocaml>
<speeddart> I prefer vastly to a 2d array
<discocaml>
<speeddart> ^
<discocaml>
<struktured> I would loathe to do that in Ocaml, personally. Would rather define a variant for the piece types
<discocaml>
<struktured> but yeah, dynamic makes it harder
<discocaml>
<speeddart> otherwise id do `type Piece = Pawn | King | etc...`
<discocaml>
<._null._> What do you want to make dynamic that wouldn't fit the type system ? You could make `piece` an extensible type if you really need it
<discocaml>
<speeddart> custom pieces
<discocaml>
<speeddart> With different patterns, etc
<discocaml>
<speeddart> I havent got to that implementation yet but the idea is that a rule for a piece is just some data that a function will use to decide the moves for the piece at a given board state
<discocaml>
<speeddart> I prefer to not use polymorphism because it will over complicate things - so I will need to match against the piece type to figure out which ruleset to use and then use the rulset
<discocaml>
<speeddart> I usually use something like go so thinking functionally is a bit challenging ig
<discocaml>
<._null._> It sounds like extensible types would fit this, OCaml makes it so that using `int` or `string` as a custom type is pretty much never the best solution
<discocaml>
<speeddart> I cant think of a way to do it, but if you ccan think of one id love to try iot
<discocaml>
<struktured> I mean you could technically use a single record type with a n integer piece value and a bunch of parameters to determine the piece behavior.
<discocaml>
<._null._> `type piece = .. type piece += Pawn | King | ...` and then in your custom piece modules `type piece += Camel` or idk
<discocaml>
<speeddart> But the custom pieces are user data, ultimately no piece type besides a King can show up in the code
<discocaml>
<speeddart> But the custom pieces are user input, ultimately no piece type besides a King can show up in the code
<discocaml>
<speeddart> Ultimately somewhere I need to say at runtime - this piece uses this ruleset
<discocaml>
<speeddart> I can't think of a way to do that aside from matching a stored option and using the right rulset or doing something with polymorphism (rather not)
<discocaml>
<speeddart> wydm?
<discocaml>
<struktured> I mean in your case a piece is just a number for indexing purposes and bunch user driven fields to detemine it's behavior.
<discocaml>
<speeddart> I was planning to make the piece behavior stored seperately from the piece itself - we will have lots of duplicate pieces
<discocaml>
<speeddart> gonna store it in the board itself probably
<discocaml>
<struktured> Ok, in any case, please make a knishop
<discocaml>
<._null._> Ok, this might need more engineering than I thought, but you can still make it work with a generative functor
<discocaml>
<speeddart> A knight and a bishop? I shall
<discocaml>
<speeddart> hope to share it with this community if I ever finish
<discocaml>
<._null._> But since you also need to store patterns, this might be the one use case for classes
<discocaml>
<speeddart> chose ocaml because a class next year is done with it
<discocaml>
<speeddart> ill look into it
<discocaml>
<speeddart> I have a rough understanding of functors - does that mean each piece ends up with a module?
<discocaml>
<struktured> that's true, and you can use first class modules to load them dynamically
<discocaml>
<._null._> For each piece, you generate a module which will contain a new variant for the type and presumably info about its pattern
<discocaml>
<functionalprogramming> what are you going to parse a user-input rule into?
<discocaml>
<._null._> Then the variant is a valid element of type piece, so the code will already have to account for it
<discocaml>
<speeddart> Probably something like this ```
<discocaml>
<speeddart> type position = (int * int)
<discocaml>
<speeddart>
<discocaml>
<speeddart> type direction =
<discocaml>
<speeddart> | single of position
<discocaml>
<speeddart> | multiple of direction array
<discocaml>
<speeddart>
<discocaml>
<speeddart> type rule = direction array
<discocaml>
<speeddart> ``` im not 100% sure yet
<discocaml>
<speeddart> position is relative to piece position
<discocaml>
<speeddart> actually no, that is wrong
<discocaml>
<speeddart> multiple needs to support a range of values basically
<discocaml>
<speeddart> i mean a array works I suppose
<discocaml>
<speeddart> the idea is that you could create a bishop that you could create a "direction" a piece moves in and say whether or not it can hop
<discocaml>
<speeddart> if not, the piece needs to check all positions in the direction before it gets there
<discocaml>
<Kali> avoid code blocks in #general, the irc bridge has to split them into newlines
<discocaml>
<speeddart> oh ok, mb
<discocaml>
<Kali> maybe move to #beginners or #advanced-help
<discocaml>
<speeddart> think im getting off for now but thats the general idea, ill do that next time
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
trev has joined #ocaml
kristjansson has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
anpad has quit [Ping timeout: 260 seconds]
anpad has joined #ocaml
trev has quit [Quit: trev]
<discocaml>
<froyo> char is immediate like bool and int
azimut has joined #ocaml
<discocaml>
<commutativeconjecture> anyone got a good survey on abstraction? rn, i mostly have 3 approaches in mind. first one is OCaml's (and Coq's IIUC?), with abstract types identified with module paths + name
<discocaml>
<commutativeconjecture> second one is dependent pairs, similar to existential GADT's in OCaml; where the work is adding support for existential bindings in top-level / cross-compilation-unit positions
<discocaml>
<commutativeconjecture> last one is a bit more hacky, where you add a special type called `Opaque/Private`, with custom constructors/destructors for this type, and you can then remove these from scope. it's closest to object encapsulation, but i'm not sure what are the consequences of making scopes non-monotonic (like the diff between scopes becomes more complex, what else??)
<discocaml>
<commutativeconjecture> am i missing anything big? links help too, blog posts, papers, some obscure okmij.org/ftp page
drakonis has quit [Quit: WeeChat 3.6]
Tuplanolla has joined #ocaml
xd1le has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<famubu>
Hi. I had been trying to use Array module (with dune). And despite having a make_matrix function used inside the file, I'm getting unused open error. What could be the reason? Do I have to mention Array as a dependency in the dune file or something?
<discocaml>
<Kali> are you doing something like...
<discocaml>
<Kali> ```ocaml
<discocaml>
<Kali> open Array
<discocaml>
<Kali> ....
<discocaml>
<Kali> Array.make_matrix ...
<discocaml>
<Kali> ```
<discocaml>
<Kali> if you are, that's the problem
bartholin has joined #ocaml
<discocaml>
<Kali> `open Array` exposes all the contents of Array, so explicitly qualifying the Array in `Array.make_matrix` is redundant and dune is warning you about that
<discocaml>
<Kali> there are two solutions, which is either to remove the `open Array` and continue qualifying all Array module functions explicitly, or to keep the `open Array` and just refer to the functions directly (`make_matrix` instead of `Array.make_matrix`)
<famubu>
Yeah that was it. I had both `open` and `Array.function`. Thanks!
<discocaml>
<._null._> (Removing the `open Array` sounds like the most natural thing to do)
<discocaml>
<Kali> if you're familiar with the difference between "import/include" and "use", `open` is like `use`, not import; importation is handled by the build system
oriba has joined #ocaml
mima has quit [Ping timeout: 245 seconds]
waleee has quit [Ping timeout: 260 seconds]
waleee has joined #ocaml
bartholin has quit [Quit: Leaving]
waleee has quit [Ping timeout: 245 seconds]
waleee has joined #ocaml
rgrinberg has joined #ocaml
<famubu>
I removed the open and just used the Array. prefix.
waleee has quit [Ping timeout: 255 seconds]
waleee has joined #ocaml
waleee has quit [Ping timeout: 268 seconds]
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]