Ovidiu Predescu wrote:
>
> > > On Thu, 28 Feb 2002 16:12:14 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> >
> > No, you didn't get my point: I totally agree that reduced verbosity is a
> > good thing for people that are used to a language, but I believe that
> > implicit behavior (means 'nothing to indicate the behavior, not even a
> > single character') is to avoid.
> >
> > In the expression a ? b : c there is nothing implicit since it's the
> > exact equivalent of
> >
> > if (a) { b } else { c }
> >
> > which is admittedly more verbose, but for
> >
> > function my_func(a,b) {
> > var c = { (a > b) ? a : b };
> > }
> >
> > there is *nothing* that tells us that something is returned from that
> > expression. This is what I don't like because I think that every
> > implicit syntactic construct makes a language harder to learn and to
> > maintenance costs much higher, despite the reduced verbosity.
> >
> > if you think 'return' is too verbose, you can have something like
> >
> > function my_func(a,b) {
> > <--[ (a > b) ? a : b ];
> > }
> >
> > indicating that the result of the <--[*] expression 'exists' (thus the
> > arrow pointing to the outside) the function. Just an example to show you
> > a very compact syntax that doesn't sacrifice explicit-ness.
>
> OK, I think I understand your point.
>
> What I'm saying is that there two ways to write the code. You can use
> the explicit return, in case the verbosity is clearer than the concise
> version. This means that in large functions most likely people
> will use return to exit from the function.
>
> Also what I'm saying is that you'd want to use an explicit return only
> when the value of the function is meaningfull, usually when the caller
> expects a value to be returned from the function. I all other cases,
> not putting a return in the function will not hurt the program in any
> way. The implicit returned value of the last expression is simply
> ignored.
>
> In Scheme for example there is no notion of explicit return,
> everything is written using functions, 'if' and recursivity. The last
> evaluated expression in a function is returned as the value of the
> function.
>
> For small snippets of code where conciseness is essential however, you
> don't want to use any additional keyword. I actually like 'return' as
> a keyword, no need to invent something else.
Ok, I don't want to be picky on this.
> > > If you think about it, there's no harm in having a block return a
> > > value if you don't use that value. You don't even have to be aware of
> > > the void value. So having the last expression returned by a block of
> > > code is really no problem at all, if you don't use it. And most of the
> > > people will not.
> >
> > It's a much higher concept: having semantical meanings encoded in
> > syntactic implicit properties (such as 'order of appearance') is
> > admittedly harder to read because it triggers two different cognitive
> > flows: one that parses the syntax and one that extracts the implicit
> > properties.
> >
> > Unfortunately, as GUI vs. CLI have shown: explicit properties ('at least
> > I can click around and try') instead of implicit properties ('what the
> > hell do I type now?') create a much lower entry gap. [nothing about
> > 'usability', that's a totally different concept]
>
> The semantic will be clearly explained in the documentation, so as a
> programmer, at least in theory, you should be aware of it. For
> somebody new to the language, it's just a matter of adapting to a new
> language, it's probably just a different way of doing things than what
> he/she is used to.
>
> If this is a problem for them to understand, what will they think of
> continuations, which have a much bigger semantical impact on a
> program? How will they understand that if they're not able to
> understand a simpler concept?
yeah, well, I was just trying to reduce the amount of things they had to
learn.
> > > > > Built-in datatypes are numbers, arrays, dictionaries and function
> > > > > objects. There is a special type 'void', that has a single possible
> > > > > value named 'void'.
> > > >
> > > > What about 'strings', 'dates' and the like?
> > >
> > > Oh, yes, those too ;-) I forgot about them.
> >
> > ok, I would add 'currency', since web-oriented flow languages will sure
> > have to deal with strings, dates and money. And having them explicitly
> > declared in the language might allow us to obtain 'easy' transparent
> > handling (say, automatic money conversion)
> >
> > Are there any other 'first class concepts' that you guys might want to
> > have in a flow language? IDs (as for credit-card numbers) might be
> > another one, even if probably a concept too detailed... ok, your turn
> > people :)
>
> As I already replied in another message, there is no need for these
> built-in data types, if they don't have a direct syntactical
> representation. The language benefits from the large set of Java
> classes underneath, which can be directly used.
I agree.
> > [snipped part in where we resonate completely, well, at least as much as
> > can I resonate with somebody that likes the power of small languages
> > built inside a bigger language :-)]
>
> :-) I hope you'll find the taste for these too.
Not really, but I don't really care that much :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
