Talk:Type detection

Hi, Is this the start of a draft task? --Paddy3118 (talk) 12:57, 7 October 2015 (UTC)

1. Questions: Is type detection itself a task ? What problem might I be trying to solve by detecting a type (at run-time) in the compiled version of a statically typed language ? Are you, for some reason, thinking of a class of problems which can't be solved in terms of an untyped lambda calculus ? If so, what are they ? Does this sound like a Rosetta task (the value of which is that languages turn out to be unexpectedly similar beneath the surface, if you set them all to the same task) ? Or is it a stamp-collector, list-maker or grammatical librarian's task (simply absorbed in the cataloguing of notational differences) ?
2. Thoughts: The message of Rosetta is that you get deep insights when different languages are coming at the same non-linguistic task from their own distinctive angles, rather than each trying to jump through contrived grammatical or notational hoops. There may well be interesting and genuine problems to which solutions can be found by making use of the notion of type, but I think the way to find them will be to step back from particular (and perhaps parochial) problems encountered within scripting (and other dynamically typed) languages, and to think a bit more deeply about what type systems are good for, and why they are there.

A task to which Miranda, Haskell or OCaml users might respond by saying not really relevant, doesn't really arise outside the REPL or doesn't arise at all, would probably be too superficial, and a bit of a waste of potential for insight and comparison.

In short – what is the concrete problem (outside the language) for which the solutions may include branching on types  ? What is the actual task ? How would you frame it so that it scored well as a Rosetta task in terms of the 3 values formulated on the landing page:

1. Likely to harvest responses from as many different languages as possible
2. Designed to demonstrate how languages are similar and different, and to
3. Aid a person with a grounding in one approach to a problem in learning another

? Hout (talk) 17:47, 7 October 2015 (UTC)

PS There are some existing tasks, like list flattening (http://rosettacode.org/wiki/Flatten_a_list) which already demonstrate type-conditional divergence of evaluation or flow. Perhaps "type detection", however, would either be too parochial (or simply misleading) as a description of what is happening in, for example, pattern matching. Hout (talk) 18:14, 7 October 2015 (UTC)

Spam attempt ?

I notice that www.BugMeNot.com provides a login-control evasion service, by sharing ersatz login credentials.

Would a bone fide editor make use of such a service ? The choice of lowest common denominator language, and the invitation to facile documentation consultation entries, rather than actual tasks, might conceivably be an attempt to set up pages which attracted instant content, in preparation for launching spam from a context which might delay deletion.

Perhaps the user(s) of these shared BugMeNot credentials would like to allay our suspicions ? Hout (talk) 13:39, 8 October 2015 (UTC)

Delete?

I am thinking of deleting this task after 09-Oct-2015 due to the lack of credibility of the creator account. --Paddy3118 (talk) 15:08, 8 October 2015 (UTC)

I agree – that seems sensible, unless they can give a proper account of themselves Hout (talk) 15:17, 8 October 2015 (UTC)

Could the draft description be coaxed into something useful ?

As Craigd has taken the trouble to start thinking about a task description, perhaps we should try to see if a spark of spam can indeed be coaxed into life as a useful task ?

Using a quick checklist of Rosetta values (copied from from the landing-page formulation), a good task with

1. Lend itself well to solutions to in as many different languages as possible

2. demonstrate how languages are similar and different

3. aid a person with a grounding in one approach to a problem in learning another

Good scope for alternative approaches and the maximum number of languages is best served by the principle of Task focus, which is specified on the Add a Task page.

Broadly, tasks from the world outside computer languages, which make no assumptions about particular models of computing, yield better insight and deeper comparisons. The value of the Rosetta stone was that 3 very different languages were dealing with the same external (non-linguistic) task.

Given that, the text processing context sounds promising, and should probably be more focal than a framing like "Show a function/procedure which … . Perhaps for example, (thinking about Goal 1 above) that is not quite how a declarative language would be used. Better to make no assumptions about language-internal issues, and to frame the task itself.

On Goals 2 and 3 (demonstrate how languages are similar and different, & learning another approach) you would need to allow for the differences such as, for example, that between run-time "Type detection" and compiler-driven pattern-matching. Framing it too tightly in terms of "type detection" assumptions would marginalise some languages and miss the scope for comparing different approaches.

Finally on the learning aspect of Goal 3, it would clearly be good to find a task which learners are quite likely to actually encounter and think about

( It may also be worth looking at some existing tasks which already demonstrate type-conditional evaluation or flow – flattening lists, for example – just to check that something more focused is really required ) Hout (talk) 18:34, 9 October 2015 (UTC)