Type Classes and Generics

[h3rald]

I am continuing here the discussion on generics and type classes that we started here, to keep it a bit more organized from the 1.0.0 discussion :)

So, to recap...

Generics

The idea is to provide a way to define generics by using a quotation within a signature, like this:

(
  symbol add
  ((string|num|quot :t) :a t :b ==> t :result)
  (
   (a type "string" ==)
     (a b suffix @result return)
   when
   (a type "num" ==)
     (a b + @result return)
   when
   (a type "quot" ==)
     (a b concat #result return)
   when
  )
) ::

Type Classes

Originally I called them "type definitions" but I think type classes is more appropriate.

The idea is to extend min to add a new typeclass operator that would allow you to define a new type class specifying a quotation and a string-like value, like this:

(:n ((n integer?) (n 0 >)) &&) 'natural typeclass

Concerning @baykus871's comment about lexical scoping... I understand what you mean, but this is not as easy as I thought: lexical scoping is implemented for symbols, but... I was thinking of keeping type classes out of the symbol table, like in another dictionary, and do not use lexical scoping to keep things simple.

However, if we don't have lexically-scoped type classes, then:

• What happens in case of a conflict?
• What happens if a type class already exist?
• Is it possible to delete a type class?
• Is it possible to seal/unseal a type class?

...which actually makes things more complicated! So let's see what happens if type classes are symbols. The only that there could be is conflict with existing symbols that to completely different things... BUT this could be solved by having the typeclass operator return a special symbol, for example a symbol prepended with type:. At present, you CANNOT create user symbols containing :, so there's no possibility of conflict with ordinary symbols, and we get all the benefits of symbols (lexical scoping, sealing, etc.) for free! 👍

So, to go back to our previous type class definition, it would basically define a lexically-scoped symbol called type:natural. If you call it directly, you basically execute the associated quotation, BUT when used within a signature quotation without the type: prefix, it would be used for validating a value, so you could write.

(
  symbol natural-sum
  (natural :n natural :m ==> natural :result)
  (n m + @result)
) ::

The signature quotation is already special: essentially it contains symbols that are not actually evaluated, and the definitions are not really definitions (hence you can use :result to capture a quotation, not =result) -- I am adding more magic here, but this is the tidiest (and simplest) way to manage this that I can think of!

[ghost]

@h3rald Good idea to solve it. We should make a try. After that, we could see what goes on. I am too excited 😋
My reconstructed examples with the new idea:

(:n ((n integer?)(n 0 >=)) && ) 'natural typeclass

50 (natural) expect -> puts ;50
;Our stack has "50" at the moment.

type puts ;type:natural


( symbol mray
	(
		(int | string :t)
		t :begin	t :end	natural :step  ==>  quot :ray
	)
	(
		(t int ==) ; Generic using(t) in the operator body
			() ; if t is an integer then...
			() ; if t is a  string  then...
		if
	)
) ::

; ..Written in Notepad++ via Min Extension

Ah yes, the above code includes generic usement . Lexicalness may be a problem again(heh🤦 ). Because our generic types should be able to be controlled in operator body. However this can be useful i think.

Am i right?

[h3rald]

Yep. Actually... erhm, I actually already implemented type classes in the next branch. It turns out that making them symbols made everything much easier than expected:

bd0baea

Next, generics, yes 😊

regarding generics usage in body... mmmmm that could actually be difficult, because t actually doesn't really exist as a symbol. In my previous example I was simply checking the type of one of the values instead.

Also the generic declaration would actually be a little different than the one you used here... check the previous example... I was thinking of using a quotation instead of the type symbol... I will think about it.

The problem with your example is that I would have to check for quotations first and then remove them, and then check the signature. Not sure. Other ideas?

[ghost]

@h3rald

My brain sometimes auto-completes codes in the way of topic then real codes can be skipped from my brain 😄 .
Sorry about that.

And i see stringlike? what is this?

So we will do hacky after. -> a type 'string ==

Are all these same things? => a type 'string == and b type 'string => That is not good. This feels like a little bit of ambiguity

I am happy for your implementation. I will wait next release then i could have time for testing the feature.

[h3rald]

I am not sure I understand... what ambiguity?

Maybe the name of the symbol a?

well, if it is used in a signature quotation, and if it is positioned as a type then a means "any type", like string means "any string". But in that example a and b are symbols used to capture input values. I could have used m and n instead...

The thing to remember here is that a signature quotation is not exactly evaluated like a traditional quotation, but specifically as a signature. If you think about it:

• the symbolsa, string, string|int etc. are parsed by min parser as symbols, but they are not evaluated: a is not defined in any module, and string is defined in lang but it converts a value to a string... in a signature is just a label for the name of a type. I could have used "a", "string" maybe instead, like in the expect symbol maybe? I wanted to be less verbose... Actually I could change the expect symbol to use raw symbols as well...
• the symbol ==> is used to separate input values from output values, again, it is not evaluated.
• the capturings:a, :result are not really variable definitions, and that's why :result will capture a quotation, even if it's not =result. Actually I must check if this is right... basically the captured quotation technically is always double-quoted. 🤔 gotta do some tests.

it feels a bit like magic but... well, the truth is quotations are used to delay evaluations, it's like macros in lisp 😉 very powerful, but confusing at times (have a look at infix-dequote and prefix-dequote).

[ghost]

@h3rald
Your explainment is very good and i understand it really. Operator definition was stranger for me, i wasn't knowing even how is it running and what its system. But now i know it. Thanks.

I just thought a type t should be preferred to a type or b type ... etc. Because it is one , but others not. And we know what it is. When changing types of a , b etc. , our t type which used in operator body is like to be changed but it must not change. Hopely i explained it. 🆗 ?

[ghost]

Other ideas?

At the future, i think there will be all doings in Min. I declare it as Min-phase. Now we are at Nim-phase. But your doings shifts the current phase to Min-phase. After that, there will be only adaptions will made in Nim. Other things will be on Min.

However i think you don't desire to make everything within Min. Because i read the passage:

min is a functional, concatenative programming language with a minimalist syntax, a small but practical standard library, and an advanced REPL. All packed in a single file*

There is going to be a mind-branching and way-branching

[h3rald]

Well, here's the deal: the main goal of min is to be 100% self-contained, i.e. to be usable enough on its own, as a single file. As a result, all the operators provided by the standard library are written in Nim.

The funny thing is that a lot of those operators could be written in min, but... I would essentially have to read the contents of min files or store them as string, bundle them in the executable file, and then execute them at run time when used. At that point, writing the same operators is Nim is definitely going to make the code a bit faster... so I essentially only used min for the prelude which is of course included in the executable file.

On the other hand, there could be packages someday, who knows! A bit like nodejs: the executable is quite big and it does a lot, but there are still a lot of packages out there to add functionality (too many in fact).

I think at some point I'll have to draw the line and decide that certain functionalities don't belong in the min executable and should be implemented in separate packages as min modules.

[ghost]

Well, here's the deal: the main goal of min is to be 100% self-contained, i.e. to be usable enough on its own, as a single file. As a result, all the operators provided by the standard library are written in Nim.

The funny thing is that a lot of those operators could be written in min, but... I would essentially have to read the contents of min files or store them as string, bundle them in the executable file, and then execute them at run time when used. At that point, writing the same operators is Nim is definitely going to make the code a bit faster... so I essentially only used min for the prelude which is of course included in the executable file.

On the other hand, there could be packages someday, who knows! A bit like nodejs: the executable is quite big and it does a lot, but there are still a lot of packages out there to add functionality (too many in fact).

I think at some point I'll have to draw the line and decide that certain functionalities don't belong in the min executable and should be implemented in separate packages as min modules.

I think so! 👍

[h3rald]

Implemented both type classes and generic support in v0.29.0 😊🎉👍

https://github.com/h3rald/min/releases/tag/v0.29.0