Language design: implementation of "references"
Charlie Dawson
thread; these prompted me to look at Java and C# in more detail
(sorry, couldn't find the Algol docs!). With these and some more
thought I've now got a better idea of what exactly the issue is, hence
the new thread.
Question: how do you cleanly add "references" to a language, in a way
which is intuitive, and which is easy for a non-programmer to use and
understand? I've compared how this is done in C++, Java, and C#
(disclaimer: I only actually write C++, and my Java/C# comments may be
wrong).
Observation #1: simply having the ability to pass a reference to a
function is only half the problem. If your language has a reference
concept, then you also need the ability to put references inside
aggregate types (structs and arrays), since these might also be passed
to a function.
Observation #2: passing a reference to a function, by *value*, is of
limited value. This does give the function the ability to change the
caller's object, but not to substitute it for another object. This
appears to lead to confusion in Java, at least.
Observation #3: Ada-(and Algol?)-style in/out/inout parameters are, I
think, sufficient for most function-level usage, without introducing
the user-level complication of "references". The implementation of
out/inout parameters could probably also fix the limitation in
Observation #2 above.
Observation #4: Just having reference *types* isn't sufficient. This
leads to problems like "how do I write a method to swap two integers
in Java?", which involve bizarre work-arounds. If you have the ability
to handle references, then you should also apply them to basic/numeric
types.
Java
----
o Has both 'primitive' and 'reference' types
- Everything passed by value (problem in #2 above)
- Can't apply references to the primitive types (problem in #4 above)
- Can't put references inside aggregates (problem in #1 above)
which leads me to suspect that Java "references" are simply an
implementation convenience, which are of limited value to the
user. Could the same effect have been achieved by adding inout-mode
parameters, with much less conceptual difficulty for the user?
C#
--
o Has both 'value' and 'reference' types
+ parameters can additionally be passed by reference
(has both 'ref' and 'out'-mode parameters - why not
'inout' instead of 'ref')?
- Can't put references inside aggregates (but see below)
There's a bodge for putting references inside aggregates, which is to
use boxing/unboxing. However, this creates a new heap object and
doesn't store an existing reference in the aggregate (presumably you
can also do the same sort of thing in Java?). This seems to be of
limited use.
In short, the developers of C# appear to have tried to fix the Java
problems, but didn't go far enough.
C++
---
o No specific reference types: all types can be referenced
+ Parameters can be passed by reference
+ Can put references inside aggregates
- There's no visibility at the point of call that an object
is to be passed by reference, unlike C#
Which appears to lead to a surprising conclusion: C++ (and C, if
you're prepared to deal with pointers) actually does it right. It
supports references completely, albeit with a syntax which possibly
isn't ideal. This also leads me to suspect that the division of types
into reference types and value types is essentially an implementation
convenience, and adds unnecessary user-level complexity.
Comments/corrections/additions?
-Charlie
Alf P. Steinbach
>
> Comments/corrections/additions?
You'll have to define more cleanly what you mean by "reference".
As it is you're mixing a lot of different concepts, comparing apples with
bananas. :-)
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
Pascal J. Bourguignon
> Thanks for the replies to "reference types, or pass-by-reference"
> thread; these prompted me to look at Java and C# in more detail
> (sorry, couldn't find the Algol docs!). With these and some more
> thought I've now got a better idea of what exactly the issue is, hence
> the new thread.
>
> Question: how do you cleanly add "references" to a language, in a way
> which is intuitive, and which is easy for a non-programmer to use and
> understand? I've compared how this is done in C++, Java, and C#
> (disclaimer: I only actually write C++, and my Java/C# comments may be
> wrong).
It seems to me that references help solving two different kinds of
problems. You mentionned originally only one:
- how to pass efficiently big objects to functions, without copying them.
The other thing references help solve is:
- how to modify a variable in the calling scope. This is what is
done with out or inout parameters (var parameters in pascal).
Since up to now your language had only pass by value, it was out of
the question to modify the variables in the calling scope.
So I would say that the best way to introduce references is to do so
obliviously. Don't mention them, it's an implementation detail.
On the other hand, mention to the user that certain value types are
mutable and certain values are immutable. When you pass a value to a
function, if it's of an immutable type, then internally you can make a
copy, it won't make a difference. If it's of a mutable type, then
internally you will pass a reference, and the user will be able to
mutate that value in the called function. Eg. it will be possible to
read, that is to mutate a stream.
And if you ever need to be able to modify variables in the calling
scope, then just define in, inout and out parameters, that is,
introduce explicit call-by-reference (inout or out) vs. call-by-value
(in) distinction, but only a the level of the parameter passing, not
as a new type. (eg. do as Pascal, Ada, etc do, not like C++). IMO,
there's no need for a special syntax at the call site. But some like
to be able to see at the call site that certain arguments are out or
inout arguments, without having to refer to the function signature.
So you could introduce the following syntax at the call site:
procedure increment(inout var:integer;in inc:integer) is
(* var is passed by reference; inc is passed by value *)
var:=var+inc;
end
var
x:integer:=42;
begin
(* call site: *)
increment(inout x,in 3*4);
end; (* ^^^^^ ^^ these keywords are optional,
but when present, must match the corresponding keyword
in the function signature. *)
--
__Pascal Bourguignon__
Harold Aptroot
news:ro5k359dpbf74s8rb...@4ax.com...
> [...]
> Comments/corrections/additions?
> [...]
C# also has a "ref" keyword (and "in" and "out" for refs that only go one
way).
You have to use it both in the function declaration and the invokation. So
it's always immediately clear that something that is normally a value type
is passed by reference instead.
It isn't even obscure syntax (to non-programmers), like & or * would be.
Might be worth considering
cr88192
> thread; these prompted me to look at Java and C# in more detail
> (sorry, couldn't find the Algol docs!). With these and some more
> thought I've now got a better idea of what exactly the issue is, hence
> the new thread.
>
> Question: how do you cleanly add "references" to a language, in a way
> which is intuitive, and which is easy for a non-programmer to use and
> understand? I've compared how this is done in C++, Java, and C#
> (disclaimer: I only actually write C++, and my Java/C# comments may be
> wrong).
>
my personal thought:
references are, sadly, needed IMO due to otherwise deficiencies in typical
programming language design (the lack of the possibility of multiple return
values).
personally, I would much rather have support for multiple return values (and
likely leave out references...).
example:
(x, y)=rotate(x, y, 45);
but, alas, references are more common and are the accepted way of doing
things...
> Observation #1: simply having the ability to pass a reference to a
> function is only half the problem. If your language has a reference
> concept, then you also need the ability to put references inside
> aggregate types (structs and arrays), since these might also be passed
> to a function.
>
IMO, not a good idea...
in this case, a reference is only marginally different than a pointer, and
one may as well use pointers in this case...
of course, a reference does come with a kind of inferrence that one will not
do pointer arithmetic with it, but leads to many other issues (likely funky
syntax to modify it, ... but this would also partly defeat the inherent
safety of references vs pointers...).
> Observation #2: passing a reference to a function, by *value*, is of
> limited value. This does give the function the ability to change the
> caller's object, but not to substitute it for another object. This
> appears to lead to confusion in Java, at least.
>
int &&v;
hmm...
> Observation #3: Ada-(and Algol?)-style in/out/inout parameters are, I
> think, sufficient for most function-level usage, without introducing
> the user-level complication of "references". The implementation of
> out/inout parameters could probably also fix the limitation in
> Observation #2 above.
>
the 'in/out/inout' notion is, IMO, more a way of crippling the notion such
that people don't start considering more contrieved uses...
granted, it works fairly well for this.
> Observation #4: Just having reference *types* isn't sufficient. This
> leads to problems like "how do I write a method to swap two integers
> in Java?", which involve bizarre work-arounds. If you have the ability
> to handle references, then you should also apply them to basic/numeric
> types.
>
> Java
> ----
>
> o Has both 'primitive' and 'reference' types
> - Everything passed by value (problem in #2 above)
> - Can't apply references to the primitive types (problem in #4 above)
> - Can't put references inside aggregates (problem in #1 above)
>
> which leads me to suspect that Java "references" are simply an
> implementation convenience, which are of limited value to the
> user. Could the same effect have been achieved by adding inout-mode
> parameters, with much less conceptual difficulty for the user?
>
this is possibly due to the JVM's internal design, which is a good deal
different than C++...
this should not be an issue, unless one is off implementing a JVM clone...
> C#
> --
>
> o Has both 'value' and 'reference' types
> + parameters can additionally be passed by reference
> (has both 'ref' and 'out'-mode parameters - why not
> 'inout' instead of 'ref')?
> - Can't put references inside aggregates (but see below)
>
> There's a bodge for putting references inside aggregates, which is to
> use boxing/unboxing. However, this creates a new heap object and
> doesn't store an existing reference in the aggregate (presumably you
> can also do the same sort of thing in Java?). This seems to be of
> limited use.
>
> In short, the developers of C# appear to have tried to fix the Java
> problems, but didn't go far enough.
>
loosely reminds me of old experience with certain MS BASIC varieties...
actually, BASIC had a way of messing up ones' mind, making one inherently
paranoid of argument passing madness and naturally going through extra
"paranoid" steps just to accomplish what languages like C do naturally (and
making for years of subsequent paranoia...).
> C++
> ---
>
> o No specific reference types: all types can be referenced
> + Parameters can be passed by reference
> + Can put references inside aggregates
> - There's no visibility at the point of call that an object
> is to be passed by reference, unlike C#
>
> Which appears to lead to a surprising conclusion: C++ (and C, if
> you're prepared to deal with pointers) actually does it right. It
> supports references completely, albeit with a syntax which possibly
> isn't ideal. This also leads me to suspect that the division of types
> into reference types and value types is essentially an implementation
> convenience, and adds unnecessary user-level complexity.
>
> Comments/corrections/additions?
>
C++ references are essentially pointers in disguise...
in C, you at least see what is a reference at the call site of an object
(well, usually, arrays and a few other things are passed by reference by
default, whereas there are times when I would rather have the option of
pass-by-value arrays...).
personally, I don't really see what the advantage of C++ style references
are, vs pointers, apart from the ability of being able to hide that it is a
reference (well, and make it a little harder to pass in a NULL). I am not
entirely certain that references are worthwhile though (apart from maybe in
a language which lacks pointers and multiple return values...).
> -Charlie
>
Ben Bacarisse
<snip>
> Observation #2: passing a reference to a function, by *value*, is of
> limited value. This does give the function the ability to change the
> caller's object, but not to substitute it for another object. This
> appears to lead to confusion in Java, at least.
For that you need to pass (by value) a reference to the reference.
> Observation #3: Ada-(and Algol?)-style in/out/inout parameters are, I
> think, sufficient for most function-level usage, without introducing
> the user-level complication of "references". The implementation of
> out/inout parameters could probably also fix the limitation in
> Observation #2 above.
I think this is what Pascal (the poster not the language) is
suggesting. You then make the reference mechanism implicit. This, of
course, does not allow you to use references elsewhere (i.e. as member
of structures).
> Observation #4: Just having reference *types* isn't sufficient. This
> leads to problems like "how do I write a method to swap two integers
> in Java?", which involve bizarre work-arounds. If you have the ability
> to handle references, then you should also apply them to basic/numeric
> types.
I am not sure why it is not sufficient. Obviously I can dream up
restrictions that mean they don't work properly, but what do you mean
by "just having them is not sufficient"?
<snip>
--
Ben.
Andrew Tomazos
> Question: how do you cleanly add "references" to a language, in a way
> which is intuitive, and which is easy for a non-programmer to use and
> understand?
You will get much better answers about programming language design at
comp.compilers.
-Andrew.
CBFalconer
> "Charlie Dawson" <cd4...@yahoo.com> wrote:
>
... snip ...
>
>> Question: how do you cleanly add "references" to a language, in
>> a way which is intuitive, and which is easy for a non-programmer
>> to use and understand? I've compared how this is done in C++,
>> Java, and C# (disclaimer: I only actually write C++, and my
>> Java/C# comments may be wrong).
>
> my personal thought:
> references are, sadly, needed IMO due to otherwise deficiencies in
> typical programming language design (the lack of the possibility
> of multiple return values).
>
> personally, I would much rather have support for multiple return
> values (and likely leave out references...).
>
> example:
> (x, y)=rotate(x, y, 45);
>
> but, alas, references are more common and are the accepted way of
> doing things...
Why? What's wrong with:
typedef struct fnret {int x, int y} fnret;
...
fnret rotate(fnret input) {
fnret retvalue;
...
return retvalue;
}
and everything can get checked.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Tony
Are you suuure? I thought that this is the NG for language design and
comp.compilers is about compiler implementation.
cr88192
"CBFalconer" <cbfal...@yahoo.com> wrote in message
news:4A3AC978...@yahoo.com...
technically, this would likely be how multiple return values would work
internally, but with the slight difference that the struct would be an
"implicit" part of the return value, and the reciever syntax will
essentially decompose the struct on return...
but, yes, what is proposed here would also work, it is just an inconvinient
syntax...
Andrew Tomazos
When you say "this" are you talking about comp.programming or
comp.lang.misc? comp.programming is about general programming
issues. comp.lang.misc is to discuss programming languages that dont
have their own comp.lang.* group.
Anyway, compiler construction and language design are generally fairly
conflatable.
-Andrew.
Tony
comp.lang.misc
I have been referred here at least once when asking a language design
question in the compiler group. I think I've been using the 2 groups that
way pretty much and haven't found objection. Certainly I'd have no need to
subscribe to comp.lang.misc for any other reason than to find info or
discuss language/library design and implementation and to compare/contrast
existing languages. And why WOULDN'T a language being developed be discussed
in c.l.m even by your description above?
Tony
> technically, this would likely be how multiple return values would
> work internally, but with the slight difference that the struct would
> be an "implicit" part of the return value, and the reciever syntax
> will essentially decompose the struct on return...
>
> but, yes, what is proposed here would also work, it is just an
> inconvinient syntax...
>
What do you have against the following rules about the written English
language:
The first word of a sentence begins with a capital letter.
A sentence ends with a period.
???
BartC
"Tony" <to...@my.net> wrote in message
news:aXI_l.1141$Rb6...@flpi147.ffdc.sbc.com...
> What do you have against the following rules about the written English
> language:
> A sentence ends with a period.
> cr88192 wrote:
>> ...
"Tony" <to...@my.net> wrote in message
news:aXI_l.1141$Rb6...@flpi147.ffdc.sbc.com...
> ???
What's the difference between using ... and ??? ?
--
Bart
Tony
> "Tony" <to...@my.net> wrote in message
> news:aXI_l.1141$Rb6...@flpi147.ffdc.sbc.com...
>
>> What do you have against the following rules about the written
>> English language:
>
The first word of a sentence begins with a capital letter.
>> A sentence ends with a period.
>
>> cr88192 wrote:
>>> ...
>
> "Tony" <to...@my.net> wrote in message
> news:aXI_l.1141$Rb6...@flpi147.ffdc.sbc.com...
>> ???
>
> What's the difference between using ... and ??? ?
I used '???' expressively one time as an emoticon-like thing while the other
poster annoyingly never obeys the above 2 English language rules in any of
his posts any of the time (not that the long length and "all over the map"
characteristics of his posts isn't equally annoying). (Surely I didn't have
to explain to you that overwhelming difference that is obvious to the most
casual observer, did I? :/ ).
Martin Eisenberg
> Observation #1: simply having the ability to pass a reference to
> a function is only half the problem. If your language has a
> reference concept, then you also need the ability to put
> references inside aggregate types (structs and arrays), since
> these might also be passed to a function.
Doess that follow? Why wouldn't it suffice to form a reference to the
whole aggregate when it gets passed?
> C#
> --
>
> o Has both 'value' and 'reference' types
> + parameters can additionally be passed by reference
> (has both 'ref' and 'out'-mode parameters - why not
> 'inout' instead of 'ref')?
The designers don't like Clockwork Orange.
Martin
--
Quidquid latine scriptum est, altum videtur.
cr88192
I write as I usually write.
I have usually written as I usually write.
"topic" is an ill-defined matter anyways.
usually enough is written so that what is needed to be written is expressed.
...
anyways, plenty of other people don't use capitalization in posts/emails
either (it is more a formality for when writing docs or papers or similar).
it can also be noted that I tend not to use other constructions which I
don't use, such as: 'jejeje', 'LOL'/'LOLZ', ...
it just seems awkward that one should have to use 2 different versions of
each word, when one version of a word is far more common than another.
or such...
>
Pascal J. Bourguignon
> anyways, plenty of other people don't use capitalization in posts/emails
> either (it is more a formality for when writing docs or papers or similar).
If plenty of other people are rude, it's not a reason for you to be rude too.
<insert standard lemnings question here>
--
__Pascal Bourguignon__
Richard Harter
Not capitalizing the initial letter of a sentence is a personal
idiosyncracy. Making snarky comments about someone doing it is
rude.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
If I do not see as far as others, it is because
I stand in the footprints of giants.
rossum
>A sentence ends with a period.
Depends on where you are writing. In the UK a sentence ends with a
full stop. "Period" is used in American English, not in English
English. :)
I am not sure about 'strine, Canadian English etc.
rossum
Tony
Should you decide to use the language and post in a non-annoying way, have
someone else post a message in the group a few times and maybe I'll see it
and remove your alias from my killfile. Buh-bye.
Bruce C. Baker
"cr88192" <cr8...@hotmail.com> wrote in message
news:h1gcs0$1ou$1...@news.albasani.net...
cr88192, what follows is meant as an OBSERVATION, not a CONDEMNATION:
Using a programming language requires adherence to the conventions imposed
by the language's designer, including but not limited to such things as
those annoying semicolons as separators/terminators and balanced braces '{'
and '}' in C-like languages.
What's surprising is that a person like you with a long history of designing
and implementing PLs appears to be so oblivious to the conventions of
written English.
Wouldn't it be easier and more consistent to apply the same self-discipline
to your prose as you do to your code?
Just a thought.
cr88192
"Bruce C. Baker" <b...@undisclosedlocation.net> wrote in message
news:RVW_l.27628$mX2....@newsfe05.iad...
I don't know...
I have just usually always written this way, and it seems like an odd
thought that I should do anything differently than I usually do so...
(I 'can' do things differently than usual, but usually not so often, as it
seems awkward/out of place to do so). it is much like how if someone sits in
one's spot, or tries to get one to wear a different color of clothes, or one
has to use a different type of fork than usual, ...
so, yeah, I have usually written this way.
>
>
Bruce C. Baker
Just a couple of things for your consideration:
1. When it comes to PLs, most if not all of your interaction with
like-minded people will be via what you post in these NGs. A good user
interface is important! :-)
2. Fair or not, people will judge the quality of your code according to the
quality of your prose.
cr88192
luckily then, I am now (anymore) mostly implementing already established
languages and technologies (apart from lesser-important internal parts...),
so not much need to promote much.
of course, this still leaves code, and I guess it can debated the value of
implementing things which could presumably be mostly assembled via (more
popular) 3rd party components, but oh well...
>
>
BartC
"Bruce C. Baker" <b...@undisclosedlocation.net> wrote in message
news:RVW_l.27628$mX2....@newsfe05.iad...
>
> news:h1gcs0$1ou$1...@news.albasani.net...
>> anyways, plenty of other people don't use capitalization in posts/emails
>> either (it is more a formality for when writing docs or papers or
>> similar). it can also be noted that I tend not to use other constructions
>> which I don't use, such as: 'jejeje', 'LOL'/'LOLZ', ...
>>
>> it just seems awkward that one should have to use 2 different versions of
>> each word, when one version of a word is far more common than another.
>>
>> or such...
>
> cr88192, what follows is meant as an OBSERVATION, not a CONDEMNATION:
>
> Using a programming language requires adherence to the conventions imposed
> by the language's designer, including but not limited to such things as
> those annoying semicolons as separators/terminators and balanced braces
> '{' and '}' in C-like languages.
C and C++ (perhaps also C#, Java and others) allow mixed letter case in
identifiers. I've seen code making so much use of capitals in the middle of
names that at first glance it looks like a Mime encoding of a binary. The
visual pattern you expect of English (even in programming code) is grossly
distorted.
I think if a programmer can deal with that, they won't have a problem with a
lower case letter at the start of a sentence. (And when I started
programming, everything was in capitals anyway.)
> What's surprising is that a person like you with a long history of
> designing and implementing PLs appears to be so oblivious to the
> conventions of written English.
They are just conventions. If you saw a vitally important or beneficial
message you wouldn't misunderstand it or reject it because one of the
letters was the wrong case (although it's better not to confuse mV and MV
for example).
> Wouldn't it be easier and more consistent to apply the same
> self-discipline to your prose as you do to your code?
There are many things a lot more annoying (such as using 'your' instead of
'you're', and many, many more).
--
bart
cr88192
"BartC" <ba...@freeuk.com> wrote in message
news:TQ2%l.45024$OO7...@text.news.virginmedia.com...
when I started programming, I was in elementary school.
I suspect my writing style partly "froze" sometime soon after, as I have
noticed before, it seems that my usenet posts from around my middle-school
and high-school years followed a very similar style (although, there are
differences, but they are more in terms of mood and psychology, and not much
in terms of writing style...).
I guess the awkwardness in my case is that I have gotten sufficiently used
to case sensitivity, that to me the capitalized and uncapitalized words
mentally register as different words, so using capitalization is similar to
having to regularly alternate between several different spellings.
I guess the issue in my case is that if I start capitalizing a word in one
place, there is a tendency to capitalize all uses of the word, and if a
non-capitalization word is used, the tendency is (apart from manual effort)
to leave other versions of the word uncapitalized.
I suspect visually I use the period as the sentance separator. I personally
have a much more difficult time reading if there are no periods or other
punctuation characters.
oddly, WRT English, it has been an observation that I tend to do much better
at tasks such as parts-of-speech labeling and organizing sentences into
grammar-trees than do many others who seem much better at reading and
writing (basically, I can do the POS marking and labelling at near my normal
reading rate, which is hindered primarily by having to mark things off on
paper...).
I have also noticed though that my skills at semantic disambiguation are not
always good though (I have sometimes gotten mentally stuck on rather 'odd'
interpretations of certain phrases, which usually disambiguate themselves
later...).
an example I can remember was when reading an article, and had gotten
confused over the term 'hand raised' (interpreting it as having ones' hand
raised), and then maybe half of the article later (and was confused by the
idea of birds having their hands' raised) managed to disambiguate it via a
substitution 'raised by hand'.
actually, in my case, when reading, these sorts of semantic-disambiguation
tasks tend to take up the majority of my thinking, and is typically far
worse for literary text than for informational text ('literature' burns out
my thinking, poetry is often incomprehensible, ...).
similarly, many people tend to dislike my attempts at writing fiction.
>> What's surprising is that a person like you with a long history of
>> designing and implementing PLs appears to be so oblivious to the
>> conventions of written English.
>
> They are just conventions. If you saw a vitally important or beneficial
> message you wouldn't misunderstand it or reject it because one of the
> letters was the wrong case (although it's better not to confuse mV and MV
> for example).
>
yep...
but mV and MV are different words, FWIW...
much like how MB and Mb are diffent, and mB and mb are invalid (except that
mb is mentally aliased to MB).
the difficulty though is using the same word in different cases. in my case,
it requires manual attention and slows down my writing speed, ... as a
result, I tend to reserve it mostly for papers and documentation and other
things.
>> Wouldn't it be easier and more consistent to apply the same
>> self-discipline to your prose as you do to your code?
>
> There are many things a lot more annoying (such as using 'your' instead of
> 'you're', and many, many more).
>
yep.
I have before noticed in spoken language that people use lots of
contractions and constructions which, if written and expanded as such, would
be rather awkward (such as "it's got", ...). I suspect in contracted form,
it is likely that the "'s" can refer to either "is" or "has".
> --
> bart
>
Pascal J. Bourguignon
> but mV and MV are different words, FWIW...
> much like how MB and Mb are diffent, and mB and mb are invalid (except that
> mb is mentally aliased to MB).
What do you have against millibytes and millibits?
And what do you do of the 8e9 factor between mb and MB?
--
__Pascal Bourguignon__
cr88192
"Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
news:87skhue...@galatea.local...
well, there is not so much concern over values which don't exist...
mb is mentally aliased to MB, as otherwise 'mb' is an invalid unit, but
sometimes people write this when they mean MB. it is much like how some
people write 'kb' and 'KB' as well, when they mean 'kB'.
if one really wants to be fussy, they can distinguish these from
'KiB'/'MeB'/'GiB' as well, but alas, people will continue to write MB and GB
in cases where MeB and GiB would be more technically correct, but hell, this
is the common convention...
>
> --
> __Pascal Bourguignon__
Pascal J. Bourguignon
> "Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
> news:87skhue...@galatea.local...
>> "cr88192" <cr8...@hotmail.com> writes:
>>> but mV and MV are different words, FWIW...
>>> much like how MB and Mb are diffent, and mB and mb are invalid (except
>>> that
>>> mb is mentally aliased to MB).
>>
>> What do you have against millibytes and millibits?
>> And what do you do of the 8e9 factor between mb and MB?
>>
>
> well, there is not so much concern over values which don't exist...
>
> mb is mentally aliased to MB, as otherwise 'mb' is an invalid unit, but
mb is not an invalid unit. It is well defined, both formally and
semantically. Fraction of bit is a notion perfectly valid.
> sometimes people write this when they mean MB.
And sometimes people don't capitalize their phrases.
Either things are not to be condoned.
--
__Pascal Bourguignon__
BartC
>
> "BartC" <ba...@freeuk.com> wrote in message
> news:TQ2%l.45024$OO7...@text.news.virginmedia.com...
>>
>> "Bruce C. Baker" <b...@undisclosedlocation.net> wrote in message
>> news:RVW_l.27628$mX2....@newsfe05.iad...
>>> Using a programming language requires adherence to the conventions
>>> imposed
>>> by the language's designer, including but not limited to such things as
>>> those annoying semicolons as separators/terminators and balanced braces
>>> '{' and '}' in C-like languages.
>>
>> C and C++ (perhaps also C#, Java and others) allow mixed letter case in
>> identifiers. I've seen code making so much use of capitals in the middle
>> of
>> names that at first glance it looks like a Mime encoding of a binary. The
>> visual pattern you expect of English (even in programming code) is
>> grossly
>> distorted.
>>
>> (And when I started programming, everything was in capitals anyway.)
> when I started programming, I was in elementary school.
> I guess the awkwardness in my case is that I have gotten sufficiently used
> to case sensitivity, that to me the capitalized and uncapitalized words
> mentally register as different words, so using capitalization is similar
> to having to regularly alternate between several different spellings.
You must have had too much exposure to C, and from early on. I never saw any
sort of code until I was 20, and that as I said was all-caps.
I find case-sensitivity in a PL completely unnatural. I do however prefer my
words in forms like ABCD, Abcd and abcd (like most people I guess), anything
else looks odd, and when C insists they are completely different too, that
seems plain Wrong.
Fortunately the real world (outside computers) is still case-insensitive
(like all of my PLs); reassuringly, a doG still barks and a cAt still miaows
(at least until someone hijacks a word for some silly acronym, then the
all-caps version becomes ambiguous).
> poetry is often incomprehensible, ...).
(Yeah, they can burn the lot of it as far as I'm concerned.)
--
Bart
Dmitry A. Kazakov
> "cr88192" <cr8...@hotmail.com> writes:
>
>> "Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
>> news:87skhue...@galatea.local...
>>> What do you have against millibytes and millibits?
>>> And what do you do of the 8e9 factor between mb and MB?
>>
>> well, there is not so much concern over values which don't exist...
>>
>> mb is mentally aliased to MB, as otherwise 'mb' is an invalid unit, but
>
> mb is not an invalid unit.
There is no SI unit 'b'. BTW, 'B' is Bel, though, not a SI unit sometimes
used with SI prefixes, like dB. 8 MB must be damn loud! (:-))
> It is well defined, both formally and semantically
bit is not a physical unit.
A possible definition as binary logarithm of the number of possible
[equivalent] states is unitless in any unit system, SI included.
> Fraction of bit is a notion perfectly valid.
Only when 2**x is even. It is like negative temperatures (< 0K) or
velocities greater than c.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
BartC
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:1naq3fmevtgin$.1gnq609fbb2gz$.dlg@40tude.net...
What's the average number of bits in these fields of: 1, 2, 4, 8 bits?
I make it 3.75 bits.
--
Bart
Dmitry A. Kazakov
There is no average of things that aren't additive. Bits are additive under
certain conditions, which do not hold in your example. Compare, there are
coins in your pocket of 1, 2, 5, 10, 20, 50 cents. What is the average
coin?. The answer is, there is no such thing.
BartC
But the average value of the coins would be 14 2/3 cents. If a million
people had exactly those six coins in their pockets, and each dug one out at
random to put into a charity box, you might estimate the total collected to
be around $146700.
(A quick check, since this random stuff is sometimes counter-intuitive:
coins:=(1,2,5,10,20,50)
sum:=0
to 1000000 do
sum+:=coins[random(1..6)]
od
println "Sum=",sum/100
Output:
Sum= 146760.940000)
--
Bart
Nick Keighley
> Thanks for the replies to "reference types, or pass-by-reference"
> thread; these prompted me to look at Java and C# in more detail
> (sorry, couldn't find the Algol docs!).
http://www.masswerk.at/algol60/report.htm
--
Nick Keighley
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:1m0xii2zopogr$.15u327psgb447.dlg@40tude.net...
>> On Sun, 21 Jun 2009 11:37:47 GMT, BartC wrote:
>>
>>> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
>>> news:1naq3fmevtgin$.1gnq609fbb2gz$.dlg@40tude.net...
>>>> On Sat, 20 Jun 2009 23:32:08 +0200, Pascal J. Bourguignon wrote:
>>>
>>>>> Fraction of bit is a notion perfectly valid.
>>>>
>>>> Only when 2**x is even. It is like negative temperatures (< 0K) or
>>>> velocities greater than c.
>>>
>>> What's the average number of bits in these fields of: 1, 2, 4, 8 bits?
>>>
>>> I make it 3.75 bits.
>>
>> There is no average of things that aren't additive. Bits are additive under
>> certain conditions, which do not hold in your example. Compare, there are
>> coins in your pocket of 1, 2, 5, 10, 20, 50 cents. What is the average
>> coin?. The answer is, there is no such thing.
>
> But the average value of the coins would be 14 2/3 cents.
The nominal value of coin /= coin. Values can be averaged as numbers. The
result of averaging (and any other numeric operation) may have some sense
or not. That depends on the "physics of coins".
> If a million
> people had exactly those six coins in their pockets, and each dug one out at
> random to put into a charity box, you might estimate the total collected to
> be around $146700.
But you were unable to split the takings into one million equal coins.
cr88192
I think I was probably somewhat exposed to C since at least maybe 4th grade
or so, but didn't really switch over (primarily) to C until maybe around
middle school (7th/8th grade...). the "C transition" was also helped along
since at the time I migrated to Linux as my primary OS, and so BASIC was no
longer available.
before this, I had used C and ASM more for attempts at "serious" code, but
BASIC more because it was better at quickly beating things together to
perform various tasks (I forget the details now, but I remember there were
also means available from which to interface with ASM code from BASIC).
in the 6th/7th grade timeframe I used a mix of BASIC, C, and assembler.
4th/5th was mostly messing around with BASIC.
(I also remember now that I could read in the 2nd/3rd grade timeframe,
whereas I remember many of the other people at the time being effectively
illiterate...).
in the mix, I guess I learned to "see" upper and lower-case letters as
essentially different symbols.
> I find case-sensitivity in a PL completely unnatural. I do however prefer
> my words in forms like ABCD, Abcd and abcd (like most people I guess),
> anything else looks odd, and when C insists they are completely different
> too, that seems plain Wrong.
>
yes, ok.
guess you probably especially wouldn't like looking at things named with
base-64 names...
> Fortunately the real world (outside computers) is still case-insensitive
> (like all of my PLs); reassuringly, a doG still barks and a cAt still
> miaows (at least until someone hijacks a word for some silly acronym, then
> the all-caps version becomes ambiguous).
>
ok.
I had before done some linguistics stuff (and later speech synth, ...), and,
oddly, I have tended to use case-sensitive phonetics systems. typically they
are ASCII based (because stuff like the IPA is essentially untypable, and
use of non-ASCII chars is awkward).
my photetic representation typically combines upper and lower-case letters
(each mapped to different sounds), but differs primarily from things like
SAMPA in that I generally avoid using any non-letter characters (the reason
being that I might actually want to mix in non-phonetic syntax, and it
doesn't help if most of the other possible chars are used for phonetics as
well).
another scheme exists (case insensitive) which is mostly used for external
file naming (since Windows uses case-insensitive file-naming, ...), where
this system is mostly derived from the one used in Festival (from which I
had "borrowed" some amount of data...).
>> poetry is often incomprehensible, ...).
>
> (Yeah, they can burn the lot of it as far as I'm concerned.)
>
ok.
I don't care much about it personally, only I can't really read or
understand it.
> --
> Bart
Nick Keighley
wrote:
> Charlie Dawson <cd4...@yahoo.com> writes:
> > Thanks for the replies to "reference types, or pass-by-reference"
> > thread; these prompted me to look at Java and C# in more detail
> > thought I've now got a better idea of what exactly the issue is, hence
> > the new thread.
>
> > Question: how do you cleanly add "references" to a language, in a way
> > which is intuitive, and which is easy for a non-programmer to use and
> > understand? I've compared how this is done in C++, Java, and C#
> > (disclaimer: I only actually write C++, and my Java/C# comments may be
> > wrong).
>
> It seems to me that references help solving two different kinds of
> problems. You mentionned originally only one:
>
> - how to pass efficiently big objects to functions, without copying them.
>
> The other thing references help solve is:
>
> - how to modify a variable in the calling scope. This is what is
> done with out or inout parameters (var parameters in pascal).
>
> Since up to now your language had only pass by value, it was out of
> the question to modify the variables in the calling scope.
>
> So I would say that the best way to introduce references is to do so
> obliviously. Don't mention them, it's an implementation detail.
>
> On the other hand, mention to the user that certain value types are
> mutable and certain values are immutable. When you pass a value to a
> function, if it's of an immutable type, then internally you can make a
> copy, it won't make a difference. If it's of a mutable type, then
> internally you will pass a reference, and the user will be able to
> mutate that value in the called function. Eg. it will be possible to
> read, that is to mutate a stream.
>
> And if you ever need to be able to modify variables in the calling
> scope, then just define in, inout and out parameters, that is,
> introduce explicit call-by-reference (inout or out) vs. call-by-value
> (in) distinction, but only a the level of the parameter passing, not
> as a new type. (eg. do as Pascal, Ada, etc do, not like C++). IMO,
> there's no need for a special syntax at the call site. But some like
> to be able to see at the call site that certain arguments are out or
> inout arguments, without having to refer to the function signature.
<snip>
I was going to write something like you wrote. Especially
distinguishing
the ability to pass large objects verses modifiable objects. But
you've
already done it. And done it better.
If you're writing a language for non-programmers then pointers
and explicit C++ style references are a mistake. This is
exposing the machine which they don't need.
--
Nick Keighley
James Harris
...
> > Are you suuure? I thought that this is the NG for language design and
> > comp.compilers is about compiler implementation.
>
> When you say "this" are you talking about comp.programming or
> comp.lang.misc? comp.programming is about general programming
> issues. comp.lang.misc is to discuss programming languages that dont
> have their own comp.lang.* group.
It's pretty rare to see comp.lang.misc used for existing languages.
Generally it's used by designers and carries discussions on language
design. That sometimes includes compiling. It is unmoderated.
AIUI comp.compilers is principally about compilers. It is moderated.
> Anyway, compiler construction and language design are generally fairly
> conflatable.
True. There's no hard and fast rule to split them. The moderator of
comp.compilers may limit discussions on the design side, though.
James
Nick Keighley
wrote:
> "cr88192" <cr88...@hotmail.com> wrote in message
>
> news:h1gcs0$1ou$1...@news.albasani.net...
>
>
>
>
>
>
>
> > "Tony" <t...@my.net> wrote in message
> >news:ksL_l.143$cl4...@flpi150.ffdc.sbc.com...
> >> BartC wrote:
> >>> "Tony" <t...@my.net> wrote in message
> >>>news:aXI_l.1141$Rb6...@flpi147.ffdc.sbc.com...
>
> >>>> What do you have against the following rules about the written
> >>>> English language:
>
> >> The first word of a sentence begins with a capital letter.
>
> >>>> A sentence ends with a period.
>
> >>>> cr88192 wrote:
> >>>>> ...
>
There are different levels of formality suitable for different
circumstances.
I write technical documents from time to time. They are in a different
style from emails I exchange with collegues. If I write a program I
am aware I am going to adhere to a greater degree of formality
than if I am in conversation with my young neice.
I admit to double standards here. Text message abbreviations
irriate me; but dropping the odd capital letter seems down in the
noise.
--
Nick Keighley
Nick Keighley
wrote:
> On Sun, 21 Jun 2009 11:37:47 GMT, BartC wrote:
> >news:1naq3fmevtgin$.1gnq609fbb2gz$.dlg@40tude.net...
> >> On Sat, 20 Jun 2009 23:32:08 +0200, Pascal J. Bourguignon wrote:
>
> >>> Fraction of bit is a notion perfectly valid.
>
> >> Only when 2**x is even. It is like negative temperatures (< 0K) or
> >> velocities greater than c.
>
> > What's the average number of bits in these fields of: 1, 2, 4, 8 bits?
>
> > I make it 3.75 bits.
>
> There is no average of things that aren't additive. Bits are additive under
> certain conditions, which do not hold in your example. Compare, there are
> coins in your pocket of 1, 2, 5, 10, 20, 50 cents. What is the average
> coin?. The answer is, there is no such thing.
I sure communications theorists can handle fractions of a bit.
For instance the wikipage on information theory entropy
has this to say
"The entropy rate of English text is between 1.0 and 1.5 bits per
letter,[1]
or as low as 0.6 to 1.3 bits per letter, according to estimates by
Shannon
based on human experiments.[2]"
--
Nick Keighley
Dmitry A. Kazakov
> On 21 June, 16:29, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sun, 21 Jun 2009 11:37:47 GMT, BartC wrote:
>>> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message
>>>news:1naq3fmevtgin$.1gnq609fbb2gz$.dlg@40tude.net...
>>>> On Sat, 20 Jun 2009 23:32:08 +0200, Pascal J. Bourguignon wrote:
>>
>>>>> Fraction of bit is a notion perfectly valid.
>>
>>>> Only when 2**x is even. It is like negative temperatures (< 0K) or
>>>> velocities greater than c.
>>
>>> What's the average number of bits in these fields of: 1, 2, 4, 8 bits?
>>
>>> I make it 3.75 bits.
>>
>> There is no average of things that aren't additive. Bits are additive under
>> certain conditions, which do not hold in your example. Compare, there are
>> coins in your pocket of 1, 2, 5, 10, 20, 50 cents. What is the average
>> coin?. The answer is, there is no such thing.
>
> I sure communications theorists can handle fractions of a bit.
In exactly same way as specialists on thermodynamic could handle fractions
of a molecule...
> For instance the wikipage on information theory entropy
> has this to say
> "The entropy rate of English text is between 1.0 and 1.5 bits per
> letter,[1]
> or as low as 0.6 to 1.3 bits per letter, according to estimates by
> Shannon based on human experiments.[2]"
Information theory is a part of mathematical statistics. The subject of
mathematical statistics is group behavior of [random] events. This subject
and so statistics ends at the individual event, not talking about any
fractions of it.
Look at the wikipage for bit. It explicitly differentiates 'bit' and
'shannon'.
Richard Harter
Actually it distinguishes two different meanings for the word,
'bit', and notes that the term, 'shannon' is *sometimes* used for a
statistical bit when "these two ideas need to be distinguished".
In my experience the use of the term, 'shannon', is quite rare. As
wikipedia goes on to note, "However, most of the time, the meaning
is clear from the context."
Dmitry A. Kazakov
Right, the bit of storage has nothing to do with statistical information
theory. When entropy is introduced it is done in the context of a certain
statistical model. That is unrelated to either storage or
knowledge/information. You can have 0.5 of entropy, but there is no 0.5
storage bit and no any additive (moreover numeric) measure of
knowledge/information in their traditional sense.
Richard Harter
<mai...@dmitry-kazakov.de> wrote:
Well, you can huff and puff all you like, but it remains that the
term "bit" is used in both senses, the usage is standard, and it is
convenient.
Tony
I've not eliminated the possibility that he could be doing drugs when he
posts: there seems to be some kind of euphoric all-over-the-map-ness beyond
the indicative immaturity to his posts.
Tony
> "cr88192" <cr8...@hotmail.com> wrote in message
> news:h1j3v5$h98$1...@news.albasani.net...
>>
>> "BartC" <ba...@freeuk.com> wrote in message
>> news:TQ2%l.45024$OO7...@text.news.virginmedia.com...
>>>
>>> "Bruce C. Baker" <b...@undisclosedlocation.net> wrote in message
>>> news:RVW_l.27628$mX2....@newsfe05.iad...
>
>
>>>> Using a programming language requires adherence to the conventions
>>>> imposed
>>>> by the language's designer, including but not limited to such
>>>> things as those annoying semicolons as separators/terminators and
>>>> balanced braces '{' and '}' in C-like languages.
>>>
>>> C and C++ (perhaps also C#, Java and others) allow mixed letter
>>> case in identifiers. I've seen code making so much use of capitals
>>> in the middle of
>>> names that at first glance it looks like a Mime encoding of a
>>> binary. The visual pattern you expect of English (even in
>>> programming code) is grossly
>>> distorted.
>>>
>>> (And when I started programming, everything was in capitals anyway.)
>
>> when I started programming, I was in elementary school.
Tom Pettie could live to be 3000, and he still would have an annoying voice
akin to fingernails on a chalkboard.
Tony
> C and C++ (perhaps also C#, Java and others) allow mixed letter case
> in identifiers. I've seen code making so much use of capitals in the
> middle of names that at first glance it looks like a Mime encoding of
> a binary. The visual pattern you expect of English (even in
> programming code) is grossly distorted.
>
> I think if a programmer can deal with that, they won't have a problem
> with a lower case letter at the start of a sentence. (And when I
> started programming, everything was in capitals anyway.)
If you're trying to make a case to justify the transcoding English into a
programming language-like code, you're soooo gonna lose that case (duh, goes
without saying).
>
>> What's surprising is that a person like you with a long history of
>> designing and implementing PLs appears to be so oblivious to the
>> conventions of written English.
>
> They are just conventions. If you saw a vitally important or
> beneficial message you wouldn't misunderstand it or reject it because
> one of the letters was the wrong case (although it's better not to
> confuse mV and MV for example).
It's not a question of extremes. It's one thing to accept someone's broken
English if they don't know the language, but to continue an annoying
phonetic or such for unnecessary reason is... at one's own peril.
>
>> Wouldn't it be easier and more consistent to apply the same
>> self-discipline to your prose as you do to your code?
>
> There are many things a lot more annoying (such as using 'your'
> instead of 'you're', and many, many more).
No your wrong. (Purposely written). Annoying is the following
".... and....
, but...
and then !,
...
So, see?"
To which I respond: you're now on ignore if you write or talk like that all
the time.
Tony
> On 19 June, 10:01, Andrew Tomazos <and...@tomazos.com> wrote:
>
> ...
>
>>> Are you suuure? I thought that this is the NG for language design
>>> and comp.compilers is about compiler implementation.
>>
>> When you say "this" are you talking about comp.programming or
>> comp.lang.misc? comp.programming is about general programming
>> issues. comp.lang.misc is to discuss programming languages that dont
>> have their own comp.lang.* group.
>
> It's pretty rare to see comp.lang.misc used for existing languages.
> Generally it's used by designers and carries discussions on language
> design. That sometimes includes compiling. It is unmoderated.
>
> AIUI comp.compilers is principally about compilers. It is moderated.
Thanks for the confirmation that I'm not insane. I've moved a step backward
in my language development recently. I see the first project that CAN be
well-defined and MUST be defined for any "clean slate" programming language
development.
>
>> Anyway, compiler construction and language design are generally
>> fairly conflatable.
>
> True. There's no hard and fast rule to split them. The moderator of
> comp.compilers may limit discussions on the design side, though.
Certainly, more than once, when I got heavy into language design issues,
someone has suggested that comp.compilers would be a rather limited forum to
post the question for discussion.
cr88192
"Tony" <to...@my.net> wrote in message
news:6ph0m.3594$Rb6....@flpi147.ffdc.sbc.com...
> Nick Keighley wrote:
>> On 20 June, 02:28, "Bruce C. Baker" <b...@undisclosedlocation.net>
>> wrote:
<snip>
>>
>> There are different levels of formality suitable for different
>> circumstances.
>> I write technical documents from time to time. They are in a different
>> style from emails I exchange with collegues. If I write a program I
>> am aware I am going to adhere to a greater degree of formality
>> than if I am in conversation with my young neice.
>>
>> I admit to double standards here. Text message abbreviations
>> irriate me; but dropping the odd capital letter seems down in the
>> noise.
>
> I've not eliminated the possibility that he could be doing drugs when he
> posts: there seems to be some kind of euphoric all-over-the-map-ness
> beyond the indicative immaturity to his posts.
>
well, who knows...
I am left to speculate if the other person in question here is an ENTP or
xSTP or something, for bothering to raise these sorts of issues.
experience would point this way...
cr88192
(I meant here the person who was not myself, I know where I am at, and I can
be fairly certain I am not any ENTP, although at least the E and T would
still match...) .
>