h3rald / min

A small but practical concatenative programming language and shell
https://min-lang.org
MIT License
310 stars 23 forks source link

Type access from modules denied #125

Closed ghost closed 3 years ago

ghost commented 3 years ago
( symbol test
    (*types/natural :x ==>)
    (x puts!)
) ::

5 test

Error:

(!) types.min(13,4) [::]: Invalid type '*types/natural' specified in signature at position 1
    types.min(13,4) in symbol: operator
    types.min(13,4) in symbol: ::

This doesn't work too:

( symbol test
    ((natural) 'types with :x ==>)
    (x puts!)
) ::

5 test
h3rald commented 3 years ago

Mmm no, I don't think allowing invoke syntax is a good idea. You should create your type definitions in a separate file and import them in the scope wherever you need them really!

ghost commented 3 years ago

Mmm no, I don't think allowing invoke syntax is a good idea. You should create your type definitions in a separate file and import them in the scope wherever you need them really!

Nah.. not that possible!

Because symbol overloading won't be possible after making yours. For example:

# math.min
...len...

# array.min
...len...

# vector.min
...len...

# main.min (My Solution -> You should make it work)
'math require :math
'array require :array
'vector require :vector

( symbol a
 (*math/len :x ...)
 (...)
) operator

( symbol b
 (*vector/len :y ...)
 (...)
) operator

( symbol c
 (*array/len :z ...)
 (...)
) operator

# main.min (Your Solution -> `len` is an ambigious symbol so that mustn't be solution of the problem)
'math require :math 'math import
'array require :array 'array import
'vector require :vector 'vector import

( symbol a
 (len :x ...)
 (...)
) operator

( symbol b
 (len :y ...)
 (...)
) operator

( symbol c
 (len :z ...)
 (...)
) operator
h3rald commented 3 years ago

OK, point taken. But the problem remains: symbols in signatures are not ordinary symbols, because for example if you define a typeclass called len it actually points to a symbol called typeclass:Len. So an invoke call there is a bit out of place because it should technically be:

*array/typeclass:len :z which is way too long and still inconsistent with the rest of the signature.

We could however have ONE level of namespacing, and allow something like:

 array/len :z

Problem is... what is array? Where do I perform in lookup?

I would assume the symbol bound to the required module, so you should do something like:

'array require :array

First. But if you do:

'array require :arr

Then your signature should be changed to:

 arr/len :a

Thoughts?

ghost commented 3 years ago

OK, point taken. But the problem remains: symbols in signatures are not ordinary symbols, because for example if you define a typeclass called len it actually points to a symbol called typeclass:Len. So an invoke call there is a bit out of place because it should technically be:

*array/typeclass:len :z which is way too long and still inconsistent with the rest of the signature.

We could however have ONE level of namespacing, and allow something like:

 array/len :z

Problem is... what is array? Where do I perform in lookup?

I would assume the symbol bound to the required module, so you should do something like:

'array require :array

First. But if you do:

'array require :arr

Then your signature should be changed to:

 arr/len :a

Thoughts?

That is not a big problem because of ⌨️ CTRL - H (Find & Replace). You can change your one keyword where exists in file, via CTRL - H. The problem you saw is that ambiguity surround the file, i think.

ghost commented 3 years ago

Seems i found a way to handle : If we implement an overloading way then we'll hold files as module dictionaries in file no more maybe.