/Prog/ramming Language

Hi /prog/, I was wondering what's the closest programming language that can do:


type percentage int x where x >= 0 and x <= 100
percentage discount = 25
# the above will not compile if e.g, discount = 9001
print discount

You get the idea, I found types lacking in conventional programming languages.

Ada

Ada

Something like this: http://en.wikipedia.org/wiki/Pascal_%28programming_language%29#Subrange_types
?

Haskell probably can do it by some peano axiomatic type masturbation.
Its probably not so useful anyway, if the language already has design-by-contract or similar.

Everything in the Pascal family has them.

Their usefulness is questionable.

>>6
not op here, but I think dta types like that can help making error detection much easier. They also could help in optimizing also that would be incredibly hard to automate and probably won't happen.

>>5,6
Why is it questionable? I can already see how useful it is to avoid bugs.

>>2
Ada seems interesting; any easy way to get Ada compiler working on osx?

>>2
Is it just me or anybody else have a difficulty taking Ada seriously for the simple reason it's named after a woman?

>>6
They're no less useful than types with ranges like -128...127 and -32768...32767.

>>4
Yes, but it could be used for much more than subranges, e.g,

type smart_student student s where s.grade > 90
This is pretty DRY, obvious, straightforward, avoids bugs, all which leads to better spec-to-code process in our industry. Why isn't this kind of typing be more adopted? Enlighten me, /prog/

>>12
also, this kind of explicit (sub?)typing can be applied wrt Erlang-style pattern matching. Think of the possibilities /prog/!

>>9
If it's a woman I don't mind going
ADA
FAS
TTS
E
R

>>9
Does gnatmake not work for you?

Maybe look around at http://libre.adacore.com/tools/

Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing number of programs the indiscriminate use of enumerations (and subranges) had led to a type explosion that contributed not to program clarity but rather to verbosity. In connection with import and export, enumerations give rise to the exceptional rule that the import of a type identifier also causes the (automatic) import of all associated constant identifiers. This exceptional rule defies conceptual simplicity and causes unpleasant problems for the implementor.

Subrange types were introduced in Pascal (and adopted in Modula) for two reasons: (1) to indicate that a variable accepts a limited range of values of the base type and to allow a compiler to generate appropriate guards for assignments, and (2) to allow a compiler to allocate the minimal storage space needed to store values of the indicated subrange. This appeared desirable in connection with packed records. Very few implementations have taken advantage of this space saving facility, because the additional compiler complexity is very considerable. Reason 1 alone, however, did not appear to provide sufficient justification to retain the subrange facility in Oberon.

- Wirth, From Modula to Oberon

Any language with operator overloading can do this like C++. Overload the arithmetic and assignment operators to include such a check. Also if you want your types to represent physical units that must combine in certain ways for your calculation, you can use C++ template metaprogramming as with Boost.Units.

this is trivial in javascript

>>9
>osx
Back to le hacker news, ``please"!

>>18
TRIVIALIZE MY ANUS