Hello,
Does anyone know if programming languages are protected by copyright or not?
When creating a new program, you are not allowed to pick-and-choose
what you want from other programs sources as that would be a copyright
violation.
But when creating a new programming language, it seems that ev
Markus Laire writes:
> Does anyone know if programming languages are protected by copyright
> or not?
Code can be copyrighted; ideas can't be.
> When creating a new program, you are not allowed to pick-and-choose
> what you want from other programs sources as that would be a copyright
> violatio
HaloO,
Larry Wall wrote:
> I now think it's a bad idea to overload | or & to do type construction,
Is it then a god idea to overload the set operations? At least the
type constructions are set theoretic on the intension set of the
roles.
> especially since the tendency is to define them backwar
HaloO,
Jonathan Lang wrote:
> OK. My main dog in this race is the idea of defining new roles
> through the concepts of the intersection or difference between
> existing roles (even the union was thrown in there mainly for the sake
> of completion), with the consequent extension of the type system
On 10/23/06, Smylers <[EMAIL PROTECTED]> wrote:
Markus Laire writes:
> Does anyone know if programming languages are protected by copyright
> or not?
Code can be copyrighted; ideas can't be.
Yes, but the syntax of the programming language is more than just an idea.
Copyright-article[1] at Wi
HaloO,
Jonathan Lang wrote:
> OK. My main dog in this race is the idea of defining new roles
> through the concepts of the intersection or difference between
> existing roles
Note that you should not call these 'intersection type' because
this term is used for the union of role interfaces. That
TSa schreef:
> A(|)B produces a subtype of A and B, and that A(&)B
> produces a supertype
Are you sure? I see "&" as "limiting; sub" and "|" as "enlarging;
super".
To me, "&" is connected to multiplication (and inproduct, statistics,
fuzzy logic), and "|" to addition (and outproduct).
$ perl -w
HaloO,
Ruud H.G. van Tol wrote:
TSa schreef:
A(|)B produces a subtype of A and B, and that A(&)B
produces a supertype
Are you sure?
Very sure ;)
In record subtyping a record is a mapping of labels to types.
In Perl 6 speak this is what a package does. One record type
is a subytpe if it ha
HaloO,
[EMAIL PROTECTED] wrote:
Log:
"does" operator is non-associative according to S03. Leave it that way for now.
[..]
-$fido does Sentry | Tricks | TailChasing | Scratch;
+$fido does (Sentry, Tricks, TailChasing, Scratch);
Does that apply to the trait verbs used in class definitio
On 10/23/06, Markus Laire <[EMAIL PROTECTED]> wrote:
On 10/23/06, Smylers <[EMAIL PROTECTED]> wrote:
> Markus Laire writes:
>
> > Does anyone know if programming languages are protected by copyright
> > or not?
>
> Code can be copyrighted; ideas can't be.
Yes, but the syntax of the programming
TSa writes:
> Ruud H.G. van Tol wrote:
>
> > TSa schreef:
> >
> > > A(|)B produces a subtype of A and B, and that A(&)B produces a
> > > supertype
> >
> > Are you sure?
>
> Very sure ;)
In which case that provides a handy example supporting Larry's
suggestion that this is confusing, with some
HaloO,
Smylers wrote:
In which case that provides a handy example supporting Larry's
suggestion that this is confusing, with some people expecting it to work
exactly opposite to how it does.
So the mere fact that there are two sets involved rules out the
set operators as well?
It doesn't re
Smylers wrote:
TSa writes:
> Ruud H.G. van Tol wrote:
> > TSa schreef:
> > > A(|)B produces a subtype of A and B, and that A(&)B produces a
> > > supertype
> >
> > Are you sure?
>
> Very sure ;)
In which case that provides a handy example supporting Larry's
suggestion that this is confusing, wit
HaloO,
Jonathan Lang wrote:
Please, no attempts to merge signatures. Instead, use multiple
dispatch
That avoids the problem before it occurs. But do you expect
every role to provide its methods as multi just in case?
Also, sub is an odd choice to use while illustrating role composition;
wh
TSa <[EMAIL PROTECTED]> wrote:
I strongly agree. Having a language that allows supertying has novelty.
But I think that union is not there for completion but as integral part
when it comes to defining a type lattice which I still believe is the
most practical approach to typing. This includes com
HaloO,
Jonathan Lang wrote:
If we make a point of highlighting the "set operations" perspective
You know that there are two sets involved. So which one do you mean?
and avoiding traditional type theory
terminology (which, as Larry pointed out and TSa demonstrated, is very
much inside out fr
TSa wrote:
Jonathan Lang wrote:
> OK. My main dog in this race is the idea of defining new roles
> through the concepts of the intersection or difference between
> existing roles
Note that you should not call these 'intersection type' because
this term is used for the union of role interfaces.
HaloO,
Jonathan Lang wrote:
BTW, are the ASCII equivalents spelled (<), (>) and (in)?
I'd hope that they'd be something like '(<)', '(>)', and 'in'; only
use parentheses when neccessary. Likewise, I'd want the "relative
complement" operator to be '-', not '(-)'.
Funny. I would have hoped th
Jonathan Lang schreef:
> (&) and (|) would actually reflect your intuition regarding the
> capabilities of the result, in that a role arrived at by means of (&)
> would provide fewer options than the individual roles used to create
> it, while a role arrived at by means of (|) would provide more
>
TSa wrote:
Jonathan Lang wrote:
> Please, no attempts to merge signatures. Instead, use multiple
> dispatch
That avoids the problem before it occurs. But do you expect
every role to provide its methods as multi just in case?
Conceded.
Bear in mind, though, that signatures include not only ty
HaloO,
Jonathan Lang wrote:
Bear in mind, though, that signatures include not only type
information, but also parameter names; and method calls are permitted
to pass an argument into a given parameter by means of its name
instead of its position, so the names cannot be disregarded. For
instance
HaloO,
Jonathan Lang wrote:
my @array = (0,1,2); # Array of Int
@array[3] = "three"; # Array of Int(&)Str
Actually, these would be something along the lines of "Array of Int"
and "Array of (Int, Int, Int, Str)", respectively. That is, each of
@array[0..2] would be of type "Int", while @ar
TSa wrote:
I don't know how close leaving an undefined method as described above
to the class designer comes to automated merge. Note that at no point
I'm arguing that the body be merged. I'm seeing guarantees that the type
system tries to hold up in favour of the users of roles.
If you're not
On October 16th Damian Conway wrote:
> If the contents are not a number, they are interpreted as an upper-case
> Unicode character name, or as a lower-case XHTML entity. For example:
One more problem: not all XHTML entities are lower-case. For example:
Ð Þ É Θ
For a complete list, see:
ht
24 matches
Mail list logo