1. RE: A question about certain language features
tone.skoda at siol.net wrote:
> Euphoria is almost perfect programming language as it is now.
> It only needs a simple OOP addition.
> Of course, debuger and editor with IDE also are missing, but that is not
> part of language itself.
I appreciate your feelings, but I'm not sure what this has
to do with my original message/questions?
> Why call by reference, becuase VB has it?
I've never used VB. I have used C, C++, Pascal, Modula 2
and Oberon, all of which feature call by reference (well, in
C you have to use pointers, but it amounts to the same thing
in actual use).
> It is complicated feature, I don't need it.
I am happy for you. However, that was not the point. I was
simply wondering why it was not included. I've read that
functional languages don't allow call by reference because
of the side effect factor. But they also (I'm not a
functional language expert - this is based on my readings of
the subject) don't allow assignment to global variables from
a subroutine, because it is a also a side effect. So, I'm
simply wandering why Euphoria's author choose not to allow
call by reference. Is it a style issue, a good programming
issue, is he trying to emulate some tenet of functional
programming, etc.
> I don't need goto either.
Good for you. But I did not ask about goto.
> Variables can not be initialized when declared, that is ok.
That may be. But I did not ask if it was 'ok', I simply
asked why it is not allowed. Is initializing a variable
when it is declared a 'bad thing'? It is supported in other
languages I have used, and so I was wondering why not in
Euphoria.
> Local constants are really not needed.
True. But again, I simply asked why the feature was not
supported.
> Things I most like with Euphoria: simplicity, sequences, type checking,
> no
> waiting for compilation, speed...
Again, I am glad you like it, I like Euphoria also. But
that is not what I was asking about.
And to make sure I'm clear - I'm not asking for these
features to be added to Euphoria.
For instance, I can see why the author would not choose to
add a goto to Euphoria. Many programmers realize that
goto's, used unwisely, can cause hard to
follow/maintain/prove correct code.
I'm simply trying to understand if in general the author
feels that call by reference, variable initialization on
declaration, and locally declared Euphoria constants are bad
things, or would lead to poor programming style, or what
have you.
If I know why these things are not allowed, who knows,
perhaps I will adopt this style for my own use in the other
languages I program in.
>
> ----- Original Message -----
> From: "Ed Davis" <ed_davis2 at yahoo.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Monday, February 11, 2002 5:39 PM
> Subject: A question about certain language features
>
>
> > I've been reading the Euphoria documentation, and I have a
> > few questions about certain features of the language.
> >
> > I assume that the author made certain choices because he
> > felt that this encouraged a better way of programming. I
> > don't want to start (or continue) an argument about this per
> > se, but I would like to try and understand the reasoning.
> > For instance, without debating their merit, I can understand
> > the author leaving out the goto statement, as abuse of goto
> > can lead to hard-to-read and hard-to-prove-correct code. Of
> > course, the converse is possibly true too.
> >
> > The features I have questions about as to why there were
> > implemented that way are:
> >
> > 1) Variables can not be initialized when declared, but
> > rather, must be initialized via an assignment statement.
> > Based on other languages, this seems like one of those
> > convenience type issues. Is there some programming
> > philosophy that says that an initialization in a declaration
> > is a 'bad thing'? What is the 'bad thing'? I also note
> > that standard Pascal does not allow variables to be
> > initialized when they are declared.
> >
> > 2) No support of call by reference. I understand that call
> > by reference can lead to unexpected side-effects, but since
> > changing global variables in a subroutine seems to
> > essentially cause the same problem, I don't understand this
> > omission.
> >
> > 3) No support for local constants.
> >
> > Again, I'm not trying to start a debate, I'm just trying to
> > understand why these features/omissions are desirable.
> >
> > Thanks for any information!
> >
> >
2. RE: A question about certain language features
> Call-by-reference isn't used much, but when it is, it makes code
> both simpler and clearer: Compare:
>
> swap(A,B)
>
> with our available alternative:
> object tmp
> tmp = A
> A = B
> B = tmp
>
> > > It is complicated feature, I don't need it.
>
> Not at all complicated. And it doesn't cause errors, because (in Pascal,
> for
> example) it must be specifically and consciously enabled in the
> function
> header.
Functional languages don't allow call by reference, because
it can cause unexpected side-effects. I wonder if Euphoria
borrows from that philosophy?
> > > Variables can not be initialized when declared, that is ok.
> >
> > That may be. But I did not ask if it was 'ok', I simply
> > asked why it is not allowed. Is initializing a variable
> > when it is declared a 'bad thing'? It is supported in other
> > languages I have used, and so I was wondering why not in
> > Euphoria.
>
> If it is a bad thing, then does that not make constant declarations
> equally
> bad?
I don't know if it is a 'bad thing' or not. That is what
I'm trying to find out!
Note that the 'standard' definitions of Pascal, Modula-2,
and Oberon, do not allow variables to be initialized when
they are declared, just like Euphoria. So Professor Wirth
perhaps thinks it is a bad thing? I have read several of
his books dealing with the mentioned languages, but I have
not been able to find a justification for not allowing
variables to be initialized when declared.
But there must be a reason. I can't believe it is just an
arbitrary restriction.
> > And to make sure I'm clear - I'm not asking for these
> > features to be added to Euphoria.
> >
> > For instance, I can see why the author would not choose to
> > add a goto to Euphoria. Many programmers realize that
> > goto's, used unwisely, can cause hard to
> > follow/maintain/prove correct code.
> >
> > I'm simply trying to understand if in general the author
> > feels that call by reference, variable initialization on
> > declaration, and locally declared Euphoria constants are bad
> > things, or would lead to poor programming style, or what
> > have you.
> >
> > If I know why these things are not allowed, who knows,
> > perhaps I will adopt this style for my own use in the other
> > languages I program in.
>
> Other than the goto, I've never seen any textbook that condemns
> these things. All that any of them can do is contribute to code clarity.
> As to why they're not in Euphoria, along with a number of other things
> which would add convenience while improving and simplifying code,
> only Rob can answer.
Thanks for your reply! Perhaps the author will chime in?
But I can appreciate that he is probably pretty busy,
especially with the new release.
3. RE: A question about certain language features
> > 1) Variables can not be initialized when declared, but
> > rather, must be initialized via an assignment statement.
> > Based on other languages, this seems like one of those
> > convenience type issues. Is there some programming
> > philosophy that says that an initialization in a declaration
> > is a 'bad thing'? What is the 'bad thing'? I also note
> > that standard Pascal does not allow variables to be
> > initialized when they are declared.
>
> There is good article by Travis Beaty about this point.
> Visit please:
> http://www.RapidEuphoria.com/hotnew.htm
> There is the link to that article in this html.
Hmmm. I read the article, but I still don't understand why:
function foo()
integer a
a = someNastyComputation()
-- lots of code that massages a snipped
return a
end function
is ok, whereas:
function foo()
integer a = someNastyComputation()
-- lots of code that massages a snipped
return a
end function
is 'dangerous'? (if it were allowed, which it is not)
> > 2) No support of call by reference. I understand that call
> > by reference can lead to unexpected side-effects, but since
> > changing global variables in a subroutine seems to
> > essentially cause the same problem, I don't understand this
> > omission.
>
> No any side-effects here with the *globals*. If you'll
> reference to gobal name from inside subroutine, then you
> change just that variable. Private variable name override
> global and local names inside subroutine and exists
> only inside subroutine.
integer a, b
function foo()
a = 5
return 6
end function
a = 1
b = foo() + a
See what I mean? Even though call by reference is not
allowed, you can still have unexpected side effects, because
global (e.g., not local to a subroutine) variables can be
modified inside a subroutine.
> > 3) No support for local constants.
>
> There *is* full support for local constants in Euphoria.
> Terms are: global - for a different files scope,
> local -- just for single file scope, private -- just for
> current subroutine scope.
> *Private* constants are not supported, becouse of *all*
> private variables exist just inside soubroutine.
> Local constants are very useful for cross-routine use
> inside the library file. Say, you have global functions in
> the include file. You can set *local* constants just for
> those global functions just inside single lib.
>
> See and try Local <--> Private <--> Global,
> thing looks just like to the real life.
I think we are not talking about the same thing. I am
referring to the reference manual, which says, in section
2.4.1, under heading "constants":
"Constants may not be declared inside a subroutine."
Thanks for your reply!
4. RE: A question about certain language features
Robert Craig wrote:
> Ed Davis writes:
<Questions/answers about certain language features snipped>
Thanks for the detailed explanations. Especially after
seeing your examples, I tend to agree that you have made the
right choices.
And I definitely agree that simplicity is a worthy goal.
I guess it all boils down to when you pay the price. Some
of the features in question definitely make it easier to
write code quickly, without as much thought or preparation.
But, one may end up spending a long time debugging the same
hastily written code.
I'd rather pay the price at design time rather than during
debug time. But because I'm lazy, I usually resist the
design stage, and want to get right to the coding. Hence
the questions. Maybe one day I'll learn to always say no to
just start coding, without first a little design.
5. RE: A question about certain language features
Mike Nelson wrote:
> Ed Davis wrote:
>
> <snip>
Thanks for the detailed reply.
Based on yours and Rob's explanation, I can see the point of
omitting the features in question.
It may be a little harder to code the Euphoria way, but I
can appreciate the argument that it can make the code
possibly cleaner and easier to understand. Lots of programs
last a long time, so anything to make them easier to follow
months or years later is a good thing.
6. RE: A question about certain language features
Ed Davis wrote:
> > > 1) Variables can not be initialized when declared, but
> > > rather, must be initialized via an assignment statement.
> > > Based on other languages, this seems like one of those
> > > convenience type issues. Is there some programming
> > > philosophy that says that an initialization in a declaration
> > > is a 'bad thing'? What is the 'bad thing'? I also note
> > > that standard Pascal does not allow variables to be
> > > initialized when they are declared.
> >
> > There is good article by Travis Beaty about this point.
> > Visit please:
> > http://www.RapidEuphoria.com/hotnew.htm
> > There is the link to that article in this html.
>
> Hmmm. I read the article, but I still don't understand why:
>
> function foo()
> integer a
> a = someNastyComputation()
> -- lots of code that massages a snipped
> return a
> end function
>
> is ok, whereas:
>
> function foo()
> integer a = someNastyComputation()
> -- lots of code that massages a snipped
> return a
> end function
>
> is 'dangerous'? (if it were allowed, which it is not)
???
Correct me if I'm wrong, but hasn't Euphoria supported that since
version 2.2? (I'm not certain, I haven't made use of it. Just
preference.)
<snip>
> > > 3) No support for local constants.
> >
> > There *is* full support for local constants in Euphoria.
> > Terms are: global - for a different files scope,
> > local -- just for single file scope, private -- just for
> > current subroutine scope.
> > *Private* constants are not supported, becouse of *all*
> > private variables exist just inside soubroutine.
> > Local constants are very useful for cross-routine use
> > inside the library file. Say, you have global functions in
> > the include file. You can set *local* constants just for
> > those global functions just inside single lib.
> >
> > See and try Local <--> Private <--> Global,
> > thing looks just like to the real life.
>
> I think we are not talking about the same thing. I am
> referring to the reference manual, which says, in section
> 2.4.1, under heading "constants":
>
> "Constants may not be declared inside a subroutine."
You can have local constants. Just do:
constant MY_CONST = 1
outside of a routine. This limits it to the include file that it's in,
so it's not global. However, *private* constants, declared and scoped
only within a routine, are NOT allowed.
I'm not sure why. Wouldn't seem to be any worse than a private variable.
Although I would think you'd have to have a fairly large routine to use
a constant in it that wouldn't be used in other routines.
Rod Jackson
7. RE: A question about certain language features
Derek Parnell wrote:
> For example, I seriously wish the win32lib.ew did not have all
> those onXXX sequences globally available. It has made serious
> issues with expanding its functionality.
Uh, since when has backward compatibility been an issue with a product
that hasn't even been "released" yet? I say ONWARD with efficiency...
damn the past! damn the broken code! They all know that it is
pre-release alpha/beta code!
Just my $0.02. Where's my change?
> cannot assume inside the library that somebody using the library
> hasn't altered the values at any time.
Don't worry about what's been done, because it's not in concrete yet
anyway... or izzit? Change up the library and gives us something sleek
and efficient if you want. That's the nature of technological
advancement.
8. RE: A question about certain language features
- Posted by bensler at mail.com
Mar 21, 2002
Karl,
Consider this syntax for shorthand slicing. Your current syntax sort
of defeats the sequence bounds checking.
seq[1..0] -- seq[1..length(seq)]
seq[1..0-1] -- seq[1..length(seq)-1]
seq[1..1-1] -- {} (reverse slice)
seq[1..-1] -- index [-1] out of bounds
integer index index=0
seq[1..index] -- {} (reverse slice)
'O' is explicit, it cannot be implied. If it is, the original EU rules
apply.
I haven't thouroughly looked. Does your shorthand work if it's implied
with a variable?
Chris
kbochert at ix.netcom.com wrote:
> -------Phoenix-Boundary-07081998-
> Content-type: text/plain; charset=ISO-8859-1
> Content-transfer-encoding: 8bit
>
> Hi Derek Parnell, you wrote on 3/20/02 7:41:44 PM:
>
>
> >I think that the primary reason for wanting to initialise variables when
> >they are being
> >declared is
> >simply because it is convenient and reduces the chance of forgetting to
> >do
> >it. The current
> >syntax
> >for doing this only works outside of routines:
> >
> > integer x x = 5
> > integer y y = 6
> >
> >the argument is that this is not a particularly pretty solution. For
> >example:
> >
> > integer CustomerResidentialAddressIndex CustomerResidentialAddressIndex
> >= 1
> > integer CustomerMailingAddressIndex CustomerMailingAddressIndex = 1
> >
>
> My ?favorite? example of this kind of redundancy is something like:
>
> CustomerResidentialAddressIndices =
> CustomerResidentialAddressIndices[2..
> length (CustomerResidentialAddressIndices)]
>
> An earlier fix I tried allowed the oddball syntax:
>
> @foo[2..]
>
> to be equivalent of:
>
> foo = foo[2..length(foo)]
>
>
> >Why not? It is inconsistent behaviour. I suggest it has been done this
> >way just so that writing the interpreter was easier for RDS.
> > I can not think of any other reason yet.
>
> I think that the only reason for this can be because Rob wants it
> that way.
> It took me 2 months to add a dozen 'enhancements' to Eu, and most
> of them were very easy once I understood the code sufficiently.
> You have got to believe that Rob could add these features in a
> week (maybe a month, with extensive testing).
>
> >
> >But real problem is the *initialisation* of variables
> >and run-time control of that initialisation,
> >Travis, in his article, explains the real problem,
> >solved in Euphoria, not a problem of some individual taste.
> >
>
> I know its been here before, but could someone point me to this
> article again?
>
>
> >> > > 2) No support of call by reference. I understand that call
> >> > > by reference can lead to unexpected side-effects, but since
> >> > > changing global variables in a subroutine seems to
> >> > > essentially cause the same problem, I don't understand this
> >> > > omission.
>
> As near as I can see, Pass By Reference involves a 'deep' change
> to the language. Every modification to every passed variable
> must check if the variable is a reference. This single extra
> check would noticeably slow down all programs, violating a
> prime design goal of Eu.
> I partially implemented PBR and was surprised to find that
> it slowed any program that did not use it extensively by
> 10-15%.
>
>
> Karl Bochert
>
>
> -------Phoenix-Boundary-07081998---
>
9. RE: A question about certain language features
- Posted by bensler at mail.com
Mar 21, 2002
> I know its been here before, but could someone point me to this
> article again?
http://www25.brinkster.com/tbeaty/pds/utopia.htm
Chris
10. RE: A question about certain language features
- Posted by bensler at mail.com
Mar 21, 2002
> As near as I can see, Pass By Reference involves a 'deep' change
> to the language. Every modification to every passed variable
> must check if the variable is a reference. This single extra
> check would noticeably slow down all programs, violating a
> prime design goal of Eu.
> I partially implemented PBR and was surprised to find that
> it slowed any program that did not use it extensively by
> 10-15%.
With your implementation, it is nessecary to perform checks everytime a
PBR variable is expressed.
If the PBR is declared when the paramter is declared, instead of when
it's accessed, then those checks can be eliminated.
As a solution to the difficulty discerning between PBR and PBV, PBR's
should be modified through special routines. This would help
readability, because people would know when they see the assignment,
that it is PBR, and not a PBV.
Something like: set_var(arg,get_var(arg)+10)
I think this is the main reason for any confusion between PBV and PBR.
Yeah, it aint pretty, but I don't think it's possible to make PBR
esthetically pleasing and still keep all the functionality.
Only routines would allow for PBR. Wouldn't the routine be optimised by
the interpreter during parsing? Each routine is read in before it's
executed. It's not inline code. I don't see the need to have any checks
at runtime.
Personally, I am not enthusiastic to see EU with PBR. I suggested PBR
before as a solution to being able to modify variables in type defines
ONLY. No PBR for other routines. If you want PBR in a regular routine,
declare it as a function and pass the modified variables as the result.
You can't do that with type defines.
Chris
11. RE: A question about certain language features
-------Phoenix-Boundary-07081998-
You wrote on 3/21/02 10:54:37 AM:
>Karl,
>
> Consider this syntax for shorthand slicing. Your current syntax sort
>of defeats the sequence bounds checking.
>
>seq[1..0] -- seq[1..length(seq)]
>seq[1..0-1] -- seq[1..length(seq)-1]
>
>seq[1..1-1] -- {} (reverse slice)
>seq[1..-1] -- index [-1] out of bounds
>
>integer index index=0
>seq[1..index] -- {} (reverse slice)
>
>'O' is explicit, it cannot be implied. If it is, the original EU rules
>apply.
>
>I haven't thouroughly looked. Does your shorthand work if it's implied
>with a variable?
>
>
>Chris
I handle 'foo[2..]' by expanding it textually. I think of it
as a macro.
when I see the '..' followed by a ']' or '-', I insert the text
'length(foo)' directly into the input stream. (Having previously
saved the 'foo').
'foo[2..]' causes the interpreter to actually see 'foo[2..length(foo)]'
and 'foo[2..-(a*b)]' is seen as 'foo[2..length(foo)-(a*b)]'
As a result, all the normal Euphoria processing is left intact.
Thanks for the link
Karl Bochert
-------Phoenix-Boundary-07081998---
12. RE: A question about certain language features
- Posted by bensler at mail.com
Mar 21, 2002
Your syntax, and the form that I am suggesting are virtually identical.
The difference is in readability, and ease of implementation.
Compare:
foo[1..] == foo[1..length(foo)]
foo[1..-1] == foo[1..length(foo)-1]
foo[1..0] == foo[1..length(foo)]
foo[1..0-1]== foo[1..length(foo)-1]
Your implementation requires 2 checks for substitution.
My suggestion is to simply subtitute the literal '0' with length(foo)
foo[1..] could just be a typo.
foo[1..0] is defined explicity.
Yes, my example could be a typo also, but not as likely to happen.
foo[1..-1] the negative could be fairly easily missed.
foo[1..0-1] knowing that the literal '0' is always substituted with
length(foo), it's easy to see the intention.
To summarize, your implementation adds two new rules, whereas my
suggestion only adds one.
The concepts are identical, but the representation is different.
Chris
kbochert at ix.netcom.com wrote:
> -------Phoenix-Boundary-07081998-
> Content-type: text/plain; charset=ISO-8859-1
> Content-transfer-encoding: 8bit
>
> You wrote on 3/21/02 10:54:37 AM:
>
> >Karl,
> >
> > Consider this syntax for shorthand slicing. Your current syntax sort
> >of defeats the sequence bounds checking.
> >
> >seq[1..0] -- seq[1..length(seq)]
> >seq[1..0-1] -- seq[1..length(seq)-1]
> >
> >seq[1..1-1] -- {} (reverse slice)
> >seq[1..-1] -- index [-1] out of bounds
> >
> >integer index index=0
> >seq[1..index] -- {} (reverse slice)
> >
> >'O' is explicit, it cannot be implied. If it is, the original EU rules
> >apply.
> >
> >I haven't thouroughly looked. Does your shorthand work if it's implied
> >with a variable?
> >
> >
> >Chris
>
> I handle 'foo[2..]' by expanding it textually. I think of it
> as a macro.
>
> when I see the '..' followed by a ']' or '-', I insert the text
> 'length(foo)' directly into the input stream. (Having previously
> saved the 'foo').
> 'foo[2..]' causes the interpreter to actually see 'foo[2..length(foo)]'
> and 'foo[2..-(a*b)]' is seen as 'foo[2..length(foo)-(a*b)]'
>
>
> As a result, all the normal Euphoria processing is left intact.
>
> Thanks for the link
> Karl Bochert
>
>
> -------Phoenix-Boundary-07081998---
>
13. RE: A question about certain language features
- Posted by bensler at mail.com
Mar 21, 2002
My suggestions are just that, suggestions :)
I prefer a symbol.
Chris
Derek Parnell wrote:
> Chris,
> I see we are thinking alike here. I suggested the '$' symbol because
> that is
> often used in regular expression syntax to mean the end-of something.
> The
> symbol '0' could also be a coding mistake, but I would think a rare one
> (eg.
> I miskeyed the '9'). Also, it doesn't seem to be associated with
> "end-of",
> except maybe a count-down by NASA.
>
> a = foo[2..0] -- is what I keyed,
> a = foo[2..9] -- but this is what I meant.
> -------
> Derek
>
>
> ----- Original Message -----
> From: <bensler at mail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Friday, March 22, 2002 8:00 AM
> Subject: RE: A question about certain language features
>
>
> > Your syntax, and the form that I am suggesting are virtually identical.
> > The difference is in readability, and ease of implementation.
> > Compare:
> > foo[1..] == foo[1..length(foo)]
> > foo[1..-1] == foo[1..length(foo)-1]
> >
> > foo[1..0] == foo[1..length(foo)]
> > foo[1..0-1]== foo[1..length(foo)-1]
> >
> > Your implementation requires 2 checks for substitution.
> > My suggestion is to simply subtitute the literal '0' with length(foo)
> >
> > foo[1..] could just be a typo.
> > foo[1..0] is defined explicity.
> >
> > Yes, my example could be a typo also, but not as likely to happen.
> >
> > foo[1..-1] the negative could be fairly easily missed.
> > foo[1..0-1] knowing that the literal '0' is always substituted with
> > length(foo), it's easy to see the intention.
> >
> >
> > To summarize, your implementation adds two new rules, whereas my
> > suggestion only adds one.
> > The concepts are identical, but the representation is different.
> >
> >
> > Chris
> >
> > kbochert at ix.netcom.com wrote:
> > > -------Phoenix-Boundary-07081998-
> > > Content-type: text/plain; charset=ISO-8859-1
> > > Content-transfer-encoding: 8bit
> > >
> > > You wrote on 3/21/02 10:54:37 AM:
> > >
> > > >Karl,
> > > >
> > > > Consider this syntax for shorthand slicing. Your current syntax sort
> > > >of defeats the sequence bounds checking.
> > > >
> > > >seq[1..0] -- seq[1..length(seq)]
> > > >seq[1..0-1] -- seq[1..length(seq)-1]
> > > >
> > > >seq[1..1-1] -- {} (reverse slice)
> > > >seq[1..-1] -- index [-1] out of bounds
> > > >
> > > >integer index index=0
> > > >seq[1..index] -- {} (reverse slice)
> > > >
> > > >'O' is explicit, it cannot be implied. If it is, the original EU rules
> > > >apply.
> > > >
> > > >I haven't thouroughly looked. Does your shorthand work if it's implied
> > > >with a variable?
> > > >
> > > >
> > > >Chris
> > >
> > > I handle 'foo[2..]' by expanding it textually. I think of it
> > > as a macro.
> > >
> > > when I see the '..' followed by a ']' or '-', I insert the text
> > > 'length(foo)' directly into the input stream. (Having previously
> > > saved the 'foo').
> > > 'foo[2..]' causes the interpreter to actually see 'foo[2..length(foo)]'
> > > and 'foo[2..-(a*b)]' is seen as 'foo[2..length(foo)-(a*b)]'
> > >
> > >
> > > As a result, all the normal Euphoria processing is left intact.
> > >
> > > Thanks for the link
> > > Karl Bochert
> > >
> > >
<snip>
14. RE: A question about certain language features
-------Phoenix-Boundary-07081998-
Chris wrote on 3/21/02 11:18:34 AM:
>
>With your implementation, it is nessecary to perform checks everytime a
>PBR variable is expressed.
>
>If the PBR is declared when the paramter is declared, instead of when
>it's accessed, then those checks can be eliminated.
>
The checks I am referring to are those that take place at runtime.
The assignment operation, for example must check at runtime to see if
its arguments are appropriate, and to chose the method to implement
the operation. Rob has done an absolutely amazing job of accomplishing
this in a minimum of machine cycles; unfortunately that means that
ANY change is a substantial hit on performance.
Adding a reference type entails creating a new basic type to Eu, which
in turn requires changes to the input scanning, the parsing, the runtime
handling of a number of operators, the memory allocation and garbage
collection. As I said, deep changes.
The way I implemented PBR was an attempt to get around these problems,
but the result was not a general solution. It only worked for modification
of the elements of a sequence, assignment or other modification of
the sequence as a whole caused reversion to PBV.
This partial solution may still prove useful for structures and classes,
whose structure should not be changeable anyway.
>As a solution to the difficulty discerning between PBR and PBV, PBR's
>should be modified through special routines. This would help
>readability, because people would know when they see the assignment,
>that it is PBR, and not a PBV.
>Something like: set_var(arg,get_var(arg)+10)
>
>I think this is the main reason for any confusion between PBV and PBR.
>
>Yeah, it aint pretty, but I don't think it's possible to make PBR
>esthetically pleasing and still keep all the functionality.
>
This might be possible, but you are right about its beauty.
Might be useful for porting Basic into EU?
>Only routines would allow for PBR. Wouldn't the routine be optimised by
>the interpreter during parsing? Each routine is read in before it's
>executed. It's not inline code. I don't see the need to have any checks
>at runtime.
What about 'foo(s[2])'? What is it sending to foo()?
Can't tell at compile-time.
>
>Personally, I am not enthusiastic to see EU with PBR. I suggested PBR
>before as a solution to being able to modify variables in type defines
>ONLY. No PBR for other routines. If you want PBR in a regular routine,
>declare it as a function and pass the modified variables as the result.
>You can't do that with type defines.
>
I see two reasons for PBR:
1) A tool exposed to the programmer to assist in porting other
languages to Eu.
2) A hidden capability used internally to implement structures (sequences
with imutable structure) and classes (structures with methods)
-------Phoenix-Boundary-07081998---
15. RE: A question about certain language features
- Posted by bensler at mail.com
Mar 22, 2002
While it is possible to write foo[1..0], I'd be baffled to see it in
someone's code. You could easily write {} or "" instead.
The entire implementation of shorthand slicing breaks down to 1 item:
length(s)
My logic is that '0' is the only element not currently usable, so
naturally it should be used to represent the length of s (not 'end of
sequence').
Imagine a sequence s, in EU's memory with a length of 5.
I know this isn't how sequences work, but looking from the outside,
in...
s[5][1][2][3][4][5]
0 1 2 3 4 5
When you break it down to the single factor: length(s),
s[0] makes plenty of sense to me.
When I was writing EUPP, I tossed around the idea of using a symbol
instead of '0' for the same reason that Derek said, it's prone to being
typed unintentionally. When I tried other symbols, I felt like I was
having to learn something new, whereas it seemed natural to use '0'. I
also found that '0' was easier for me to discern than other symbols.
I was also not enthusiastic about introducing a new symbol where an
existing symbol would work and seemed natural.
I tried using no symbol, and was distraught with the lack of
readability. The symbols serve as separators as well as designators.
without the end symbol, or without the start symbol, it was hard to tell
where one slice ended and another began. The time spent trying to read
the code outwieghed the time spent writing it.
The best alternative to '0' that I came up with was '?'. It's the most
readable symbol that can be used, it doesn't add any new symbols to the
language, and it goes with the shorthand already implemented for
print().
Instead of thinking of ? as a shorthand for print(), it would instead be
thought of as just a shorthand. I suspect there are other places in EU's
syntax where this could be put to use as well.
To add to the benefit of using ? we could have:
?? as a shorthand for printing strings
I don't particularly care what symbol is used, but I think there are
benefits to one over another. I know Derek's point, and the logic to
using '0' is fairly obscure :P
That's why I suggest ? instead.
Someone might argue that ? is already used as a symbol in EU. Only in
one specific case, and it's barely utilized. I'd rather have an old dog
with a new trick, than a new dog with a new trick. Instead of 2 dogs
with two tricks, I have one dog with 2 tricks.
I've noticed that people have the mindset of the symbol representing the
'END' of the sequence. I prefer to think of the symbol as representing
the 'LENGTH' of the sequence. Just semantics, but it makes more sense to
me, seeing as we are only talking about the outer dimension of a
sequence, and the actual code that would be replaced is length().
Chris
Mike Nelson wrote:
> foo[1..0] is already a legal (null) slice, using it to mean length(foo)
> will
> break existing code. Perhaps a better scheme would be using -1 for the
> end
> of the sequence. This is also fairly intuitive:
>
> foo[1..3] means the first thru third elements conting from the
> beginning,
> and
> foo[-3..-1] would mean the third thru first elements counting from the
> end.
>
> also something like foo[2..-2] would be legal (this would return the
> sequence minus the first and last element)
>
> Internally a negative slice would be converted like this:
>
> foo[-3..-1] becomes foo[length(foo)+1-3,length(foo)=1-1] which can be
> simplifed in this case to foo[length(foo)-2..length(foo)]
>
> Of course, the same negative indexing should apply to subscripts, where
> it
> is even more intuitive:
>
> foo[4] is the fouth element form the beginning, foo[-4] is the fourth
> element from the end.
>
> -- Mike Nelson
>
>
