modules, that is very Wurth like of you!
i'm curious, why do you like objects as opposed to interfaces and structural typing?
And for those interested in the implementation
https://deavmi.assigned.network/projects/tlang/implementation/39-modman/
Discussion
There are some cases where I use many interfaces (in fact a lot) but a lot of the AST is sub-typing (or sub-classing) as it naturally makes sense.
A BinaryOperstor has a LHS and RHS of type Expression. BinaryOperstor itself is a kind-of Expression. Hence it can nest itself with (1*1)+(2*1).
Examples like those are prevalent through TBS syntax of T (and all languages) and hence implementation wise it just made sense to model it using OOP like that.
Open to suggestions and critique!
Operator is a red flag... builtin logic should only apply to values, and values, specifically, that are based on the CPU's built in types
vertical bars | are generally used as either bitwise OR or as concatenation operators for cryptographic operations, for example
but there's some nasty ambiguity there... append(first, second...) is unambiguous
i'm not gonna say anything about inheritance just focus on the point of redefining operators
many languages now allow you to redifine any infix, postfix or prefix operation on many other types
this creates ambiguity in the mind of the programmer, what does this + mean? addition? concatenation? encapsulation?
the more i have to think about what a common operation means, the more likely i am to not understand what two variables with this operatior between them means, and that increases the risk that i'm going to miss a bug
Once it is parsed it (a binary operator) is parsed it becomes:
LHS (Expression)
RHS (Expression)
Operator (SymbolType)
So it is available as such at that point.
As for your semantic point of view. Well that is processed later during typechecking.
A binary operator is the most generic way to describe it.
You determine the meaning based on the operands. In many cases I have used my type coercion mechanism which, I believe, coerces to the left hand operand.
So it works out well.
Do let me know if I have missed the point. This discussion is useful to me.
redefining infix, postfix and prefix operators on anything other than value types is a bad game, as is macros - they make it so when reading the code you have to go through two things to remember instead of just one, and then spread that out to a whole project
i'd say the thing you missed is why make another language when there is already a pretty much perfect one?
for me, there is #bitcoin and then there is #golang and these are two things that really don't need to be changed without inordinately long processes of deliberation, testing and modeling
in fact, in both cases i am of the opinion that several things could be removed and nothing of value would be lost
i am warming up to type parameters though, they have a use in reducing the amount of casting between basically identical types (eg int and int64)
Type parameters. As in meta programming?
golang's "generics" are really just a logical extension of duck typing... if it can be inferred, then it is permitted if the type parameter specifies it
although i don't know yet what the ~ means in them yet, didn't read that in the docs yet but i've seen it in an "x" package
In D we have full blown metaprogramming. I don't use it all too heavily except in a few projects like serializers etc.
But it is great. I can write code that writes code.
I'm a compiler man, it's my craft.
So of course I would make my own language as I want to write in it.
yeah, it's a bit of a search for the holy grail... i can't deny i don't think about it... was one of the first things i did when i got my hands on a c compiler was to play with bison and yacc
Oh and yes. I stole that header from Modula
yes, and so did Oberon and then Go
the fact that all the popular languages other than Go don't use it is pretty messed up
it makes it a lot easier to create good names for things
i mean, how does C even make namespaces at all?
why are we still suffering from OOP nonsense when you can make filesystems and namespaces that are one and the same?
personally, i always call my directories the same name as the package i put inside them, and this is a common practise with #golang it's even a setting in intellij for Go, to automatically rename packages if you rename folders, and vice versa
may i suggest that you adopt the idea of just making the directories the names for referencing them? actually, there is no reason to repeat this!
btw, there is one good reason to not make folders 1:1 with package names, that is the fact that filesystems don't respect the semantics of things like - and + and other operators, this is a waste of processing time to have to distinguish them
this is the best reason to have module name headers... i just hadn't thought about it that deeply, but the guys who designed Go have been drowning in computer programming for 40 years
The Go designers, the original ones are indeed balls deep in that 40 year + language design experience indeed.
yeah, the longer i use #golang the more i get it too...
the only thing i warn people about go is that maps and slices are funny with concurrency and be really careful about where you put channel operations and goroutines
there can be a tendency to go nuts on those two things, i think every go programmer goes through a phase of it
oh yeah, sometimes some people go nuts with interfaces - don't make them unless you already have a concrete type, or a plan to make multiple types, more often you don't need them and they create an unhelpful layer of indirection
the usual trigger for making interfaces fro me these days is noticing that i just made three sets of methods for types that were the same, then i am facepalm
Yep! Same
Slices have to be handled carefully in D to, or well by carefully I mean one must think when using them.
yeah, i remember when i first used a language with dynamic arrays
i kinda prefer static arrays to be honest, i always look at the code and think to myself "is this probably going to need a reallocation?" and try to avoid that
Defs agree!
The only times I have interfaces is when I know there are a few classes with behavior I need via an interface.
Well, other way round. Describe a behavior and implement it in many place.
yeah, there is definitely use for it... i just implemented a binary codec recently for database index keys, it is way cleaner than the previous offset laden code full of wordy and error prone constants (literals even) read and write are two examples that often come up... interface methods also tend to come in pairs, in general, not always... and yes, interfaces need to be small... there is an interface in my current project that i think could do without one idiotic method that doesn't do anything actually - an init function... another principle of #golang is to design structs so the zeros are reasonable defaults if they aren't, you can also handle that as a function called from methods that need a value other than zero to set the value to a reasonable default, then the interface is cleaner and the programmer can just throw these things in
The name resolution is tied to the module names. The strict headed option is only optional now because some unittests don't yet conform.
I will be defaulting it to true soon, once done with those tests.
Then yes, it enforces the matching of names to FS