search

PyHP-pph / PyHP_pph

This repository serves as a centre for collaboration on the PyHP++# language. It will also include a functioning interpreter and compiler for PyHP++# once the standard is finalised.
https://www.reddit.com/r/PyHP_pph/
GNU Affero General Public License v3.0
23 stars 3 forks source link

Primitive types should be in PascalCase #43

Open cntkillme opened 7 years ago

cntkillme commented 7 years ago

In boolean.md it is explicitly stated that the boolean type is named boolean. Clearly this is a problem, formal language dictates we capitalize the first letter of proper nouns and Boolean is a NAME of a type.

We can see this same problem in functions.md where int is used, however the integer type is not (at the time of this writing) part of the standard so it will be easy to alter.

Logically, all types should be capitalized and as so the specifications making up the standard should account for this sooner rather than later.

Kampfkarren commented 7 years ago

What do you think about the types singleString and DOUBLE_STRING in strings.md?

cntkillme commented 7 years ago

I believe the name singleString is okay as strings encapsulated within single-quotes is an unacceptable idea. The camelCase form is fantastic for specifying the names of informal types such as singleString.

However I do believe DOUBLE_STRING should be renamed to ProperCorrectString to ensure newcomers understand this type should be used for strings.

ghost commented 7 years ago

I think it might be a good idea to distinguish primitive types from classes.

cntkillme commented 7 years ago

That would be irrelevant, in modern times all primitive types should be classes. For example Java has boxed-types which is a step in the right direction. Sadly Java is notorious for having these types as well as primitive types... but if they just removed primitives it would indeed be the most modern language out there.

So differentiating between primitives and classes should not be necessary since primitives should not exist in the first place.

ghost commented 7 years ago

(On mobile so using email/GitHub relay)

I see your point, and I agree, but how do we create classes like, say, Integer, when there's no way to represent those types within the language? And how do we implement the operations on those classes? If we make them a special case and/or define/implement them in the CIC, they become just disguised primitives.

For example, if we make Integer a class, with no special treatment, (even if we find a way to tell the CIC 'allocate one register-width of memory as a property') we cannot implement +, since the only way to do that is with an ADD instruction. Without special handling for Integer, the only way to do that is with the dreaded inline assembly. We could make Integer a class defined and implemented at least partially in non-PyPH++# code, or give it special treatment, but now we just have a thinly-disguised primitive.

One simple idea is to let the CIC define non-standardized primitives, and use those to implement wrapper classes that take the roles of primitives in general use.

I'm sure I'm missing something here, but that's my interpretation with the information I have now.

On Wed, Jun 28, 2017 at 16:51 Matthew notifications@github.com wrote:

That would be irrelevant, in modern times all primitive types should be classes. For example Java has boxed-types which is a step in the right direction. Sadly Java is notorious for having these types as well as primitive types... but if they just removed primitives it would indeed be the most modern language out there.

So differentiating between primitives and classes should not be necessary since primitives should not exist in the first place.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/PyHP-pph/PyHP_pph/issues/43#issuecomment-311786415, or mute the thread https://github.com/notifications/unsubscribe-auth/AB915PC6STRQSKx1k8hoOI-pzAge1Pa5ks5sIrzkgaJpZM4OFC1F .

Kampfkarren commented 7 years ago

An "ADD" instruction doesn't need to know about integers at all, it can just call an "__add" metamethod or something similar.

ghost commented 7 years ago

I'm talking about the actual, CPU-level, machine code, ALU ADD instruction. The one that actually tells the CPU, "Add these two integers together." A CPU ADD instruction only works on register-length integers (and they have to be loaded into the registers). That means we need special treatment somewhere in order to execute the instruction. Whether that be inline assembly, non-PyPH++# implementation, or plain special treament of the Integer class to allow adding it.

cntkillme commented 7 years ago

We're going to be treating the CPU as a black box. The implementation details do not matter, however to the user all types must be a class. Implementation of arithmetic operators must be abstract, these operators can be overloaded-- and must be, in the case of the Integer class.

To actually implement, say, addition, code can be wrapped within an unsafe block. The hash of the Integer class can then be retrieved (which, by the standard, must be the value it encapsulates) and arithmetic operations of this hash as a raw type can be done within the unsafe block.

ghost commented 7 years ago

What goes in the unsafe block? And what is the type of the hash?

cntkillme commented 7 years ago

A hash can only be retrieved within an unsafe block and it returns an unsafe type (for the Integer class, it will return the raw integer it encapsulates). You can interact with unsafe types through the unsafe API which deals with unsafe types through intrinsic functions provided by the compiler.

ghost commented 7 years ago

Okay. That makes sense. On Mon, Jul 3, 2017 at 06:05 Matthew notifications@github.com wrote:

A hash can only be retrieved within an unsafe block and it returns an unsafe type (for the Integer class, it will return the raw integer it encapsulates). You can interact with unsafe types through the unsafe API which deals with unsafe types through intrinsic functions provided by the compiler.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/PyHP-pph/PyHP_pph/issues/43#issuecomment-312605073, or mute the thread https://github.com/notifications/unsubscribe-auth/AB915JDDerRUFLY5NF01oELmZLYmZaZUks5sKLz_gaJpZM4OFC1F .

Kampfkarren commented 7 years ago

cntkillme, are you willing to make a specification on this?

cntkillme commented 7 years ago

I need to run this through my manager. I believe you know him, Bubsby. He is currently working on some standards and rewriting the entire spec. to help get rid of any currently existing ambiguity. Sadly, he claims that his environment only supports the "Drako" language. Apart from the standards I would not expect anything else to be completed by him due to this restriction.

It is entirely possible, though, for quicker results that I formalize and standardize a few specific specifications and then run them through Bub later this week.

Kampfkarren commented 7 years ago

@cntkillme Has Bubsby gotten back to you? I would like to see a specification for this.