1. More feature requests, or is it syntax?
I haven't touched Pascal for... several weeks now. I am
writing a text parser in Euphoria, and hitting upon the
same syntactic quirks, time and again.
1. No local constants. Often I have a need for constants
local to a function or procedure. Sure, there is a
way around it: declare them in an "include" file, but
that is a kludge.
2. I find myself having to initialize a large number of
local variables by hand. An extension of the syntax
of declarations like this would be wonderful:
atom posSubject=0, posVerb=0, posObject=0
sequence subject="", clause={}
3. This is half-baked, but... it's function versus procedure
again. I find myself writing:
dic=dicAddItem(dic,thisWord)
It gets rather intricate (and tedious) when a function
modifying the dictionary calls another modifying the
same dictionary which calls... you know.
In fact, there are two types of procedures and of functions
in Euphoria: I/O functions and the rest, I/O procedures and
the rest.
In I/O functions and procedures *only* the first parameter is
called by reference (file open in "write" or "update" mode),
or by value (file open in "read" mode). The rest are always
called by values.
In other functions and procedures, ALL parameters are called
by value, including the first.
Would it not be better to generalize to all functions and
procedures this distinction which applies only to I/O?
How to do it best syntactically, I don't know. Me, I'd
merely use square brackets when parameters are passed by
reference, and parentheses when they're passed by value.
So that the same function/procedure identifier can serve
both ways. I'd advocate having only the *first* parameter
passable by reference, too (I feel that this limitation is
a GREAT bug-squasher).
Frogguy (a.k.a. the other Jacques)
2. Re: More feature requests, or is it syntax?
Jacques Guy wrote:
> initialize a large number of local variables by hand.
For a language the *requires* that variables be initialized before use, =
I always though not allowing declaration during initialization rather =
odd and occasionally irritating.
I'd love to have it.
> dic=3DdicAddItem(dic,thisWord)
I almost always end up assigning a global variable in these instances, =
and calling a procedure like:
dicAddItem( thisWord )
I've almost gotten used to only passing by value, but it's a hard habit =
to break. But somewhere in my heart, I suspect the discipline of doing =
without passing by reference is a Good Thing, and makes my code better.
> *only* the first parameter is called by reference
Yeah, there are many times when I've written something using the form:
variable =3D function( variable, value )
such as:
a =3D a + 1
s =3D append( s, "foo" )
dictionary =3D addDictionary( dictionary, word )
when I've wondered if there were a better syntax for it. In PP, there =
are a number of tools, similar to the +=3D in C:
a =3D+ 1 -- a =3D a + 1
s =3Da "foo" -- s =3D append( s, "foo" )
s =3D& "foo" -- s =3D s & "foo"
but they've always struck me as too C-like (read: terse and cryptic) to =
be acceptable. I've played with a number of syntax options with PP in =
mind, such as:
dictionary =3D addDictionary( self, "foo" )
or in the other direction:
self =3D addDictionary( [dictionary], "foo" )
Here, the [braces] make it easier to parse the value of 'self'); or even =
just:
self =3D addDictionary( dictionary, "foo" )
where the first argument of the function is assumed to be the value of =
'self'.
These would work for a program like PP, or macro expansion. The 'self' =
keyword isn't half bad, but it lacks the kind of inspired elegance I'd =
like to see in a solution.=20
Even worse is the the proc_id version:
dictionary =3D self( "addDictionary", { "foo" } )
Be afraid.=20
I'd love to see a suggestion where this syntax was handled elegantly, =
without passing by reference. As it stands, the cure seems much worse =
than the disease.
-- David Cuny
3. Re: More feature requests, or is it syntax?
David Cuny wrote:
> > dic=dicAddItem(dic,thisWord)
> I almost always end up assigning a global variable in these instances, and
^^^^^^ AAARRGGGHHH!
>calling a procedure like:
> dicAddItem( thisWord )
Despite my AAARRRGGGHHH, yes, and I am sorely tempted to do so, but that
destroys everything, we're nearly back to the dark old days of
everything
global.
> Yeah, there are many times when I've written something using the form:
> variable = function( variable, value )
> when I've wondered if there were a better syntax for it. In PP, there are a nu
mber of tools, > similar to the += in C:
> a =+ 1 -- a = a + 1
> s =a "foo" -- s = append( s, "foo" )
> s =& "foo" -- s = s & "foo"
Dirty kludges. "Dirty" and "kludges" because they cater only for
particular
cases. If you really want that, then the syntax should be general, for
instance, if we accept +=, /= etc. which means:
<var 1> <operator>=<var 2>
is shorthand for:
<var 1> = <var 1><operator><var 2>
Then we should have:
s append="foo"
dic addWord="foo"
But that is horrible. The meaning is not evident at all. It is
a perversion of syntax (to me, syntax should be reader-friendly)
> dictionary = addDictionary( self, "foo" )
I had proposed that in an earlier post, not knowing that you had had
the same idea.
> or in the other direction:
> self = addDictionary( [dictionary], "foo" )
No, because you don't know what "self" is straight away, you have to
wait
until you encounter "[dictionary]"
> Even worse is the the proc_id version:
> dictionary = self( "addDictionary", { "foo" } )
That is horrible. I can't make head or tail of it. Terribly
anti-intuitive.
> I'd love to see a suggestion where this syntax was handled elegantly,
> without passing by reference. As it stands, the cure seems much worse than the
disease.
Well, let me think aloud... That would involve regularizing I/O. That
means that
there would be not procedures at all any longer, only functions. Do we
want that?
A function is really a shortcut, so that you can use its value without
having
to assign it to an intermediate variable. So functions ARE useful, but
they are
shortcuts for procedures. It seems the procedure is fundamental, and
that we
must allow for procedures which modify at least ONE parameter, just like
I/O procedures do. My idea of using square brackets [] instead of () was
silly, as it leads to ambiguities with sequences. Further, it was
completely
stupid because a procedure with () would do absolutely nothing, all of
its
parameters being passed by value! So, this leads to this simple
solution:
the first parameter of a function is passed by reference, all the rest
by
value. E.g.:
inc(i,10)
dicAdd(dic,"foo")
(I have a further idea, but I'll keep it under my hat for the time
being)
Frogguy (a.k.a. the other Jacques)
